Thanks for all the hard work on the double and float parsers. Would there be any chance that you could consider adding support for BigDecimal parsing? A lot of the low level parser could be reused.

The FastDoubleParser was recently introduced in Jackson through this issue https://github.com/FasterXML/jackson-core/issues/577 is 3-4x times faster compared to the version that's implemented in OpenJDK. This is fantastic news, since many numerical processing workloads would benefit from this.

However the OpenJDK Double/Float parsers support variety of input formats that the FastDoubleParser will fail on, therefore it can cause unexpected regressions when used.

For example, the FastDoubleParser will fail with a NumberFormatException on these example patterns (there are more to be found in the OpenJDK Double/Float tests):

1.1e-23f 0x.003p12f 0x1.17742db862a4P-1d

I think apart from the first one in this list, the rest are all hexadecimal if I'm not mistaken.

The parser throws StringIndexOutOfBoundsException/ArrayIndexOutOfBoundsException for some inputs. For example with the following input: "0x".

This issue has been discovered in https://github.com/FasterXML/jackson-core/issues/809

The only exceptions, that the parser may throw are:

• NumberFormatException when the input is illegal
• OutOfMemoryException when the JVM fails to allocate memory for objects created by the parser

https://github.com/wrandelshofer/FastDoubleParser/blob/8df68712f159304a828b4ddfc11a14a54ec6c973/src/main/java/ch/randelshofer/fastdoubleparser/FastDoubleParser.java#L530

why allocate here?? by that time you know it's not a NaN for sure... so instead of returning null you can just return Double.NaN or whatever special constant.

lack of jmh tests is also troubling :(

The *FromByteArray, *FromCharArray and *FromCharSequence classes are stateless and their references in the *Parser classes can be made constants.

I was working on a patch for Jackson to make double parsing work on char[] directly without allocating a String. When profiling the allocation rate did not go down as much as expected. The reason was that I got a lot of JavaDoubleBitsFromCharArray allocations in JavaDoubleParser. In theory escape analysis should catch these and scalar replacement should eliminate them. It does not. I haven't looked into it, maybe the method is already too large.

After the changes the allocations and GCs are gone.

I'm seeing a small performance improvement but it's hard to be sure as the deviation is still quite large.

For https://github.com/fastfloat/fast_float, we have extensive tests. I have run them through on FastDoubleParser and found many failures, I have collected them in this gist...

https://gist.github.com/lemire/641a34589c36747f6d24ed6d29ac75f0

The algorithm at https://github.com/fastfloat/fast_float handles all of these cases correctly.

You may refer to https://arxiv.org/abs/2101.11408 or to the C# port at https://github.com/CarlVerret/csFastFloat

https://github.com/wrandelshofer/FastDoubleParser/blob/0903817a765b25e654f02a5a9d4f1476c98a80c9/src/main/java/ch.randelshofer.fastdoubleparser/ch/randelshofer/fastdoubleparser/FastDoubleSimd.java#L117

Use 0x76 instead of 0x46 byte for detection of invalid digits in "numbers" like 1X345678.

Hi - thanks for all the great work on the double parser. I've been experimenting with it for possible inclusion in jackson-core.

Parsing floats using the double parser is also much faster than using Float.parseFloat but unfortunately casting doubles to floats can often give you different result from plain Float.parseFloat.

Would it be possible to consider also supporting a dedicated float parser?

An example is 7.006492321624086e-46 which Float.parseFloat returns as 1.4E-45 but using FastDoubleParser:

        double dbl = FastDoubleParser.parseDouble("7.006492321624086e-46");
        System.out.println("double=" + dbl); //7.006492321624085E-46
        System.out.println("float=" + (float)dbl); //0.0

I have found another input string for which the return values of Double.parseDouble and FastDoubleParser.parseDouble differ. This one is less important than #6 though as it implies only a very minor loss in precision:

Double.parseDouble("-2.2222222222223e-322"): -2.2E-322
FastDoubleParser.parseDouble("-2.2222222222223e-322"): 0.0

Both this issue and #6 have been found with the open-source JVM fuzzer Jazzer. If you are interested in these kinds of findings, I could add the fuzzer to the project as a PR.

Relates to https://github.com/FasterXML/jackson-core/issues/809

This change is based on the stacktrace in that issue. I don't yet have the value that caused the failure.

"We use your java8 code in jackson-core. If you publish a jar with your java8 branch code that would be great - we would change our build to use your published jars and that shades the class packages to include them in jackson-core jar.

One solution would be to append '-java8' to the artifact name (and '-java17' for the java17 jar). Or maven supports 'classifiers' which basically lead to a similar result."

Originally posted by @pjfanning in https://github.com/wrandelshofer/FastDoubleParser/issues/22#issuecomment-1318507290

JavaDoubleParser seems to be slower than Double.parseDouble for very large numbers (thousands of digits). Malicious actors often create input files with large numbers to try to cause denial of service issues.

I have a jmh benchmark at https://github.com/pjfanning/jackson-number-parse-bench

./gradlew jmh

It's worth checking the build.gradle file as I have a param that controls which benchmark to run.

jmh {
    includes = ['org.example.jackson.bench.DoubleParserBench']
}

I'm wondering if it would be possible to disregard the least significant digits. If there are 1000 digits, only the first 30 or 40 digits should really impact the double value - even if you were conservative and limited it 100 or 200, this would limit the risk vector.

    @wrandelshofer I'm using v0.5.2 and have found that `JavaBigIntegerParser,parseBigInteger(CharSequence str)` accepts hex values like "AAAA" but `new BigInteger(String)` throws a NumberFormatException with "AAAA".

Would it be possible to support being able to disable hex support?

Originally posted by @pjfanning in https://github.com/wrandelshofer/FastDoubleParser/issues/24#issuecomment-1332929009