• deadalnix (19/19) Aug 31 2021 When formatting floats, as far as I can tell, one either has to
• user1234 (6/26) Aug 31 2021 ah yes, what a mess, IIRC it's
• Nicholas Wilson (3/6) Aug 31 2021 I don't know what your use case is but have you tried %a which
• =?UTF-8?Q?Ali_=c3=87ehreli?= (10/13) Aug 31 2021 the whole decimal gallery, or accept that the end result might be ambigu...
• deadalnix (2/5) Sep 01 2021 1 is an integer, not a float. This is what's ambiguous there.
• John Colvin (2/22) Sep 01 2021 https://github.com/libmir/mir-algorithm/blob/master/source/mir/format.d
• deadalnix (3/4) Sep 01 2021 This is looking good:

deadalnix <deadalnix gmail.com> writes:

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.

user1234 <user1234 1234.de> writes:

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.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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?

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

[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

deadalnix <deadalnix gmail.com> writes:

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.

John Colvin <john.loughran.colvin gmail.com> writes:

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

deadalnix <deadalnix gmail.com> writes:

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