[Numpy-discussion] NEP 50: deprecating np.find_common_type

As part of the work outlined in NEP 50, the function np.find_common_type will be deprecated soon after the release of NumPy 1.24. To provide feedback on this decision, please respond in the Conversation section of the pull request: https://github.com/numpy/numpy/pull/22539. -- Cheers, Inessa In

[Numpy-discussion] status of long double support and what to do about it

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. The problem ---

[Numpy-discussion] Re: status of long double support and what to do about it

Thanks Ralf, this indeed strikes a chord also from SciPy point of view. In my limited opinion, it's not just the dtype but also everything else that this dtype is going to be used in defines its proper implementation. Upstream (lapack, fft, so on) and downstream (practically everything else) does

[Numpy-discussion] Re: status of long double support and what to do about it

On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers 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

[Numpy-discussion] Re: status of long double support and what to do about it

On 11/17/22 7:13 PM, Charles R Harris wrote: On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers > 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

[Numpy-discussion] Re: status of long double support and what to do about it

On Thu, Nov 17, 2022 at 5:29 PM Scott Ransom wrote: > 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.

[Numpy-discussion] Re: status of long double support and what to do about it

On Thu, Nov 17, 2022 at 6:30 PM Scott Ransom wrote: > > > On 11/17/22 7:13 PM, Charles R Harris wrote: > > > > > > On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers > > wrote: > > > > Hi all, > > > > We have to do something about long double support. This is som

[Numpy-discussion] Re: status of long double support and what to do about it

Around 2015-2016 I created a fork of numpy with IEEE 128bit float support, but I never upstreamed it because I couldn't see a way to make it not depend on GCC/libquadmath (the licensing issue Chuck brought up). I wonder if it's possible now with the dtype changes to have different dtypes on differe

[Numpy-discussion] Re: status of long double support and what to do about it

On 11/17/22 8:53 PM, Charles R Harris wrote: On Thu, Nov 17, 2022 at 6:30 PM Scott Ransom 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 mailto:ralf.gomm...@gmail.com> >

[Numpy-discussion] Re: status of long double support and what to do about it

Hi Scott - Thanks for providing input! Do you have a minimal example that shows the type of calculations you would like to be faster with extended precision? Just so we are clear on the goal for this use case. Would you or some of your colleagues be open to helping maintain a library that adds