On Wed, 01 May 2013, Nathaniel Smith wrote:
not sure there is anything to fix here. Third-party code relying on a certain outcome of rounding error is likely incorrect anyway.
Yeah, seems to just be the standard floating point indeterminism. Using Matthew's numbers and pure Python floats:
In [9]: (0.49505185 + 0.53529587) + -0.13461665 Out[9]: 0.89573107
In [10]: 0.49505185 + (0.53529587 + -0.13461665) Out[10]: 0.8957310700000001
In [11]: _9 - _10 Out[11]: -1.1102230246251565e-16
Looks like a bug in pymvpa or its test suite to me.
well -- sure thing we will "fix" the unittest to not rely on precise correspondence any longer since released 1.7.1 is effected. So it is not a matter of me avoiding "fixing" pymvpa's "bug". I brought it to your attention because 1. from e.g. np.sum(data[:, 0]) - np.sum(data, axis=0)[0] which presumably should be the same order of additions for 0-th column it is not clear that they do not have to be identical. 2. so far they were identical across many numpy releases 3. they are identical on other architectures (e.g. amd64) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik