On Thu, 2019-05-23 at 10:17 -0400, Marten van Kerkwijk wrote:
> I agree that we should not have two functions
>
> I also am rather unsure whether a ufunc is a good idea. Earlier,
> while discussing other possible additions, like `erf`, the conclusion
> seemed to be that in numpy we should just
On Thu, May 23, 2019 at 7:20 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> I agree that we should not have two functions
>
> I also am rather unsure whether a ufunc is a good idea. Earlier, while
> discussing other possible additions, like `erf`, the conclusion seemed to
> be that
I agree that we should not have two functions
I also am rather unsure whether a ufunc is a good idea. Earlier, while
discussing other possible additions, like `erf`, the conclusion seemed to
be that in numpy we should just cover whatever is in the C standard. This
suggests `sinc` should not be a
On Thu, May 23, 2019 at 3:24 AM Charles R Harris
wrote:
>
>
> On Wed, May 22, 2019 at 7:14 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> On a more general note, if we change to a ufunc, it will get us stuck
>> with sinc being the normalized version, where the units of the
Re Ralf's question:
> Can you quantify the precision improvement (approximately)?
On one level you'll get a large decrease in relative error around the
zeros of the sinc function because argument reduction is being done by
a number which is exactly representable in double precision (i.e. the
On Wed, May 22, 2019 at 7:14 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> On a more general note, if we change to a ufunc, it will get us stuck with
> sinc being the normalized version, where the units of the input have to be
> in the half-cycles preferred by signal-processing
On a more general note, if we change to a ufunc, it will get us stuck with
sinc being the normalized version, where the units of the input have to be
in the half-cycles preferred by signal-processing people rather than the
radians preferred by mathematicians.
In this respect, note that there is
> Otherwise, there should
>>> be no change except additional features of ufuncs and the move to a C
>>> implementation.
>>>
>>
> I see this is one of the functions that uses asanyarray, so what about
> impact on subclass behavior?
>
So, subclasses are passed on, as they are in ufuncs. In general,
On Wed, May 22, 2019 at 2:00 PM Ralf Gommers wrote:
>
>
> On Wed, May 22, 2019 at 7:34 PM Nathan Goldbaum
> wrote:
>
>> It might be worth using BigQuery to search the github repository public
>> dataset for usages of np.sinc with keyword arguments.
>>
>
> We spent some effort at Quansight to
On Wed, May 22, 2019 at 7:34 PM Nathan Goldbaum
wrote:
> It might be worth using BigQuery to search the github repository public
> dataset for usages of np.sinc with keyword arguments.
>
We spent some effort at Quansight to try different approaches to this.
BigQuery turns out to be suboptimal,
It might be worth using BigQuery to search the github repository public
dataset for usages of np.sinc with keyword arguments.
On Wed, May 22, 2019 at 1:05 PM Sebastian Berg
wrote:
> Hi all,
>
> there is an open PR (https://github.com/numpy/numpy/pull/12924) to
> convert `np.sinc` into a ufunc.
Hi all,
there is an open PR (https://github.com/numpy/numpy/pull/12924) to
convert `np.sinc` into a ufunc. Since it should improve general
precision in `np.sinc`, I thought we could try to move that forward a
bit. We check whether this is worth it or not in the end.
However, it would also change
12 matches
Mail list logo
