[pypy-dev] More strategies

Eli Stevens (Gmail) wickedgrey at gmail.com
Thu Nov 14 21:31:05 CET 2013


>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.cuni at 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 at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev


More information about the pypy-dev mailing list