[Numpy-discussion] Why ufunc out arg has to be an ndarray?

From time to time I find myself overwriting a python buffer with the output of a ufunc, for example like this: import array import numpy as np a = array.array('f', (1,1,1)) np.exp2(a, out=np.asarray(a)) assert a.tolist() == [2, 2, 2] Here I have to wrap `out=np.asarray(a)` because the more natu

[Numpy-discussion] Re: np.ndenumerate doesn't obey mask?

> On 22 Oct 2024, at 18:00, numpy-discussion-requ...@python.org wrote: > > From: Neal Becker > Subject: [Numpy-discussion] np.ndenumerate doesn't obey mask? > Date: 21 October 2024 at 18:52:41 CEST > To: Discussion of Numerical Python > Reply-To: Discussion of Numerical Python > > > I was us

[Numpy-discussion] Re: Extend ldexp to handle complex inputs

‘np.ldexp’ exists mainly for compatibility with the C/C++ functions ldexp, ldexpf, ldexpl, which are defined for float/double/long double. Quoting the C refs: > On binary systems (where FLT_RADIX is 2), ldexp is equivalent to scalbn. > The function ldexp ("load exponent"), together with its dual,

[Numpy-discussion] Re: Comparison between numpy scalars returns numpy bool class and not native python bool class

> On 27 Jun 2024, at 23:48, Aaron Meurer wrote: > > Apparently the reason this happens is that True, False, and None are > compared using 'is' in structural pattern matching (see Please let me stress that the ‘match/case’ snippet was only a concrete example of a situation in which, say ‘f(a)’

[Numpy-discussion] Comparison between numpy scalars returns numpy bool class and not native python bool class

It is well known that ‘np.bool' is not interchangeable with python ‘bool’, and in fact 'issubclass(np.bool, bool)’ is false. On the contrary, numpy floats are subclassing python floats—'issubclass(np.float64, float) is true—so I’m wondering if the fact that scalar comparison returns a np.bool b

[Numpy-discussion] Re: Introducing quarterly date units to datetime64 and timedelta64

Actually quarters (3 months sub-year groupings) are already supported as ‘M8[3M]’ and ‘m8[3M]’: >>> np.datetime64('2024-05').astype('M8[3M]') - np.datetime64('2020-03').astype('M8[3M]') numpy.timedelta64(17,'3M') So explicitly introducing a ‘Q’ time unit is only to enable more int

[Numpy-discussion] Re: How is "round to N decimal places" defined for binary floating point numbers?

Oscar Gustafsson wrote: > I would take it that round x to N radix-R digits means > round_to_integer(x * R**N)/R**N > (ignoring floating-point issues) Yes, this is the tried-and-true way: first define the function in exact arithmetic, then ask for the floating point implementation to return an ap

[Numpy-discussion] How is "round to N decimal places" defined for binary floating point numbers?

I have always been puzzled about how to correctly define the python built-in `round(number, ndigits)` when `number` is a binary float and `ndigits` is greater than zero. Apparently CPython and numpy disagree: >>> round(2.765, 2) 2.77 >>> np.round(2.765, 2) 2.76 My

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

On 31 May 2023, at 16:32, numpy-discussion-requ...@python.org wrote: It seems fairly clear that with this recent change, the feeling is that the tradeoff is bad and that too much accuracy was lost, for not enough real-world gain. However, we now ha

[Numpy-discussion] Re: New feature: binary (arbitrary base) rounding

On 8 Nov 2022, at 15:32, numpy-discussion-requ...@python.org wrote: Thanks for the proposal. I don't have much of an opinion on this and right now I am mainly wondering whether there is prior art which can inform us that this is relatively widely us

[Numpy-discussion] Re: An article on numpy data types (Lev Maximov)

First of all, happy new 2022 UTC year! Let my add just a very brief note to this discussion: I opened https://github.com/numpy/numpy/issues/20675 which addresses the shortcomings of the current documentation, which is in my opinion not sufficiently

[Numpy-discussion] Re: Proposal for new function to determine if a float contains an integer

I would rather suggest .is_integer(integer_dtype) signature because knowing that 1e300 is an integer is not very useful in the numpy world, since this integer number is not representable as a numpy.integer dtype. Note that in python assert not f.is_integer() or int(f) == f never fails because

[Numpy-discussion] Re: NumPy-Discussion Digest, Vol 183, Issue 33

Lev, excuse me if I go in super pedantic mode, but your answer and the current text of the article fail to grasp an important point. 1) The proleptic Gregorian calendar is about leap year rules. It tracks days without making any assumption on the length of days. If we agree on using this calend

[Numpy-discussion] Re: An article on numpy data types

Nice overview! In my opinion section 5. Datetimes could benefit from some clarifications, and contains a couple of typos. Let me start with the typos. I read "As in pure python, np.datetime64 is accompained by np.timedelta64 (stored as a single np.uint64) with the expectable arithmetic opera

Re: [Numpy-discussion] bad CRC errors when using np.savez, only sometimes though!

If changing the on-disk format is an option, I would suggest h5py which allows to save numpy arrays in HDF5 format. Stefano On 14 May 2021, at 16:22, numpy-discussion-requ...@python.org wrote: Aside from writing m

Re: [Numpy-discussion] Proposal: add the timestamp64 type

Discussion on time is endless! (Sorry for the extra noise, on the mailing list, but I would clarify some points.) If I got it right, np.datetime64 is defined by these points. 1) Internal representation: 64bit signed integer *plus* a time unit. The time unit can be expressed as - a SI valid unit

Re: [Numpy-discussion] Proposal: add the timestamp64 type (Noam Yorav-Raphael)

On 11 Nov 2020, at 18:00, numpy-discussion-requ...@python.org wrote: I propose to add a new type called "timestamp64". It will be a pure timestamp, meaning that it represents a moment in time (as seconds/ms/us/ns since the epoch), without any timez

Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

There several mixed issues here. 1. PEP 3141 compliance. Numpy scalars are `numbers.Real` instances, and have to respect the `__round__` semantics defined by PEP 3141: def __round__(self, ndigits:Integral=None): """Rounds self to ndigits d

Re: [Numpy-discussion] New DTypes: Are scalars a central concept in NumPy or not?

The fact that `isinstance(np.float64(1), float)` raises the problem that the current implementation of np.float64 scalars breaks the Liskov substitution principle: `sequence_or_array[round(x)]` works if `x` is a float, but breaks down if x is a np.float64. See https://github.com/numpy/numpy/issu

Re: [Numpy-discussion] round / set_printoptions discrepancy

In my opinion the problem is that numpy floats break the Liskov substitution principle, >>> pyfloat = 16.055 >>> npfloat = np.float64(pyfloat) >>> isinstance(npfloat, float) True >>> round(pyfloat, 2) 16.05 >>> round(npfloat, 2) 16.06 Since numpy.float64 is a subclass of builtins.float I would e