format/2: number of float digits incorrect starting with 1024

[UWN]

?- format("~1023f",[5.0e-324]).
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004940656458412465441765687928682213723650598026143247644255856825006755072702087518652998363616359923797965646954457177309266567103559397963987747960107818781263007131903114045278458171678489821036887186360569987307230500063874091535649843873124733972731696151400317153853980741262385655911710266585566867681870395603106249319452715914924553293054565444011274801297099995419319894090804165633245247571478690147267801593552386115501348035264934720193790268107107491703332226844753335720832431936092382893458368060106011506169809753078342277318329247904982524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993664809941164205702637090
yes % fine
?- format("~1024f",[5.0e-324]).
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004940656458412465441765687928682213723650598026143247644255856825006755072702087518652998363616359923797965646954457177309266567103559397963987747960107818781263007131903114045278458171678489821036887186360569987307230500063874091535649843873124733972731696151400317153853980741262385655911710266585566867681870395603106249319452715914924553293054565444011274801297099995419319894090804165633245247571478690147267801593552386115501348035264934720193790268107107491703332226844753335720832431936092382893458368060106011506169809753078342277318329247904982524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993664809941164205702637090
yes % unexpected - digit 3 is missing (according to SICStus, GNU, SWI, B)
?- 

[jfmc]

Ops! Thanks for reporting. It seems that we have an arbitrary fixed output digits in the code:

#define MAX_OUTPUT_DIGITS 1023

is there any reasonable limit in other systems?

[UWN]

The minimum required to represent above number precisely is: format("~1074f",[5.0e-324]). So this might seem necessary to read them back in precisely.

GNU has a limit above 65_000 and aborts, SICStus 4 from 100_000 on with an exception, SWI an uncaught allocation error above 100_000_000. A representation error (for a fixed value) or ressource error (for dynamic memory allocation) would be the cleanest. The non-conforming consistency error of SICStus 4 seems to be a Quintus legacy. In SICStus 3.12.1 1_000_000_000 worked fine. But 1_000_000_000_000 just produced 0.0.

[jfmc]

I double checked this problem. It seems that 64-bit number need around 17 decimal digits plus some additional zeroes if we do not use scientific notation. Around 325 digits are enough to ensure the round-trip property of floating point numbers. So no information is lost if we saturate the number of digits to something above that number.

When reading back that number, Ciao gets exactly the same number even if removing more and more digits. I will close this issue but please feel free to reopen if needed.

[UWN]

To represent a floating point value exactly in decimal notation (that is, independently of the float format be it single/double/quad precision or whatever), you need about 1074 digits. You could remove the leading zeroes, about 300, but then you would need an exponent which is again another notation.

In any case, currently the result is just wrong. And, ideally, there is an error for too many digits as mentioned above.

UWN_open

[jfmc]

Do you mean that it is wrong because it is not using the expected number of digits? (I reopen the issue then)

The result is not wrong w.r.t. round-trip property, I can read it back (also in other languages) and obtain the same number (in 64-bit floating points). The exponent is so large that it do not have enough bits to represent the significand. Even 0.00...4 represent 5.0e-324 (in 64-bits).

Just one question: I do not see where the 1074 digits number comes. Is it for base 2?

[UWN]

Do you mean that it is wrong because it is not using the expected number of digits? (I reopen the issue then)

Yes.

The result is not wrong w.r.t. round-trip property, I can read it back (also in other languages) and obtain the same number (in 64-bit floating points).

But that is not the criterion. You depend here on IEEE 64-bit double precision. With another precision this no longer works. And for the round-trip property, the canonical form is sufficient.

Just one question: I do not see where the 1074 digits number comes. Is it for base 2?

Base 10 is just as good to represent a negative power of two like base 2. Thus you need the same number of digits. You need ~52 digits (not bits) for the mantissa and then ~1022 digits for the exponent.

[jfmc]

Do you mean that it is wrong because it is not using the expected number of digits? (I reopen the issue then)

Yes.

OK!

The result is not wrong w.r.t. round-trip property, I can read it back (also in other languages) and obtain the same number (in 64-bit floating points).

But that is not the criterion. You depend here on IEEE 64-bit double precision. With another precision this no longer works. And for the round-trip property, the canonical form is sufficient.

Thanks, yes.

Just one question: I do not see where the 1074 digits number comes. Is it for base 2?

Base 10 is just as good to represent a negative power of two like base 2. Thus you need the same number of digits. You need ~52 digits (not bits) for the mantissa and then ~1022 digits for the exponent.

But base 10 requires fewer digits than base 2. I must do something wrong because my numbers do not match yours.

[UWN]

... to represent a negative power of two like base 2. ....

But base 10 requires fewer digits than base 2. I must do something wrong because my numbers do not match yours.

Does it?

?- length(_,E),F is 2**(-E).
   E = 0, F = 1.0
;  E = 1, F = 0.5
;  E = 2, F = 0.25
;  E = 3, F = 0.125
;  E = 4, F = 0.0625
;  E = 5, F = 0.03125
;  E = 6, F = 0.015625
;  E = 7, F = 0.0078125
;  E = 8, F = 0.00390625
;  E = 9, F = 0.001953125
;  E = 10, F = 0.0009765625
;  E = 11, F = 0.00048828125
;  E = 12, F = 0.000244140625
;  E = 13, F = 0.0001220703125
;  E = 14, F = 0.00006103515625
;  E = 15, F = 0.000030517578125
;  E = 16, F = 0.0000152587890625
;  ... .

So for each increment in the exponent, a further decimal digit is required.

[jfmc]

... to represent a negative power of two like base 2. ....

But base 10 requires fewer digits than base 2. I must do something wrong because my numbers do not match yours.

Does it?

?- length(_,E),F is 2**(-E).
   E = 0, F = 1.0
;  E = 1, F = 0.5
;  E = 2, F = 0.25
;  E = 3, F = 0.125
;  E = 4, F = 0.0625
;  E = 5, F = 0.03125
;  E = 6, F = 0.015625
;  E = 7, F = 0.0078125
;  E = 8, F = 0.00390625
;  E = 9, F = 0.001953125
;  E = 10, F = 0.0009765625
;  E = 11, F = 0.00048828125
;  E = 12, F = 0.000244140625
;  E = 13, F = 0.0001220703125
;  E = 14, F = 0.00006103515625
;  E = 15, F = 0.000030517578125
;  E = 16, F = 0.0000152587890625
;  ... .

So for each increment in the exponent, a further decimal digit is required.

I do not have time now to do a precise analysis but as mantissa bits are exhausted, decimal exponent shows a slower growth:

E = 49,
F = 1.7763568394002505e-15 ? ;

E = 50,
F = 8.881784197001252e-16 ? ;

E = 51,
F = 4.440892098500626e-16 ? ;

E = 52,
F = 2.220446049250313e-16 ? ;

E = 53,
F = 1.1102230246251565e-16 ? ;

E = 54,
F = 5.551115123125783e-17 ? ;