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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
