[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Thomas Caswell]

 CPython shouldn't either.
>
> I'll make the same argument now that I made in 2016 about dropping 2.7
> support https://www.asmeurer.com/blog/posts/moving-away-from-python-2/.
> If users want to use older versions of Python, that's their
> prerogative, but they then have no reason to also expect to be able to
> use the latest versions of libraries.
>
> Aaron Meurer
>
> >
> > Current numbers (as of May 4th) for downloads of manylinux wheels:
> > * 2.7: 2%
> > * 3.5: 0.3%
> > * 3.6: 7.4%
> > * 3.7: 20.4%
> > * 3.8: 23.0%
> > * 3.9: 15.3%
> > * 3.10: 20.8%
> > * 3.11: 8.4%
> > * 3.12: 2.3%
> >
> > So only 30% of users have Python 3.10+ or newer. Most smaller or newer
> projects can more than double their user base by supporting  3.8+. I could
> even argue that 3.7+ is still helpful for a new project. Once a library is
> large and stable, then it can go higher, even 3.13+ and not hurt anyone
> unless there's a major development.
> >
> > Little rant finished. :)
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: asmeu...@gmail.com
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

Re: [Numpy-discussion] record data previous to Numpy use

[Thomas Caswell]

Are you tied to ASCII files?   HDF5 (via h5py or pytables) might be a
better storage format for what you are describing.

Tom

On Wed, Jul 5, 2017 at 8:42 AM  wrote:

> Dear all
>
>
> I’m sorry if my question is too basic (not fully in relation to Numpy –
> while it is to build matrices and to work with Numpy afterward), but I’m
> spending a lot of time and effort to find a way to record data from an asci
> while, and reassign it into a matrix/array … with unsuccessfully!
>
>
> The only way I found is to use *‘append()’* instruction involving dynamic
> memory allocation. :-(
>
>
> From my current experience under Scilab (a like Matlab scientific solver),
> it is well know:
>
>1. Step 1 : matrix initialization like *‘np.zeros(n,n)’*
>2. Step 2 : record the data
>3. and write it in the matrix (step 3)
>
>
> I’m obviously influenced by my current experience, but I’m interested in
> moving to Python and its packages
>
>
> For huge asci files (involving dozens of millions of lines), my strategy
> is to work by ‘blocks’ as :
>
>- Find the line index of the beginning and the end of one block (this
>implies that the file is read ounce)
>- Read the block
>- (process repeated on the different other blocks)
>
>
> I tried different codes such as bellow, but each time Python is telling me *I
> cannot mix iteration and record method*
>
> #
>
> position = []; j=0
>
> with open(PATH + file_name, "r") as rough_ data:
>
> for line in rough_ data:
>
> if *my_criteria* in line:
>
> position.append(j) ## huge blocs but limited in number
>
> j=j+1
>
>
> i = 0
>
> blockdata = np.zeros( (size_block), dtype=np.float)
>
> with open(PATH + file_name, "r") as f:
>
>  for line in itertools.islice(f,1,size_block):
>
>  blockdata [i]=float(f.readline() )
>
>  i=i+1
>
>  #
>
>
> Should I work on lists using f.readlines (but this implies to load all the
> file in memory).
>
>
> *Additional question*:  can I use record with vectorization, with ‘i
> =np.arange(0,65406)’ if I remain  in the previous example
>
>
>
> Thanks for your time and comprehension
>
> (I’m obviously interested by doc references speaking about those specific
> tasks)
>
>
> Paul
>
>
> PS: for Chuck:  I’ll had a look to pandas package but in an code
> optimization step :-) (nearly 2000 doc pages)
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] pytest and degrees of separation.

[Thomas Caswell]

Going with option 2 is probably the best option so that you can use pytest
fixtures and parameterization.

Might be worth looking at how Matplotlib re-arranged things on our master
branch to maintain back-compatibility with nose-specific tools that were
used by down-stream projects.

Tom

On Tue, Jul 11, 2017 at 4:22 PM Sebastian Berg 
wrote:

> On Tue, 2017-07-11 at 14:49 -0600, Charles R Harris wrote:
> > Hi All,
> >
> > Just looking for opinions and feedback on the need to keep NumPy from
> > having a hard nose/pytest dependency. The options as I see them are:
> >
> > pytest is never imported until the tests are run -- current practice
> > with nose
> > pytest is never imported unless the testfiles are imported -- what I
> > would like
> > pytest is imported together when numpy is -- what we need to avoid.
> > Currently the approach has been 1), but I think 2) makes more sense
> > and allows more flexibility.
>
>
> I am not quite sure about everything here. My guess is we can do
> whatever we want when it comes to our own tests, and I don't mind just
> switching everything to pytest (I for one am happy as long as I can run
> `runtests.py` ;)).
> When it comes to the utils we provide, those should keep working
> without nose/pytest if they worked before without it I think.
>
> My guess is that all your options do that, so I think we should take
> the one that gives the nicest maintainable code :). Though can't say I
> looked enough into it to really make a well educated decision, that
> probably means your option 2.
>
> - Sebastian
>
>
>
> > Thoughts?
> > Chuck
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: SciPy 1.0 beta release

[Thomas Caswell]

It seems major versions are in the air!

For matplotlib 2.0 we put together
http://matplotlib.org/users/dflt_style_changes.html for the style changes
which shows the new behavior, the old behavior, and how to get the old
behavior back.


Tom

On Sun, Sep 17, 2017 at 10:48 AM Ilhan Polat  wrote:

> Well also thank you Ralf, for going through all those issues one by one
> from all kinds of topics. Must be really painstakingly tedious.
>
>
> On Sun, Sep 17, 2017 at 12:48 PM, Ralf Gommers 
> wrote:
>
>> Hi all,
>>
>> I'm excited to be able to announce the availability of the first beta
>> release of Scipy 1.0. This is a big release, and a version number that
>> has been 16 years in the making. It contains a few more deprecations and
>> backwards incompatible changes than an average release. Therefore please do
>> test it on your own code, and report any issues on the Github issue tracker
>> or on the scipy-dev mailing list.
>>
>> Sources: https://github.com/scipy/scipy/releases/tag/v1.0.0b1
>> Binary wheels: will follow tomorrow, I'll announce those when ready
>> (TravisCI is under maintenance right now)
>>
>> Thanks to everyone who contributed to this release!
>>
>> Ralf
>>
>>
>>
>>
>> Release notes (full notes including authors, closed issued and merged PRs
>> at the Github Releases link above):
>>
>> [snip]
>>
>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [ANN] Matplotlib 2.1 released

[Thomas Caswell]

We are happy to announce the release of Matplotlib 2.1. This is the second
minor release in the Matplotlib 2.x series and the first release with major
new features since 1.5.

This release contains approximately 2 years worth of work by 275
contributors
across over 950 pull requests.  Highlights from this release include:

 - support for string categorical values
 - export of animations to interactive javascript widgets
 - major overhaul of polar plots
 - reproducible output for ps/eps, pdf, and svg backends
 - performance improvements in drawing lines and images
 - GUIs show a busy cursor while rendering the plot

along with many other enhancements and bug fixes.

The gallery, examples, and tutorials have been overhauled and consolidated:

  Examples: http://matplotlib.org/gallery/index.html
  Tutorials: http://matplotlib.org/tutorials/index.html

A big thank you to everyone who contributed to this release!

Wheels are available on pypi for win/mac/manylinux and for conda via
conda-forge.

Full whats new:
http://matplotlib.org/users/whats_new.html#new-in-matplotlib-2-1
Full API changes:
http://matplotlib.org/api/api_changes.html#api-changes-in-2-1-0
github stats: http://matplotlib.org/users/github_stats.html

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

[Thomas Caswell]

I am in very supportive of this plan.

For Matplotlib the intention is to do a mpl2.2LTS early 2018 and a mpl3.0
(no major API breaks other than dropping py2 support) summer 2018 with the
same meaning of LTS.

I also had thought about bumping the minimum numpy version of Matplotlib to
the first py3 only version when it is out.  There is no technical reason,
but it seems nicely symmetric.

In general we all need to get better about dropping support for old
versions of dependencies (I am throwing stones from inside my glass
house).  The prolonged support of py2 has warped our idea of how long old
versions of things need to be supported and it imposes real costs up and
down the stack.

Tom

On Mon, Nov 13, 2017 at 1:26 PM Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:

> > If a wheel is not available for the client platform, pip will try to
> install the latest version of the source distribution (.tar.gz or .zip)
> which I think is the cause of the problem here.
>
> Unless the sdist is tagged with require_python and users have
> recent-enough pip. Which is what was referred to earlier as
> "Automagically".
> This behavior is "new" (Nov/Dec 2016). The upstream patches were
> written (in part) by the IPython/Jupyter team, for this exact purpose,
> to not install an incompatible sdists.
> (Works great I can share download graphs for IPython[0])
>
> It _does_ require to have a version of pip which is not decades old
> though, and may not work if you use a pypi proxy which is not pep 503
> compliant (which happens, we got bug report, users then complained to
> IT who fixed it).
> --
> M
>
> On Mon, Nov 13, 2017 at 10:14 AM, Olivier Grisel
>  wrote:
> > If a wheel is not available for the client platform, pip will try to
> install
> > the latest version of the source distribution (.tar.gz or .zip) which I
> > think is the cause of the problem here.
> >
> > --
> > Olivier
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [REL] Matplotlib 2.1.1

[Thomas Caswell]

Folks,

Happy to announce Matplotlib 2.1.1

This is primarily a bug fix release, see
https://github.com/matplotlib/matplotlib/releases/tag/v2.1.1 for details.

The next planned release is a 2.2 feature release in January/February
2018.

Thank you to everyone who worked on this release!

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] building numpy with python3.7

[Thomas Caswell]

I have been building numpy master with CPython master but am also using
cython master.

My not-pretty script for doing this is:

#! /usr/bin/bash
set -e
TARGET_ENV=bleeding

OSPATH=~/source/other_source/

pushd $OSPATH/cpython/
git pull
git clean -xfd
./configure
make -j 9
./python -m venv --copies --clear ~/.virtualenvs/$TARGET_ENV
popd

source ~/.virtualenvs/$TARGET_ENV/bin/activate

master_build () {
git checkout master
git pull
git clean -xfd
pip install -v .
}

pushd $OSPATH/cython
master_build
popd
pushd $OSPATH/numpy
master_build
popd

