Hi Levent, Thanks for this although it made me feel sad that this has not been resolved in 7 years. I just had a quick look at what OCAML does and they define floor :: Double -> Double (the don’t really but that’s the gist of it). Python, in so far as it is typed, does the same. So NaN can just be passed straight through for the user to deal with (no performance hit). Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com

On 26 Oct 2015, at 20:54, Levent Erkok wrote:

There's an existing ticket about this, filed 7 years ago: https://ghc.haskell.org/trac/ghc/ticket/3070 https://ghc.haskell.org/trac/ghc/ticket/3070

On Mon, Oct 26, 2015 at 1:49 PM, Dominic Steinitz mailto:dominic@steinitz.org> wrote: I have probably misunderstood but is the following expected? floor, round, truncate and ceiling give similar results (all methods of the RealFrac class).

properFraction :: (Integral b, RealFrac a) => a -> (b, a)

*Girsanov> properFraction (-1 / 0) (-17976931348623159077293051907890247336179769789423065727343008115773267 5805500963132708477322407536021120113879871393357658789768814416622492847 4306394741243777678934248654852763022196012460941194530829520850057688381 5068234246288147391311054082723716335051068458629823994724593847971630483 5356329624224137216,0.0) *Girsanov> properFraction (1 / 0) (179769313486231590772930519078902473361797697894230657273430081157732675 8055009631327084773224075360211201138798713933576587897688144166224928474 3063947412437776789342486548527630221960124609411945308295208500576883815 0682342462881473913110540827237163350510684586298239947245938479716304835 356329624224137216,0.0) *Girsanov> properFraction (0 / 0) (-26965397022934738615939577861835371004269654684134598591014512173659901 3708251444699062715983611304031680170819807090036488184653221624933739271 1459592111865666518401372982279144533294018691411791796244281275086532572 2602351369432221086966581124085574502576602687944735992086890771957445725 3034494436336205824,0.0)

The Haskell Report "6.4.6 Coercions and Component Extraction" is silent on what to expect with NaN, Infinity and -Infinity so I think it should be amended. Alternatively, one could expect implementations to throw a runtime error?

In ghc, the problem is here https://phabricator.haskell.org/D160a https://phabricator.haskell.org/D160a

/* This is expected to replace uses of __decodeDouble_2Int() in the long run */ StgInt __decodeDouble_Int64 (StgInt64 *const mantissa, const StgDouble dbl) { if (dbl) { int exp = 0; *mantissa = (StgInt64)scalbn(frexp(dbl, &exp), DBL_MANT_DIG); return exp-DBL_MANT_DIG; } else { *mantissa = 0; return 0; } }

I believe frexp [1] and scalbn [2] both pass through NaN, Infinity and -Infinity and I think type coercion in C is undefined for these values.

Furthermore exp is undefined for these values [1].

1. http://en.cppreference.com/w/cpp/numeric/math/frexp http://en.cppreference.com/w/cpp/numeric/math/frexp 2. http://en.cppreference.com/w/cpp/numeric/math/scalbn http://en.cppreference.com/w/cpp/numeric/math/scalbn

Dominic Steinitz dominic@steinitz.org mailto:dominic@steinitz.org http://idontgetoutmuch.wordpress.com http://idontgetoutmuch.wordpress.com/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe