[Haskell-cafe] Haskell Report Infelicity?

[Dominic Steinitz]

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:
> 
> 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 <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?
> 
> 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 at steinitz.org <mailto:dominic at steinitz.org>
> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151027/0544049a/attachment.html>