Tom

On Fri, Dec 15, 2017 at 5:54 AM Nathaniel Smith  wrote:

> On Fri, Dec 15, 2017 at 2:42 AM, Hannes Breytenbach 
> wrote:
> >
> > I don't think this is a cython version issue - cloned the latest version
> from git yesterday...
> >
> > python3.7 -c "import cython; print(cython.__version__)"
> > 0.28a0
>
> It is a cython version issue: https://github.com/cython/cython/issues/1955
>
> It's supposed to be fixed though, so I don't know why you it isn't
> working for you. Are you sure that cython is installed in the same
> virtualenv as you're using to build numpy? If you were using a numpy
> sdist then it would make sense because we include the pre-generated .c
> files in the sdists instead of running cython, but given that you're
> building from a numpy checkout I dunno.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy should not silently promote numbers to strings

[Thomas Caswell]

This has recently been a major point point for Matplotlib for the
implementation of string-categoricals as well.

Having numpy go to object or fail on `np.asarray([1, 2, 'foo'])` would make
things much easier for us.

Tom

On Fri, Feb 9, 2018 at 2:22 AM Stephan Hoyer  wrote:

> On Thu, Feb 8, 2018 at 11:00 PM Eric Wieser 
> wrote:
>
>> Presumably you would extend that to all (str, np.number), or even (str,
>> np.generic_)?
>>
> Yes, I'm currently doing (np.character, np.number) and (np.character,
> np.bool_). But only in direct consultation with the diagram of NumPy's
> type hierarchy :).
>
>> I suppose there’s the argument that with python-3-only support around the
>> corner, even (str, bytes) should go to object.
>>
> Yes, that's also pretty bad.
>
> The current behavior (str, bytes) -> str relies on bytes being valid ASCII:
> >>> np.array([b'\xFF', u'cd'])
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0:
> ordinal not in range(128)
>
> It exactly matches Python 2's str/unicode behavior, but doesn't make sense
> at all in a Python 3 world.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PR to add a function to calculate histogram edges without calculating the histogram

[Thomas Caswell]

As commented in the OP, this would be very useful for Matplotlib.

Tom

On Fri, Mar 9, 2018 at 1:42 PM Kirit Thadaka 
wrote:

> Hi!
>
> I've created a PR to add a function called "histogram_bin_edges" which
> will allow a user to calculate the bins used by the histogram for some data
> without requiring the entire histogram to be calculated.
>
> https://github.com/numpy/numpy/pull/10591#issuecomment-371863472
>
> This function allows one set of bins to be computed, and reused across
> multiple histograms which gives more easily comparable results than using
> separate bins for each histogram.
>
> Please let me know if you have any suggestions on how to improve this PR.
>
> Thanks!
>
> -
> Kirit
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PR to add a function to calculate histogram edges without calculating the histogram

[Thomas Caswell]

Yes I like the name.

The primary use-case for Matplotlib is that our `hist` method can take in a
list of arrays and produces N histograms in one shot. Currently with 'auto'
we only use the first data set to sort out what the bins should be and then
re-use those for the rest of the data sets.  This will let us get the bins
on the merged input, but I take Josef's point that this is not actually
what we want

Tom

On Mon, Mar 12, 2018 at 11:35 PM  wrote:

> On Mon, Mar 12, 2018 at 11:20 PM, Eric Wieser
>  wrote:
> >> Given that the bin selection are data driven, transferring them across
> datasets might not be so useful.
> >
> > The main application would be to compute bins across the union of all
> > datasets. This is already possibly by using `np.histogram` and
> > discarding the first result, but that's super wasteful.
>
> assuming "union" means a combined dataset.
>
> If you stack  datasets, then the number of observations will not be
> correct for individual datasets.
>
> In that case an additional keyword like nobs, or whatever name would
> be appropriate for numpy, would be useful, e.g. use the average number
> of observations across datasets.
> Auxiliary statistic like std could then be computed on the total
> dataset (if that makes sense, which would not be the case if the
> variance across datasets is larger than the variance within datasets.
>
> Josef
>
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

[Thomas Caswell]

It would be nice if there was an IntEnum [1] that was taken is an input to
`np.asarrayish` and `np.isarrayish` to require a combination of the groups
of attributes/methods/semantics.

Tom

[1] https://docs.python.org/3/library/enum.html#intenum

On Sat, Mar 10, 2018 at 7:14 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

>
> ​I think we don't have to make it sounds like there are *that* many types
> of compatibility: really there is just array organisation
> (indexing/reshaping) and array arithmetic. These correspond roughly to
> ShapedLikeNDArray in astropy and NDArrayOperatorMixin in numpy (missing so
> far is concatenation). The advantage of the ABC classes is that they can
> supply missing methods (say, size, isscalar, __len__, and ndim given shape;
> __iter__ given __getitem__, ravel, squeeze, flatten given reshape; etc.).
>
> -- Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

[Thomas Caswell]

Yes, meant IntFlag :sheep:

On Sat, Mar 17, 2018 at 6:02 PM Hameer Abbasi 
wrote:

>
> It would be nice if there was an IntEnum [1] that was taken is an input to
> `np.asarrayish` and `np.isarrayish` to require a combination of the groups
> of attributes/methods/semantics.
>
>
> Don’t you mean IntFlag
> ? I like Marten’s
> idea of “grouping together” related functionality via ABCs and implementing
> different parts via ABCs (for example, in pydata/sparse we use
> NDArrayOperatorsMixin for exactly this), but I believe that separate ABCs
> should be provided for different parts of the interface.
>
> Then we can either:
>
>1. Check with isinstance for the ABCs, or
>2. Check with hasattr.
>
> I like the IntFlag idea most (it seems to be designed for use-cases like
> these), but a string-based (np.aspyarray(x,
> functionality=‘arithmetic|reductions')) or list-based (np.aspyarray(x,
> functionality=[‘arithmetic’, ‘reductions’]) is also fine.
>
> It might help to have some sort of a “dry-run” interface that (given a run
> of code) figures out which parts you need.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [REL] Matplotlib 3.0.0

[Thomas Caswell]

Folks,

Happy to announce Matplotlib 3.0.0!

This is the first version of Matplotlib to only support Python 3.

If you need Python 2.7 support the 2.2.x LTS series will continue to
receive critical bug-fixes until 2020.

Highlights of this release include:

 - GUI backend is selected at run-time based on what toolkits are
   installed.  A GUI toolkit will not be selected on a headless
   server.
 - New cyclic color map *twilight*
 - Improvements to automatic layout of titles, ticks, and GridSpec
 - Many bug fixes!

For the full details see  https://matplotlib.org/users/whats_new.html and
https://matplotlib.org/api/api_changes.html for whats new and API changes
respectively.

For packagers: Matplotlib no longer depends on six or pytz.

A big thank you to everyone who worked on this release in terms of commits
(~130 people have commits), reporting issues, and review.

I expect there to be a v3.0.1 release in the next month or so.

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [REL] Matplotlib 3.0.0

[Thomas Caswell]

Folks,

A small update, when I uploaded the wheels yesterday I only uploaded about
half of them [1] and did not check my work carefully enough.  This has been
rectified, sorry to everyone who had installs fail his morning.

Tom

[1] I downoladed one of the wheels from http://wheels.scipy.org/ twice, the
browser helpfully added (1) to the name, when I when to upload everything
twine got half way through and failed out on that file.  I thought it had
done everything else, but it had actually only done everything up to that
file.

On Tue, Sep 18, 2018 at 8:43 PM Thomas Caswell  wrote:

> Folks,
>
> Happy to announce Matplotlib 3.0.0!
>
> This is the first version of Matplotlib to only support Python 3.
>
> If you need Python 2.7 support the 2.2.x LTS series will continue to
> receive critical bug-fixes until 2020.
>
> Highlights of this release include:
>
>  - GUI backend is selected at run-time based on what toolkits are
>installed.  A GUI toolkit will not be selected on a headless
>server.
>  - New cyclic color map *twilight*
>  - Improvements to automatic layout of titles, ticks, and GridSpec
>  - Many bug fixes!
>
> For the full details see  https://matplotlib.org/users/whats_new.html
> and  https://matplotlib.org/api/api_changes.html for whats new and API
> changes respectively.
>
> For packagers: Matplotlib no longer depends on six or pytz.
>
> A big thank you to everyone who worked on this release in terms of commits
> (~130 people have commits), reporting issues, and review.
>
> I expect there to be a v3.0.1 release in the next month or so.
>
> Tom
>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to accept NEP 22: Duck typing for NumPy arrays

[Thomas Caswell]

I think the NEP does a very good job of capturing the high-level issue
around duck arrays and will serve as a solid base to build future
discussions on.

With my Matplotlib and h5py hats on, I like the discussion about how down
stream projects need to work out their issues with the support of the NumPy
devs.

Tom

On Thu, Sep 20, 2018 at 9:48 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> I read the NEP again and think it is a good and useful one (also in
> discussing why NEP 16 was not a good idea!).  -- Marten
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Search not working on www.numpy.org/devdocs/search.html

[Thomas Caswell]

I suspect this is due to issues with sphinx 1.8.0.  Matplotlib also has
this problem (see https://github.com/matplotlib/matplotlib/pull/12183).

Tom

On Mon, Sep 17, 2018 at 10:47 AM Matti Picus  wrote:

> I can enter a search term (say `ndarray`) in
> www.numpy.org/devdocs/search.html, but the result is empty. It worked
> yesterday. My firefox javascript debug console for the remote search says:
>
> jQuery.Deferred exception: Search is not defined
> @http://www.numpy.org/devdocs/search.html?q=ndarray:34:25
> j@http://www.numpy.org/devdocs/_static/jquery.js:2:29997
> g/http://www.numpy.org/devdocs/_static/jquery.js:2:30313 undefined
>
> If I build the documentation locally, search emits a different error but
> still works:
>
> XML Parsing Error: not well-formed Location:
> file:///.../doc/build/html/searchindex.js Line Number 1, Column 16:
>
> Searching on scipy.org, for instance
>
> https://docs.scipy.org/doc/numpy/search.html?q=ndarray&check_keywords=yes&area=default
> works with no errors on the console
>
> Any hints?
> Matti
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NEP 28 — A standard community policy for dropping support of old Python and NumPy versions

[Thomas Caswell]

Folks,

This NEP is a proposing a standard policy for the community to determine
when we age-out support for old  versions of Python. This came out of
in-person discussions at SciPy earlier in July and scattered discussion
across github. This is being proposed by maintainers from Matplotlib,
scikit-learn,
IPython, Jupyter, yt, SciPy, NumPy, and scikit-image.

TL;DR:

We propose only supporting versions of CPython initially released in the
preceding 42 months of a major or minor release of any of our projects.

Please see https://github.com/numpy/numpy/pull/14086 and keep the
discussion there as there are many interested parties (from the other
projects) that may not be subscribed to the numpy mailing list.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Proposal to accept NEP #29: Recommend Python and Numpy version support as a community policy standard

[Thomas Caswell]

https://numpy.org/neps/nep-0029-deprecation_policy.html

The outstanding concern in https://github.com/numpy/numpy/pull/14086 was
that some projects want to continue to support additional versions of
Python and numpy outside of the minimum support windows.  The language has
been changed to specify that these are _minimum_ support windows and that
projects _should_ not _will_ drop support as they can.

There is one trivial wording change PR open (
https://github.com/numpy/numpy/pull/1).

If there are no substantive objections within 7 days from this email, then
the NEP will be accepted; see NEP 0 for more details.

Tom
-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Matplotlib Research Software Engineering Fellow

[Thomas Caswell]

Hi folks,

Matplotlib has received a grant from the Chan Zuckerberg Initiative to fund
maintenance!  As part of the grant, we have 1 year of funding for
a Research Software Engineering Fellow to carry out this work. If you are
interested in working on Matplotlib full time, please apply!   See below
for a link to the full job description and application instructions.

The timeline on this is rather short, so applications are due Jan 3.

https://discourse.matplotlib.org/t/now-hiring-matplotlib-research-software-engineering-fellow/20701

Tom and Hannah

-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

[Thomas Caswell]

uthors, that
>> > "as tech workers, we should take responsibility in how our software is
>> > used".
>> >
>> > Many thanks to all of the contributors who have put so much time and
>> > energy into NumPy. ✨ ❤️ 😃
>> >
>> > [1] https://github.com/gazprom-neft/petroflow
>> > [2] https://github.com/climate-strike/analysis
>> > [3] https://github.com/climate-strike/license
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP 42 and physical unit DType

[Thomas Caswell]

>From the Matplotlib side we can definitely do dispatch based on the dtype
of the ndarray (not just that it is an array) which is how we handle arrays
of datetimes.

Matplotlib should (internally) never try to do operations on user data
before we do the unit conversion and my default position is that where we
let that leak is a bug in mpl.  I don't think bugs in Matplotlib
should feed back to the dtype design.

Tom

On Fri, Oct 9, 2020 at 1:08 PM Sebastian Berg 
wrote:

> On Fri, 2020-10-09 at 07:48 -0500, Lee Johnston wrote:
> > NEP 42 mentions physical units as a possible use case for the new
> > DType.
> > Having worked on `unyt`, which is an ndarray subclass, and other unit
> > system implementations based on the dispatch mechanism, I am quite
> > familiar
> > with the challenges. One challenge is integration with Matplotlib
> > that has
> > a unit conversion interface. This interface is invoked by a registry
> > mapping from unit array type, such as `unyt_array`, and its
> > conversion
> > class. A custom DType will still result in an ndarray type - correct?
>
> A custom DType will be attached to a normal NumPy array (or, hopefully
> a pandas dataframe, etc.). I am not sure if that is what you meant, but
> a custom DType will mean there is no array subclass involved (this is
> different from how pandas approaches extension dtypes).
> But, I am not sure that this makes much of a difference with respect to
> the problem.
>
> > If
> > so, Matplotlib will attempt to perform its internal calculations
> > eventually
> > leading to an invalid operation when adding a physical quantity to a
> > pure
> > number. This happens today with `unyt_array` and some of the plotting
>
> It sounds unlikely that this would solve the issue immediately. Rather,
> we probably need to think about creating some kind of "protocol" to
> drop units, such as:
>
>arr.astype(Unitless)
>
> which would be a no-op for the NumPy numerical types. Or baking in
> something similar to make working with units easier.
>
> I would have hoped a bit that it is possible to avoid such issues e.g.
> by dividing by a step/difference, but I do not know the details.
>
> The most important question for me would be more whether there is
> something in the basic infrastructure to consider that cannot be done
> as an extension/protocol later (like the `arr.astype(Unitless)` cast,
> which should be a straight forward extension).
>
> Although, it would be interesting to figure out how a future Unit DType
> would best look in this regard!
>
> Cheers,
>
> Sebastian
>
>
> > functions that allow the subclass to leak through into the internals.
> > Has
> > this been discussed? I can imagine other libraries will have the same
> > challenge.
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org?

[Thomas Caswell]

I agree with Matti that keeping at least the nightly wheel building /
uploading for a bunch of projects all in on place makes sense.

Tom

On Thu, Oct 29, 2020 at 6:00 AM Matti Picus  wrote:

>
> On 10/29/20 5:42 AM, Charles R Harris wrote:
> > Hi All,
> >
> > Seems that is pretty easy to transfer a github repo to another owner.
> > Should we do this for the numpy-wheels repo? That would put all the
> > management in one place and now might be a good time to do it before
> > the 1.20.x branch.
> >
> > Chuck
> >
>
> What is the goal? So far it is convenient that all the repos that upload
> to https://anaconda.org/multibuild-wheels-staging are under one org to
> coordinate upload token use.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

[Thomas Caswell]

proposed revision:
>> > > > https://github.com/numpy/numpy/pull/14086#issuecomment-649287648
>> > > > Specifically, rather than saying "the latest release of NumPy
>> > > > supports all versions of Python released in the 42 months before
>> > > > NumPy's release", it says "NumPy will only require versions of
>> > > > Python that were released more than 24 months ago". In practice,
>> > > > this works out to the same thing (at least given Python's old 18
>> > > > month release cycle).
>> > > >
>> > > > This changes the definition of the support window (in a way that
>> > > > I think is clearer and that works better for infrequent
>> > > > releases), but there is still the question of how large that
>> > > > window should be for NumPy.
>> > >
>> > > I'm not sure it's clearer, the current NEP has a nice graphic and
>> > > literally says "a project with a major or minor version release in
>> > > November 2020 should support Python 3.7 and newer."). However happy
>> > > to adopt it if it makes others happy - in the end it comes down to
>> > > the same thing: it's recommended to drop Python 3.6 now.
>> > >
>> > > > My personal opinion is that somewhere in the range of 24-36
>> > > > months would be appropriate.
>> > >
>> > > +1
>> > >
>> > > Cheers,
>> > > Ralf
>> > >
>> > >
>> > >
>> > > ___
>> > > NumPy-Discussion mailing list
>> > > NumPy-Discussion@python.org
>> > > https://mail.python.org/mailman/listinfo/numpy-discussion
>> > >
>> >
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] manylinux wheels with Github Actions

[Thomas Caswell]

Matplotlib has also migrated to building wheels via github actions and it
has been working well.

Tom

On Mon, Nov 16, 2020, 17:48 Andrew Nelson  wrote:

> For my project (refnx) I solely use GH Actions to test and make wheels. In
> my workflow (
> https://github.com/refnx/refnx/blob/master/.github/workflows/pythonpackage.yml)
> I make a 3.7/3.8/3.9 matrix across Linux/macOS/Windows. First of all I make
> the wheels for all those combos, then install the wheels, then run tests on
> the installed wheel (thereby checking that the libraries are all delocated
> nicely). The final step in the workflow is uploading the wheel artefacts
> (stored somewhere on GH).
> To make the Linux 2010/2014 wheels I use PyPA docker images (
> https://github.com/refnx/refnx/blob/master/.github/workflows/pythonpackage.yml#L70).
> I specify what platform I want to make wheels for, as an environment
> variable that is used to select the correct docker image
> ["manylinux2010_x86_64", "manylinux2014_x86_64"]. There are other images
> available. The docker image runs a script to make all the wheels (
> https://github.com/refnx/refnx/blob/master/tools/build_manylinux_wheels.sh)
> and put them in a wheelhouse, that is then uploaded as an artefact along
> with the macOS and windows wheels.
>
> I decided to make the deployment step to PyPI a manual process, just so I
> can check that everything went ok. When I've just made a release tag I
> download the artefacts corresponding to the release commit, then upload
> them from my personal PC.
>
> It all works really well.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] reducing effort spent on wheel builds?

[Thomas Caswell]

I am pretty -1 on removing sdists.  At least for Matplotlib we have a
number of users on AIX who rely on the the sdists (I know they exist
because when our build breaks they send us patches to un-break it) for
their installation.  I strongly suspect that numpy also has a fair number
of users who are willing and able to compile from source on niche systems
and it does seem like a good idea to me to break them.

I like Ralf's proposal, but would amend it with "unless someone stands up
and puts their name on ensuring the wheels exist for platform " with the
understanding that if they have to step away support for that
platform stops until someone else is willing to put their name on it.

This may be a good candidate for the new SPEC process to handle? Just like
supported versions of Python, we should have consistent platform support
(and processes for how we decide on / provide that support) across the
community (thinking with my Matplotlib and h5py hats here).

Tom


On Mon, Aug 9, 2021 at 9:51 AM Matti Picus  wrote:

>
> On 16/7/21 9:11 pm, Chris Barker wrote:
> > Just a note on:
> >
> > > For the record, I am +1 on removing sdists from PyPI until pip changes
> > its default to --only-binary :all: [1]
> >
> > I agree that the defaults for pip are unfortunate (and indeed the
> > legacy of pip doing, well, a lot, (i.e. building and installing and
> > package managing and dependencies, and ...) with one interface.
> >
> > However, There's a long tradition of sdists on PyPi -- and PyPi is
> > used, for the most part, as the source of sdists for other systems
> > (conda-forge for example). I did just check, and numpy is an exception
> > -- it's pointing to gitHub:
> >
> > source:
> > url: https://github.com/numpy/numpy/releases/download/v{{
> > <https://github.com/numpy/numpy/releases/download/v{{> version
> > }}/numpy-{{ version }}.tar.gz
> >
> > But others may be counting on sdists on PyPi.
> >
> > Also, an sdist is not always the same as a gitHub release -- there is
> > some "magic" in building it -- it's not just a copy of the repo.
> > Again, numpy may be building its releases as an sdist (or it just
> > doesn't. matter), but something to keep in mind.
> >
> > Another thought is to only support platforms that have a
> > committed maintainer -- I think that's how Python itself does it. The
> > more obscure platforms are only supported if someone steps up to
> > support them (I suppose that's technically true for all platforms, but
> > not hard to find someone on the existing core dev team to support the
> > majors). This can be a bit tricky, as the users of a platform may not
> > have the skills to maintain the builds, but it seems fair enough to
> > only support platforms that someone cares enough about to do the work.
> >
> > -CHB
> >
> >
> > --
> >
> > Christopher Barker, Ph.D.
> > Oceanographer
> >
> > Emergency Response Division
> > NOAA/NOS/OR&R(206) 526-6959   voice
> > 7600 Sand Point Way NE   (206) 526-6329   fax
> > Seattle, WA  98115   (206) 526-6317   main reception
> >
> > chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>
>
>
> Just an empty response since this ended up in my spam filter, and I am
> probably not the only one.
>
> Matti
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Re: NEP 29 and the faster Python release cadence

[Thomas Caswell]

 NumPy. For even older Python versions the old NumPy releases
>> will stay available, and it allow NumPy to move on to new Python features a
>> full year earlier then with a 42 month support window. Which not only
>> improves feature and performance adaptation, but also lowers maintenance,
>> testing, backporting and CI effort.
>>
>> Ewout ter Hoeven (EwoutH)
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: ralf.gomm...@gmail.com
>>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: NEP 29 and the faster Python release cadence

[Thomas Caswell]

I created https://github.com/numpy/numpy/pull/21601 to update NEP29 to
address PEP602.

I'm not sure what the procedure for updating the NEP is.  What I wrote may
be too editorial, we could amend it to "PEP602 changed cadence, we are not
reacting." with no explanation as well.

Tom

On Wed, May 25, 2022 at 10:41 PM Aaron Meurer  wrote:

> > I have seen problems popping up already in a few places with latest
> numpy not supported what is still the most commonly used Python version
> (don't have links, sorry - but they were real packaging-related issues). So
> I don't think it makes sense to shorten the time window. I also don't think
> there's a need to drop one version that's urgent - it's some effort and CI
> time, but the balance is decent right now.
>
> It's hard to say the balance is decent right now if the faster cadence
> isn't even in full effect yet (as I noted in my original email).
>
> Generally I would say that dropping support only means that users of
> older versions would simply need to use an older version of the
> library.
>
> However this:
>
> > We cannot do that (yet, at least). Failing to publish wheels for a
> supported Python version on a major OS is far worse than dropping support
> completely. This will remain true until the time that Pip starts defaulting
> to wheels-only and never picks the sdist if there's an older release for
> that platform + Python combo.
>
> sounds like if even the latest version doesn't support a given CPython
> version (and has CPython-versioned wheels), then pip installing it
> will fail. Is that correct?
>
> > There was a lot of discussion around how big the window should be with
> 42mo being about in the middle of what people advocated for.  I am aware of
> institutions that are on an every-other Python upgrade pattern (py37 ->
> py39 -> (expected) py311) so always having at least 3 Pythons in the window
> is important.  Based on what we have seen so far, I still think 42mo is a
> good choice, but do not think we have seen it in operations long enough to
> draw any conclusions (the downside of year-scale planning is you need to
> wait years to see if it worked out like you expected!) and hence do not
> think we should make any changes to the time window for another few years.
>  That said, I am currently sympathetic to making the window longer and
> against making it shorter.
>
> The reason I brought this up is because we were looking at whether it
> makes sense to use NEP 29 for SymPy. Obviously we aren't bound to
> using it, but given this apparent discrepancy in the text (which still
> exists), I thought I would mention it here. But I will say that from
> my point of view, supporting more Python versions is a burden. Having
> more builds on CI means longer wait times to merge PRs. And having to
> wait longer for new Python features is also annoying.
>
> Aaron Meurer
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: NEP 29 and the faster Python release cadence

[Thomas Caswell]

https://github.com/numpy/numpy/pull/21601 has been merged, but we should
make sure everyone is on board with the updated wording.  The intent was to
resolve the discrepancy I think Aaron is referring to (the text spoke of
the 18mo release cycle  in present tense) and to justify sticking with
42months despite the upstream change.

I think it is good for the overall community if we have a (mostly) unified
position on this, but if projects are going to disregard NEP 29 I am
personally happy for them to run faster :)

Tom

On Thu, May 26, 2022 at 7:08 AM Ralf Gommers  wrote:

>
>
> On Thu, May 26, 2022 at 4:41 AM Aaron Meurer  wrote:
>
>> > I have seen problems popping up already in a few places with latest
>> numpy not supported what is still the most commonly used Python version
>> (don't have links, sorry - but they were real packaging-related issues). So
>> I don't think it makes sense to shorten the time window. I also don't think
>> there's a need to drop one version that's urgent - it's some effort and CI
>> time, but the balance is decent right now.
>>
>> It's hard to say the balance is decent right now if the faster cadence
>> isn't even in full effect yet (as I noted in my original email).
>>
>> Generally I would say that dropping support only means that users of
>> older versions would simply need to use an older version of the
>> library.
>>
>
> That is not the full story unfortunately. The Python packaging tooling
> (Pip, Poetry et al) is imperfect, so if other packages depend on NumPy and
> then at install time a tool figures out that latest NumPy cannot be used,
> or somewhere there's an upper bound in the version constraints explicitly,
> some things tend to go wrong.
>
>
>>
>> > There was a lot of discussion around how big the window should be with
>> 42mo being about in the middle of what people advocated for.  I am aware of
>> institutions that are on an every-other Python upgrade pattern (py37 ->
>> py39 -> (expected) py311) so always having at least 3 Pythons in the window
>> is important.  Based on what we have seen so far, I still think 42mo is a
>> good choice, but do not think we have seen it in operations long enough to
>> draw any conclusions (the downside of year-scale planning is you need to
>> wait years to see if it worked out like you expected!) and hence do not
>> think we should make any changes to the time window for another few years.
>>  That said, I am currently sympathetic to making the window longer and
>> against making it shorter.
>>
>> The reason I brought this up is because we were looking at whether it
>> makes sense to use NEP 29 for SymPy. Obviously we aren't bound to
>> using it, but given this apparent discrepancy in the text (which still
>> exists),
>
>
> What discrepancy?
>
> Cheers,
> Ralf
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

[Thomas Caswell]

I am not in favor of reverting this change.

We already accounted for this in Matplotlib (
https://github.com/matplotlib/matplotlib/issues/25789 and
https://github.com/matplotlib/matplotlib/pull/25813).  It was not actually
that disruptive and mostly identified tests that were too brittle to
begin with.

My understanding is that a majority of the impact is not that the results
are inaccurate, it is that they are differently inaccurate than they used
to be.  If this is going to be reverted I think the burden should be on
those who want the reversion to demonstrate that the different results
actually matter.

Tom


On Wed, May 31, 2023 at 10:11 AM Matthew Brett 
wrote:

> On Wed, May 31, 2023 at 3:04 PM Robert Kern  wrote:
> >
> > I would much, much rather have the special functions in the `np.*`
> namespace be more accurate than fast on all platforms. These would not have
> been on my list for general purpose speed optimization. How much time is
> actually spent inside sin/cos even in a trig-heavy numpy program? And most
> numpy programs aren't trig-heavy, but the precision cost would be paid and
> noticeable even for those programs. I would want fast-and-inaccurate
> functions to be strictly opt-in for those times that they really paid off.
> Probably by providing them in their own module or package rather than a
> runtime switch, because it's probably only a part of my program that needs
> that kind of speed and can afford that precision loss while there will be
> other parts that need the precision.
> >
>
> What Robert said :)
>
> But I still think the ideal would be the runtime option, maybe via the
> proposed context manager, for them as do need it, or want to try it
> out.
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

[Thomas Caswell]

Just for reference, this is the current results on the numpy main branch at
special points:

In [1]: import numpy as np

In [2]: np.sin(0.0)
Out[2]: 0.0

In [3]: np.cos(0.0)
Out[3]: 0.

In [4]: np.cos(2*np.pi)
Out[4]: 0.9998

In [5]: np.sin(2*np.pi)
Out[5]: -2.4492935982947064e-16

In [6]: np.sin(np.pi)
Out[6]: 1.2246467991473532e-16

In [7]: np.cos(np.pi)
Out[7]: -0.9998

In [8]: np.cos(np.pi/2)
Out[8]: 6.123233995736766e-17

In [9]: np.sin(np.pi/2)
Out[9]: 0.9998

In [10]: np.__version__
Out[10]: '2.0.0.dev0+60.g174dfae62'

On Wed, May 31, 2023 at 6:20 PM Robert Kern  wrote:

> On Wed, May 31, 2023 at 5:51 PM Benjamin Root 
> wrote:
>
>> I think it is the special values aspect that is most concerning. Math is
>> just littered with all sorts of identities, especially with trig functions.
>> While I know that floating point calculations are imprecise, there are
>> certain properties of these functions that still held, such as going from
>> -1 to 1.
>>
>> As a reference point on an M1 Mac using conda-forge:
>> ```
>> >>> import numpy as np
>> >>> np.__version__
>> '1.24.3'
>> >>> np.sin(0.0)
>> 0.0
>> >>> np.cos(0.0)
>> 1.0
>> >>> np.sin(np.pi)
>> 1.2246467991473532e-16
>> >>> np.cos(np.pi)
>> -1.0
>> >>> np.sin(2*np.pi)
>> -2.4492935982947064e-16
>> >>> np.cos(2*np.pi)
>> 1.0
>> ```
>>
>> Not perfect, but still right in most places.
>>
>
> FWIW, those ~0 answers are actually closer to the correct answers than 0
> would be because `np.pi` is not actually π. Those aren't problems in the
> implementations of np.sin/np.cos, just the intrinsic problems with floating
> point representations and the choice of radians which places particularly
> special values at places in between adjacent representable floating point
> numbers.
>
>
>> I'm ambivalent about reverting. I know I would love speed improvements
>> because transformation calculations in GIS is slow using numpy, but also
>> some coordinate transformations might break because of these changes.
>>
>
> Good to know. Do you have any concrete example that might be worth taking
> a look at in more detail? Either for performance or accuracy.
>
> --
> Robert Kern
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com