[fitsbits] [EXT] Re: 16-bit floats {External} {External}

Sat Jul 26 09:36:51 EDT 2025

Since Paul injected these statements into the conversation:

“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.”

It hasn’t been clear whether it makes sense for FITS to make any change at this point, 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?

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)?

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 is the right answer, not a binary table or FORTRAN storage order in a multi-dimensional image array. Though I find this statement somewhat useless:

“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.”
(https://en.wikipedia.org/wiki/Half-precision_floating-point_format)

Wouldn’t it be more to the point to compare half-precision to single-precision applications?

One would want to see a coherent proposal with:

  *   Science use cases
  *   Project engineering requirements
  *   A fairly comprehensive search of pertinent literature (e.g., github), including standards efforts already in progress
  *   Benchmarks and trade-offs between size and speed: Maybe FITS needs to support multiple truncated FP formats tuned variously for one or the other?

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.

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.

Rob

On 7/26/25, 5:45 AM, "fitsbits" wrote:

External Email

On Fri 2025-07-25T14:27:15-1000 Paul Hirst via fitsbits hath writ:
> I would support updating the standard to include both 16 and 128 bit floats
> as both image and binary table data types. My instinct is to just update
> the standard rather than going with an extension.
>
> I don't think it follows that this forces all packages to update - as far
> as I'm aware there's nothing that says every package has to support all
> possible FITS files. Obviously, if you want to make use of the new types,
> you'd need to use software that supports them, but that's only the same as
> for example if you want to use tables, or tile compression, you need to use
> software that supports them.

I agree. It is important that FITS not change in a way that
invalidates existing files which conform to the standard.
It is impossible for FITS to guarantee that any given software
will indefinitely read all new FITS files.
It is desirable that FITS not be like web browsers which require an
update to the software every few weeks.

I think FITS should include half precision floats into all existing
ways of storing binary data.

--
Steve Allen <sla at ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 https://www.ucolick.org/~sla/<https://www.ucolick.org/~sla> Hgt +250 m

_______________________________________________
fitsbits mailing list
fitsbits at listmgr.nrao.edu
https://listmgr.nrao.edu/mailman/listinfo/fitsbits<https://listmgr.nrao.edu/mailman/listinfo/fitsbits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20250726/c4cede80/attachment-0001.html>