[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] gradient improvement
From: |
Kai Antweiler |
Subject: |
Re: [glob2-devel] gradient improvement |
Date: |
Thu, 06 Apr 2006 21:41:28 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Jumbo Shrimp, linux) |
>> Yes, but the distance to the nearest resource of two fields in listedAddr
>> can at maximum differ by 1.
>
> Sorry, I don't get what you mean here ?
Ignore this comment. I mixed things up. I don't know the AI code.
> Do you have another suggestion for the fall back ?
For now we are fine. But if we choose to optimize the size, we
should use something like:
After: (line 2280)
while (listCountRead < listCountWrite)
{
Put:
// Check if listedAddr could have an overflow
// The current field can spawn 8 fields at maximum
if(listCountWrite+8>=listCountRead+size)
{
size_t oldsize=size;
FILE *MapLog = globalContainer->logFileManager->getFile\
("Map");
fprintf(MapLog, "changed size to %d, Resource Type: %d\\
n", size, ressourceType);
size>>1;
Tint *listedAddr2 = new Tint[size];
for(int i=0; i<=oldsize; i++)
*listedAddr2[i]=listedAddr[(i+listCountRead)&ol\
dsize];
delete listedAddr;
updateGlobalGradientVersionSimple<Tint>(gradient, liste\
dAddr2, listCountWrite-listCountRead, gradientType);
size<<1;
return;
}
If we make size high enough that the overflow will almost never happen,
the overhead will not worsen the runtime much.
But this handling is not beautiful.
> Which space you want to save?
> I see two things:
> -1- Computing the listedAddr[] of forbidden gradients differently.
> Yes, that's a good idea. Go ahead and test it!
> -2- Reducing the size when we can guess it will not overflow.
> I'm not sure I want this, but if it shows exceptional speedup I'll take it
> into
> account. Go ahead and test it! (again)
I mean both. And I will test both - sometime.
>>>Sounds ok to you ?
> Anyway the worst exploit ever will be the AI to make bad choices at
> long ranges.
I have closed the bug today.
--
Kai Antweiler
- Re: [glob2-devel] gradient improvement, (continued)
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/03
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/03
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/05
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/06
- Re: [glob2-devel] gradient improvement,
Kai Antweiler <=
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/07
- Re: [glob2-devel] gradient improvement, Simon Schuler, 2006/04/05
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/17
- Message not available
- Message not available
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/20
Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/09