toRational should error out on NaN and Infinity values for Double/Floats
The current implementation of toRational
for Float
/Double
types accept NaN
and Infinity
values and produce results. For Infinity
the result nicely maps back to Infinity
:
Prelude> fromRational (toRational (1/0)) :: Double
Infinity
Prelude> fromRational (toRational (-1/0)) :: Double
-Infinity
Prelude>
But the same isn't true for NaNs:
Prelude> fromRational (toRational (0/0)) :: Double
-Infinity
Also, these results are probably architecture specific.
In any case, I think toRational
should simply error out if it receives NaN
or Infinity
, as there are really no legitimate values we can map them to, even though we might be able to complete the round-trip correctly in case if infinities. The following just doesn't make sense:
Prelude> toRational (1/0)
179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1
So, I propose the toRational
instance for Float/Double's should simply recognize NaN
and Infinite
values and throw an error.
[Note that this is also how the HW implementations for the corresponding conversions work, raising a floating-point-exception (in the unmasked case). See CVTPS2PI
/CVTPS2DQ
etc., for instance, in x86.]
Trac metadata
Trac field | Value |
---|---|
Version | 7.10.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |