[Numpy-discussion] Re: What should remain on PyPi

[Stefan van der Walt via NumPy-Discussion]

Hi Chuck,

On Tue, Sep 3, 2024, at 08:18, Charles R Harris wrote:
> I just got through deleting a bunch of pre-releases on PyPi and it occurred 
> to me that we should have a policy as to what releases should be kept. I 
> think that reproducibility requires that we keep all the major and micro 
> versions, but if so, we should make that an official guarantee. Perhaps a 
> short NEP? This might even qualify for an SPEC. Thoughts?

That sounds right to me: keep any versions that aren't expressly targeted for 
testing (rc's, beta's, etc.). We still have the GitHub tags for those, should 
developers want to reproduce them.

Stéfan
___
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: Welcome Joren Hammudoglu to the NumPy Maintainers Team

[Stefan van der Walt via NumPy-Discussion]

On Mon, Aug 19, 2024, at 03:00, Sebastian Berg wrote:
> please join me in welcoming Joren (https://github.com/jorenham) to the
> NumPy maintainers team.

Thanks for your contributions, Joren, great to have you on board!

Stéfan
___
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: numpy-user-dtypes updated for NumPy 2.0

[Stefan van der Walt via NumPy-Discussion]

Hi Nathan,

On Tue, Jul 16, 2024, at 12:24, Nathan wrote:
> I just pushed some commits to the numpy-user-dtypes repo 
> (https://github.com/numpy/numpy-user-dtypes) that fixes compatibility with 
> the public version of the DType API that shipped in NumPy 2.0. If you’ve been 
> waiting for some runnable examples to look at before trying to write your own 
> DType, wait no more!

Thanks for working on these!

I see some dtypes have build instructions, and some don't. Does it make sense 
to add generic build instructions to the repo README, or otherwise at least 
ensure that each has a well described install & activation mechanism?

Stéfan
___
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: Policy on AI-generated code

[Stefan van der Walt via NumPy-Discussion]

On Thu, Jul 4, 2024, at 08:18, Daniele Nicolodi wrote:
> I wish it for be common sense for contributors to an open source 
> codebase that they need to own the copyright on their contributions, but 
> I don't think it can be assumed. Adding something to these lines to the 
> project policy has also the potential to educate the contributions about 
> the pitfalls of using AI to autocomplete their contributions.

The ultimate concern is whether GPL code lands in your open source project. 
Will instructions to the author, that they need to make sure they own copyright 
to their code, indemnify the project? I don't think so. You also cannot enforce 
such an instruction. At best, you can, during review, try and establish whether 
the author understands the code they provided; and I hope, where code of any 
complexity is involved, that that should be reasonably obvious.

You'll see we've grappled with this in scikit-image as well: 
https://github.com/scikit-image/scikit-image/pull/7429

Stéfan
___
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: Improved 2DFFT Approach

[Stefan van der Walt via NumPy-Discussion]

Hi Alexander,

On 2024-03-14 22:43:38, Alexander Levin via NumPy-Discussion 
 wrote:
Memory Usage - 
https://github.com/2D-FFT-Project/2d-fft/blob/testnotebook/notebooks/memory_usage.ipynb 
Timing comparisons(updated) - 
https://github.com/2D-FFT-Project/2d-fft/blob/testnotebook/notebooks/comparisons.ipynb


I see these timings are still done only for power-of-two shaped 
arrays. This is the easiest case to optimize, and I wonder if 
you've given further thought to supporting other sizes? PocketFFT, 
e.g., implements the Bluestein / Chirp-Z algorithm to deal with 
cases where the sizes have large prime factors.


Your test matrix also only contains real values. In that case, you 
can use rfft, which might resolve the memory usage difference? I'd 
be surprized if PocketFFT uses that much more memory for the same 
calculation.


I saw that in the notebook code you have:

matr = np.zeros((n, m), dtype=np.complex64)
matr = np.random.rand(n, m)

Was the intent here to generate a complex random matrix?

Stéfan
___
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: New DType and ArrayMethod C APIs are public

[Stefan van der Walt via NumPy-Discussion]

On Wed, Feb 14, 2024, at 14:34, Nathan wrote:
> The DType API publicly exposes the PyArray_DTypeMeta C struct, which 
> represents DType metaclasses. It also exposes a function for registering 
> user-defined DTypes and a set of slot IDs and function typedefs that users 
> can implement in C to write new DTypes.
> 
> The ArrayMethod API allows defining cast and ufunc loops in terms of these 
> new DTypes, in a manner that forbids value-based promotion and abstracts many 
> of the internals of NumPy. We hope the ArrayMethod API is enables sharing 
> low-level loops that work out-of-the-box in NumPy in other projects.

To emphasize what Nathan wrote: this is the culmination of YEARS of work. My 
gratitude goes out to everyone who took part in meetings (both in-person and 
virtual), code development & review, NEP & documentation writing, community 
discussions, etc.: thank you.

I cannot wait to see everything your hard work will enable.

Stéfan
___
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: welcome Raghuveer, Chris, Mateusz and Matt to the NumPy maintainers team

[Stefan van der Walt via NumPy-Discussion]

On Fri, Jan 26, 2024, at 12:04, Ralf Gommers wrote:
> We've got four new NumPy maintainers! Welcome to the team, and 
> congratulations to:
> 
> - Raghuveer Devulapalli (https://github.com/r-devulap)
> - Chris Sidebottom (https://github.com/mousius)
> - Mateusz Sokół (https://github.com/mtsokol/)
> - Matt Haberland (https://github.com/mdhaber)

Fantastic! Your commit bits are well deserved, and your contributions greatly 
appreciated. 

I look forward to our continued work together. 

Thank you, 
Stéfan 
___
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: Meson - C extension - Finding numpy includes in virtual env

[Stefan van der Walt via NumPy-Discussion]

Hi Nathan,

On Tue, Nov 28, 2023, at 08:42, Nathan wrote:
> It looks like `spin build` does `meson build` and `meson install` and doesn't 
> do `pip install`. I'd like numpy to be importable in a python environment of 
> my choosing, so I tend to instead manually install numpy into that 
> environment by invoking pip with something like `python -m pip install . -v 
> --no-build-isolation -Cbuilddir=build -C'compile_args=-v' 
> -C'setup_args=-Dbuildtype=debug'. I like seeing the compile command meson 
> uses, so I pass in `-v` through meson's `compile_args` and I often need a 
> debug build, so I set the build type manually as well. 

That makes sense. We recently added the `spin.pip.install` command for that 
purpose, but of course you don't *need* a command if you know the invocation :)

Stéfan
___
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: Meson - C extension - Finding numpy includes in virtual env

[Stefan van der Walt via NumPy-Discussion]

On Sun, Nov 26, 2023, at 12:03, Nathan wrote:
> For my work I tend to use a persistent build directory with build isolation 
> disabled as discussed in the meson-python docs.

Out of curiosity, how is this different from, e.g., `spin build` which builds 
into `./build-install`?

Stéfan
___
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: Meson - C extension - Finding numpy includes in virtual env

[Stefan van der Walt via NumPy-Discussion]

Hi Doug,

On Sun, Nov 26, 2023, at 06:29, Doug Turnbull wrote:
> To debug, I ran `pip install . --no-build-isolation` it worked (using venv's 
> numpy)

When developing NumPy, we typically build in the existing environment. This is 
done either via `pip install -e .` (which installs hooks to trigger a 
re-compile upon import), or via the spin tool 
(https://github.com/scientific-python/spin), which have meson commands 
pre-bundled:

pip install spin
spin  # lists commands available

Best regards,
Stéfan
___
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: Meson - C extension - Finding numpy includes in virtual env

[Stefan van der Walt via NumPy-Discussion]

Hi Doug,

On Sat, Nov 25, 2023, at 07:14, Doug Turnbull wrote:
> Unfortunately the following command fails:
> 
> incdir_numpy = run_command(py,
>   ['-c', 'import numpy; print(numpy.get_include())'],
>   capture: true,
>   check: false,
> ).stdout().strip()

In your repo it says stderr, but the version above (stdout) works for me.

Perhaps you are using a different Python than the one in your virtual env, 
because meson was installed onto your path previously? Try `python -m pip 
install meson` and then invoking the meson binary directly from your 
virtualenv: venv/bin/meson.

Stéfan
___
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: How to sample unique vectors

[Stefan van der Walt via NumPy-Discussion]

On Fri, Nov 17, 2023, at 16:52, Robert Kern wrote:
> That optimistic optimization makes this the fastest solution.

That'd work great, thanks Robert, Aaron, and everyone who shared input. 

Stéfan___
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: How to sample unique vectors

[Stefan van der Walt via NumPy-Discussion]

On Fri, Nov 17, 2023, at 14:28, Stefan van der Walt wrote:
> Attached is a script that implements this solution.

And the version with set duplicates checking.

Stéfan
import random
import functools
import itertools
import operator

import numpy as np


def cumulative_prod(arr):
return list(itertools.accumulate(arr, func=operator.mul))


def unravel_index(x, dims):
dim_prod = cumulative_prod([1] + list(dims)[:0:-1])[::-1]
return [list((ix // dim_prod[i]) % dims[i] for i in range(len(dims))) for ix in x]


# From Robert Kern's comment at
# https://github.com/numpy/numpy/issues/24458#issuecomment-1685022258
class PythonRandomInterface(random.Random):
def __init__(self, rng):
self._rng = rng

def getrandbits(self, k):
"""getrandbits(k) -> x.  Generates an int with k random bits."""
if k < 0:
raise ValueError('number of bits must be non-negative')
numbytes = (k + 7) // 8   # bits / 8 and rounded up
x = int.from_bytes(self._rng.bytes(numbytes), 'big')
return x >> (numbytes * 8 - k)# trim excess bits

def indices(self, shape, size=1):
D = functools.reduce(lambda x, y: x * y, dims)
indices = set()
while len(indices) < size:
indices.add(pri.randint(0, D))
return unravel_index(indices, shape)


rng = np.random.default_rng()
pri = PythonRandomInterface(rng)

dims = (500, 400, 30, 15, 20, 800, 900, 2000, 800)
k = 5

print(pri.indices(dims, size=k))
___
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: How to sample unique vectors

[Stefan van der Walt via NumPy-Discussion]

On Fri, Nov 17, 2023, at 11:07, Robert Kern wrote:
> If the arrays you are drawing indices for are real in-memory arrays for 
> present-day 64-bit computers, this should be adequate. If it's a notional 
> array that is larger, then you'll need actual arbitrary-sized integer 
> sampling. The builtin `random.randrange()` will do arbitrary-sized integers 
> and is quite reasonable for this task. If you want it to use our 
> BitGenerators underneath for clean PRNG state management, this is quite 
> doable with a simple subclass of `random.Random`: 
> https://github.com/numpy/numpy/issues/24458#issuecomment-1685022258

Thanks, Robert. The use case is for randomly populating a hypothetical 
N-dimensional sparse array object.
In practice, int64 will probably suffice. 

I can see how to generate arbitrarily large integers using the pattern above, 
but still unsure how to sample without replacement. Aaron mentioned that 
conflicts are extremely unlikely, so perhaps fine to assume they won't happen. 
Checking for conflicts is expensive.

Attached is a script that implements this solution.

Stéfan
import random
import functools
import itertools
import operator

import numpy as np


def cumulative_prod(arr):
return list(itertools.accumulate(arr, func=operator.mul))


def unravel_index(x, dims):
dim_prod = cumulative_prod([1] + list(dims)[:0:-1])[::-1]
return [list((x[j] // dim_prod[i]) % dims[i] for i in range(len(dims))) for j in range(len(x))]


# From Robert Kern's comment at
# https://github.com/numpy/numpy/issues/24458#issuecomment-1685022258
class PythonRandomInterface(random.Random):
def __init__(self, rng):
self._rng = rng

def getrandbits(self, k):
"""getrandbits(k) -> x.  Generates an int with k random bits."""
if k < 0:
raise ValueError('number of bits must be non-negative')
numbytes = (k + 7) // 8   # bits / 8 and rounded up
x = int.from_bytes(self._rng.bytes(numbytes), 'big')
return x >> (numbytes * 8 - k)# trim excess bits

def indices(self, shape, size=1):
D = functools.reduce(lambda x, y: x * y, dims)
indices = [pri.randint(0, D) for i in range(size)]
return unravel_index(indices, shape)


rng = np.random.default_rng()
pri = PythonRandomInterface(rng)

dims = (500, 400, 30, 15, 20, 800, 900, 2000, 800)
k = 5

print(pri.indices(dims, size=k))
___
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] How to sample unique vectors

[Stefan van der Walt via NumPy-Discussion]

Hi all,

I am trying to sample k N-dimensional vectors from a uniform distribution 
without replacement.
It seems like this should be straightforward, but I can't seem to pin it down.

Specifically, I am trying to get random indices in an d0 x d1 x d2.. x dN-1 
array.

I thought about sneaking in a structured dtype into `rng.integers`, but of 
course that doesn't work.

If we had a string sampler, I could sample k unique words (consisting of 
digits), and convert them to indices.

I could over-sample and filter out the non-unique indices. Or iteratively draw 
blocks of samples until I've built up my k unique indices.

The most straightforward solution would be to flatten indices, and to sample 
from those. The integers get large quickly, though. The rng.integers docstring 
suggests that it can handle object arrays for very large integers:

> When using broadcasting with uint64 dtypes, the maximum value (2**64)
> cannot be represented as a standard integer type.
> The high array (or low if high is None) must have object dtype, e.g., 
> array([2**64]).

But, that doesn't work:

In [35]: rng.integers(np.array([2**64], dtype=object))
ValueError: high is out of bounds for int64

Is there an elegant way to handle this problem?

Best regards,
Stéfan
___
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: welcome Andrew Nelson to the NumPy maintainers team

[Stefan van der Walt]

On Mon, Aug 21, 2023, at 01:34, Ralf Gommers wrote:
> On behalf of the steering council, I am very happy to announce that Andrew is 
> joining the Maintainers team.

Andrew, a warm welcome to the team! Thank you for all your work so far, and for 
continuing your involvement with the project. 

Best regards, 
Stéfan 
___
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: update on build system changes in NumPy's main branch

[Stefan van der Walt]

On Fri, Aug 11, 2023, at 12:04, Ralf Gommers wrote:
> We've landed some major changes in `main` this week, so I thought it's a good 
> idea to keep everyone in the loop.

This is a *significant* amount of work. Thank you, Ralf, for keeping track of 
all the moving parts and for working with the rest of the team to get this 
overhaul completed. 

The Meson build machinery is a joy to use! 

Best regards, 
Stéfan
___
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] Example gufuncs

[Stefan van der Walt]

Hi all,

To teach gufuncs, we used to rely on the example implementations in 
`numpy.core.umath_tests`. That module has since been deprecated. Is there 
another, more suitable location for such examples?

I know it's been on SciPy's roadmap to convert some of `sp.linalg` to gufuncs, 
but that hasn't yet happened.

Stéfan
___
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: Moving busday functionality to numpy-financial

[Stefan van der Walt]

Hi Kai, 

I agree with that the change has maintenance implications for numpy-financial. 
It's not *hard* building binary wheels, per se, but it's certainly a bigger job 
than maintaining and testing pure Python. 

As the maintainer of that library, you should decide whether that's something 
you wish to take on. Myself and others here can help getting the build set up, 
if you wish to go that direction. 

Best regards, 
Stéfan 

On Fri, Jun 23, 2023, at 20:47, kaistri...@gmail.com wrote:
> TLDR: There has been some discussion regarding moving busday and 
> related functions to numpy--financial. The sentiment for this has 
> generally been positive, this thread is to assess the amount of work 
> required to move these functions.
>
> Dear NumPy Maintainers,
>
> There has been some discussion about moving np.busday* to 
> numpy-financial first on GitHub [1] and more recently on Slack. The 
> sentiment has largely been positive, however one concern is that the 
> amount of work required is not justified as few people currently use 
> these functions and the move could be messy.  I have recently been 
> contributing to NumPy and am currently the sole maintainer of 
> numpy-financial, so it feels like I am the right person to do this. In 
> my opinion, these functions conceptually fit the scope of 
> numpy-financial. 
>
> However, I have some hesitations about this work. Namely, I am 
> struggling to estimate the scope of this work and I have only some 
> experience with C, and the NumPy C API. I am having trouble estimating 
> the amount of work this would require, but suspect that it will not be 
> easy. The functions use some of the internal C-API (I think, how do I 
> find out the differences between the internal/external API?) and 
> depends on `np.datetime`. Further, the busday* functions are 
> implemented in C. I only have some experience with C and the C aspects 
> of NumPy—I am happy to learn, but this seems like a pretty steep 
> learning curve. Finally, numpy-financial is currently a pure Python 
> module and does not build C, again I will either need help with this or 
> to learn how to do this.
>
> To finish, I have a few questions / requests for advice:
>
> * Is this change supported by the NumPy community?
> * Does anyone have advice on how to estimate the amount of work 
> required?
> * If I start working on this, would anyone be willing to help me learn 
> the C components?
>
> Kind regards
>
> Kai Striega (@Kai-Striega)
>
> [1]_ https://github.com/numpy/numpy/pull/23229#issuecomment-1467084886
> ___
> 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: stef...@berkeley.edu
___
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: Port Powersort Improvement of Timsort

[Stefan van der Walt]

Hi Ben,

Thanks for your proposal!

On Wed, Jun 14, 2023, at 03:24, Ben Weston wrote:
> I wonder if you'd be receptive to a PR bringing the same change to 
> numpy.  I do have an existing implementation in C++ to work from 
> (https://github.com/sebawild/powersort), in addition to the C 
> implementations in CPython and PyPy and am willing to invest time into 
> porting Powersort for numpy.

Powersort looks interesting.  I see in our docs:

```
kind : {'quicksort', 'mergesort', 'heapsort', 'stable'}, optional
Sorting algorithm. The default is 'quicksort'. Note that both 'stable'
and 'mergesort' use timsort or radix sort under the covers and, in general,
the actual implementation will vary with data type. The 'mergesort' option
is retained for backwards compatibility.
```
Given that timsort is used "underneath the hood", it may be an option to 
improve it, especially given that it does not change fundamental aspects such 
as stability.

You can take a look at src/npysort/timsort.cpp to see what we currently have (a 
whole bunch of code for handling various object types).

Best regards,
Stéfan
___
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?

[Stefan van der Walt]

Hi Sebastian, 

Could you clarify whether there are now varying code paths, depending on the 
CPU features available? 

As mentioned on the skimage issue, if results differ but errors are reduced 
across the board, I'd be happy to fix the test suite. But if this simply 
jiggers results, I'm less sure it is worth it.

You also mentioned a potential middle ground, where the approximating 
polynomial could be expanded by another term?

Overall, I feel this is a rather invasive change to NumPy that affects results 
that have been stable for many years, so it warrants careful 
consideration--perhaps even postponing until 2.0? 

Best regards, 
Stéfan 


On Tue, May 30, 2023, at 22:55, Sebastian Berg wrote:
> Hi all,
>
> there was recently a PR to NumPy to improve the performance of sin/cos
> on most platforms (on my laptop it seems to be about 5x on simple
> inputs).
> This changes the error bounds on platforms that were not previously
> accelerated (most users):
>
> https://github.com/numpy/numpy/pull/23399
>
> The new error is <4 ULP similar to what it was before, but only on high
> end Intel CPUs which not users would have noticed.
> And unfortunately, it is a bit unclear whether this is too disruptive
> or not.
___
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: Introducing `np.types`

[Stefan van der Walt]

On Tue, Feb 14, 2023, at 12:27, Ralf Gommers wrote:
> Okay, as long as we keep in mind that it should contain all these 
> not-for-main-namespace functions/classes, it seems fine with me. We can live 
> with two namespaces (`types` and `exceptions`), but more would get a bit too 
> much. We were planning to use `np.lib.*` for more detailed user-facing 
> functions that didn't belong in the main namespace, so let's make sure that 
> we don't end up with >2 of these kinds of namespaces right below the top 
> level one.

If it's mainly for internal use, we can also use sub-namespaces under lib right 
now, and not add those to the main namespace with the next release? I.e., we 
can create `lib.types`, `lib.exceptions` and whatever we want, and then import 
lib as _np or similar internally.

Stéfan
___
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: Congratulation to our newest maintainer Mukulika Pahari

[Stefan van der Walt]

On Fri, Jan 27, 2023, at 02:20, Matti Picus wrote:
> The NumPy steering council recently granted maintainer rights to 
> Mukulika Pahari (https://github.com/Mukulikaa/)

Congratulations, Makulika, and thank you for all your work on the project!

Stéfan
___
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: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

[Stefan van der Walt]

On Thu, Dec 1, 2022, at 13:27, Stefan van der Walt wrote:
> On Thu, Dec 1, 2022, at 13:17, Ralf Gommers wrote:
>> I'm excited to be able to share this announcement on behalf of the NumPy 
>> Steering Council. We have created a new program, the NumPy Fellowship 
>> Program, and offered Sayed Adel the very first Developer in Residence role. 
>> Sayed starts his 1 year tenure in that role today, and we are really looking 
>> forward to him working on NumPy full-time.
> 
> This is a celebration-worthy milestone for the project: thank you to everyone 
> who worked to make it possible!

Sorry for another email, but how can I miss this: congratulations, Sayed, on 
your new role.  We're so happy to have you on board!

Stéfan
___
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: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

[Stefan van der Walt]

On Thu, Dec 1, 2022, at 13:17, Ralf Gommers wrote:
> I'm excited to be able to share this announcement on behalf of the NumPy 
> Steering Council. We have created a new program, the NumPy Fellowship 
> Program, and offered Sayed Adel the very first Developer in Residence role. 
> Sayed starts his 1 year tenure in that role today, and we are really looking 
> forward to him working on NumPy full-time.

This is a celebration-worthy milestone for the project: thank you to everyone 
who worked to make it possible!

> so we are hoping that with guidelines to spend funds plus a concrete 
> fellowship program that we're expecting to be quite impactful, we are now 
> able to confidently tell people that if they donate to NumPy, we will manage 
> their contribution well and translate it into more time for someone on the 
> NumPy team to make NumPy better.

There are a lot of moving pieces here; thank you for getting them all in place. 
 It feels great being able to invite financial contributions, knowing how they 
will be spent!

Stéfan
___
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: Expanding support in testing for external collections.Sequence objects

[Stefan van der Walt]

On Tue, Nov 29, 2022, at 07:21, i...@markopacak.com wrote:
> The debate is whether np.testing.asset_equal should support 
> collections.Sequence objects. 

assert list(sequence1) == list(sequence2)

should do the trick, and also handles int vs float and nan comparisons.

> What is the general view on adding support in testing for Sequence objects?

If it's a straightforward change that doesn't impact the NumPy test suite, it's 
probably fine. Let's see what the others say.

Stéfan
___
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: Formally accept NEP 51: Changing the Representation of NumPy Scalars

[Stefan van der Walt]

On Fri, Nov 25, 2022, at 08:33, Sebastian Berg wrote:
> I would like to formally propose accepting NEP 51.  Without any concern
> voiced, we will consider it accepted within 7 days.

+1

We should update the NEP to match any changes made later, like `np.str_` and 
`np.bool_`, so that we have a good reference document.

Stéfan
___
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: Add a new CI provider for aarch64, macos arm64, musl

[Stefan van der Walt]

Hi Matti,

On Mon, Nov 21, 2022, at 06:20, Matti Picus wrote:
> I am writing to the list for visibility: I opened an issue [0] about 
> adding the Cirrus CI provider to take over some of the CI task runners 
> from travis.com. We have been experiencing strange timeouts on the 
> travis runs, and in general the platform does not feel stable. SciPy 
> made the transition about two months ago and seem to be satisfied.
>
> Thoughts?

I don't see why not. Increased stability, slower reduction of Travis credits, 
better CI runtime through implicit parallelization. Besides, it's easy enough 
to go back.

Stéfan
___
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: plan for moving to Meson

[Stefan van der Walt]

On Fri, Nov 11, 2022, at 06:03, Evgeni Burovski wrote:
> before: any thoughts to change it to e.g. tempita templating?

With the "e.g." maybe being jinja2. tempita works well, but hasn't been worked 
on since 2013.

Stéfan
___
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: Create `np.exceptions` for new exceptions in NumPy?

[Stefan van der Walt]

Hi Sebastian,

On Fri, Nov 11, 2022, at 05:46, Sebastian Berg wrote:
> I would suggest introducing `np.exceptions`.
>
> We already have custom errors and warnings:
>
> * AxisError
> * TooHardError  (used by `np.shares_memory()`)
> * ComplexWarning
> * RankWarning
> * VisibleDeprecationWarning
> * ModuleDeprecationWarning  (not sure what this is)

At first glance, grouping these classes, mainly used internally, into a 
namespace makes sense to me.
We also now have the ability to keep them exposed in their old locations for 
backward compatibility, while not showing them in __all__ and __dir__ (but not 
even sure that's 100% necessary?).

Stéfan
___
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 51: Changing the Representation of NumPy Scalars

[Stefan van der Walt]

On Fri, Oct 28, 2022, at 01:54, Sebastian Berg wrote:
> The main change is to show scalars as:
>
> * `np.float64(3.0)`  ­instead of just `3.0`
> * `np.True_` instead of `True`
> * `np.void((3, 5), dtype=[('a', '   `(3, 5)`
> * Use `np.` rather than `numpy.` for datetime/timedelta.

I very much like the consistency of the `np` everywhere, compared to previous 
proposals.  Thanks, Sebastian!

Stéfan
___
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 50 and integers (e.g. uint8 together -1)

[Stefan van der Walt]

Hi Sebastian,

On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote:
> np.array([1, 2], dtype="uint8") + (-1)
>
> which currently returns an "int16" array must raise an error.  This is
> because we want to return a uint8 array but the -1 cannot be
> represented well by -1.

Did you mean: the -1 is not representable in uint8?

Since -1 cannot cast to uint8, and since we cannot look at the value, we cannot 
determine a suitable minimal output dtype for x - 1.

Stéfan
___
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: PR hasn't been responded to in 2 weeks

[Stefan van der Walt]

On Wed, Sep 28, 2022, at 08:01, Matti Picus wrote:
> The reviewers also asked you to consider a different interface 
> (method=), I did not see a response to that suggestion.

I think that interface suggestion makes sense. Since there seemed to be some 
confusion in the comments, I'll summarize here:

Polynomials, as Chuck pointed out on the PR, typically do not have that many 
coefficients, so method='direct' would remain the default. Adding method='fft' 
becomes an optionally enabled feature.

Stéfan
___
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: Representation of NumPy scalars

[Stefan van der Walt]

I am in favor of such a change. It will make what is returned more transparent 
to users (and reduce confusion for newcomers). 

With NEP50, we're already adopting a philosophy of explicit scalar usage 
anyway: no longer pretending or trying to make transparent that Python floats 
and NumPy floats are the same.

No one *actually* round-trips objects via repr, but if a user could look at a 
result and know how to construct the object, that is an improvement.

Stéfan 

On Thu, Sep 8, 2022, at 22:26, Matti Picus wrote:
> On 9/9/22 04:15, Warren Weckesser wrote:
>> ...
>> To quote from https://docs.python.org/3/library/functions.html#repr:
>>
>>> For many types, this function makes an attempt to return a string
>>> that would yield an object with the same value when passed to eval();
>> Sebastian, is this an explicit goal of the change?  (Personally, I've
>> gotten used to not taking this too seriously, but my world view is
>> biased by the long-term use of NumPy, which has never followed this
>> guideline.)
>>
>> If that is a goal, than the floating point types with precision
>> greater than double precision will need to display the argument of the
>> type as a string.  For example, the following is run on a platform
>> where numpy.longdouble is extended precision (80 bits):
>>
>> ```
>> In [161]: longpi = np.longdouble('3.14159265358979323846')
>>
>> In [162]: longpi
>> Out[162]: 3.1415926535897932385
>>
>> In [163]: np.longdouble(3.1415926535897932385)  # Argument is parsed
>> as 64 bit float
>> Out[163]: 3.141592653589793116
>>
>> In [164]: np.longdouble('3.1415926535897932385')  # Correctly
>> reproduces the longdouble
>> Out[164]: 3.1415926535897932385
>> ```
>>
>> Warren
>
>
> As others have mentioned, the change will greatly enhance UX at the cost 
> of documentation cleanups. While the representation may not be perfectly 
> roundtrip-able, I think it still is an improvement and worthwhile. 
> Elsewhere I have suggested we need more documentation around 
> array/scalar printing, perhaps that would be a place to mention the 
> limitations of string representations.
>
> Matti
___
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: Display runtime information through a new function: `show_runtime`

[Stefan van der Walt]

On Tue, Aug 9, 2022, at 04:10, Ralf Gommers wrote:
>> 
>> On 7/8/22 07:08, Stefan van der Walt wrote:
>> >
>> > If the aim is to merge these functions (show_config/runtime) 
>> > eventually, why not merge them now and avoid introducing another 
>> > function into the root namespace?
> 
> I'm guessing that the reason is that `show_config` is defined in 
> `numpy/__config__.py`, which is a file that is generated by `numpy.distutils 
> (deprecated). So adding to it now means having to reimplement it soon. For 
> runtime info there's also no need to put that in a build system component, 
> while for build-time info there must be such a connection somewhere. Hence I 
> think the PR is fine as is.

That makes sense. +1 from me then. 

Stéfan ___
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: Display runtime information through a new function: `show_runtime`

[Stefan van der Walt]

Hi Ganesh, 

If the aim is to merge these functions (show_config/runtime) eventually, why 
not merge them now and avoid introducing another function into the root 
namespace?

Stéfan

On Sat, Aug 6, 2022, at 20:55, Ganesh Kathiresan wrote:
> Hi Team,
> 
> We are planning on adding a new function called `np.show_runtime` to display 
> the runtime information of the machine in addition to `np.show_config` which 
> displays the build-related information.
> Relevant PR: ENH: Use threadpoolctl in show_runtime (a new function) #21468 
> 
> 
> Reasons for new function:
> 1. Will be helpful in root-causing issuing with information from the 
> acceleration frameworks.
> 2. Build time information alone is not always helpful [1]
> 
> Sample Output of new function
> >>> np.show_runtime()
> [{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
>   'found': ['SSSE3',
> 'SSE41',
> 'POPCNT',
> 'SSE42',
> 'AVX',
> 'F16C',
> 'FMA3',
> 'AVX2'],
>   'not_found': ['AVX512F',
> 'AVX512CD',
> 'AVX512_KNL',
> 'AVX512_KNM',
> 'AVX512_SKX',
> 'AVX512_CLX',
> 'AVX512_CNL',
> 'AVX512_ICL']}},
>  {'architecture': 'Zen',
>   'filepath': 
> '/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so',
>   'internal_api': 'openblas',
>   'num_threads': 12,
>   'prefix': 'libopenblas',
>   'threading_layer': 'pthreads',
>   'user_api': 'blas',
>   'version': '0.3.20'}]
> Under the hood
> `np.show_runtime` will use `threadpoolctl` [2] to get the runtime information 
> of the frameworks. In addition to this, we will also display useful SIMD 
> extensions that are supported.
> 
> Future Scope
> 1. When we move towards meson, we can leverage the additional information and 
> revamp `np.show_config` to utilize it.
> 2. If needed, we can gradually merge `show_runtime` and `show_config` to 
> display information in sections and various other formats.
> 
> Please do let us know if you have any suggestions on improving this function 
> or concerns about the information provided by the new function.
> 
> Thanks,
> Ganesh
> 
> [1] show_config displays useless info when installed through conda-forge 
> channel  (#14492)
> [2] threadpoolctl ___
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: GSoC Student Announcement 2022

[Stefan van der Walt]

On Mon, May 23, 2022, at 07:24, Rohit Goswami wrote:
> NumPy as a sub-organization under the Python Software Foundation 
> organization will be mentoring a summer student this year funded by the 
> Google Summer of Code program. Ralf facilitated the application process 
> and I will be the primary mentor this year (with Gagandeep for 
> support). Please look forward to work done by our mentee, Namami 
> Shankar who will be working on F2PY and in particular our front-end.

Congratulations, Namami!  We look forward to working with you, and to seeing 
f2py improve!

Stéfan
___
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: Dropping the pdf documentation.

[Stefan van der Walt]

On Mon, May 23, 2022, at 10:34, Ralf Gommers wrote:
> I'm not so interested in the detailed discussion later on in this thread to 
> be honest. Let me propose a simple solution that should make everyone happy:
> 1. We drop pdf builds in CI, the release process and the Docker image, but 
> keep support in the code base.
> 2. Rohit volunteered to maintain the pdf build, so if he (or another person 
> we know and trust to receive artifacts from and distribute them) wants to 
> send PRs to fix doc build issues and merge a pdf build into 
> https://github.com/numpy/doc/, we'll review and merge those.

I second this proposal.  Maybe with the provision that if, in a year from now, 
the PDF build is in a broken / unmaintained state, we remove it completely.

Stéfan
___
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: Automatic formatters for only changed lines

[Stefan van der Walt]

Hi Matti,

On Thu, May 5, 2022, at 22:08, Matti Picus wrote:
> This somehow runs when I do "git commit"? Do I need to add anything to 
> my git environment to pick up the hook? How do I turn it off if I find 
> it prevents progress or breaks? Do we need to add anything to the 
> documentation to warn developers about possible complications or errors?

The hook is optional, and is set up  by running pre-commit (which itself is a 
pip-installable python package):

pre-commit install

If you want to turn it off, you simply uninstall it.  `pre-commit` has a 
configuration file in which you set up all the linting-type checks you want to 
do (e.g. 
https://github.com/networkx/networkx/blob/main/.pre-commit-config.yaml).  You 
could also run the linter manually:

pre-commit run -a  (on all files)
pre-commit run filename

And this is typically what happens in the CI (except that it will only run on 
modified files).

> If it runs locally before committing, what does "enforce on CI" mean and 
> how is that different from the current linting CI job?

You run the linter on CI same as now, to ensure that all style rules are met. 
But the hook gives a developer earlier warning, so they don't have to wait for 
CI runs to complete to know they need to fix things up.

Stéfan
___
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: Automatic formatters for only changed lines

[Stefan van der Walt]

On Thu, May 5, 2022, at 12:00, Trevor Gross wrote:
> I don't necessarily know that this should be enforced on CI off the bat 
> (though in the future it could be), but at least having the tool available 
> and easily usable would help to incrementally improve codebase style, and 
> remove the need for formatting by hand.

On all projects we've set up pre-commit with style formatting, it has 
significantly reduced noise and nitpicks in PR discussions.  It makes for a 
better contributor experience, thus I am in favor.  Black isn't perfect by any 
means, but never having to talk about formatting again makes it worth it!

Stéfan
___
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: Exposing `from_dlpack` to the main namespace

[Stefan van der Walt]

On Tue, Mar 8, 2022, at 09:01, Sebastian Berg wrote:
> An annoyance with methods is that our class is `np.ndarray` with an
> awkward `__new__` [2].
> So if it is `np.array.from_*` it would not be (only) a static- or
> classmethod, but also attached to that function.

It sounds like there are several good reasons not to go the static route; 
thanks for considering, though.

Stéfan
___
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: Exposing `from_dlpack` to the main namespace

[Stefan van der Walt]

Hi Sebastian,

On Tue, Mar 8, 2022, at 07:41, Sebastian Berg wrote:
> just a brief note that:
>
> https://github.com/numpy/numpy/pull/21145
>
> will add `np.from_dlpack` (to import objects implementing the
> `__dlpack__` dunder [1].

In other places in the ecosystem, like pandas and xarray, `from_x` and friends 
live as static methods on their respective classes.  Any reason not to add this 
as `numpy.array.from_dlpack`? We may also want to consider adding all the other 
`from*`'s there and deprecating the original usage (without removing it).

Stéfan
___
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] Depending on NumPy: to future pin or not

[Stefan van der Walt]

Hi all,

There's a discussion at

https://github.com/numpy/numpy/pull/21144

on whether we should recommend to libraries that depend on NumPy to limit the 
number of future NumPy releases their package will operate with.

If this is something you've spent time thinking about, please weigh in.

Thanks,
Stéfan
___
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 draft for the future behaviour of scalar promotion

[Stefan van der Walt]

On Mon, Feb 21, 2022, at 20:56, Juan Nunez-Iglesias wrote:
> > the
> > latter would seem consistent with the "principle of least surprise" when 
> > moving from a typed language to
> > NumPy work perhaps, though arguably slightly less user-friendly if naively 
> > doing some operations with
> > a less formal view of typing (new Python user messing around with NumPy?)
> 
> fwiw, my rationale here is that many (most?) beginners will eventually become 
> intermediate-to-advanced, at which point purity becomes increasingly 
> important. It is often easier to explain a "pure" principle to a beginner 
> than it is to navigate around magic behaviour as an expert. At scikit-image 
> tutorials we often begin by having the users overflow a uint8 image, then we 
> explain why that's the case and how to work around it.

Just to play a bit of devil's advocate here, I'd have to say that most people 
will not expect

x[0] + 200

To often yield a number less than 200!

I think uint8's are especially problematic because they overflow so quickly 
(you won't easily run into the same behavior with uint16 and higher).  Of 
course, there is no way to pretend that NumPy integers are Python integers, but 
by changing the casting table for uint8 a bit we may be able to avoid many 
common errors.

Besides, coming from value based casting, users already have this expectation:

In [1]: np.uint8(255) + 1
Out[1]: 256

Currently, NumPy scalars and arrays are treated differently.  Arrays have 
stronger types than scalars, in that users expect:

In [3]: np.array([253, 254, 255], dtype=np.uint8) + 3
Out[3]: array([0, 1, 2], dtype=uint8)

So perhaps the real question is: how important is it to us that arrays and 
scalars behave the same in the new casting scheme?  (JAX, from the docs you 
linked, also makes the scalar vs array distinction.)

> We have also increasingly encountered users surprised/annoyed that 
> scikit-image blew up their uint8 to a float64, using 8x the RAM.

I know this used to be true, but my sense is that it is less and less so, 
especially now that almost all skimage functions use floatx internally.

Stéfan

___
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: Unpacking 0-D object arrays when setting item/filling

[Stefan van der Walt]

On Mon, Feb 14, 2022, at 12:45, Sebastian Berg wrote:
> But this is currently *not* consistently the case.  I wish to make this
> consistent.  The confusion is around object arrays, though:
>
> value = np.array(None, dtype=object)
> arr[0] = value
>
> Stores `value` without unpacking it currently.
>
> arr.fill(value)
>
> Stores the `None` (unpacking `value`) if and only if `value` is 0-D.

That last behavior doesn't look right to me.  An object array should be thought 
of as a collection of pointers, and if you happen to want to point to a NumPy 
array, so be it.

> Further related behaviour is that:
>
> np.array(value)  # unpacks any array
> np.array([value, None], dtype=object)  # does not unpack

This seems reasonable. What would another reasonable expectation be?

> Now, we could unpack making it impossible to place a 0-D array into an
> object array except via `arr.itemset()`.

Not sure why we'd do that.

> My current preference is to store the 0-D arrays as-is, and basically
> say that passing a 0-D array as value for:
>
> arr.fill(0d_arr)
> arr[0] = 0d_arr  # this is fine: arr[0, ...] = 0d_arr

Does this differ from the current behavior?  It looks to me like object arrays 
get correctly filled and assigned.

Stéfan
___
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: Announcement: SciPy Community Meetings

[Stefan van der Walt]

On Sat, Jan 29, 2022, at 07:11, Melissa Mendonça wrote:
> The next one will happen this week, on* February 2, at 12 pm UTC*.

I just want to confirm that this means "mid-day UTC" or "4am Pacific"?

Stéfan
___
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: Shape detection

[Stefan van der Walt]

Hi Pawel,

I would recommend scikit-image for these types of analysis. Here's a start:

---

from skimage import io, measure
import numpy as np

image = io.imread('disc.png')
thresholded = image > 10
labels = measure.label(image)
regions = measure.regionprops(labels)
regions_small = [r for r in regions if r.area < 10]

mu = np.mean([r.area for r in regions_small])
M = np.max([r.area for r in regions_small])
print(f"Mean area: {mu}")
print(f"Max area: {M}")

---

That's a pretty crude way of rejecting the background areas, and can be 
improved in various ways.  Feel free to also post to the scikit-image user 
forum at https://forum.image.sc/tag/scikit-image

Best regards,
Stéfan

On Sat, Jan 22, 2022, at 10:45, pawel.dar...@gmail.com wrote:
> Hello,
>
> I am not sure that this is correct group for my problem but I hope 
> someone can help me :)
>
> I try to analyze picture with porous material 
> (https://python.neocast.eu/disc.png). I calculate a total quantity of 
> each pores but I would like also calculate a porosity. To make I need a 
> size of sample or total pixels which are in the sample. How to do it ?
>
> thanks in advance
> Pavel
___
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: Fit 2D points to closed curve

[Stefan van der Walt]

Hi Roger,

On Thu, Jan 20, 2022, at 07:13, roger.dav...@geo-spatial.co.uk wrote:
> I use a CAD package called Rhino which lets users write python scripts 
> that run in the cad environment. I have a closed curve that is a design 
> surface border and I have a sparse data set of 2D surveyed points taken 
> around that border, so some error is included in the 2D data set. I 
> would like to know what python function I could use to do a 2D best fit 
> of the points to the curve.

This isn't exactly what you asked for, but in case you are looking to refine 
these points into a smoother, I've found subdivision splines very handy.  To 
get the boundary conditions right is usually just a matter of repeating the 
start and end points enough times to cover the subdivision mask. 

Here is an example implementation of Catmul-Clark subdivision: 
https://github.com/matplotlib/viscm/blob/master/viscm/bezierbuilder.py#L323

You can choose subdivision coefficients so that the resulting curve goes 
exactly through your data points or not.

Best regards,
Stéfan
___
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: Performance mystery

[Stefan van der Walt]

On Tue, Jan 18, 2022, at 21:55, Warren Weckesser wrote:
> expr = 'z.real**2 + z.imag**2'
>
> z = generate_sample(n, rng)

🤔 If I duplicate the `z = ...` line, I get the fast result throughout.  If, 
however, I use `generate_sample(1, rng)` (or any other value than `n`), it does 
not improve matters.

Could this be a memory caching issue?

Stéfan
___
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: Code formatters

[Stefan van der Walt]

On Thu, Nov 18, 2021, at 09:51, Sebastian Berg wrote:
> Git can even mark commits as "only style fixups" I think to hide them
> from `git blame` and following history has never bothered me too much;
> the only thing that seems tricky there is when functionality is moved
> between files.
> The main downside to me is probably that it will creating conflicts in
> all open PRs.  With some coordination/announcement that is maybe OK.

if we do this, we should probably go through each of the 200+ open PRs (or, at 
least, the non-conflicted ones), apply the formatter, and then squash the PR 
into a single commit. We can do that by script.

Stéfan
___
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] Tensor typing meeting (15 Nov) slides & video

[Stefan van der Walt]

I thought this might be of interest to Bas and others.

- Original message -
From: Matthew Rahtz via Typing-sig
Date: Tuesday, November 16, 2021 02:31

Thanks to everyone for coming! Recording is here 
,
 and the slides are at Dealing with DTypes 
.
 Details of this and previous tensor typing meetings are available here 
.

Our next tensor typing meeting will tentatively be on *Monday the 13th of 
December*. See you then!

A quick summary of the talk is below.
 * How should we handle data type promotion in stubs?
 * Option 1: One overload for each possible combination of dtypes
 * Option 2: One overload for each result dtype
 * Option 3: Don't handle type promotion
 * Option 4: Use a dtype class hierarchy and exploit Union type operator 
behaviour
 * Option 5: Propose a type promotion operator
 * Option 6: Propose a 'nearest common parent' operator
 * Option 7: Propose a type lookup table operator
 * Consensus during discussion was that since it looks like a new type operator 
*would* be required, we should probably hold off on dealing with this until the 
community shows a strong desire for this feature, and in the meantime just not 
handle data type promotion in stubs.

___
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: Code formatters

[Stefan van der Walt]

On Sun, Nov 14, 2021, at 15:26, Juan Nunez-Iglesias wrote:
> Oh, and yes, yapf does allow formatting only the diff. I agree that 
> reformatting the entire code base is problematic.

That's a good point: it's possible to make these changes incrementally. There's 
something called yapf-diff. It's in the main repo, but not integrated into the 
pre-commit hook yet. 

Best regards, 
Stéfan ___
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: Code formatters

[Stefan van der Walt]

On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote:
> The black formatter is much improved in its latest version and I think good 
> enough to start using. The main drawbacks that I see are:
>  * all operators, including '*' and '/',  get spaces around them,
>  * very long strings are not broken into multiple lines,
>  * lists, tuples, and function signatures are either on one line, or broken 
> into multiple lines of one element/argument each,
>  * the formatting of extended logical expressions could be improved to 
> emphasize the priority of 'and' over 'or' operators

We've also been having a conversation around mathematical formatting here: 
https://discuss.scientific-python.org/t/how-to-format-mathematical-expressions/62/8

I tried yapf recently, and was pleased with the output.  One concern about yapf 
was that it has many configuration options: but the only important thing is 
that you fix the knobs, then you simply have a different version of black.

In my experience, while none of these tools are perfect, not having to have 
discussions around formatting is completely worth it!

Stéfan
___
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: Spam in PRs?

[Stefan van der Walt]

Hi Chuck,

On Wed, Oct 20, 2021, at 14:35, Charles R Harris wrote:
> Anyone know why/how app.netlify got into scipy.org? See 
> https://github.com/scipy/scipy.org/pull/417 for an example. More information 
> at https://app.netlify.com/sites/condescending-hopper-c3ed30/deploys .

Yes, this is part of: https://github.com/scipy/scipy.org/pull/413

Stéfan
___
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: Musllinux wheels

[Stefan van der Walt]

On Tue, Oct 12, 2021, at 10:13, Matthew Brett wrote:
> If you haven't got to it, I can do it.

Filed a PR for this last night: 
https://github.com/multi-build/docker-images/pull/20

Best regards,
Stéfan
___
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: Musllinux wheels

[Stefan van der Walt]

On Mon, Oct 11, 2021, at 07:56, Matthew Brett wrote:
> My guess is that that would be less than 90 minutes of work for
> someone with some Docker experience.

I'll give it a shot.

Stéfan
___
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: spam on the mailing lists

[Stefan van der Walt]

On Wed, Oct 6, 2021, at 13:57, Aaron Meurer wrote:
> Coming back to earth on the original discussion, is there really no
> way to moderate new users on the mailing list platform used by this
> list (mailman?)? On the SymPy list, which uses Google Groups, we
> moderate all new users, so that first time posts have to be moderated
> but after that people can post directly. We have had very minimal spam
> even in the queue (to be fair, I'm sure Google applies its own
> filtering), and only one in recent memory that got through, due to the
> moderators not reading the message contents carefully enough.

For scikit-image we have to pre-approve all new posters and subscribers.  The 
posts are fine, but vetting subscribers is a pain because you can't just Google 
every email to find out if it is legit.

The spammers are getting smarter; one of them recently used `kern` in their 
name to get around our moderation :)

We've updated discuss.scientific-python.org to allow "Mailing list mode", which 
should simulate what Matti and Chuck want (i.e., receiving emails for each 
post, and being able to reply).  You can enable it under your user profile if 
you want to try it out.

Stéfan
___
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: spam on the mailing lists

[Stefan van der Walt]

On Wed, Sep 29, 2021, at 14:39, Ralf Gommers wrote:
> 
> On Wed, Sep 29, 2021 at 11:32 PM Stefan van der Walt  
> wrote:
>> __
>> On Wed, Sep 29, 2021, at 13:58, Ralf Gommers wrote:
>>> This was discussed in the community meeting today. No one was really 
>>> enthusiastic, concerns that were brought up included the lack of an email 
>>> interface, and an unclear boundary between issues and discussions.
>> 
>> FWIW, Discourse has an email interface.  I'm not sure what is meant by 
>> "unclear boundary between issues and discussions"—that is not something our 
>> mailing list provides either.
> 
> That was specifically about GitHub Issues vs. GitHub Discussions. It's often 
> not clear if something is a bug or not, so moving items between those two 
> tabs can get confusing quickly. It wasn't my remark, but in the one case 
> where I tried out Discussions my experience was indeed the same - visitors to 
> the repo don't quite know which one to use.

Ah, yes, that makes sense.  This will hopefully not be an issue for a dedicated 
forum then.

Stéfan
___
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: spam on the mailing lists

[Stefan van der Walt]

On Wed, Sep 29, 2021, at 13:58, Ralf Gommers wrote:
> This was discussed in the community meeting today. No one was really 
> enthusiastic, concerns that were brought up included the lack of an email 
> interface, and an unclear boundary between issues and discussions.

FWIW, Discourse has an email interface.  I'm not sure what is meant by "unclear 
boundary between issues and discussions"—that is not something our mailing list 
provides either.

> If we move, importing the mailing list archives will clearly be important 
> though, any replacement should be able to do this.

python.org allows us to download an mbox backup of numpy-discussion, and this 
archive can be imported into discourse.  I'd be happy to do so as a proof of 
concept, if that would be helpful.

Stéfan
___
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: spam on the mailing lists

[Stefan van der Walt]

On Wed, Sep 29, 2021, at 03:02, Ralf Gommers wrote:
> We don't have admin access to the python.org lists, so this is a bit of a 
> problem. We have never had a spam problem, so we can ask to block this user 
> first. If it continues to happen, we may be able to moderate new subscriber 
> emails, but we do need to ask for permissions first and I'm not sure we'll 
> get them.
> 
> A better solution longer term is migrating to Discourse, which has far better 
> moderation tools than Mailman and is also more approachable for people not 
> used to mailing lists (which is most newcomers to open source). Migrating is 
> a bit of a pain, but with the new CZI grant having a focus on improving the 
> contributor experience, we should be able to do this.

I would like to offer the use of https://discuss.scientific-python.org.  I 
would be happy to handle email list migration, and have created the following 
two categories for NumPy discussion:

User discussion: https://discuss.scientific-python.org/c/user/numpy 

Contributor discussion: 
https://discuss.scientific-python.org/c/contributor/numpy 


We're happy to support this as part of the Scientific Python ecosystem grant, 
and will give admin rights to anyone on the NumPy developer team who wants to 
help manage / moderate discussions.

Of course, we can also just delete these if the team prefers to have their 
discussions somewhere else.  But I think there is a benefit to bringing 
community discussions together in one place.

Best regards,
Stéfan
___
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] Proposal for adding bit_count

[Stefan van der Walt]

On Mon, Aug 2, 2021, at 10:50, Sebastian Berg wrote:
> * Should `np.ndarray.bit_count()` exist?  I tend against this;
>   but we should have it on (integer) scalars to mirror the
>   Python `int`.

Should `np.bit_count` exist?  Having it on the int* types may be sufficient.

> * The return value is currently the same type as the input.  That
>   means that: `np.bit_count(uint8)` returns the count as `uint8`
>   while `np.bit_count(int32)` returns it as `int32`, etc.

What is the max value of the count?  64?  If so it can go in a uint8.

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Mon, Jul 5, 2021, at 00:42, Ralf Gommers wrote:
> I share your dislike, but I don't really see a better place where it doesn't 
> make it even harder to spell, but I did just think of an alternative that may 
> actually be quite reasonable: keep it private.

That would be fine.  We haven't had this feature requested for many years, so 
as long as it is available in some shape or form it should satisfy the advanced 
users who need it.  It also doesn't force us into a decision we cannot reverse 
(adding to the top-level API).

> The reason why Gagandeep started working on this is so we can have the 
> never-copy behavior in the `numpy.array_api` namespace. For the `asarray` 
> function there, the `copy` keyword is still boolean, with description:
> 
> Whether or not to make a copy of the input. If ` True`, always copies. 
> If ` False`, never copies for input which supports DLPack or the buffer 
> protocol, 
> and raises ` ValueError`` `in case that would be necessary. 
> If ` None ` , reuses existing memory buffer if possible, copies 
> otherwise. 
> Default: ` None`. 
> 
> In the end I think that's better than strings, and way better than enums - we 
> just can't have that in the main namespace, because we can't change what 
> `False` does.

I agree  that 
this is a good API (although not everybody else does). 


W.r.t. NumPy's API: it could be okay to change the behavior of copy=False to 
make it more strict (no copies ever), because then at least errors will be 
raised and we can provide a message with instructions on how to fix it.

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Sun, Jul 4, 2021, at 13:00, Ralf Gommers wrote:
> I don't think so. We basically arrived at the solution, and there's a PR that 
> is mostly done too. This really isn't that complicated that we should require 
> a NEP.

Personally, I don't like np.CopyMode in the main namespace. If we can agree to 
stash it somewhere else, and tentatively aim to move to strings at point X in 
time for consistency with the rest of the API, I have no issue with going 
ahead. 

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

Re: [Numpy-discussion] `keepdims=True` for argmin/argmx and C-API `PyArray_ArgMaxWithKeepdims`

[Stefan van der Walt]

Hi Sebastian,

On Wed, Jun 30, 2021, at 18:23, Sebastian Berg wrote:
> The PR https://github.com/numpy/numpy/pull/19211 proposes to extend
> argmin and argmax with a `keepdims=False` keyword-only argument.

This seems consistent with existing APIs, so I'm not concerned.

For those wondering, `keepdims` preserves the number of dimensions of the 
original array in a reduction operation like `sum`:

In [1]: X = np.random.random((10, 15))

In [2]: np.sum(X).shape
Out[2]: ()

In [3]: np.sum(X, keepdims=True).shape
Out[3]: (1, 1)

This is sometimes useful for broadcasting.

> The PR  also proposes to add:
> 
> * `PyArray_ArgMinWithKeepdims`
> * `PyArray_ArgMaxWithKeepdims`

I am curious whether this is our general pattern for adding keyword argument 
functionality to functions in the C-API.  It seems a bit excessive!

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Thu, Jun 24, 2021, at 01:03, Ralf Gommers wrote:
> For this one, I'd say it kinda looks like we do need one, so then  let's just 
> add one and be done with it, rather than inventing odd patterns like tacking 
> enum members onto an existing function.

There are two arguments on the table that resonate with me:

1. Chuck argues that the current `copy=False` behavior (which, in fact, means 
copy-if-needed) is nonsensical and should be fixed.
2. Ralf argues that strings are ultimately the interface we'd like to see.

To achieve (1), we would need a deprecation cycle.  During that deprecation 
cycle, we would need to provide a way to continue providing 'copy-if-needed' 
behavior.  This can be achieved either with an enum or by accepting strings.

Stephan argues that accepting strings will be harmful to new code running on 
old versions of NumPy.  I would still like to get a sense of how often this 
happens, or if that is a hit we are willing to take.  If we decide that the 
concern is a significant one, then we would have to go the enum route, at least 
for a while.  However, I see no compelling reason to have that enum live in the 
top-level namespace though: it is for relatively advanced use, and it will be 
temporary.

If we take the enum route, how do we get to (2)?  We add a type check for a few 
releases and raise an error on string arguments (or, alternatively, handle 
'always'/'never'/'if_needed' without advertising that functionality).  Then, 
once we switch to string arguments, users will get an error (for old NumPy) or 
it will work as expected (for new NumPy).

I didn't think so originally, but I suppose we are in NEP territory now.

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote:
> Personally I was a fan of the Enum approach. People dislike it because 
> it is not “Pythonic”, but imho that is an accident of history because 
> Enums only appeared (iirc) in Python 3.4. In fact, they are the right 
> data structure for this particular problem, so for my money we should 
> *make it* Pythonic by starting to use it everywhere where we have a 
> finite list of choices.

The enum definitely feels like the right abstraction. But the resulting API is 
clunky because of naming and top-level scarcity.

Hence the suggestion to tag it onto np.copy, but there is an argument to be 
made for consistency by placing all enums under np.flags or similar.

Still, np.flags.copy.IF_NEEDED gets long.

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

Perhaps it is also worth going back to explore our original motivation for 
making this change.

One reason was that Sebastian didn't like people doing `x.shape = ...`.  Users 
do that, presumably, to trigger an error if a copy needs to be made.  However, 
we can catch that already:

x = np.reshape(y, ...)
if np.may_share_memory(x, y):
...

We can fix Sebastian's issue by introducing a `copy` keyword to `reshape`, 
which currently has none:

x = np.reshape(y, copy='never')

For consistency, it would be nice to have `np.array` support copy=never, but if 
there is no urgency we can take the long route towards an API that uses strings 
(consistent with the rest of NumPy).

The arguments against string names *right now* is that, if users write code 
with `copy='if-needed'` it will not work correctly with old NumPy code, since 
old versions will evaluate `if-needed` to True.  The assessment was that this 
happens frequently, but we should consider how frequently, and how big of an 
issue it is.

So, I guess ultimately I am wondering if the change to `np.array` is needed 
right now, or whether we can get away without it for a while.

Stéfan

On Tue, Jun 22, 2021, at 15:21, bas van beek wrote:
> > Stefan, that sketch is more complicated than it needs to be - `np.copy` is 
> > a python function, so you can just attach the attributes directly! 
> > (although maybe there are implications for static typing)
> 
> For the type annotations we can simply use something akin to Stéfans proposed 
> `NpCopy` class; 
> probably in combination with `Protocol`.
> It's a bit more work compared to annotating a normal python function, but 
> it's quite easy nevertheless.
> 
> Regards, Bas
> 
> 
> *From:* NumPy-Discussion 
>  on behalf of 
> Eric Wieser 
> *Sent:* 21 June 2021 18:56
> *To:* Discussion of Numerical Python 
> *Subject:* Re: [Numpy-discussion] copy="never" discussion and no deprecation 
> cycle? 
>  
> 
> Stefan, that sketch is more complicated than it needs to be - `np.copy` is a 
> python function, so you can just attach the attributes directly! (although 
> maybe there are implications for static typing)
> ```
> class CopyFlag(enum.Enum):
> IF_NEEDED = 0
> ALWAYS = 1
> NEVER = 2
> 
> np.copy.IF_NEEDED = CopyFlag.IF_NEEDED
> np.copy.ALWAYS = CopyFlag.ALWAYS
> np.copy.NEVER = CopyFlag.NEVER
> ```
> It would also work nicely for the `True/False/other` version that was 
> proposed in the much older PR as `np.never_copy`:
> ```
> class _CopyNever:
> def __bool__(self): raise ValueError
> 
> np.copy.NEVER = _CopyNever()
> ```
> 
> All of these versions (and using the enum directly) seem fine to me.
> If we go down the enum route route, we probably want to add "new-style" 
> versions of `np.CLIP` and friends that are true enums / live within a more 
> obvious namespace.
> 
> Eric 
> 
> On Mon, 21 Jun 2021 at 17:24, Stefan van der Walt  
> wrote:
>> On Sun, Jun 20, 2021, at 20:46, Gagandeep Singh wrote:
>> > I have recently joined the mailing list and have gone through the previous 
>> > discussions on this thread. I would like to share my analysis (advantages 
>> > and disadvantages) of three possible alternatives (Enum, String, boolean) 
>> > to support the proposed feature.
>> 
>> Thanks for this thorough analysis, Gagandeep!
>> 
>> I'll throw one more heretical idea out there:
>> 
>> `np.copy.IF_NEEDED`, `np.copy.ALWAYS`, `np.copy.NEVER`.
>> 
>> This has the advantages of the enum, doesn't pollute the global namespace, 
>> and has an intuitive name.
>> 
>> `np.array(x, copy=np.copy.ALWAYS)`
>> 
>> It would be slightly more awkward to type, but is doable.  A rough Python 
>> version sketch would be:
>> 
>> class CopyFlag(enum.Enum):
>> IF_NEEDED = 0
>> ALWAYS = 1
>> NEVER = 2
>> 
>> class NpCopy:
>> IF_NEEDED : CopyFlag = CopyFlag.IF_NEEDED
>> ALWAYS : CopyFlag = CopyFlag.ALWAYS
>> NEVER : CopyFlag = CopyFlag.NEVER
>> 
>> def __call__(self, x):
>> return ...whatever copy returns...
>> 
>> np.copy = NpCopy()
>> 
>> 
>> Stéfan
>> ___
>> 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] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Sun, Jun 20, 2021, at 20:46, Gagandeep Singh wrote:
> I have recently joined the mailing list and have gone through the previous 
> discussions on this thread. I would like to share my analysis (advantages and 
> disadvantages) of three possible alternatives (Enum, String, boolean) to 
> support the proposed feature.

Thanks for this thorough analysis, Gagandeep!

I'll throw one more heretical idea out there:

`np.copy.IF_NEEDED`, `np.copy.ALWAYS`, `np.copy.NEVER`.

This has the advantages of the enum, doesn't pollute the global namespace, and 
has an intuitive name.

`np.array(x, copy=np.copy.ALWAYS)`

It would be slightly more awkward to type, but is doable.  A rough Python 
version sketch would be:

class CopyFlag(enum.Enum):
IF_NEEDED = 0
ALWAYS = 1
NEVER = 2

class NpCopy:
IF_NEEDED : CopyFlag = CopyFlag.IF_NEEDED
ALWAYS : CopyFlag = CopyFlag.ALWAYS
NEVER : CopyFlag = CopyFlag.NEVER

def __call__(self, x):
return ...whatever copy returns...

np.copy = NpCopy()


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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Sun, Jun 20, 2021, at 18:53, Charles R Harris wrote:
> 
> On Fri, Jun 18, 2021 at 8:52 AM Stefan van der Walt  
> wrote:
>> __
>> On Thu, Jun 17, 2021, at 16:23, Stephan Hoyer wrote: 
>>> This happens all the time. Even if we make copy='never' an error *today*, 
>>> users will be encountering existing versions of NumPy for years into the 
>>> future, so we won't be able to change the behavior of copy='never' for a 
>>> very long time. Our deprecation policy says we would need to wait at least 
>>> one year for this, but frankly I'm not sure that's enough for the 
>>> possibility of silent bugs. 3-4 years might be more realistic.
>> 
>> If we go the enum route, we may just as well deprecate string arguments at 
>> the same time so that we have the flexibility to introduce them again in the 
>> future.

That makes sense to me, but I think this would not preclude the enum from being 
introduced right now. If we make this change, the enum will become the only 
mechanism by which to get the behavior we currently have (copy-if-needed). 

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

Re: [Numpy-discussion] NEP 36- fair play (was: request to remove the numpy-aarch64 package from PyPI)

[Stefan van der Walt]

On Tue, Jun 15, 2021, at 00:38, Matti Picus wrote:
> Having just re-read the NEP, I think the Motivation section should 
> mention name re-use: "Additionally, we wish to reduce confusion when 
> package names imply they are sanctioned or maintained by NumPy". Other 
> than that it looks good to me. Do you want to make a PR to add the 
> discussion and change the status, and notify the list of your intention 
> to accept it?

Thanks, Matti.  I've made the change suggested and updated the status here:

https://github.com/numpy/numpy/pull/19284

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

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Thu, Jun 17, 2021, at 16:23, Stephan Hoyer wrote: 
> This happens all the time. Even if we make copy='never' an error *today*, 
> users will be encountering existing versions of NumPy for years into the 
> future, so we won't be able to change the behavior of copy='never' for a very 
> long time. Our deprecation policy says we would need to wait at least one 
> year for this, but frankly I'm not sure that's enough for the possibility of 
> silent bugs. 3-4 years might be more realistic.

If we go the enum route, we may just as well deprecate string arguments at the 
same time so that we have the flexibility to introduce them again in the future.

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

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

[Stefan van der Walt]

On Tue, Jun 15, 2021, at 11:12, ALFONSO LUIS CASTAÑO MARIN wrote:
> To what potential PEP are you referring exactly? Type arithmetic or 
> automatically interpret `1` as `Literal[1]` wherever it makes sense?


I guess both, but particularly the first (using standard operators in type 
definitions).  The first seems pretty unwieldy without the second, though.


> Indeed to have a common repository with an initial document would be a good 
> way to go. So far we did not start anything because the PEP on Variadics was 
> still waiting for appoval. However, we also wanted to make sure that Numpy 
> folks believe that this approach towards type arithmetic makes sense for 
> their use cases.
> Maybe we could sync on this on the next Numpy Development meeting?


We have a "triage" meeting this coming Wednesday at 11am Pacific, which would 
be a good venue for discussing these details.

Best regards,
Stéfan

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

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

[Stefan van der Walt]

Hi Alfonso, Matthew,

On Tue, Jun 15, 2021, at 06:59, ALFONSO LUIS CASTAÑO MARIN wrote:
>  First of all, when talking about type arithmetic I suggest to refer to the 
> latest presentation for the summit rather than from the Tensor Typing 
> Meetings 
> (https://docs.google.com/presentation/d/1NZzZfbUCXi78LDDe8C3hAaK9on8ZiX3Z2k4BlZXwsJ8/edit).
>  Here I intentionally refer to the +,-,*,// syntax rather than the Add[] one. 
> Moreover, I also write 1 + A rather than Literal[1] + A, assuming that we 
> could write a PEP for enabling this behavior if needed, and as Matthew said, 
> it seems feasible based on what was said in the summit.


This PEP sounds like it is of some interest to many of us.  Would it make sense 
to start a repository with an initial document that we can iterate on, or how 
do you typically develop these?

Stéfan___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] request to remove the numpy-aarch64 package from PyPI

[Stefan van der Walt]

On Sun, Jun 13, 2021, at 18:21, Charles R Harris wrote:
> 
> 
> On Sun, Jun 13, 2021 at 10:47 AM Ralf Gommers  wrote:
>> FYI, I noticed this package that claimed to be maintained by us: 
>> https://pypi.org/project/numpy-aarch64/. That's not ours, so I tried to 
>> contact the author (no email provided, but guessed the same username on 
>> GitHub) and asked to remove it: 
>> https://github.com/tomasriv/DNA_Sequence/issues/1.
>> 
>> There are a very large number of packages with "numpy" in the name on PyPI, 
>> and there's no way we can audit/police that effectively, but if it's a 
>> rebuild that pretends like it's official then I think it's worth doing 
>> something about. It could contain malicious code for all we know.
>> 
> 
> That is a pretty misleading package description, would have fooled me if I 
> didn't know better. I didn't get the impression it was malicious, but still . 
> . .

Maybe now is a good time to move to accept:

https://numpy.org/neps/nep-0036-fair-play.html

Stéfan


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

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

[Stefan van der Walt]

On Tue, Jun 8, 2021, at 03:23, Juan Nunez-Iglesias wrote:
> Hello! Any chance this could be recorded for those of us in useless 
> time zones? 😂 

I added a note to the agenda; we'll ask the speakers and record if they don't 
mind.

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

Re: [Numpy-discussion] Google Season of Docs

[Stefan van der Walt]

On Fri, May 14, 2021, at 11:41, Melissa Mendonça wrote:
> I am happy to announce we found our technical writer for the Google Season of 
> Docs program. After looking at all submitted proposals we have decided to 
> hire Mukulika. You can see her Statement of Interest here: 
> https://mail.python.org/pipermail/numpy-discussion/2021-May/081746.html

A great big welcome to the team, Mukulika!  We are excited to work with you.

Thank you also to Melissa & Ross for mentoring, and to all the other applicants 
for their interest in the project.

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

Re: [Numpy-discussion] Steering Council membership updates

[Stefan van der Walt]

On Wed, Mar 31, 2021, at 03:18, Ralf Gommers wrote:
> We're excited to welcome Inessa Pawson and Melissa Mendonça as new SC 
> members. Inessa has been contributing for close to two years, and has been a 
> driving force behind the new website, the user survey, and other content and 
> community initiatives. Melissa has been contributing since the start of last 
> year, she leads the documentation team, co-maintains f2py, does a lot of 
> mentoring, and is the PI on our current CZI grant.

Thank you for your service, Inessa and Melissa!  Welcome to the steering 
council.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Development branches renamed

[Stefan van der Walt]

Hi everyone,

The development branches of most of the repositories on github.com/numpy have 
been renamed to `main` (this is the GitHub default for newly created 
repositories).  The move has not yet been made for sub-projects such as 
`numpydoc` or `numpy.org`, but those should follow soon.

We were able to preserve all PRs, other than those for which the original 
branches have been deleted.

You can update your locally cloned repository to have a `main` branch as 
follows:

git branch -m master main
git fetch 
git branch -u /main main

(where YOUR_UPSTREAM_REMOTE is typically called `upstream` or `origin`)

If you have any trouble, let us know.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

[Stefan van der Walt]

On Tue, Feb 16, 2021, at 07:49, Joseph Fox-Rabinovitz wrote:
> I'm getting a generally lukewarm not negative response. Should we put it to a 
> vote?

Things here don't typically get decided by vote—I think you'll have to build 
towards consensus.  It may be overkill to write a NEP, but outlining a proposed 
solution along with pros and cons and getting everyone on board is necessary.

The API surface is a touchy issue, and so it is difficult to get new features 
like these added.

Ralf has been working towards this idea, but having a well-organised namespace 
of utility functions outside of the core NumPy API would be helpful in allowing 
expansion and experimentation, without making the current situation worse 
(where we effectively have to support things forever).  As an example, take 
Cartesian product [0] and array combinations [1], which have been requested 
several times on StackOverflow, but there's nowhere to put them.

Stéfan

[0] 
https://stackoverflow.com/questions/1208118/using-numpy-to-build-an-array-of-all-combinations-of-two-arrays#comment22769580_1235363

[1] 
https://stackoverflow.com/questions/16003217/n-d-version-of-itertools-combinations-in-numpy/16008578#16008578___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Pearu Peterson has joined the NumPy developers team.

[Stefan van der Walt]

On Sun, Feb 7, 2021, at 10:12, Charles R Harris wrote:
> Pearu Peterson has joined the NumPy developers team. Pearu was responsible 
> for contributing f2py and much of distutils in the early days of NumPy. 
> Welcome back Pearu.

Welcome back, it's good to see you around more, Pearu!

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On the use of adding an expfit class in or next to the polynomial module

[Stefan van der Walt]

Hi there,

Thanks for reaching out.

On Wed, Jan 27, 2021, at 04:24, Swan BOSC wrote:
> Namely, the expfit function, as presented here 
>  
> (https://octave.sourceforge.io/optim/function/expfit.html) doesn't seem to 
> exist. I'm currently building a replacement for it in my words (keywords I 
> mean ;) ) but maybe a better solution would be to contribute some code into 
> NumPy.
> 
> AFAIK, the preferred way to fit a Polynomial nowadays is to call 
> `numpy.polynomial.polynomial.``Polynomial.` 
> Do you think that a class for `Exponential` based on that one would be an 
> interesting addition to NumPy ?

I think Prony's method would probably be a better fit for `scipy.signal`.  
Please be mindful not to translate this from existing GPL code, but to 
implement it afresh.

Best regards,
Stéfan___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] PSF Scientific WG grants

[Stefan van der Walt]

Hi all,

I'd like to make you aware of this call for funding from the PSF:

https://pyfound.blogspot.com/2020/12/psf-scientific-working-group-announces.html

Funding is for up to 4000 USD.

The deadline has been extended (the blog post will soon be updated 
accordingly); I recommend submitting requests within the next two weeks.

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

Re: [Numpy-discussion] accepting NEP 23 - backwards compatibility and deprecation policy NEP

[Stefan van der Walt]

On Tue, Jan 26, 2021, at 00:25, Ralf Gommers wrote:
> The update PR was merged after a lot more review on GitHub. I propose we 
> change the status of this NEP to Accepted. We'll merge a PR to do so unless 
> there are objections within the next five days.

Thanks for the heads-up, Ralf.  I am happy to have the NEP accepted.

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

Re: [Numpy-discussion] Rules for argument parsing/forwarding in __array_function__ and __array_ufunc__

[Stefan van der Walt]

Hi Sebastian,

Looking at these three rules, they all seem to stem from one simple question: 
do we desire for a single code snippet to be runnable on multiple array 
implementations?

On Wed, Dec 2, 2020, at 15:34, Sebastian Berg wrote:
> 1. If an argument is invalid in NumPy it is considered and error.
>For example:
> 
>np.log(arr, my_weird_argument=True)
> 
>is always an error even if the `__array_function__` implementation
>of `arr` would support it.
>NEP 18 explicitly says that allowing forwarding could be done, but
>will not be done at this time.

Relaxing this rule will mean that code working for one array implementation 
(which has this keyword) may not work for another.

> 2. Arguments must only be forwarded if they are passed in:
> 
>np.mean(cupy_array)
> 
>ends up as `cupy.mean(cupy_array)` and not:
> 
>cupy.mean(cupy_array, axis=None, dtype=None, out=None,
>  keepdims=False, where=True)
> 
>meaning that CuPy does not need to implement all of those kwargs and
>NumPy can add new ones without breaking anyones code.

This may ultimately make it harder for array implementors (they will only see 
errors once someone tries to pass in an argument that they forgot to 
implement).  Perhaps better to pass all so they know what they're dealing with?

> 3. NumPy should not check the *validity* of the arguments. For example:
>`np.add.reduce(xarray, axis="long")` should probably work in xarray.
>(`xarray.DataArray` does not actually implement the above.)
>But a string cannot be used as an axis in NumPy.

Getting back to the original question: if this code is to be run on multiple 
implementations, we should ensure that no strange values pass through.

Personally, I like the idea of a single API that works on multiple backends.  
As such, I would 1) not pass through unknown arguments, 2) always pass through 
all arguments, and 3) validate inputs to each call.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A second CZI grant for NumPy and OpenBLAS

[Stefan van der Walt]

On Thu, Nov 19, 2020, at 12:33, Melissa Mendonça wrote:
> I'm happy to announce that NumPy and OpenBLAS have (again) received a joint 
> grant from the Chan Zuckerberg Initiative. 

That's fantastic news—congratulations, Melissa!

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

Re: [Numpy-discussion] API, NEP: Inclusion of the experimental `like=` argument in NumPy 1.20 (we currently lean to yes)

[Stefan van der Walt]

On Thu, Nov 12, 2020, at 17:48, Sebastian Berg wrote:
> [3] There is the "middle ground": We could require an environment
> variable to activate it. But we discussed it briefly at the community
> meeting as well, and I think the consensus was there is probably no
> good argument for that. (e.g. it would mean the argument doesn't show
> up in the online documentation.)

As long as we don't follow this option (3), I think the changes are innocuous.  
If it helps some libraries out there, I see no reason not to include it.

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

Re: [Numpy-discussion] New package to speed up ufunc inner loops

[Stefan van der Walt]

On Wed, Nov 4, 2020, at 16:21, Aaron Meurer wrote:
> But as I noted, this is already off topic for the original discussion
> here, and since there's apparently no interest in improving the NEP
> wording, I'll drop it.

I was trying to understand where, specifically, the language falls short, and 
what to do about improving it.

Perhaps a sentence making it clear that this is not a licensing issue will 
assuage your concerns? If not, please help me understand where statements are 
overly strong, unclear, or insufficient in coverage.

Best regards, 
Stéfan 
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New package to speed up ufunc inner loops

[Stefan van der Walt]

On Wed, Nov 4, 2020, at 14:54, Aaron Meurer wrote:
> Again, *I* understand the purpose of this document, but I think the
> way it is currently written it could easily be misinterpreted by
> someone else.

Misinterpreted in what way? That they would think we have an ability to enforce 
the guidelines? We *are* trying to encourage certain behavior here. If they 
read it and, our of abundant caution reach out to us, that's a fine outcome. 

What negative outcomes do you foresee? 

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

Re: [Numpy-discussion] New package to speed up ufunc inner loops

[Stefan van der Walt]

On Wed, Nov 4, 2020, at 13:47, Aaron Meurer wrote:
> I hope this isn't too off topic, but this "fair play" NEP reads like
> it is a set of additional restrictions on the NumPy license, which if
> it is, would make NumPy no longer open source by the OSI definition. I
> think the NEP should be much clearer that these are requests but not
> requirements.

Specifically, the NEP is worded as follows:

"""
This document aims to define a minimal set of rules that, when followed, will 
be considered good-faith efforts in line with the expectations of the NumPy 
developers.

...

When in doubt, please talk to us first. We may suggest an alternative; at 
minimum, we’ll be prepared.
"""

There is no language of forced restriction.

The heading in question is "Do not reuse the NumPy name for projects not 
developed by the NumPy community".  Matti is a member of our community, and 
while the project may be sponsored by others, he is doing exactly what the NEP 
recommends: discussing the issue with the community.

Community members should weigh in if they see an issue with the naming.  I 
don't think this is a particularly good name for a package (not easy to 
pronounce, does not indicate functionality of the package), but I don't 
personally have an issue with it either.

Best regards,
Stéfan
___
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

[Stefan van der Walt]

On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> I also misunderstood the purpose of the NEP.  I assumed it was
> intended to encourage projects to drop old versions of Python.  Other
> people have viewed the NEP similarly:
> https://github.com/networkx/networkx/issues/4027

Of all the packages, it makes sense for NumPy to behave most conservatively 
with depreciations. The NEP suggests allowable support periods, but as far as I 
recall does not enforce minimal support. 

Stephan Hoyer had a good recommendation on how we can clarify the NEP to be 
easier to intuit. Stephan, shall we make an ammendment to the NEP with your 
idea? 

Best regards, 
Stéfan 
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy team update

[Stefan van der Walt]

Ralf, thank you very much for summarizing community movements—it is great to 
see all this growth. To all new committers and team members, thank you, and 
welcome! Your work is so appreciated.

Keep up the good work!

Stéfan

On Thu, Jun 18, 2020, at 23:57, Ralf Gommers wrote:
> The NumPy team is growing, and it's awesome to see everything that is going 
> on. Hard to keep up with, but that's a good thing! I think it's a good time 
> for an update on people who gained commit rights, or joined one of the teams 
> we now have.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Armv8 server donation

[Stefan van der Walt]

On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote:
>  I noticed that the shippable CI always skipped after PR submitted , The 
> reason why it's skip seems to be "No active nodes found in shared node pool 
> "shippable_shared_aarch64""
> Potential bugs may buried through out numpy without shippable CI.
>  I happened to own an idle armv8 server that can donate to numpy community, 
> please let me know if that can improve numpy's CI/CD environment , also need 
> somebody help me set up the CI/CD environment on that server.

Thank you for your kind offer!

Someone else would be more qualified than I to comment on why the pool is 
empty, and what resources we have available.

I know that AppVeyor allows you to host your own nodes, and it looks like Azure 
does too:

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops
https://www.appveyor.com/docs/server/#linux

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

Re: [Numpy-discussion] Google Season of Docs 2020 - New NumPy Community Member

[Stefan van der Walt]

Hi Themistoklis,

Welcome to the NumPy mailing list! Thank you for the overview of your work. We 
look forward to the GSoD this year, and I'm excited to see all the enthusiasm 
for it.

Best regards,
Stéfan

On Tue, May 12, 2020, at 16:02, Themistoklis Spanoudis wrote:
> Hello everyone!
> 
> I am very excited to introduce myself to the NumPy community!
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Season of Docs technical writer

[Stefan van der Walt]

Hi Ben,

On Fri, May 1, 2020, at 05:52, Ben Nathanson wrote:
> I've updated my page (https://bennathanson.com/numpy2020) to include a 
> section on Curation and Adaptation.

I enjoyed reading your page, and appreciate the wit sprinkled through your 
writing. I look forward to working with you this season!

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Feelings about type aliases in NumPy

[Stefan van der Walt]

On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
> But, Stephan pointed out that it might be confusing to users for
> objects to only exist at typing time, so we came around to the
> question of whether people are open to the idea of including the type
> aliases in NumPy itself. Ralf's concrete proposal was to make a module
> numpy.types (or maybe numpy.typing) to hold the aliases so that they
> don't pollute the top-level namespace. The module would initially
> contain the types

That sounds very sensible.  Having types available with NumPy should also 
encourage their use, especially if we can add some documentation around it.

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

Re: [Numpy-discussion] Suggestion: prevent silent downcast in np.full_like

[Stefan van der Walt]

Hi Alexis,

On Mon, Feb 24, 2020, at 12:00, A T wrote:
> Here is a summarized code example of how unsafe downcasting in np.full_like() 
> resulted in issues in our scientific toolbox:
> 
>  t0 = 20.5
> # We're trying to make a constant-valued "ufunc"
> temperature = lambda x: np.full_like(x, t0)
> print(temperature([0.1, 0.7, 2.3]))
>  # [20.5 20.5 20.5]
> print(temperature(0))
>  # 20

I agree that this behavior is counter-intuitive. When t0 is not of the same 
type as x, the user intent is likely to store t0 as-is.

If a check is introduced, there is the question of how strict that check should 
be. Checking that dtypes are identical may be too strict (there are objects 
that cast to one another without loss of information). Perhaps, for now, a 
warning is the best way to flag that something is going on. Users who do not 
wish to see such a warning can first cast t0 to the correct dtype:

 np.full_like(x, x.dtype.type(t0))

or

 np.full_like(x, int(t0))

I imagine we'd want to show the warning even if dtype is specified.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to accept NEP #44: Restructuring the NumPy Documentation

[Stefan van der Walt]

On Wed, Feb 19, 2020, at 03:58, Melissa Mendonça wrote:
> I am proposing the acceptance of NEP 44 - Restructuring the NumPy 
> Documentation. 
> 
> https://numpy.org/neps/nep-0044-restructuring-numpy-docs.html

Thanks, Melissa, for developing this NEP! The plan makes sense to me.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Tensor Developer Summit

[Stefan van der Walt]

Hi Neil,

On Wed, Feb 19, 2020, at 11:43, Neal Becker wrote:
> Sounds like an exciting group!  Will it be streamed?

Due to the highly interactive nature of this event, we will not be streaming.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Tensor Developer Summit

[Stefan van der Walt]

Hi all,

This has been mentioned on the community calls, but not on the mailing list, so 
a reminder about the Tensor Developer Summit happening at March in Berkeley:

https://xd-con.org/tensor-2020/

We would love to have developers and advanced users of NumPy (or other array 
libraries with Python interfaces) attend.  Registration closes 20 February.

Best regards,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] BIDS-NumPy progress reports, 2018/2019

[Stefan van der Walt]

Dear colleagues,

I'd like to thank everyone who contributed to NumPy over the past year.
NumPy is a complex undertaking that requires inputs from many spheres to
progress.  Your contribution, however big or small, is important, and we
appreciate you taking the time to make it.

As we look back over the past year, I would like to share with you the
two grant reports we've written, reporting on our work done with the
community:

2018: http://doi.org/10.5281/zenodo.3585761
2019: http://doi.org/10.5281/zenodo.3585767

I fully appreciate that none of this work could have happened in
isolation, and that we depend on the community to help set a development
agenda, review code, establish regular meetings, do outreach, and much
more. Thank you.

We look forward to seeing you on 8 January for the next community call.
With Ralf's CZI award coming into play, 2020 promises to be an exciting
year for NumPy!

Happy holidays,
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion