Re^2: [XS] C printf() and Microsoft compilers.

The output of MS's libc printf function is not unreasonable because it essentially gives you all 16 digits of precision correctly and then pads the rest with zeroes.

I pretty much agree with that assessment - though I believe it's actually rounding to 17 digits, not 16. (16 digits is not enough.)
However, it's a pity that MS doesn't provide the service offered by gcc.
I was hoping that someone would tell me that with MS toolchains there was a means of extracting the same behaviour, if only with toolchains beyond a certain version.
But, if that's not the case, then so be it.

It might actually be considered helpful for scientific applications because it correctly displays the digits of precision that you really have

I suppose that's how one would go about trying to present the behaviour as being desirable.
But, given that the value is a 53-bit integer (that doesn't exceed double precision), multiplied by a power of 2 (that doesn't exceed the maximum double exponent),
I see no harm in displaying the exact value of the double - as opposed to displaying a 17-digit value padded with sufficient zeroes that rounds to the same double.

To me, it's not a question of "right" and "wrong" - rather a question of "helpful" and "pointless".

The extreme case is that gcc provides:

C:\>perl -MPOSIX -e "printf '%.0f', POSIX::DBL_MAX;"
1797693134862315708145274237317043567980705675258449965989174768031572
+607800285387605895586327668781715404589535143824642343213268894641827
+684675467035375169860499105765512820762454900903893289440758685084551
+339423045832369032229481658085593321233482747978262041447231687381771
+80919299881250404026184124858368
[download]

whereas cl provides:

C:\Windows\System32>perl -MPOSIX -e "printf '%.0f', POSIX::DBL_MAX;"
1797693134862315700000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000
[download]

Both values assign to the same double, but the former is an exact representation of that double, whereas the latter is an approximation.

Cheers,
Rob

Comment on Re^2: [XS] C printf() and Microsoft compilers. Select or Download Code

Replies are listed 'Best First'.
Re^3: [XS] C printf() and Microsoft compilers. by NERDVANA (Priest) on Jan 08, 2020 at 15:00 UTC
In a scientific application, that exact floating point representation could be the literal you gave it, but it could also be the result of math that has been rounded to fit in the 53 bit mantissa. For example `perl -MPOSIX -e “printf ‘%.0f’, POSIX::DBL_MAX - 10000000000000000;”` Now the very precise answer from gcc is wrong. If you actually care about the digits beyond the first 17 then you need to use a BigFloat. Anyway, but no I don’t know if there’s a way to ask ms libc for a different implementation.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: [XS] C printf() and Microsoft compilers.
by NERDVANA (Priest) on Jan 08, 2020 at 15:00 UTC

In a scientific application, that exact floating point representation could be the literal you gave it, but it could also be the result of math that has been rounded to fit in the 53 bit mantissa. For example perl -MPOSIX -e “printf ‘%.0f’, POSIX::DBL_MAX - 10000000000000000;” Now the very precise answer from gcc is wrong. If you actually care about the digits beyond the first 17 then you need to use a BigFloat.

Anyway, but no I don’t know if there’s a way to ask ms libc for a different implementation.

[reply]
[d/l]