Maximum string length DoubleToStringConverter::EcmaScriptConverter() ToShortest? 26 chars?

[N-Dekker]

Having tried DoubleToStringConverter::EcmaScriptConverter().ToShortest(value, &builder) for quite a few floating point values, it appears to me that the length of the built string is always below 26 characters. (While some values do actually get represented by a string of length 25, excluding terminating null-character.) Is that a correct observation? Examples:

"-1.7976931348623157e+308" (-DBL_MAX, string length 24)
"-0.0000033333333333333333" (-3e-005/9.0, string length 25)

Is this maximum string length already documented somewhere? And could this number be added to the double-conversion library API as a named constant? For example as a public member of DoubleToStringConverter:

static const int kMaxCharsShortestStringEcmaScript = 26;

I think it would be very helpful to have such a constant available for users, as I guess EcmaScriptConverter is quite popular. And a user of ToShortest typically likes to know how "short" that string could possibly be!

Typical use case:

char userBuffer[ DoubleToStringConverter::kMaxCharsShortestStringEcmaScript ];
StringBuilder builder(userBuffer, sizeof(userBuffer));
DoubleToStringConverter::EcmaScriptConverter().ToShortest(value, &builder);

Note that in the ITK library, we currently just use a buffer size of 32, because such a named constant is not yet available: https://github.com/InsightSoftwareConsortium/ITK/blob/c00531fe23cea71f61685e50e4b6503ab8f1ae82/Modules/Core/Common/src/itkNumberToString.cxx#L51 (From pull request InsightSoftwareConsortium/ITK#2256) Which seems suboptimal to me.

[floitsch]

I'm pretty sure you are right that 25 characters is the longest sequence the Ecma conversion can yield.
This is, because the longest sequence of decimal digits for a number is 17 (kBase10MaximalLength), but then needs a few more for the sign, decimal point and 0 padding (due to the decimal_in_shortest_low).

The problem with a constant is, that it would only apply for the ecma configuration, but the converter supports many others. Might still be worth adding...

What we could (also) do: create an instance method on the converter to return the length. You wouldn't be able to use it to (easily) stack-allocate the buffer, but you could use it to ASSERT, that your buffer is of the right size.

Will try to see if I can add that.

[N-Dekker]

@floitsch Thank you very much, Florian. I'm glad you pretty much confirm that 25 characters is the maximum string length, for Ecma.

I do believe it might be reasonable to only just provide this maximum number for the Ecma conversion, as that is what this double-conversion library is based upon, if I understand correctly. It is also the only conversion configuration that has a dedicated helper function to create such a converter, DoubleToStringConverter::::EcmaScriptConverter().

However, if you are able to create a method that estimates the maximum for any configuration, that would certainly be great, of course. I leave it up to you 😃

[floitsch]

I created #150

To me, the length should not include the trailing '\0' character (even though it's, obviously, important not to forget).

Wdyt?

[N-Dekker]

I created #150

Cool!!!

To me, the length should not include the trailing '\0' character

@floitsch I agree, just like std::strlen and std::string::size() don't include a trailing '\0'. So 25 is fine to me, as long as it is documented not to include the '\0'.

[N-Dekker]

BTW, it appears to me that the longest string from EcmaScriptConverter().ToShortestSingle (for 32-bit float) is only slightly shorter. I think it's 22 (rather than 25 for double), for example for -1e20, which is returned as "-100000000000000000000".

Would that be worth an extra constant, kMaxCharsEcmaScriptShortestSingle?

[floitsch]

Yes the "-100000000000000000000" comes from decimal_in_shortest_high. The maximal amount of significant digits for singles is significantly smaller (17 to 9 iirc).
EcmaScript itself doesn't support singles, and I think I would create a different converter with a different configurations if I had to deal with singles. As such, it doesn't really make too much sense to add a constant.

[N-Dekker]

Thanks, @floitsch For ITK, we still use the same string buffer size for EcmaScriptConverter().ToShortest and EcmaScriptConverter().ToShortestSingle. I guess the new constant that you added, kMaxCharsEcmaScriptShortest = 25, is certainly sufficient for ToShortestSingle` as well 😃

Anyway, which converter or which configuration would you use for singles?

[floitsch]

I would probably change decimal_in_shortest_high. It doesn't make too much sense to have lots of '0's.
With the current decimal_in_shortest_high you will have something like: "12345678900000000000", and the "0"s at the end would never have anything else. Might as well make it smaller: "12345678900000", and let the rest be exponential. In other words, I would tune the decimal_in_shortest_high so that it has a length similar to the equivalent exponential representation. You want decimals as long as they aren't (much) longer than the exponential representation.
For the decimal_in_shortest_low it's already good the way it is: we trade a 'e-5' suffix for 5 leading '0's.

Since you can't have two different decimal_in_shortest_high in one converter you would just need to create two different ones, and use the correct one for the single call. The EcmaScript converter now has a documentation with the values it used, so it should be trivial to do that.