Menu
Search

Forums

Forum Index

Thread overview
How to format float unambiguously?
Aug 31, 2021
deadalnix
Aug 31, 2021
user1234
Sep 01, 2021
Nicholas Wilson
Sep 01, 2021
Ali Çehreli
Sep 01, 2021
deadalnix
Sep 01, 2021
John Colvin
Sep 01, 2021
deadalnix
August 31, 2021
Gravatar of deadalnixPosted by deadalnixReply
deadalnix
Gravatar of deadalnix


Reply

When formatting floats, as far as I can tell, one either has to pick the whole decimal gallery, or accept that the end result might be ambiguous.

For instance:

writefln!"%f"(1.); // 1.000000
writefln!"%F"(1.); // 1.000000
writefln!"%#f"(1.); // 1.000000
writefln!"%#F"(1.); // 1.000000
writefln!"%g"(1.); // 1
writefln!"%G"(1.); // 1
writefln!"%#g"(1.); // 1.000000
writefln!"%#G"(1.); // 1.000000

Specifying the precision allows to reduce it, but not increase it:

writefln!"%.1f"(1.0); // 1.0
writefln!"%.1f"(1.11111); // 1.1

Am I missing something? This problem also seem to exist when dumping value in D format. For instance:

writeln([1.0]); // [1]

Which is now an array of integers instead of floats.

August 31, 2021
Gravatar of user1234Posted by user1234
in reply to deadalnix		Reply
user1234
Gravatar of user1234
Posted in reply to deadalnix


Reply

On Tuesday, 31 August 2021 at 17:53:12 UTC, deadalnix wrote:

>

When formatting floats, as far as I can tell, one either has to pick the whole decimal gallery, or accept that the end result might be ambiguous.

For instance:

writefln!"%f"(1.); // 1.000000
writefln!"%F"(1.); // 1.000000
writefln!"%#f"(1.); // 1.000000
writefln!"%#F"(1.); // 1.000000
writefln!"%g"(1.); // 1
writefln!"%G"(1.); // 1
writefln!"%#g"(1.); // 1.000000
writefln!"%#G"(1.); // 1.000000

Specifying the precision allows to reduce it, but not increase it:

writefln!"%.1f"(1.0); // 1.0
writefln!"%.1f"(1.11111); // 1.1

Am I missing something? This problem also seem to exist when dumping value in D format. For instance:

writeln([1.0]); // [1]

Which is now an array of integers instead of floats.

ah yes, what a mess, IIRC it's

  • %.8g for floats
  • %.18g for doubles

%f is a known source of problem when dealing with serialization... like "1" looks like an integer.

September 01, 2021
Gravatar of Nicholas WilsonPosted by Nicholas Wilson
in reply to deadalnix		Reply
Nicholas Wilson
Gravatar of Nicholas Wilson
Posted in reply to deadalnix


Reply

On Tuesday, 31 August 2021 at 17:53:12 UTC, deadalnix wrote:

>

When formatting floats, as far as I can tell, one either has to pick the whole decimal gallery, or accept that the end result might be ambiguous.

I don't know what your use case is but have you tried %a which formats it as a hex float?

August 31, 2021
Gravatar of Ali ÇehreliPosted by Ali Çehreli
in reply to Nicholas Wilson		Reply
Ali Çehreli
Gravatar of Ali Çehreli
Posted in reply to Nicholas Wilson


Reply
[Sorry for the double-post Nic.]

On 8/31/21 5:31 PM, Nicholas Wilson wrote:
> On Tuesday, 31 August 2021 at 17:53:12 UTC, deadalnix wrote:
>> When formatting floats, as far as I can tell, one either has to pick the whole decimal gallery, or accept that the end result might be ambiguous.
>
> I don't know what your use case is but have you tried %a which formats it as a hex float?

I was going to suggest the same but because I did not understand anything about the question I kept it to myself. :) (What is ambiguous about 1 or 1.000000? :) )

I use %a to show differences at bit level between two executions, which should produce the same bit result.

Ali
September 01, 2021
Gravatar of John ColvinPosted by John Colvin
in reply to deadalnix		Reply
John Colvin
Gravatar of John Colvin
Posted in reply to deadalnix


Reply

On Tuesday, 31 August 2021 at 17:53:12 UTC, deadalnix wrote:

>

When formatting floats, as far as I can tell, one either has to pick the whole decimal gallery, or accept that the end result might be ambiguous.

For instance:

writefln!"%f"(1.); // 1.000000
writefln!"%F"(1.); // 1.000000
writefln!"%#f"(1.); // 1.000000
writefln!"%#F"(1.); // 1.000000
writefln!"%g"(1.); // 1
writefln!"%G"(1.); // 1
writefln!"%#g"(1.); // 1.000000
writefln!"%#G"(1.); // 1.000000

Specifying the precision allows to reduce it, but not increase it:

writefln!"%.1f"(1.0); // 1.0
writefln!"%.1f"(1.11111); // 1.1

Am I missing something? This problem also seem to exist when dumping value in D format. For instance:

writeln([1.0]); // [1]

Which is now an array of integers instead of floats.

https://github.com/libmir/mir-algorithm/blob/master/source/mir/format.d

September 01, 2021
Gravatar of deadalnixPosted by deadalnix
in reply to John Colvin		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to John Colvin


Reply

On Wednesday, 1 September 2021 at 09:38:43 UTC, John Colvin wrote:

>

https://github.com/libmir/mir-algorithm/blob/master/source/mir/format.d

This is looking good:
https://github.com/libmir/mir-algorithm/blob/master/source/mir/format.d#L739

September 01, 2021
Gravatar of deadalnixPosted by deadalnix
in reply to Ali Çehreli		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Ali Çehreli


Reply
On Wednesday, 1 September 2021 at 01:15:19 UTC, Ali Çehreli wrote:
> I was going to suggest the same but because I did not understand anything about the question I kept it to myself. :) (What is ambiguous about 1 or 1.000000? :) )
>

1 is an integer, not a float. This is what's ambiguous there.