
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 /* 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 2. http://en.cppreference.com/w/cpp/numeric/math/scalbn Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com