printing variable length floats

[Ouroborus777]

I've been messing around with printing floats. It seems that printf()
is only capable of printing the fractional portion at a fixed length.
Is there some way to print floats such that the full fraction is shown
but without the trailing zeroes? I realize that this could be an
exercise in string manipulation (ie: stringify the float giving a
length that's longer than the float could possibly be then trim the
trailing zeroes) but I would prefer to do this as modification

What I have ("%.16e"):
-9.0673828125000 000e-001
-4.9169921875000 000e-001
-4.2138671875000 000e-001
-3.6889648437500 000e-001
-2.4206542968750 000e-001
-2.0385742187500 000e-001
0.0000000000000 000e+000
4.3029785156250 000e-003
4.4750976562500 000e-001
7.2753906250000 000e-001
7.8857421875000 000e-001
8.7060546875000 000e-001
8.7890625000000 000e-001
8.9794921875000 000e-001
8.7011718750000 000e-001

What I would like:
-9.0673828125e-1
-4.9169921875e-1
-4.2138671875e-1
-3.68896484375e-1
-2.420654296875e-1
-2.03857421875e-1
0 (or 0.0, or 0.0e+0, but I would prefer just 0)
4.302978515625e-3
4.47509765625e-1
7.275390625e-1
7.8857421875e-1
8.7060546875e-1
8.7890625e-1
8.9794921875e-1
8.701171875e-1

So, any suggestions or maybe point me to some code?

[Ouroborus777]

On Aug 23, 5:23*am, Ouroborus777 <deadchic...@gm ail.comwrote:

I've been messing around with printing floats. It seems that printf()
is only capable of printing the fractional portion at a fixed length.
Is there some way to print floats such that the full fraction is shown
but without the trailing zeroes? I realize that this could be an
exercise in string manipulation (ie: stringify the float giving a
length that's longer than the float could possibly be then trim the
trailing zeroes) but I would prefer to do this as modification

err, clicked send to early. I meant to continue:

... but I would prefer to do this as a modification to printf.

[Bartc]

"Ouroborus7 77" <de*********@gm ail.comwrote in message
news:01******** *************** ***********@t1g 2000pra.googleg roups.com...

I've been messing around with printing floats. It seems that printf()
is only capable of printing the fractional portion at a fixed length.
Is there some way to print floats such that the full fraction is shown
but without the trailing zeroes? I realize that this could be an
exercise in string manipulation (ie: stringify the float giving a
length that's longer than the float could possibly be then trim the
trailing zeroes) but I would prefer to do this as modification

What I have ("%.16e"):
-9.0673828125000 000e-001
0.0000000000000 000e+000

What I would like:
-9.0673828125e-1
0 (or 0.0, or 0.0e+0, but I would prefer just 0)

So, any suggestions or maybe point me to some code?

Try using g instead of e.
--
Bartc

[Gordon Burditt]

>I've been messing around with printing floats. It seems that printf()

>is only capable of printing the fractional portion at a fixed length.
Is there some way to print floats such that the full fraction is shown
but without the trailing zeroes?

The number of digits you get might be surprising. For example, 0.1
as a double ends up with 55 digits, since it can't be represented
exactly. And even the slightest roundoff error can change the
number of digits.

0.1 as long double:
Before: 0.0999999999999 999999945789891 375724778299627 359956502914428 710937500000000 0000000
Value: 0.1000000000000 000000013552527 156068805425093 160010874271392 822265625000000 0000000
After: 0.1000000000000 000000081315162 936412832550558 960065245628356 933593750000000 0000000

0.1 as double:
Before: 0.0999999999999 999916733273153 113259468227624 893188476562500 00
Value: 0.1000000000000 000055511151231 257827021181583 404541015625000 00
After: 0.1000000000000 000194289029309 402394574135541 915893554687500 00

0.1 as float:
Before: 0.0999999940395 355224609375000 000000000000000 000000000000000 00
Value: 0.1000000014901 161193847656250 000000000000000 000000000000000 00
After: 0.1000000089406 967163085937500 000000000000000 000000000000000 00

>I realize that this could be an
exercise in string manipulation (ie: stringify the float giving a
length that's longer than the float could possibly be then trim the
trailing zeroes) but I would prefer to do this as modification

