float parsing bug

[Sebastian Egner]

Hello Alex,

Some while ago, I had the same problem: I had to read non-Erlangian floats and solving the problem "at the source", i.e. have the producing program comply with Erlang-syntax, was not really an option. (In my case, the sources are embedded systems that had been rolled out to customers in the hundreds.)

My solution is attached to this email: unifloat:to_float/1 parses a deep list of characters into a floating point number, understanding a most liberal floating point syntax.

The module is not designed for performance but rather for 'at least you know what you get'.

On the design side, separating integers and floats syntactially has its merits in a dynamically typed language like Erlang, but IMHO it would not hurt if the 'result-will-be-float'-parsing functions (list_to_float/1, fread "~g" etc.) would understand a most liberal floating point syntax, making them viable for reading external data sources.

Regards,

Sebastian.

P.S. Did you run into the other "float parsing bug" yet? Erlang floats do not represent NANs, e.g. <<X:32/float>> = <<-1:32>> throws a 'no match'. Again, while this is fine within the Erlang world itself, dealing with binary represented floats from external sources can become messy and slow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unifloat.erl
Type: application/octet-stream
Size: 2874 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100113/567a6fd2/attachment.obj>