report at bugs
Aug 4, 2012, 11:52 AM
Post #16 of 24
Stefan Krah added the comment:
[issue15544] math.isnan fails with some Decimal NaNs
[In reply to]
Mark Dickinson <report [at] bugs> wrote:
> Looks like we've got two separate issues here, that should probably be
> split into two separate bug reports. The first issue is that
> Decimal.__float__ is brain-dead when it comes to NaNs with payloads;
> I consider that a clear bug, and Steven's patch fixes it nicely for
> the Python version of decimal.
If we are viewing the whole issue in terms of decimal -> float conversion,
I'm not so sure anymore: Not all Decimal payloads have a meaning for floats
(and payloads get lost in the conversion).
On the other hand it doesn't matter since I doubt anyone is using payloads. :)
> The second has to do with finding a nice type-agnostic way of determing
> whether something is a NaN---anyone mind if I open a separate issue for this?
Yes, that should probably be another issue.
> Two questions: (1) What would you think about raising ValueError explicitly
> for the signaling NaN case rather than falling back to the ValueError coming
> from the string-to-float conversion.
If we use your latest rationale for raising in case of Decimal('snan').__float__(),
I think that indeed __float__() should raise like Decimal.to_integral() does
If we are aiming for sNaN support in floats in the long term and at some point
allow carrying over sNaNs from decimal to float, then perhaps the error message
could say that sNaN conversion is currently not supported.
> (2) Should we apply the fix to 2.7 and/or 3.2 as well?
Yes, I think so.
> I'll look at extending Steven's fix to the cdecimal code, unless Stefan
> really wants to do it (which would be fine with me :-).
Please go ahead! For this year, I've seen more than enough of _decimal.c
Python tracker <report [at] bugs>
Python-bugs-list mailing list