On 11/17/22 7:13 PM, Charles R Harris wrote:
>
>
> On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers <ralf.gommers@gmail.com
> <mailto:ralf.gommers@gmail.com>> wrote:
>
>     Hi all,
>
>     We have to do something about long double support. This is something I wanted to propose a long
>     time ago already, and moving build systems has resurfaced the pain yet again.
>
>     This is not a full proposal yet, but the start of a discussion and gradual plan of attack.
<snip>
> I would agree that extended precision is pretty useless, IIRC, it was mostly intended as an accurate
> way to produce double precision results. That idea was eventually dropped as not very useful. I'd
> happily do away with subnormal doubles as well, they were another not very useful idea. And strictly
> speaking, we should not support IBM double-double either, it is not in the IEEE standard.
>
> That said, I would like to have a quad precision type. That precision is useful for some things, and
> I have a dream that someday it can be used for a time type. Unfortunately, last time I looked
> around, none of the available implementations had a NumPy compatible license.
>
> The tricky thing here is to not break downstream projects, but that may be unavoidable. I suspect
> the fallout will not be that bad.
>
> Chuck

A quick response from one of the leaders of a team that requires 80bit extended precision for
astronomical work...

"extended precision is pretty useless" unless you need it. And the high-precision pulsar timing
community needs it. Standard double precision (64-bit) values do not contain enough precision for us
to pass relative astronomical times via a single float without extended precision (the precision
ends up being at the ~1 microsec level over decades of time differences, and we need it at the
~1-10ns level) nor can we store the measured spin frequencies (or do calculations on them) of our
millisecond pulsars with enough precision. Those spin frequencies can have 16-17 digits of base-10
precision (i.e. we measure them to that precision). This is why we use 80-bit floats (usually via
Linux, but also on non X1 Mac hardware if you use the correct compilers) extensively.

Numpy is a key component of the PINT software to do high-precision pulsar timing, and we use it
partly *because* it has long double support (with 80-bit extended precision):
https://github.com/nanograv/PINT
And see the published paper here, particularly Sec 3.3.1 and footnote #42:
https://ui.adsabs.harvard.edu/abs/2021ApJ...911...45L/abstract

Going to software quad precision would certainly work, but it would definitely make things much
slower for our matrix and vector math.

We would definitely love to see a solution for this that allows us to get the extra precision we
need on other platforms besides Intel/AMD64+Linux (primarily), but giving up extended precision on
those platforms would *definitely* hurt. I can tell you that the pulsar community would definitely
be against option "B". And I suspect that there are other users out there as well.

Scott
NANOGrav Chair
www.nanograv.org