www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to format float unambiguously?

reply 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.
Aug 31
next sibling parent 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.
Aug 31
prev sibling next sibling parent reply 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?
Aug 31
parent reply =?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
Aug 31
parent 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.
Sep 01
prev sibling parent reply 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
Sep 01
parent 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
Sep 01