<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Levent,<div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""><div apple-content-edited="true" class="">
<div class="">Dominic Steinitz</div><div class=""><a href="mailto:dominic@steinitz.org" class="">dominic@steinitz.org</a></div><div class=""><a href="http://idontgetoutmuch.wordpress.com" class="">http://idontgetoutmuch.wordpress.com</a></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 26 Oct 2015, at 20:54, Levent Erkok <<a href="mailto:erkokl@gmail.com" class="">erkokl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">There's an existing ticket about this, filed 7 years ago: <a href="https://ghc.haskell.org/trac/ghc/ticket/3070" class="">https://ghc.haskell.org/trac/ghc/ticket/3070</a></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Oct 26, 2015 at 1:49 PM, Dominic Steinitz <span dir="ltr" class=""><<a href="mailto:dominic@steinitz.org" target="_blank" class="">dominic@steinitz.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have probably misunderstood but is the following expected? floor, round, truncate and ceiling give similar results (all methods of the RealFrac class).<br class="">
<br class="">
properFraction :: (Integral b, RealFrac a) => a -> (b, a)<br class="">
<br class="">
*Girsanov> properFraction (-1 / 0)<br class="">
(-17976931348623159077293051907890247336179769789423065727343008115773267<br class="">
5805500963132708477322407536021120113879871393357658789768814416622492847<br class="">
4306394741243777678934248654852763022196012460941194530829520850057688381<br class="">
5068234246288147391311054082723716335051068458629823994724593847971630483<br class="">
5356329624224137216,0.0)<br class="">
*Girsanov> properFraction (1 / 0)<br class="">
(179769313486231590772930519078902473361797697894230657273430081157732675<br class="">
8055009631327084773224075360211201138798713933576587897688144166224928474<br class="">
3063947412437776789342486548527630221960124609411945308295208500576883815<br class="">
0682342462881473913110540827237163350510684586298239947245938479716304835<br class="">
356329624224137216,0.0)<br class="">
*Girsanov> properFraction (0 / 0)<br class="">
(-26965397022934738615939577861835371004269654684134598591014512173659901<br class="">
3708251444699062715983611304031680170819807090036488184653221624933739271<br class="">
1459592111865666518401372982279144533294018691411791796244281275086532572<br class="">
2602351369432221086966581124085574502576602687944735992086890771957445725<br class="">
3034494436336205824,0.0)<br class="">
<br class="">
The Haskell Report "6.4.6 Coercions and Component Extraction" is<br class="">
silent on what to expect with NaN, Infinity and -Infinity so I think it should<br class="">
be amended. Alternatively, one could expect implementations to throw a<br class="">
runtime error?<br class="">
<br class="">
In ghc, the problem is here <a href="https://phabricator.haskell.org/D160a" rel="noreferrer" target="_blank" class="">https://phabricator.haskell.org/D160a</a><br class="">
<br class="">
/* This is expected to replace uses of __decodeDouble_2Int() in the long run */<br class="">
StgInt<br class="">
__decodeDouble_Int64 (StgInt64 *const mantissa, const StgDouble dbl)<br class="">
{<br class="">
if (dbl) {<br class="">
int exp = 0;<br class="">
*mantissa = (StgInt64)scalbn(frexp(dbl, &exp), DBL_MANT_DIG);<br class="">
return exp-DBL_MANT_DIG;<br class="">
} else {<br class="">
*mantissa = 0;<br class="">
return 0;<br class="">
}<br class="">
}<br class="">
<br class="">
I believe frexp [1] and scalbn [2] both pass through NaN, Infinity and -Infinity and I<br class="">
think type coercion in C is undefined for these values.<br class="">
<br class="">
Furthermore exp is undefined for these values [1].<br class="">
<br class="">
1. <a href="http://en.cppreference.com/w/cpp/numeric/math/frexp" rel="noreferrer" target="_blank" class="">http://en.cppreference.com/w/cpp/numeric/math/frexp</a><br class="">
2. <a href="http://en.cppreference.com/w/cpp/numeric/math/scalbn" rel="noreferrer" target="_blank" class="">http://en.cppreference.com/w/cpp/numeric/math/scalbn</a><br class="">
<br class="">
Dominic Steinitz<br class="">
<a href="mailto:dominic@steinitz.org" class="">dominic@steinitz.org</a><br class="">
<a href="http://idontgetoutmuch.wordpress.com/" rel="noreferrer" target="_blank" class="">http://idontgetoutmuch.wordpress.com</a><br class="">
<br class="">
_______________________________________________<br class="">
Haskell-Cafe mailing list<br class="">
<a href="mailto:Haskell-Cafe@haskell.org" class="">Haskell-Cafe@haskell.org</a><br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>