On Thu, Nov 17, 2022 at 6:30 PM Scott Ransom <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>> 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 > > > 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? Chuck
_______________________________________________ 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
