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 cov
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
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 u
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 inpu
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
numb
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 peop
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 an
> 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 try
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, p
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. S
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
