As someone who worked on a project that used to use yapf, a word of caution
- regardless of quality of formatting versus black, it generally has not
had the resources to keep up with new releases of Python. See
https://github.com/google/yapf/issues/772
https://github.com/google/yapf/issues/993
htt
I'll note that SciPy actually does have `sinpi` and `cospi`-they just
happen to be private:
https://github.com/scipy/scipy/blob/master/scipy/special/functions.json#L58
https://github.com/scipy/scipy/blob/master/scipy/special/functions.json#L12
They are used extensively inside the module though as
> Just to speak for myself, I don't think the precise choice matters very much.
> There are arguments for consistency both ways.
I agree with this. In the absence of strong theoretical considerations
I'd fall back to a practical one-we can make ndarray generic over
dtype _right now_, while for sh
noise.
>
>
> On Sun, Apr 26, 2020 at 11:19 PM Joshua Wilson
> wrote:
>>
>> To try and add some more data points to the conversation:
>>
>> > Maybe we can go for a bit more distant name like "numpy.annotations" or
>> > whatever.
>>
>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg
>>> wrote:
>>>>
>>>> On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote:
>>>> > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
>&g
Hey everyone,
Over in numpy-stubs we've been working on typing "array like":
https://github.com/numpy/numpy-stubs/pull/66
It would be nice if the type were public so that downstream projects
could use it (e.g. it would be very helpful in SciPy). Originally the
plan was to only make it publicly a
Over in the NumPy stubs there's an issue
https://github.com/numpy/numpy-stubs/issues/41
which points out that you can in fact do something like
```
np.float32([1.0, 0.0, 0.0])
```
to construct an ndarray of float32. It seems to me that though you can
do that, it is not a best practice, and one
> That is, is this an all-or-nothing thing where as soon as we start,
> numpy-stubs becomes unusable?
Until NumPy is made PEP 561 compatible by adding a `py.typed` file,
type checkers will ignore the types in the repo, so in theory you can
avoid the all or nothing. In practice it's maybe trickier
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
