>From http://en.wikipedia.org/wiki/NaN#Encoding :
"The state/value of the remaining bits (i.e. other than the ones used to identify a NaN as NaN, including the quiet/signaled bits) are not defined by the standard except that they must not be all zero. This value is called the 'payload' of the NaN. If an operation has a single NaN input and propagates it to the output, the result NaN's payload should be that of the input NaN. If there are multiple NaN inputs, the result NaN's payload should be from one of the input NaNs; the standard does not specify which." Speaking from the perspective of a potential user of pypy, I would like to advocate strongly against any solution which trades correctness for speed in a way that isn't easily and explicitly controllable by the end user at runtime (I'd point to the CUDA fast math options as examples of this done well: http://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#options-for-steering-cuda-compilation). Running into a situation where custom NaN payloads are in use and having pypy not handle them properly would be incredibly frustrating (and hard to debug, especially since it would be turning something exceptional into something ordinary-looking but incorrect). I would also like to point out that anyone who mixes ints and floats in a list (or anywhere, really) under python 2.7 is asking for trouble. >>> [a / b for a, b in itertools.izip([1, 1, 1.0, 1.0], [2, 2.0, 2, 2.0])] [0, 0.5, 0.5, 0.5] IMHO, It's not a use case worth optimizing for. Thanks for all the hard work! Cheers, Eli On Thu, Nov 14, 2013 at 5:35 AM, Antonio Cuni <anto.c...@gmail.com> wrote: > On 14/11/13 10:57, Armin Rigo wrote: > >> Bah, there is another issue. The following code happens to work right >> now: >> >> x, = struct.unpack("d", "ABCDxx\xff\x7f") >> y = struct.pack("d", x) >> assert y == "ABCDxx\xff\x7f" >> >> This works even though x happens to be a NaN; its bit pattern is >> preserved. Such an x could not be stored into a >> FloatIntegerListStrategy: if it has the wrong bit pattern, we'd get >> the nonsensical result that storing it in a list and reading it back >> gives us suddenly an integer object with a random value... >> >> Unsure what to do about that. > > > I'm tempted to say that this is an implementation detail, although for all I > know there might be some code relying on this. > > If we REALLY want to support this case, we can always have a > W_FloatObjectPreservingTheBits which cannot be put in a > FloatIntegerListStrategy. > W_FloatObjectPresevingTheBits will be created only by operations like > struct.unpack, cffi.cast, etc. > > Not sure if it's worth the pain. > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
