Re: [glob2-devel] gradient improvement

[Kai Antweiler]

> Check the last CVS for latest updateGlobalGradientVersionSimple().
>
> We found out that this listedAddr[] smashing is more than unlikely to happen.

That's good to hear.

> 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.

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";




> 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.


> 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.

Simplicity is ok, but I favor clever code and lots of 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.

-- 
Kai Antweiler