Use float to string kernel

[thirtiseven]

This PR updates the float to string casting to a new kernel in JNI. It won't match Spark's behavior exactly, but the results are closer than the current version.

The JNI kernel is part of the format_number support, so I split it out as a subtask.

This PR uses Ryū: fast float-to-string conversion (PLDI'18) as the solution for casting float/double to string. The results differ from the output of Spark's in some cases: sometimes the output is shorter (which is arguably more accurate) and sometimes the output may differ in the precise digits output (e.g., see ulfjack/ryu#83).

In most cases, the result will match Spark's results, and in the cases where it does not, the values will match when we cast them back to float.

Depends on: NVIDIA/spark-rapids-jni#1508

There is some related discussion in format_number issue #9173.

Closes #4204

performance test results

50000000 random number generated by BigDataGen:

test code:

spark.time(df.selectExpr("COUNT(cast(a as string)) as a", "COUNT(cast(a as string)) as b", "COUNT(cast(a as string)) as c", "COUNT(cast(a as string)) as d", "COUNT(cast(a as string)) as e").show())

spark.time(df.selectExpr("COUNT(cast(b as string)) as a", "COUNT(cast(b as string)) as b", "COUNT(cast(b as string)) as c", "COUNT(cast(b as string)) as d", "COUNT(cast(b as string)) as e").show())

Data Type	GPU Time (ms)	CPU Time (ms)	Speed up
float	282	5,221	18.51x
double	379	14,638	38.62x

[thirtiseven]

build

[revans2]

I filed a PR to fix the markdown failure #10029

[revans2]

nit: The Rapids Accelerator for Apache Spark uses a method based on ryu when converting floating point data type to string. ...

[thirtiseven]

done.

[revans2]

This does not need to be an approximate float? How many DATAGEN_SEEDS have you tested with this?

[thirtiseven]

I tested 10 more times with length=200000 and they all passed.

The difference between ryu and jdk's float to string is that jdk sometimes keeps more precision, but ryu keeps it as short as possible. The results will be the same float when converted back. So I think it makes sense that we don't need an approximate float here.

[thirtiseven]

And also the float to string is fully matched to cpu but double to string is not. It is the reason to test float to string and double to string in two different ways.

Seems the compatibility doc for float to string is outdated, so I'm not sure if we are aware that double to string is not fully matched with cpu. Filed #10037

[thirtiseven]

build