Change ParserBase to track floats independently from doubles

[pjfanning]

It seems like in some cases, casting a double to a float may result in a slightly different answer than parsing the original number string using Float.parseFloat.

This code in ParserBase (jackson-core) may be contributing to an 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]

@plokhotnyuk could you check the test case in FasterXML/jackson-databind#3464 - result seems correct as is

[cowtowncoder]

Hmmh. Yes, I agree.

Unfortunately this may also require more changes for cases where coercion is used (at least for textual formats) -- in case where double is requested first, decoded double will be used as the base to coerce from (due to assumption that coercion is faster than decoding).

I think what would be really useful is/are test cases to trigger the problem.

One quick question: was the specific textual representation 1.2? If so, could just verify that the float we get is same as Float.parseFloat("1.2"), for example.

[pjfanning]

@cowtowncoder I still haven't reproduced the problem - so for now, this can be ignored. When I get a chance, I'll try the jsoniter-scala benchmark scenario directly to see if I can debug it there.

[pjfanning]

@cowtowncoder I added FasterXML/jackson-databind#3470 - it shows the issue that @plokhotnyuk reported. Would you be able to take a look?

[pjfanning]

@cowtowncoder #757 seems to fix the issue in FasterXML/jackson-databind#3470 -- could you review that PR?

[cowtowncoder]

I think this was indeed resolved via #757, closing.