<div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>Please see attached patch which fixes rather peculiar "feature" of GiNaC - non-determinism.<br></div><br>One can think of many arguments why non-determinism of CAS is a bad idea. Shortly speaking, it is simply unacceptable. Especially when there is no good reason for it (and I can hardly think of a good reason anyway).<br>
<br></div>At the moment GiNaC relies on OS-assigned memory addresses of type-names to define its term-ordering, which results in different output from the same program. When this bug was brought up in the mailing list (several times) the developers called it a "design decision".<br>
<br></div>Well, it is time to stop the insanity. The attached patch fixes the bug at zero cost to the performance.<br></div>Here are the results of "/usr/bin/time make check" (second run with pre-warmed caches)<br>
</div>unpatched non-deterministic: 132.57 s<br></div>fixed deterministic: 132.62 s<br><div><div><div><div><div><br></div><div>Keep in mind that it wouldn't make GiNaC canonical ordering entirely predictable, since it still depends on the order of symbol declaration and such (btw, fixing that wouldn't be too hard either). But at least for the same program and compiler the result must be identical.<br>
<br></div><div>PS I added FNV1a hash, one could just keep using crc32 which is already there. It makes no difference since the hash function is now called only once for each type (before it was called for every object).<br>
<br></div><div>PPS I'm attaching patches against master and release_1-6-2 since I hope that developers recognize it as a bug and update stable releases as well.<br></div><div><br clear="all"><div><div><div><div><div><div>
<div>With best regards, Valery Yundin.</div>
</div>
</div></div></div></div></div></div></div></div></div></div></div>