[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

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

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

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