[erlang-questions] OtpErlangDouble/OtpErlangFloat

[Richard O'Keefe]

On 8/08/2012, at 11:01 PM, Martin Dimitrov wrote:

> Hello,
> 
> I have some strings in Java representing floating point numbers. I want
> to transfer them to Erlang. So I create an object of type
> OtpErlangFloat. The problem is that is rounds the number funnily. For
> example,
> 
> String s = "22.4";
> float f = Float.parseFloat(s);

Here you asked for a SINGLE-PRECISION floating point number.
I presume you did try

Prelude> 22.4 - 22.399999618530273
3.8146972514141453e-7

and you did notice that the difference is about the size of
single precision epsilon?
Well that's why.  You asked for a number with 24 bits of
precision that was close to 22.4, and 22.399999618530273
was indeed the answer you got.

> System.out.println(f); // 22.4

PrintStream.println(float) calls
PrintStream.print(float) calls
String.valueOf(float) calls
Float.toString(float) 

whose documentation says (for this value of m) tha
it will be the integer part, then a dot, then "as
any, but only as many, more digits as are needed to
uniquely distinguish the argument value from adjacent
values of type 'float'".

So the value that is printed is the _least_ precise
decimal representation that cannot be mistaken for
a different single-precision (24 bits of precision)
float.

If you convert the same value to a double in Java and
print that in Java, you will get, well, try it:

L% cat NotErlangsFault.java
public class NotErlangsFault {
    public static void main(String[] args) {
        final String    s = "22.4";
        final float     f = Float.parseFloat(s);
        final double    d = (double)f;

        System.out.println(s + " converts to float " + f +
            " which as double is " + d);
    }
}

L% java NotErlangsFault
22.4 converts to float 22.4 which as double is 22.399999618530273

See?   Nothing to do with Erlang at all.

> OtpErlangFloat ef = new OtpErlangFloat(f);
> System.out.println(ef.toString()); // 22.399999618530273

And this tells us that an OtpErlangFloat contains a Java double,
which is *more* precise than the float you gave it.
> 
> Then in Erlang:
> 
> mochinum:digits(Ef).
> "22.399999618530273"

And this is the right answer.
> 
> but
> 
> mochinum:digits(22.4).
> "22.4"
> 
> Is there a way to keep the precision when constructing
> OtpErlangDouble/OtpErlangFloat?

No precision whatsoever was lost in that step.

The precision was lost when you first converted a String
to a float.  The value in the float really *is* much
better approximated by 22.399999618530273 than by 22.4.