[Numpy-discussion] Converting np.sinc into a ufunc
sebastian at sipsolutions.net
Thu May 23 16:22:48 EDT 2019
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 cover whatever is in the C
> standard. This suggests `sinc` should not be a ufunc.
We are not adding a function though, as Robert already noted. So this
is about how much we prefer ufuncs for functions that are a perfect
The accuracy can certainly be improved, but it involves some branching,
so I think we would see at least 50% speed penalty compared to the
ufunc version in the end (right now the speed improvement is about 20%
for larger arrays, much more for smaller of course).
I do not have a perfect feeling about what the precision improvements
mean exactly here, but I posted some relative errors below as
additional stats .
Overall I think I would be pretty neutral if there was no gain at all
(as there is some loss of maintainability). Here it seems that we have
some decent enhancement as well though, so I am slightly in favor.
 And here maybe an additional point for better relative precision:
xarr = np.linspace(0, 2.1, 200000)
res = 
for x in xarr:
res.append((np.sinc(x) - mpmath.sincpi(x))/mpmath.sincpi(x))
res = np.asarray(res, dtype=object)
we probably should have tests if we add this.
> -- Marten
> p.s.`scipy.special.sinc` *is* `np.sinc`
> p.s.2 The accuracy argument is not in itself an argument for a ufunc,
> as it could be done in python too.
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the NumPy-Discussion