encodeFloat . decodeFloat

(0.0/0.0)

NaN

(uncurry encodeFloat . decodeFloat) (0.0/0.0)

-Infinity

It seems reasonable to expect NaN here.

Trac metadata

Trac field	Value
Version	6.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Prelude
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import core libraries labels

Interesting, I thought we had a very old ticket about this, but I can't seem to find it.

Anyway, I suppose the issue is what the representation of NaN and Infinity should be in the output of decodeFloat. There is no provision for NaN and Infinity in the Haskell definition of encodeFloat and decodeFloat:

The function decodeFloat applied to a real floating-point number returns the significand expressed as an Integer and an appropriately scaled exponent (an Int). If decodeFloat x yields (m,n), then x is equal in value to mbn, where b is the floating-point radix, and furthermore, either m and n are both zero or else bd-1<=m<bd, where d is the value of floatDigits x. encodeFloat performs the inverse of this transformation.

from Section 6.4.6, http://haskell.org/onlinereport/basic.html

mentioned in issue #3174 (closed)

mentioned in issue #3898 (closed)

See also #3174 (closed)

Maybe the right thing is for decodeFloat applied to NaN or Infinity to be an error, rather than silently succeeding with a bogus value.

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

For the particular values which decodeFloat returns for !NaNs (Float and Double), it would be easy to add a test to integer_cbits_encodeType, that would probably even be not too expensive.

However, those functions look a little dubious. Remind me to look at them again some time, maybe there's speed and correctness to be gained.

daniel.is.fischer, perhaps you would like to have another look now?

added Pnormal label

mentioned in merge request !3145

mentioned in issue #18145 (closed)