[erlang-questions] BSON parsing?

Thomas Lindgren thomasl_erlang@REDACTED
Fri May 16 10:57:27 CEST 2014

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.

Being dirty, you don't have to think about things like NaNs, infinities, denormalized numbers, fp according to ISO/IEC 9899:TC3 Section 7.6, tracking the evolution of fp standards or what to do about

     fenv(3), feclearexcept(3), fegetenv(3), fegetexceptflag(3), feholdexcept(3),
     fesetenv(3), feraiseexcept(3), fesetexceptflag(3), feraiseexcept(3), feupdateenv(3)"

(Any choice you make beyond providing that is probably a liability.)

Nevertheless, IEEE arithmetic is the standard and I think we'd at least want to represent and operate on standard floating point. 


On Friday, May 16, 2014 12:44 AM, Richard A. O'Keefe <ok@REDACTED> wrote:

>On 15/05/2014, at 11:35 PM, Loïc Hoguin wrote:
>> Erlang doesn't have a representation for NaN, +infinity and -infinity.
>Does anyone know why?
>I've used Smalltalk systems which say "If non-IEEE arithmetic
>was good enough for Granddad, it's good enough for me.  SNIFF!"
>and Smalltalk systems which say "Standard since 1985, available
>everywhere, even on IBM z/Series, what earthly excuse could
>there be for NOT presenting IEEE arithmetic?"
>And the ones that don't hide infinities and NaNs turn out to be
>easier to use.
>Well, if I have straightforward numeric code, I'm going to
>write it so that infinities and NaNs don't happen, so the
>only downside to being nonstandard is the extra run-time cost.
>But in fact very little numeric code is _that_ straightforward.
>Using a Smalltalk that respects the standard, I can take working
>numeric code in C or Fortran and convert it with very little
>effort and it will do the SAME thing.  Using a Smalltalk that
>does not respect the standard, I have to analyse every
>operation to make sure that it will work.
>In fact my own Smalltalk library includes some vectorised
>operations on specialised arrays, and it really would NOT
>be safe to switch from an Array that happens to hold
>FloatE objects to a FloatEArray if the arithmetic could be
>different in any way.
>Conversely, if I have some numeric code written in Erlang,
>it would be nice to be able to translate it to C and link
>it in.  But making floating point semantics *different* in
>Erlang and C makes this rather dangerous.
>Is Erlang running these days on *any* hardware platform
>that doesn't have IEEE arithmetic?
>erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140516/3c80ee69/attachment.htm>

More information about the erlang-questions mailing list