Re: [glob2-devel] gradient improvement

[Nuage]

>>Anyway I put a test to improve the quality of the gradient if it happen. If 
>>this
>>even happen, the fields closest of the sources will be prioritized. This is
>>because far gradients are more likely to be wrong in such a case, and more
>>likely to be recomputed anyway. So this even increase the chances the gradient
>>to be perfectly right anyway. 
> 
> 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 ? Do you have another suggestion for the
fall back ?


> listCountWrite is never smaller than listCountRead.  You have to
> add: + size
> this is a good place for a errormsg in the unlikely case.
> 
> line 2315:
> 
> if (listCountWrite + 1 != listCountRead + size) 
>    listedAddr[(listCountWrite++)&(size-1)] = deltaAddrC[ci];
> else
>    std::cerr << "updateGlobalGradientVersionSimple: listedAddr Overflow\n";

Hey, thank you, hopefully you did check this one! Code is patched now.


>>I think it's the best if we stick to this size of listedAddr[], and
>>want to keep it simple.
> 
> Ok, but your stats show that there is space we could save.
> At least we should try Simon's init for forbidden gradients.
> It is  not complex, but more complex and beautiful then the
> normal init.

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)


>>Sounds ok to you ?
> 
> If there are no severe consequences and no evil map designer could
> create a map which exploits it - documentation shall be enough.

There may be a demonstrable theory where "size" is big enough, but I don't want
to make it up. Anyway the worst exploit ever will be the AI to make bad choices
at long ranges.


> Simplicity is ok, but I favor clever code and lots of documentation.

Oh, I favor clever code simplicity :D .hopefully you're here to force me to make
up some documentation.


> ps:
> Your comment is partially incorrect:
> even ordered listedAddr can be buggy.
> 
> . . . .   .
> . . . .  .
> . . . . .
> 5 5 5 5 ...
> 9 9 5 5 ...
> 
> is ordered but will cause wrong gradients.

It *may* cause wrong gradient. Allot of listedAddr[] will work fine. But you're
right the comment is inaccurate, so I fixed it too.


Thanks for your awareness!