[fitsbits] 16-bit floats {External}

[Arnold Rots]

Just an observation.
In the context of high resolution timing and ephemerides it has been common
to
use arrays of double precision floating point of length 2 to represent a
time stamp..
Typically, the first element would provide the integer part of the JD, the
second the decimal part.
It's the equivalent of a 128 bit floating point number, of course, and a
129 bit float
would be more elegant, but some built-in compatibility options would be
helpful.

Cheers,

  - Arnold


Arnold H Rots

Research Associate

SAO/HEAD

Center for Astrophysics | Harvard & Smithsonian

Email: arots at cfa.harvard.edu

Office: +1 617 496 7701 | Cell: +1 617 721 6756

60 Garden Street | MS 69 | Cambridge, MA 02138 | USA


cfa.harvard.edu | Facebook <http://cfa.harvard.edu/facebook> | Twitter
<http://cfa.harvard.edu/twitter> | YouTube <http://cfa.harvard.edu/youtube>
| Newsletter <http://cfa.harvard.edu/newsletter>


On Thu, Jul 24, 2025 at 9:25 AM Seaman, Robert Lewis - (rseaman) via
fitsbits <fitsbits at listmgr.nrao.edu> wrote:

> Hi Tom and all,
>
>
>
> This discussion would benefit from describing explicit science or
> engineering use cases. Which is to say, how much time and effort is it
> worth to the FITS community to add this to the standard and to the various
> libraries and applications? Will current software fail gracefully on
> encountering 16-bit floats?
>
>
>
> There is no reason to tie adopting a 16-bit format to support for 128-bit
> floats. Talk about both at the same time if folks want, but the decision
> grid would allow for the adoption of one but not the other (or for the
> adoption of neither). Alternatively, we could expand the discussion to
> embrace all possible data types and data structures, both for
> multidimensional image arrays and in binary tables, and the resulting
> implications for data compression, for instance.
>
>
>
> “I am curious” is one of the best motivators for talking about things, but
> not for changing the standard. What is the justification for this specific
> proposed change to the standard? Writing this up as a brief, quasi-formal
> proposal with its pros and cons would be a useful exercise.
>
>
>
> Statements like “16-bit floats would perform a lot better” and “16-bit
> floats would perform a lot better than using compression on 32-bit floats”
> need to be supported in such a proposal. Are these statements true? For all
> chipsets, operating systems, programming languages, libraries,
> applications, use cases? Can the performance (speed and size) be
> quantified? What does “a lot better” really mean? For example, JPEGXL
> offers the possibility of larger compression ratios than RICE, but it is
> slower.
>
>
>
> And statements like “16-bit floats would allow a larger dynamic range than
> using 16-bit ints with BSCALE/BZERO” call out for exploration of the edge
> cases and are worth maybe a figure or two in the proposal.
>
>
>
> Does anybody have a copy of IEEE 754-2008? It’s otherwise behind a
> paywall: https://ieeexplore.ieee.org/document/4610935
>
>
>
> Does anybody here regularly use 16-bit floats? Under what circumstances,
> for what projects? Images or binary tables? Has their lack in FITS been an
> impediment to realizing a project’s full potential?
>
>
>
> And finally, even in the few messages so far in this thread, there have
> been arguments built on top of the original vision of FITS purely as an
> interchange format, and others built on the evolution of FITS into an
> archival format. The two kinds of format don’t necessarily benefit from the
> same features or suffer from the same bugs.
>
>
>
> And finally, finally, discussions like this and about JPEGXL demonstrate
> that we need to revive the IAU FITS WG.
>
>
>
> Rob
>
>
>
>
>
>
>
>
>
> On 7/23/25, 5:36 AM, "fitsbits" wrote:
>
>
>
> *External Email*
>
>
> ------------------------------
>
> Hi everyone,
>
>
>
> As far as I understand, IEEE 754-2008 standardized the representation of
> 16-bit floats (as well as 128-bit floats). I was curious whether there is
> any interest in extending the FITS format to allow BITPIX=-16 and
> BITPIX=-128?
>
>
>
> I am aware of some modern projects that would benefit from having 16-bit
> floats, since they consider it to be sufficient in precision to store very
> large datasets, and using 16-bit floats would perform a lot better than
> using compression on 32-bit floats for example, and 16-bit floats would
> allow a larger dynamic range than using 16-bit ints with BSCALE/BZERO.
>
>
>
> I'm curious to hear if this has been discussed before!
>
>
>
> Thanks,
>
> Tom
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20250724/029c2c16/attachment.html>