Opened 4 years ago

Closed 4 years ago

Last modified 22 months ago

#10754 closed bug (duplicate)

truncate /= double2Int

Reported by: cblp Owned by:
Priority: normal Milestone:
Component: libraries/base Version: 7.10.2
Keywords: truncate, double2Int, rewrite, rule Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


There is a rule in libraries/base/GHC/Float.hs:

"truncate/Double->Int"  truncate = double2Int

But it is not true for some values. Particularly,

let infinity = 1/0 :: Double
truncate infinity :: Int == 0
double2Int infinity == -9223372036854775808  -- minBound

As a result, the value of truncate (1/0 :: Double) :: Int depends on optimization level.

Change History (7)

comment:1 Changed 4 years ago by bgamari

One could even argue here that neither answer is in fact correct in light of the description of truncate,

truncate x returns the integer nearest x between zero and x

In this case truncate infinity should be maxBound :: Int, no?

comment:2 Changed 4 years ago by cblp

Infinity is not representable in Int. Maybe maxBound is the closest answer, and they both must return maxBound, maybe they both must throw an exception. I don't know the precise answer.

But I know they must return the same value, or it must be documented as undefined behaviour. Currently this rule is invalid.

comment:3 Changed 4 years ago by cblp

Speaking mathematically, yes, as 1/0 is actually +infinity, nearest Int is maxBound, and for (-1/0) the nearest Int is minBound.

But what is the correct answer for truncate (1/0) :: Integer? Now it is 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216.

comment:4 Changed 4 years ago by rwbarton

Resolution: duplicate
Status: newclosed

Essentially a duplicate of #3070. Feel free to continue the discussion there.

comment:5 Changed 4 years ago by cblp

rwbarton, I don't consider this a duplicate of #3070. That is about the value of NaN, but this is about consistency-breaking optimization.

comment:6 Changed 4 years ago by rwbarton

While not exactly identical, the issues here and in #3070 are so closely related that any attempt to address one should also take the other into consideration. So, it's more helpful if the discussion is consolidated into one ticket thread.

Certainly we would not give up the rule truncate = double2Int simply because the two sides give different nonsense outputs for the same nonsense input.

comment:7 Changed 22 months ago by cblp

I don't think you can consider Infinity a nonsense because it is a valid IEEE 754 value.

Note: See TracTickets for help on using tickets.