Dominic Steinitz dominic at steinitz.org
Tue Oct 27 09:38:01 UTC 2015

```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 at steinitz.org
http://idontgetoutmuch.wordpress.com

> On 26 Oct 2015, at 20:54, Levent Erkok <erkokl at gmail.com> wrote:
>
>
> On Mon, Oct 26, 2015 at 1:49 PM, Dominic Steinitz <dominic at steinitz.org <mailto:dominic at 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?
>
>
> /* 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 at steinitz.org <mailto:dominic at steinitz.org>
> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>
>
> _______________________________________________