<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 2 1 2 1 8 4 8 7 8;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:903836747;
mso-list-type:hybrid;
mso-list-template-ids:1214400674 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Since Paul injected these statements into the conversation:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">“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.”<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal">It hasn’t been clear whether it makes sense for FITS to make any change
<u>at this point</u>, even if a change were strongly motivated (which it has yet to be). Do we need 16-bit floats? Or do we need a general binary format for packing arbitrary precision floats?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I believe LSST will be using the default Rice algorithm with tile compression. (Please, somebody correct me – it can be disquietingly difficult to track down answers to such basic questions with LSST.) It may be that the majority of astronomical
pixels are already Rice coded, but they soon will be. The point being that FITS binary tables (including FITS tile-compressed images) are more unary tables than binary ones. An absurd talking point, perhaps, but do we have to generalize this discussion (once
somebody introduces enough use cases to justify a change to the standard)?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And if one purpose of a shorter floating point format is speed, ought FITS look more carefully at other aspects of the data structures? Maybe a hand-tailored FITS extension
<u>is</u> the right answer, not a binary table or FORTRAN storage order in a multi-dimensional image array. Though I find this statement somewhat useless:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><i>“Depending on the computer, half-precision can be over an order of magnitude faster than double precision, e.g. 550 PFLOPS for half-precision vs 37 PFLOPS for double precision on one cloud provider.”<o:p></o:p></i></p>
<p class="MsoNormal" style="margin-left:.5in">(https://en.wikipedia.org/wiki/Half-precision_floating-point_format)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wouldn’t it be more to the point to compare half-precision to single-precision applications?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One would want to see a coherent proposal with:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Science use cases<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Project engineering requirements<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">A fairly comprehensive search of pertinent literature (e.g., github), including standards efforts already in progress<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Benchmarks and trade-offs between size and speed: Maybe FITS needs to support multiple truncated FP formats tuned variously for one or the other?<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">From the tile compression efforts, I’d guess this is closer to weeks of effort (or months, depending on the rabbit holes) than years of toil.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If this is in support of AI, what does ChatGPT say we should do? Maybe that’s the answer to the future of the IAU FITS WG: ChatGPT can chair the WG.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Rob<o:p></o:p></p>
<div style="mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 7/26/25, 5:45 AM, "fitsbits" wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br>
External Email<br>
<br>
On Fri 2025-07-25T14:27:15-1000 Paul Hirst via fitsbits hath writ:<br>
> I would support updating the standard to include both 16 and 128 bit floats<br>
> as both image and binary table data types. My instinct is to just update<br>
> the standard rather than going with an extension.<br>
><br>
> I don't think it follows that this forces all packages to update - as far<br>
> as I'm aware there's nothing that says every package has to support all<br>
> possible FITS files. Obviously, if you want to make use of the new types,<br>
> you'd need to use software that supports them, but that's only the same as<br>
> for example if you want to use tables, or tile compression, you need to use<br>
> software that supports them.<br>
<br>
I agree. It is important that FITS not change in a way that<br>
invalidates existing files which conform to the standard.<br>
It is impossible for FITS to guarantee that any given software<br>
will indefinitely read all new FITS files.<br>
It is desirable that FITS not be like web browsers which require an<br>
update to the software every few weeks.<br>
<br>
I think FITS should include half precision floats into all existing<br>
ways of storing binary data.<br>
<br>
<br>
--<br>
Steve Allen <sla@ucolick.org> WGS-84 (GPS)<br>
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855<br>
1156 High Street Voice: +1 831 459 3046 Lng -122.06015<br>
Santa Cruz, CA 95064 <a href="https://www.ucolick.org/~sla">
https://www.ucolick.org/~sla/</a> Hgt +250 m<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
fitsbits@listmgr.nrao.edu<br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><o:p></o:p></p>
</div>
</body>
</html>