glob2-devel
[Top][All Lists]
Advanced

[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: Sun, 02 Apr 2006 20:36:20 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Jumbo Shrimp, linux)

>       1 2 3 4         1. generation line
>     1 3 2 4 5 6               2. generation
>   1 3 2 5 4 6 7 8     3. 
> 1 3 2 5 4 7 6 8 9 10  4.
> The last 3 elements remain in bad order.
> As long as it's only 3 elements it doesn't hurt, but if you have a 20
> fields long line of ressources the last 19 fields remain in bad order.

Ok. I see.

> But perhaps such long lines don't appear often and don't hurt that much.

I will try to confirm this.  It should be simple to measure how long
the longest bad part is each "turn" (gradient decrementation)
or the number of n-long sequences of (horizontal) neighbours in
listedAddr each "turn".

I just want to know how to access the logfiles first.


> In the forbidden gradient you could even just list the fields at the 
> edge of the forbidden zone...
> something like this:
> if (field is forbidden)
> {
>       if (there is a free field next to the current one)
>       {
>               set gradient to 254
>               add the field to the list
>       }
>       else
>               set gradient to 1
> }
> else if (field is free)
>       set gradient to 255
>
> because you usually have more free fields than forbidden ones that
> could be a speedup. It would prevent more fields from being listed than
> your suggestion, but it would be slightly more complex.

nice :-)



>> >> Why is it possible to have so different gradient values in field
>> >> which are in listedAddr?
>> >> I would expect only two values:
>> >> the present one and the present one minus one
>> > erm, I'd expect that too.
>> 
>> I once changed the:
>> 
>> if (g <= 2)
>>    continue;
>> 
>> to:
>> 
>> if (g <= 2)
>>    return;
>> 
>> and got different gradients.
>> Maybe I had changed some other thing too.
>> (but I don't think so.)
> I don't know about all the places which initialize a gradient, but if
> gradients are really initiallized with different values, I think this
> is a bug. (listedAddr would no more be guaranteed to be big enough
> because fields could be listed more than once)

Your right.  I will look into this too.  In fact this is crucial to
define "turn" for my other statistic.

-- 
Kai Antweiler





reply via email to

[Prev in Thread] Current Thread [Next in Thread]