On Sat, Oct 15, 2011 at 1:12 PM, Matthew Brett <matthew.br...@gmail.com>wrote:
> Hi, > > Continuing the exploration of float128 - can anyone explain this behavior? > > >>> np.float64(9223372036854775808.0) == 9223372036854775808L > True > >>> np.float128(9223372036854775808.0) == 9223372036854775808L > False > >>> int(np.float128(9223372036854775808.0)) == 9223372036854775808L > True > >>> np.round(np.float128(9223372036854775808.0)) == > np.float128(9223372036854775808.0) > True > > I know little about numpy internals, but while fiddling with this, I noticed a possible clue: >>> np.float128(9223372036854775808.0) == 9223372036854775808L False >>> np.float128(4611686018427387904.0) == 4611686018427387904L True >>> np.float128(9223372036854775808.0) - 9223372036854775808L Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'numpy.float128' and 'long' >>> np.float128(4611686018427387904.0) - 4611686018427387904L 0.0 My speculation - 9223372036854775808L is the first integer that is too big to fit into a signed 64 bit integer. Python is OK with this but that means it must be containing that value in some more complicated object. Since you don't get the type error between float64() and long: >>> np.float64(9223372036854775808.0) - 9223372036854775808L 0.0 Maybe there are some unimplemented pieces in numpy for dealing with operations between float128 and python "arbitrary longs"? I could see the == test just producing false in that case, because it defaults back to some object equality test which isn't actually looking at the numbers. Aronne
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion