Re: [Haskell-cafe] Haskell Report Infelicity?

27 Oct 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@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