Add `NumberInput.parseFloat()`

[pjfanning]

For v2.14, NumberInput has become the main way to centralise the code for parsing numbers. One inconsistency is that Floats are still parsed using Float.parseFloat. Having a NumberInput.parseFloat that does that means we can change the implementation later to use the fast-double-parser or something similar. See #577

[plokhotnyuk]

@pjfanning Please ensure that it is used for parsing floats to avoid 1ULP rounding error that happens with v2.13.2

[pjfanning]

@plokhotnyuk I think the jackson issue you describe is because in some cases jackson seems to use Double.parseDouble to parse floats and then later to cast that to a float and that seems to lead to the loss of precision with the "1.199999988079071" case. Float.parse("1.199999988079071") gives 1.1999999f but (float)Double.parse("1.199999988079071") seems to give 1.2f.

[pjfanning]

@plokhotnyuk is 1.2f actually a better answer than 1.999999f - it is actually closer to 1.199999988079071

1.2 - 1.199999988079071 = 1.19209289e-8
1.999999 - 1.199999988079071 = -8.80790711e-8

[plokhotnyuk]

Exact binary representation of 1.199999988079071 is:

1.0011001100110011001100101111111111111111111111111111110011000011...

When fitting to 32-bit float the properly rounded binary value is:

1.00110011001100110011001

That is 1.19999992847442626953125 when converted back to exact decimal representation.

You can use the following online calculator to check this:
https://www.exploringbinary.com/binary-converter/

[pjfanning]

@cowtowncoder this code in ParserBase (jackson-core) may be contributing to the issue that @plokhotnyuk described with parsing 1.199999988079071 as a float.

    @Override
    public float getFloatValue() throws IOException
    {
        double value = getDoubleValue();
        /* 22-Jan-2009, tatu: Bounds/range checks would be tricky
         *   here, so let's not bother even trying...
         */
        /*
        if (value < -Float.MAX_VALUE || value > MAX_FLOAT_D) {
            _reportError("Numeric value ("+getText()+") out of range of Java float");
        }
        */
        return (float) value;
    }

From my testing, it seems that casting doubles to floats may not get the same result as parsing the text representation directly with Float.parseFloat(String).

[pjfanning]

I created #755 for the issue about 1.199999988079071 - I want to keep this issue for the original purpose of updating NumberInput to have a parseFloat(String)

[GedMarc]

Hmm, I may be mistaken, but isn't float inaccurate/non-precise by default, are we absolutely sure the algorithm doesn't go to that value as the closest possible match to the requested value?

Is there any benefit in trying to make an inherent non precise number system precise?

[pjfanning]

I need to go into this with more detail with @plokhotnyuk because I can't reproduce his issue and I'd like to move that discussion to #755 - this issue was originally about a small code refactor

[cowtowncoder]

I think this issue specifically is resolved, so closing, but follow-up discussions -- which are related but not directly caused by this -- should proceed.

Put another way: this just adds a method to call; coercions between float, double etc happen in different places in code (mostly ParserBase)