On 11/17/22 8:53 PM, Charles R Harris wrote:
On Thu, Nov 17, 2022 at 6:30 PM Scott Ransom <sran...@nrao.edu
<mailto:sran...@nrao.edu>> wrote:
On 11/17/22 7:13 PM, Charles R Harris wrote:
>
>
> On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers <ralf.gomm...@gmail.com
<mailto:ralf.gomm...@gmail.com>
> <mailto:ralf.gomm...@gmail.com <mailto:ralf.gomm...@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 <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
<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 <http://www.nanograv.org>
Pulsar timing is one reason I wanted a quad precision time type. I thought Astropy was using a self
implemented double-double type to work around that?
That is correct. For non-compute-intensive time calculations, Astropy as a Time object that
internally uses two 64-bit floats. We use it, and it works great for high precision timekeeping over
astronomical times.
*However*, it ain't fast. So you can't do fast matrix/vector math on time differences where your
precision exceeds a single 64-bit float. That's exactly where we are with extended precision for our
pulsar timing work.
Scott
--
Scott M. Ransom Address: NRAO
Phone: (434) 296-0320 520 Edgemont Rd.
email: sran...@nrao.edu Charlottesville, VA 22903 USA
GPG Fingerprint: A40A 94F2 3F48 4136 3AC4 9598 92D5 25CB 22A6 7B65
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