What I have ("%.16e"):
-9.0673828125000 000e-001
-4.9169921875000 000e-001
-4.2138671875000 000e-001
-3.6889648437500 000e-001
-2.4206542968750 000e-001
-2.0385742187500 000e-001
0.000000000000 0000e+000
4.302978515625 0000e-003
4.475097656250 0000e-001
7.275390625000 0000e-001
7.885742187500 0000e-001
8.706054687500 0000e-001
8.789062500000 0000e-001
8.979492187500 0000e-001
8.701171875000 0000e-001

What I would like:
-9.0673828125e-1
-4.9169921875e-1
-4.2138671875e-1
-3.68896484375e-1
-2.420654296875e-1
-2.03857421875e-1
0 (or 0.0, or 0.0e+0, but I would prefer just 0)
4.302978515625 e-3
4.4750976562 5e-1
7.275390625e-1
7.8857421875 e-1
8.7060546875 e-1
8.7890625e-1
8.9794921875 e-1
8.701171875e-1

So, any suggestions or maybe point me to some code?

[Ouroborus777]

On Aug 23, 6:02*am, "Bartc" <[e-mail] mwrote:

Try using g instead of e.

Ah, that does the trick. By itself, it still clips to 7 significant
digits but with "%.99g", it works great.

[Joe Wright]

Gordon Burditt wrote:

The number of digits you get might be surprising. For example, 0.1
as a double ends up with 55 digits, since it can't be represented
exactly. And even the slightest roundoff error can change the
number of digits.

0.1 as long double:
Before: 0.0999999999999 999999945789891 375724778299627 359956502914428 710937500000000 0000000
Value: 0.1000000000000 000000013552527 156068805425093 160010874271392 822265625000000 0000000
After: 0.1000000000000 000000081315162 936412832550558 960065245628356 933593750000000 0000000

0.1 as double:
Before: 0.0999999999999 999916733273153 113259468227624 893188476562500 00
Value: 0.1000000000000 000055511151231 257827021181583 404541015625000 00
After: 0.1000000000000 000194289029309 402394574135541 915893554687500 00

0.1 as float:
Before: 0.0999999940395 355224609375000 000000000000000 000000000000000 00
Value: 0.1000000014901 161193847656250 000000000000000 000000000000000 00
After: 0.1000000089406 967163085937500 000000000000000 000000000000000 00

Your representations are deceptively wide. The 64-bit mantissa of long
double has about 19 digits of precision. The 53-bit double about 16 digits.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Gordon Burditt]

>The number of digits you get might be surprising. For example, 0.1

>as a double ends up with 55 digits, since it can't be represented
exactly. And even the slightest roundoff error can change the
number of digits.

0.1 as long double:
Before:

0.099999999999 999999994578989 137572477829962 735995650291442 871093750000000 00000000

>Value:

0.100000000000 000000001355252 715606880542509 316001087427139 282226562500000 00000000

>After:

0.100000000000 000000008131516 293641283255055 896006524562835 693359375000000 00000000

>>
0.1 as double:
Before: 0.0999999999999 999916733273153 113259468227624 893188476562500 00
Value: 0.1000000000000 000055511151231 257827021181583 404541015625000 00
After: 0.1000000000000 000194289029309 402394574135541 915893554687500 00

0.1 as float:
Before: 0.0999999940395 355224609375000 000000000000000 000000000000000 00
Value: 0.1000000014901 161193847656250 000000000000000 000000000000000 00
After: 0.1000000089406 967163085937500 000000000000000 000000000000000 00

Your representations are deceptively wide. The 64-bit mantissa of long
double has about 19 digits of precision. The 53-bit double about 16 digits.

I'm still printing the exact value that is present in the floating-point
variable. There's nothing wrong with that, especially when you're
talking about and/or debugging issues of floating-point roundoff.

Granted, whatever calculation produced this value does not have
this much precision.

[Ouroborus777]

On Aug 24, 10:18*pm, [e-mail] rditt.org (Gordon Burditt) wrote:

Granted, whatever calculation produced this value does not have
this much precision.

For the curious, they're from a 3D model file. The values are stored
as 16-bit reals. I'm using POV-Ray to render the data. While I
probably don't need what relatively little precision real16 offers, it
makes me happy in an OCD kind of way.