<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>Thanks for all the feedback! And thanks Paul for offering to write up a case, let me know if I can help. A few thoughts/comments regarding things people have mentioned here:</div><div><br></div><div>First I think we should focus on 16-bit floats and not consider 128-bit floats for now, since the latter are a lot more complicated as in fact most languages don't even truly support 128 bits of precision but rather 80 or 64 depending on the platform, even for types advertised as 128-bit. 16-bits are a lot more straightforward because either languages represent them natively, or 32-bit floats can be used in memory without loss of precision. I think adding 16-bit float support would have the biggest immediate impact, and I was only asking about 128-bit floats at the same time out of curiosity.</div><div><br></div><div>Here is a prototype implementation for supporting 16-bit float in Primary and ImageHDU extensions in astropy, which is a pretty independent implementation from CFITSIO (we only use CFITSIO for some of the tile compression/decompression algorithms):</div><div><br></div><div><a href="https://github.com/astrofrog/astropy/pull/139" target="_blank">https://github.com/astrofrog/astropy/pull/139</a></div><div><br></div><div>Obviously this needs tests, and similar changes to support 16-bit floats in tables, but it is a pretty simple change (2 lines added!). I don't think supporting 16-bit floats will be very difficult for most packages compared to some other changes, and indeed for languages that don't natively support representing 16-bit floats they could just use 32-bit floats instead in memory.</div><div><br></div><div>The main use cases that interest me have been mentioned in this thread:<br></div><div><br></div><div>- Radio cubes, which can be very large (100s of Gb or more in future) and can in principle have high dynamic range, say 1e6 or more. Because of the dynamic range, using 16-bit ints with BSCALE/BZERO isn't really an option, so currently one would need to use 32-bit floats. However, in many cases, if it was an option, using 16-bit floats would have sufficient significant digits while also allowing large dynamic ranges.<br></div><div><br></div><div>- HiPS datasets, which can be very large (Tb+). If the tiles are stored in FITS, 16-bit floats would in general be sufficient for the purposes of data visualization, and would be faster to access than having to decompress compressed data (Then of course there is a combination of this and radio data - the proposed HiPS3D format can in principle be used to serve gigantic datasets)</div><div><br></div><div>An alternative is to use e.g. RICE compression on 32-bit floats, but this has a large computational cost at these data volumes. I did some preliminary tests with the astropy 16-bit float implementation above with a 'small radio cube which was 7Gb in 32-bit floats, and writing out the data as 16-bit floats was 15x faster than RICE-compressing it. Accessing the full data was at least 2x faster with 16-bit floats than accessing the RICE-compressed 32-bit data. The biggest performance benefit of 16-bit floats would however be that tools could access only the exact data that is needed (via e.g. memory-mapping, or range requests when dealing with remote data) without having to decompress tiles. For instance, if I wanted to access a single spaxel in my example cube, it is again almost 15x faster to do so with 16-bit floats than with compressed data. Obviously this will change a little depending on the tiling parameters, but in fact that is another benefit - whereas with tiled compression it is often impossible to optimise all use cases in terms of chunk size/shape, there is no such choice to make for 16-bit floats.</div><div><br></div><div>Regarding comments about the FITS working group and bringing in new people, with my astropy.io.fits maintainer hat on I would be happy to volunteer if there was indeed interest in getting new people on board.</div><div><br></div><div>Cheers,</div><div>Tom</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 25 Jul 2025 at 03:08, Barrett, Paul via fitsbits <<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">No, FITS does not need to wait on the sub-16-bit standard. I see no use for it in the foreseeable future. I mention it to emphasize the fact that if one thinks 16-bits floats are not useful, then sub-16-bits floats are even less so.<div><br></div><div>Note that the use of 16-bit floats is kind of a chicken and egg problem. If there is no astronomical data format to store them, then no one is going to write software to use them. And if no one writes software to use them, then there are no use cases to justify including them in an astronomical data format.</div><div><br></div><div>I'll try to find the time late next week to write up a use case. I've got some deadlines next week.</div><div><br></div><div> -- Paul</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 24, 2025 at 9:46 PM Seaman, Robert Lewis - (rseaman) <<a href="mailto:rseaman@arizona.edu" target="_blank">rseaman@arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>





