>>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! _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
