<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div class="" style=""><span class="" style="">On the positive side, doing "dirty" floating point like current Erlang means you don't have to manage or keep up with the strange cruft and corner cases of a rabbit hole far from the erlang core, so I can sort of see the (f.) point. Yet ultimately I consider it a mistaken design choice.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" class="">Being dirty, you don't
have to think about things like NaNs, infinities, denormalized numbers, fp according to <span style="font-size: 10pt;" class="">ISO/IEC 9899:TC3 Section 7.6, tracking the evolution of fp standards or what to do about</span></div><div style="color: rgb(0, 0, 0); font-size: 10pt; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" class=""><span style="font-size: 10pt;" class=""><br></span></div>
<div class="" style="">"SEE ALSO</div><div class="" style=""> fenv(3), feclearexcept(3), fegetenv(3), fegetexceptflag(3), feholdexcept(3),</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" class="">
</div><div class="" style=""> fesetenv(3), feraiseexcept(3), fesetexceptflag(3), feraiseexcept(3), feupdateenv(3)"</div><div class="" style=""><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">(Any choice you make beyond providing that is probably a liability.)</div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">Nevertheless, IEEE arithmetic is the standard and I think we'd at least want to represent and
operate on standard floating point. </div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent;">Best,</span><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">Thomas</div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10pt;" class=""> <div style="font-family: HelveticaNeue,
Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;" class=""> <div dir="ltr" class="" style=""> <font size="2" face="Arial" class="" style=""> On Friday, May 16, 2014 12:44 AM, Richard A. O'Keefe <ok@cs.otago.ac.nz> wrote:<br class="" style=""> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;" class=""> <br class="" style=""><br class="" style=""> <div class="" style=""><br clear="none" class="" style="">On 15/05/2014, at 11:35 PM, Loïc Hoguin wrote:<br clear="none" class="" style=""><br clear="none" class="" style="">> Erlang doesn't have a representation for NaN, +infinity and -infinity.<br clear="none" class="" style=""><br clear="none" class="" style="">Does anyone know why?<br clear="none" class="" style=""><br clear="none" class="" style="">I've used Smalltalk systems which say "If non-IEEE arithmetic<br clear="none" class=""
style="">was good enough for Granddad, it's good enough for me. SNIFF!"<br clear="none" class="" style="">and Smalltalk systems which say "Standard since 1985, available<br clear="none" class="" style="">everywhere, even on IBM z/Series, what earthly excuse could<br clear="none" class="" style="">there be for NOT presenting IEEE arithmetic?"<br clear="none" class="" style=""><br clear="none" class="" style="">And the ones that don't hide infinities and NaNs turn out to be<br clear="none" class="" style="">easier to use.<br clear="none" class="" style=""><br clear="none" class="" style="">Why?<br clear="none" class="" style=""><br clear="none" class="" style="">Well, if I have straightforward numeric code, I'm going to<br clear="none" class="" style="">write it so that infinities and NaNs don't happen, so the<br clear="none" class="" style="">only downside to being nonstandard is the extra run-time cost.<br clear="none" class="" style="">But in
fact very little numeric code is _that_ straightforward.<br clear="none" class="" style="">Using a Smalltalk that respects the standard, I can take working<br clear="none" class="" style="">numeric code in C or Fortran and convert it with very little<br clear="none" class="" style="">effort and it will do the SAME thing. Using a Smalltalk that<br clear="none" class="" style="">does not respect the standard, I have to analyse every<br clear="none" class="" style="">operation to make sure that it will work.<br clear="none" class="" style=""><br clear="none" class="" style="">In fact my own Smalltalk library includes some vectorised<br clear="none" class="" style="">operations on specialised arrays, and it really would NOT<br clear="none" class="" style="">be safe to switch from an Array that happens to hold<br clear="none" class="" style="">FloatE objects to a FloatEArray if the arithmetic could be<br clear="none" class="" style="">different in any
way.<br clear="none" class="" style=""><br clear="none" class="" style="">Conversely, if I have some numeric code written in Erlang,<br clear="none" class="" style="">it would be nice to be able to translate it to C and link<br clear="none" class="" style="">it in. But making floating point semantics *different* in<br clear="none" class="" style="">Erlang and C makes this rather dangerous.<br clear="none" class="" style=""><br clear="none" class="" style="">Is Erlang running these days on *any* hardware platform<br clear="none" class="" style="">that doesn't have IEEE arithmetic?<div class="" id="yqtfd74590" style=""><br clear="none" class="" style=""><br clear="none" class="" style="">_______________________________________________<br clear="none" class="" style="">erlang-questions mailing list<br clear="none" class="" style=""><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org" class=""
style="">erlang-questions@erlang.org</a><br clear="none" class="" style=""><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank" class="" style="">http://erlang.org/mailman/listinfo/erlang-questions</a></div><br class="" style=""><br class="" style=""></div> </blockquote> </div> </div> </div> </div></body></html>