[erlang-questions] String representations of floating point numbers
Bryan Paxton
starbelly@REDACTED
Sun Mar 17 17:28:34 CET 2019
On 3/17/19 3:40 AM, Richard O'Keefe wrote:
> Me, I'd have taken Cowlishaw's reference implementation in C or the
> Intel library
> https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library
> and wrapped a NIF around it.
Interesting. I'll dive deeper into that for sure.
>
> If I needed it. z/Series and POWER have decimal FP in their
> instruction sets, but on other machines it's emulation or nothing.
>
> Erlang/OTP is very much influenced by its users' needs.
> (It doesn't always move *fast*, you understand, but when you
> want to develop long-lived systems that can be a good thing.)
I agree :) 100%
> Why not write up an EEP?
Maybe ;) I think there are a few others in the community who are better
suited for such a thing, but we shall see!
Thanks RoK!
--
Bryan
>
>
>
>
> On Sun, 17 Mar 2019 at 21:18, Bryan Paxton <starbelly@REDACTED
> <mailto:starbelly@REDACTED>> wrote:
>
> A library that implements IEEE-754: http://speleotrove.com/decimal/
>
> Example implementations in Erlang:
>
> https://github.com/tim/erlang-decimal
>
> https://github.com/egobrain/decimal
>
>
> On 3/17/19 1:29 AM, Richard O'Keefe wrote:
>> What do you mean by "a decimal lib"?
>>
>> On Sun, 17 Mar 2019 at 06:35, Bryan Paxton <starbelly@REDACTED
>> <mailto:starbelly@REDACTED>> wrote:
>>
>> All of this begs the question of why there is no decimal lib
>> in otp... I'm sure there's a good reason... ?
>>
>>
>> On 3/16/19 12:31 PM, Bob Ippolito wrote:
>>> While it's more code, the most straightforward way would be
>>> to parse the whole float for that spec into its constituent
>>> parts and reassemble (with defaults where necessary) to
>>> parse with float_to_list.
>>>
>>>
>>>
>>>
>>> On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills
>>> <hugo@REDACTED <mailto:hugo@REDACTED>> wrote:
>>>
>>> Hi, Bob,
>>>
>>> On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito
>>> wrote:
>>> > If you dive into the implementation it's effectively a
>>> wrapper around
>>> > strtod from C with a validation pass that is more
>>> strict than the strtod
>>> > standard.
>>> >
>>> >
>>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54
>>> >
>>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732
>>> >
>>> > So as far as a regex goes it would be something like this:
>>> >
>>> > [+-]?\d+[.,]\d+([eE][+-]?\d+)
>>> >
>>> > The major differences between this and other popular
>>> float grammars are:
>>> >
>>> > * At least one digit is required in each part
>>> > * Both integer and fractional parts are required, even
>>> if there's an
>>> > exponent part (so "1", ".1", "1e-1" would not be valid)
>>> > * The decimal separator is either , or . (the
>>> implementation will try the
>>> > other if necessary to compensate for a different locale)
>>>
>>> Thanks for the confirmation. That's more or less what
>>> I discovered
>>> while playing around with list_to_float. It's the first
>>> two cases that
>>> are the problems for me, because the spec I'm working
>>> to(*) says that
>>> "1." and ".3" are valid floats, for example, as is "1e-1".
>>>
>>> Just for the record, here's the code I'm using to
>>> convert a Turtle
>>> double or decimal (the former in scientific notation;
>>> the latter
>>> without the E) into a form suitable for list_to_float/1:
>>>
>>> [...]
>>> % W3C's description of a float is wider than
>>> erlang's. We need to
>>> % split up the number into a few parts to add extra
>>> characters
>>> % where necessary so that list_to_float/1 will work
>>> right.
>>> F = case string:lexemes(Text, "eE") of
>>> [M, E] ->
>>> fixup_decimal(M) ++ "e" ++ E;
>>> [M] ->
>>> fixup_decimal(M)
>>> end,
>>> O = lagra_model:new_literal(list_to_float(F)),
>>> [...]
>>>
>>> -spec fixup_decimal(string()) -> string().
>>> fixup_decimal(M) ->
>>> case string:lexemes(M, ".") of
>>> [I] ->
>>> I++".0";
>>> [I, ""] ->
>>> I++".0";
>>> ["", J] ->
>>> "0."++J;
>>> [I, J] ->
>>> M
>>> end.
>>>
>>> Hugo.
>>>
>>> (*) W3C's Turtle recommendation.
>>>
>>>
>>> > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills
>>> <hugo@REDACTED <mailto:hugo@REDACTED>> wrote:
>>> >
>>> > > Where in the manual is the set of allowable
>>> string representations
>>> > > of floating point numbers documented? I'd have
>>> expected it to be here:
>>> > >
>>> > > http://erlang.org/doc/reference_manual/data_types.html
>>> > >
>>> > > ... but apparently not.
>>> > >
>>> > > Specifically, I'm trying to use list_to_float/1,
>>> and I've been
>>> > > trying to reverse engineer it:
>>> > >
>>> > > 1> list_to_float("-1").
>>> > > ** exception error: bad argument
>>> > > in function list_to_float/1
>>> > > called as list_to_float("-1")
>>> > > 2> list_to_float("-1.0").
>>> > > -1.0
>>> > > 3> list_to_float("-1.0e-23").
>>> > > -1.0e-23
>>> > > 4> list_to_float("-1e-23").
>>> > > ** exception error: bad argument
>>> > > in function list_to_float/1
>>> > > called as list_to_float("-1e-23")
>>> > > 5> list_to_float(".3").
>>> > > ** exception error: bad argument
>>> > > in function list_to_float/1
>>> > > called as list_to_float(".3")
>>> > >
>>> > > An actual written specification would be really
>>> handy here. Even
>>> > > just a regex or EBNF for them. I'm writing a parser
>>> for something
>>> > > where the definition of floating point literals
>>> isn't quite the same
>>> > > as Erlang's, and it's a bit painful.
>>> > >
>>> > > Hugo.
>>> > >
>>>
>>> --
>>> Hugo Mills | Nostalgia isn't what it used to be.
>>> hugo@REDACTED carfax.org.uk <http://carfax.org.uk> |
>>> http://carfax.org.uk/ |
>>> PGP: E2AB1DE4 |
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>
>>> iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ
>>> x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+
>>> trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp
>>> 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf
>>> 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b
>>> CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE
>>> Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz
>>> wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa
>>> 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF
>>> 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv
>>> S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx
>>> 5uMAhklJZ0OnQgmxOfVU
>>> =0Eaq
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> --
>>
>> Bryan Paxton
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190317/1a688837/attachment.htm>
More information about the erlang-questions
mailing list