[fitsbits] 16-bit floats {External}

[Mark Taylor]

Correction: it's misleading to say that Java has support for
half-precision floats.  It's true that a Float16 class has
been introduced very recently into the Java Runtime Environment
(Java 24 released March 2025 has a class jdk.incubator.vector.Float16, 
not as yet in any Long Term Support version of the JRE), 
but most astronomical java code targets earlier versions of the JRE, 
and more importantly there is no matching float16 primitive type,
so for most purposes 16-bit floats would have to be expanded to 
32-bit floats by java code processing such values read from a
FITS file or elsewhere.

I don't believe there is any support in the Java language or
standard libraries for 128-bit floats.

This is not to argue either for or against 16-bit floats in FITS.

On Thu, 24 Jul 2025, Barrett, Paul via fitsbits wrote:

> I suggest asking the question: What FITS library cannot handle 16-bit and
> 128-bit floats?  We know that half-precision is supported in C/C++ and
> FORTRAN, which means that it is potentially available in FITSIO, CFITSIO,
> and Python/numpy that depend on these languages. It is also available in
> Java and Julia. This leaves languages such as IDL, Matlab, and R that may
> not be supported, unless the maintainers decide to eventually add those
> types. My feeling is that those who use those languages are a small
> percentage (<1 %) of the user base. It does not seem reasonable to me that
> such a small percentage of users have such a large influence on the
> development of our community. It has always been my opinion that a data
> format should not control what and how software is developed. It places an
> unnecessary constraint on the development of high quality, high performance
> software.
> 
>  -- Paul
> 
> 
> On Thu, Jul 24, 2025 at 5:01 AM jaffe via fitsbits <
> fitsbits at listmgr.nrao.edu> wrote:
> 
> > Whether a FITS storage format is supported by any programming language,
> > or even any machine processor architecture is irrelevant, FITS is a
> > transport standard.  If half-precision FP is accepted into the FITS
> > standard, this implies that the FITS reader/writers for any language or
> > architecture have to be adapted to convert the FITS data into a locally
> > functional format, e.g. 32-bit FP if local 16-bit FP is not supported.
> >
> > Walter
> >
> > On 2025-07-23 20:11, Lucio Chiappetti via fitsbits wrote:
> > > On Wed, 23 Jul 2025, Barrett, Paul via fitsbits wrote:
> > >
> > >> Yes, definitely. I have been advocating for half-precision (16-bit)
> > >> floating point for several years now for radio astronomy. In addition,
> > >> 128-bit floats
> > >
> > > Are these formats supported by any major programming language ?
> > >
> > > Is it worth supporting "exotic" formats, which might be suitable for
> > > some niche application, when most data producers often use improperly
> > > 64-bit all the times, even when overshoot ?
> > >
> > > Historically FITS went the other way round (concentrating on 16 and 32,
> > > later 64, when mainframres with 36 or 60 bits were around).
> > >
> > > _______________________________________________
> > > fitsbits mailing list
> > > fitsbits at listmgr.nrao.edu
> > > https://listmgr.nrao.edu/mailman/listinfo/fitsbits
> >
> > _______________________________________________
> > fitsbits mailing list
> > fitsbits at listmgr.nrao.edu
> > https://listmgr.nrao.edu/mailman/listinfo/fitsbits
> >
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/