[Numpy-discussion] savetxt() has fmt='%.18e' as default, but fmt='%.16e' is always sufficient

[Jeppe Dakin]

Double-precision numbers need at most 17 significant decimal digits to be 
serialised losslessly. Yet, savetxt() uses 19 by default, meaning that most 
files produced with savetxt() takes up about 9% more disk space than they need 
to, without any benefit. I have described the problem more detailed on 
Stackoverflow:
https://stackoverflow.com/questions/77535380/minimum-number-of-digits-for-exact-double-precision-and-the-fmt-18e-of-numpy

Is there any reason behind the default choice of savetxt(..., fmt='%.18e')? If 
not, why not reduce it to savetxt(..., fmt='%.16e')?
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: savetxt() has fmt='%.18e' as default, but fmt='%.16e' is always sufficient

[Jeppe Dakin]

Thanks for the explanation, Robert Kern. It seems then that indeed, these days 
the optimal default would be `fmt='%.16e'`.

The test on StackOverflow was just a quick demonstration. See also the 
description for `DBL_DECIMAL_DIG` here:
https://en.cppreference.com/w/cpp/header/cfloat

> But if your true concern is that 9% of disk space,
> you probably don't want to be using `savetxt()` in any case.
Well, I do in fact want to save as text, but I would rather not do so in an 
unnecessarily wasteful fashion. So i just set `fmt='%.16e'` myself, no biggie. 
The point, however, is that most users will not set this, and so `savetxt()` is 
a cause of wasted disk space generally, which I think should be fixed (if 
indeed we can be 100% certain that `fmt='%.16e'` is in fact always enough).
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com