# Floating point precision in fits header keywords **URL:** \ **Category:** Astropy\ **Created:** [March 11, 2022, 10:23pm UTC](https://community.openastronomy.org/t/floating-point-precision-in-fits-header-keywords/301 "2022-03-11T22:23:47Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![hamogu](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/hamogu/32/93_2.png) [@hamogu](https://community.openastronomy.org/u/hamogu)\ **Post date:** [March 11, 2022, 10:23pm UTC](https://community.openastronomy.org/t/floating-point-precision-in-fits-header-keywords/301/1 "2022-03-11T22:23:47Z")
reposting here so that search engines can find this discussion for the future We’ve noticed a bug/glitch in the way floating point values are written to header cards (in our usecase, through fits.setval). This is probably an underlying glitch in the C library. Our institution requires having floating-point keyword values in a given precision format. One said values happens to be -99.9, to be written as %.1f format. A call to fits.setval(file, ‘D\_APDTI’, -99.9) results in the file header showing: D\_APDTI = -99.90000000000001 / APD coolant inlet temperature (degC) Where D\_APDTI = -99.9 / APD coolant inlet temperature (degC) is expected. Writing a string is not appropriate, e.g. fits.setval(file, ‘D\_APDTI’, ‘%.2f’ % (-99.9,), as it results in a single-quoted string in the header: D\_APDTI = ‘-99.9’ / APD coolant inlet temperature (degC) Please let us know of the appropriate way to enforce float formatting, or of a known workaround. This issue may very well be a classic one, and I apologize for the inconvenience in that case. ---
**Author:** ![hamogu](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/hamogu/32/93_2.png) [@hamogu](https://community.openastronomy.org/u/hamogu)\ **Post date:** [March 12, 2022, 3:03am UTC](https://community.openastronomy.org/t/floating-point-precision-in-fits-header-keywords/301/2 "2022-03-12T03:03:59Z")
I think what’s happening happening here is that -99.9 is not an exact representation of a binary number (see [15. Floating Point Arithmetic: Issues and Limitations — Python 3.9.10 documentation](https://docs.python.org/3.9/tutorial/floatingpoint.html)). Which version of Python are you using? Some of those formatting issues are supposed to be solved in recent versions. Also, instead of `fits.setval(file, ‘D_APDTI’, -99.9)` you could try to set the header directly `header['D_APDTI'] = -99.9`. I don’t know if that makes a difference; I’ve never looked into code inside of the fits module, but that’s the things I will try. ---
**Author:** ![hamogu](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/hamogu/32/93_2.png) [@hamogu](https://community.openastronomy.org/u/hamogu)\ **Post date:** [March 12, 2022, 3:14am UTC](https://community.openastronomy.org/t/floating-point-precision-in-fits-header-keywords/301/3 "2022-03-12T03:14:48Z")
Here is a minimal example for other trying to reproduce the problem to help with debugging: ```auto from astropy.io import fits # Just use table to quickly make a short fits file to experiment on from astropy.table import Table tab = Table({'a': [1,2]}) tab.write('text.fits') fits.setval('text.fits', 'D_APDTI', value=-99.9) fits.setval('text.fits', 'D_APDTI2', value=23) ``` Then, outside of Python (e.g. `less text.fits`), I see: ```auto SIMPLE = T / conforms to FITS standard BITPIX = 8 / array data type NAXIS = 0 / number of array dimensions EXTEND = T D_APDTI = -99.90000000000001 D_APDTI2= 23 END ``` So, I can reproduce the problem (Python 3.9, astropy 5.0) but I don’t have a solution. -99.9 is not the only value where this happens; one can get that with several other numbers. It’s just one of the numbers that happens to off in binary representation just enough to show up here. I think it’s one of those cases where you can’t have a solution: If you want to control exactly how it’s formatted, you need to use a string. If you can’t use a string, you’ll get the binary representation as good as it gets. Depending on your machine architecture, you might be able to use higher precision numbers to avoid that issue (e.g. `numpy.float128`), but on my computer 64-bit floats is the best that numpy offers me. If you disagree and believe that this is a bug that should be fixed, we’d appreciate a bug report on [Issues · astropy/astropy · GitHub](https://github.com/astropy/astropy/issues/) (feel free to copy my minimal example above into the issue description). ---
**Author:** ![hamogu](https://dub1.discourse-cdn.com/flex005/user_avatar/community.openastronomy.org/hamogu/32/93_2.png) [@hamogu](https://community.openastronomy.org/u/hamogu)\ **Post date:** [March 12, 2022, 12:06pm UTC](https://community.openastronomy.org/t/floating-point-precision-in-fits-header-keywords/301/4 "2022-03-12T12:06:17Z")
After sleeping on it, I’ve decided to report that as a bug: [Floating point precision in fits header keywords · Issue #12954 · astropy/astropy · GitHub](https://github.com/astropy/astropy/issues/12954) Let’s see what the maintainers of astropy.io.fits think.