<div lang="EN-US">
<div>
<p class="MsoNormal">In that case, it should be easy to write up a few specific astronomical use cases. And collect citations to pertinent literature.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Does FITS need to wait on the new sub-16-bit standard before taking action?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Rob<u></u><u></u></p>
<div style="border-width:medium medium 1pt;border-style:none none solid;border-color:currentcolor currentcolor windowtext;padding:0in 0in 1pt">
<p class="MsoNormal" style="border:medium;padding:0in"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div id="m_-7417298848443971845m_-2084045193119436930m_-4892217606970438890mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">On 7/24/25, 5:08 PM, "fitsbits" wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<div>
<div>
<p align="center" style="margin-left:0.5in;text-align:center"><strong><span style="font-family:Helvetica;color:red">External Email</span></strong><b><span style="font-family:Helvetica"><u></u><u></u></span></b></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-family:Helvetica"><u></u> <u></u></span></p>
<div class="MsoNormal" align="center" style="margin-left:0.5in;text-align:center">
<span style="font-family:Helvetica">
<hr size="0" width="92%" align="center">
</span></div>
</div>
<p class="MsoNormal" style="margin-left:0.5in">Malcom:<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Just because we are old does not mean that we are not working on state-of-the art software. The reason for wanting 16-bit floats is for this specific reason. Radio astronomy software would benefit from 16-bit floats.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">All:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">As I noted previously, the IEEE is working on sub-16-bit (<= 15) floating point formats for AI. There is clearly a need for such data types in the machine learning community. Currently, hardware vendors are using
 various sub-16-bit formats. The new standard is meant to standardize on a common one, just like IEEE 754 did decades ago.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> -- Paul<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">On Thu, Jul 24, 2025 at 6:32 PM Malcolm J. Currie via fitsbits <<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:0.5in">Being (allegedly) retired and having little contact with the<br>
astronomical programming world post COVID, it's no surprise that<br>
I too was unaware of 16-bit floats before this discussion.<br>
<br>
My sympathies are with Walter's view, as I'm inclined towards regarding<br>
FITS as an interchange format rather than a processing format.  My bias<br>
is partly due to having our own flexible and extensible format in<br>
Starlink.  I'm wary of additions to the standard that have a quite<br>
limited usage solely for FITS as a working format.<br>
<br>
I agree with the points and questions made by Rob, especially how widely<br>
would these two additions be used and evidence of their benefits.  A<br>
document for discussion covering these points, how the new data types<br>
would be implemented, and the implications for existing software<br>
packages should be presented.  In many packages the float16 FITS data<br>
would presumably have to be converted to another data type, or say it's<br>
not supported.<br>
<br>
Starlink's data system is now built on HDF5 (rather than the in-house<br>
HDS that preceded it).  A quick search turned up an RFC to add 16-bit<br>
floats to HDF5, and a long user discussion of the RFC, but I've yet to<br>
find HDF's justification for the introduction of float16, or whether it<br>
has been implemented.<br>
<br>
Wikipedia, that trusty source of knowledge and wisdom,<br>
(<a href="https://en.wikipedia.org/wiki/Half-precision_floating-point_format" target="_blank">https://en.wikipedia.org/wiki/Half-precision_floating-point_format</a>)<br>
relates that the concept has been around as early as 1982.  Also I'd<br>
forgotten IEEE 754 had a binary16, presumably because there wasn't a<br>
perceived need and it wasn't in the floating-point addition to FITS.<br>
We already had BSCALE/BZERO to increase the dynamic range.  The<br>
Wikipedia entry does give some reasons for using 16-bit floats, such as<br>
machine learning, and lists programming languages that support it, but<br>
I'd certainly like to hear more on potential benefits in astronomy.<br>
<br>
Lucio:<br>
> That is true, and it was what I referred to as the early times when one<br>
> could write a reader of FITS magtapes on 36-bit or 60-bit mainframes. Or<br>
> different endianness.<br>
<br>
Hence the strange, to a young audience, 2880-byte logical record length.<br>
That accompanies the restrictive 80-byte headers that must look so<br>
antiquated to postdocs and students.  Are they doing their own thing<br>
rather than join in the FITS discussion?  Most of the participants in<br>
this thread are of, let's say, a certain vintage.<br>
<br>
Lucio:<br>
> Also I seem to remember in the past there was a rule, or at least a<br>
> practice, that a new feature has tp be supported by two independent<br>
> existing implementattions.<br>
<br>
Indeed.<br>
<br>
>> And finally, finally, discussions like this and about JPEGXL demonstrate<br>
>> that we need to revive the IAU FITS WG.<br>
><br>
> And that's even more true than all the rest, specially for a delicate item<br>
> like basic data formats.<br>
<br>
Yes but who would serve on it?  There needs to be a mix of decades of<br>
FITS experience, combined with a new generation who work with<br>
cutting-edge data and state-of the-art tools or who are designing<br>
upcoming major data-generating projects.<br>
<br>
Malcolm<br>
<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>

</div></blockquote></div>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</blockquote></div>