<div dir="ltr">Malcom:<div><br></div><div>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.</div><div><br></div><div>All:</div><div>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.</div><div><br></div><div> -- Paul</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 24, 2025 at 6:32 PM Malcolm J. Currie via fitsbits <<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</blockquote></div>