[Numpy-discussion] Re: New GitHub issue UI

2025-01-15 Thread Sebastian Berg
On Wed, 2025-01-15 at 13:50 +0200, Matti Picus via NumPy-Discussion wrote: > > On 14/01/2025 19:05, Nathan via NumPy-Discussion wrote: > > GitHub now has support for "issue types". > > > I couldn't figure out how to customize the types, all I see are > 'bug', > 'feature', 'task' > It can be

[Numpy-discussion] Re: New GitHub issue UI

2025-01-15 Thread Matti Picus via NumPy-Discussion
On 14/01/2025 19:05, Nathan via NumPy-Discussion wrote: GitHub now has support for "issue types". I couldn't figure out how to customize the types, all I see are 'bug', 'feature', 'task' Matti ___ NumPy-Discussion mailing list -- numpy-discussi

[Numpy-discussion] Re: New matvec and vecmat functions

2024-11-22 Thread Sebastian Berg
Hi all, I would like to/lean to going ahead with adding these. And in some discussions I think that was basically the decision, so that is the default currently. But, I am not sure that nobody had serious disagreement about it (or maybe the conjugation part, although I think it drops out of the

[Numpy-discussion] Re: New feature

2024-05-11 Thread Matti Picus
For a start you could share the link for the stand-alone package here, with a short description of what it does. Additional steps would be to write a blog post about it, write it up on reddit's python subreddit, give a talk about it at a conference. Matti On 25/04/2024 23:36, Alexei Lisitsa

[Numpy-discussion] Re: New feature

2024-04-25 Thread Alexei Lisitsa
Ok, thanks package stand alone I did but how I advertise it? Maybe you as expert can say some thing that is needed , something to develop I want some new experience чт, 25 апр. 2024 г., 23:30 Matti Picus : > On 25/04/2024 23:16, Alexei Lisitsa wrote: > > > Waiting for answer > > > What kind of an

[Numpy-discussion] Re: New feature

2024-04-25 Thread Matti Picus
On 25/04/2024 23:16, Alexei Lisitsa wrote: Waiting for answer What kind of answer would you like? I took a look at numpy_list[0] and if it serves your needs, that is great, but I don't think such ndarray generation routines should be added to NumPy until they become more commonly known, us

[Numpy-discussion] Re: New feature

2024-04-25 Thread Alexei Lisitsa
Waiting for answer ___ 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.

[Numpy-discussion] Re: New DType and ArrayMethod C APIs are public

2024-02-14 Thread 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 wri

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-26 Thread Marten van Kerkwijk
> I tend to agree with not using the complex conjugate for vecmat, but would > prefer having > separate functions for that that make it explicit in the name. I also note > that mathematicians > use sesquilinear forms, which have the vector conjugate on the other side, so > there are > different

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-25 Thread Marten van Kerkwijk
Hi Alan, The problem with .dot is not that it is not possible, but more that it is not obvious exactly what will happen given the overloading of multiple use cases; indeed, this is why `np.matmul` was created. For the stacks of vectors case in particular, it is surprising that the vector dimensio

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-25 Thread Alan
On Wed, Jan 24, 2024 at 11:02 PM Marten van Kerkwijk wrote: > Stack of matrices in this context is a an ndarray in which the last two > dimensions are interpreted as columns and rows of matrices (in that > order), stack of vectors as an ndarray in which the last dimension is > interpreted as colu

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-25 Thread Charles R Harris
On Tue, Jan 23, 2024 at 3:18 PM Marten van Kerkwijk wrote: > Hi All, > > I have a PR [1] that adds `np.matvec` and `np.vecmat` gufuncs for > matrix-vector and vector-matrix calculations, to add to plain > matrix-matrix multiplication with `np.matmul` and the inner vector > product with `np.vecdot

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Marten van Kerkwijk
> Could you please offer some code or math notation to help communicate this? > I am forced to guess at the need. > > The words "matrix" and "vector" are ambiguous. > After all, matrices (of given shape) are a type of vector (i.e., can be added > and scaled.) > So if by "matrix" you mean "2d array

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Marten van Kerkwijk
> FWIW, +1 for matvec & vecmat to complement matmat (erm, matmul). Having a > binop where one argument is a matrix and the other is a > stack/batch of vectors is indeed awkward otherwise, and a dedicated function > to clearly distinguish "two matrices" from "a matrix and a > batch of vectors" sou

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Alan
On Wed, Jan 24, 2024 at 2:27 PM Marten van Kerkwijk wrote: > > Why do these belong in NumPy? What is the broad field of application of > these functions? And, > > does a more general concept underpin them? > > Multiplication of a matrix with a vector is about as common as matrix > with matrix or

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Oscar Benjamin
On Wed, 24 Jan 2024 at 19:29, Marten van Kerkwijk wrote: > > > Why do these belong in NumPy? What is the broad field of application of > > these functions? And, > > does a more general concept underpin them? > > Multiplication of a matrix with a vector is about as common as matrix > with matrix o

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Evgeni Burovski
FWIW, +1 for matvec & vecmat to complement matmat (erm, matmul). Having a binop where one argument is a matrix and the other is a stack/batch of vectors is indeed awkward otherwise, and a dedicated function to clearly distinguish "two matrices" from "a matrix and a batch of vectors" sounds great fr

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Marten van Kerkwijk
> Why do these belong in NumPy? What is the broad field of application of these > functions? And, > does a more general concept underpin them? Multiplication of a matrix with a vector is about as common as matrix with matrix or vector with vector, and not currently easy to do for stacks of vector

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-24 Thread Alan
Why do these belong in NumPy? What is the broad field of application of these functions? And, does a more general concept underpin them? Thanks, Alan Isaac On Tue, Jan 23, 2024 at 5:17 PM Marten van Kerkwijk wrote: > Hi All, > > I have a PR [1] that adds `np.matvec` and `np.vecmat` gufuncs for >

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Marten van Kerkwijk
> I can understand the desire to generalise the idea of matrix > multiplication for when the arrays are not both 2-D but taking the > complex conjugate makes absolutely no sense in the context of matrix > multiplication. > > You note above that "vecmat is defined as x†A" but my interpretation > of

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Oscar Benjamin
On Tue, 23 Jan 2024 at 23:13, Marten van Kerkwijk wrote: > > >> I also note that for complex numbers, `vecmat` is defined as `x†A`, > >> i.e., the complex conjugate of the vector is taken. This seems to be the > >> standard and is what we used for `vecdot` too (`x†x`). However, it is > >> *not* wh

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Marten van Kerkwijk
>> I also note that for complex numbers, `vecmat` is defined as `x†A`, >> i.e., the complex conjugate of the vector is taken. This seems to be the >> standard and is what we used for `vecdot` too (`x†x`). However, it is >> *not* what `matmul` does for vector-matrix or indeed vector-vector >> produc

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Marten van Kerkwijk
> For dot product I can convince myself this is a math definition thing and > accept the > conjugation. But for "vecmat" why the complex conjugate of the vector? Are we > assuming that > 1D things are always columns. I am also a bit lost on the difference of dot, > vdot and vecdot. > > Also if _

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Oscar Benjamin
On Tue, 23 Jan 2024 at 22:18, Marten van Kerkwijk wrote: > > I also note that for complex numbers, `vecmat` is defined as `x†A`, > i.e., the complex conjugate of the vector is taken. This seems to be the > standard and is what we used for `vecdot` too (`x†x`). However, it is > *not* what `matmul`

[Numpy-discussion] Re: New matvec and vecmat functions

2024-01-23 Thread Ilhan Polat
For dot product I can convince myself this is a math definition thing and accept the conjugation. But for "vecmat" why the complex conjugate of the vector? Are we assuming that 1D things are always columns. I am also a bit lost on the difference of dot, vdot and vecdot. Also if __matmul__ and np.m

[Numpy-discussion] Re: New Ruff rule for migrating to NumPy 2.0

2024-01-11 Thread Peter Cock via NumPy-Discussion
This looks handy - I used the following to try it: $ pip install -U ruff $ ruff --preview --select NPY201 --fix Happily nothing to address on the code baseI tried. Thanks, Peter On Thu, Jan 11, 2024 at 11:32 AM Mateusz Sokol wrote: > > Hi all! > > Some time ago we added a new rule to Ruff li

[Numpy-discussion] Re: *New Time* Next Documentation team meeting

2023-11-20 Thread Hetav
Hi Makulika, I would love to join today's meeting. Can I get the passcode for it? Regards, Hetav Pandya On Sun, Nov 19, 2023 at 9:07 PM Mukulika Pahari wrote: > Hi all, > > Our next Documentation Team meeting will happen on *Monday, November 20* > at *11PM UTC*. If this time slot is inconveni

[Numpy-discussion] Re: *New Time* Next Documentation team meeting

2023-11-19 Thread Mukulika Pahari
Hi all, Our next Documentation Team meeting will happen on *Monday, November 20* at *11PM UTC*. If this time slot is inconvenient for you to join, please let me know in the replies or Slack and we will try to add another time slot. All are welcome - you don't need to already be a contributor to

[Numpy-discussion] Re: *New Time* Next Documentation team meeting

2023-10-22 Thread Mukulika Pahari
Hi all, Our next Documentation Team meeting will happen on *Monday, October 23* at *11PM UTC*. If this time slot is inconvenient for you to join, please let me know in the replies or Slack and we will try to add another time slot. All are welcome - you don't need to already be a contributor to

[Numpy-discussion] Re: New user dtypes and the buffer protocol

2023-07-06 Thread Matti Picus
On 6/7/23 20:44, Evgeni Burovski wrote: On Thu, Jul 6, 2023 at 7:56 PM Nathan wrote: > > Hi all, > > As you may know, I'm currently working on a variable-width string dtype using the new experimental user dtype API. As part of this work I'm running into papercuts that future dtype authors wil

[Numpy-discussion] Re: New user dtypes and the buffer protocol

2023-07-06 Thread Evgeni Burovski
I wonder if the dlpack protocol can be helpful for these kinds of dtypes? On Thu, Jul 6, 2023 at 7:56 PM Nathan wrote: > > Hi all, > > As you may know, I'm currently working on a variable-width string dtype using the new experimental user dtype API. As part of this work I'm running into papercu

[Numpy-discussion] Re: new time for community meetings

2022-11-19 Thread Inessa Pawson
To follow up on this topic, according to the poll, 19:00 (7 pm) UTC will work best for everyone. I’ve updated the NumPy community events calendars to reflect the change. On Mon, Nov 14, 2022 at 10:25 AM Inessa Pawson wrote: > It’s that time of the year again when some of us have to adjust our >

[Numpy-discussion] Re: New methods exposing UFunc dtype resolution/promotion and internals

2022-11-16 Thread Sebastian Berg
Hi again, On Tue, 2022-10-25 at 11:41 +0200, Sebastian Berg wrote: > Hi all, > > I would like to expose more of the ufunc internals in the following > PR: > >     https://github.com/numpy/numpy/pull/22422/ Just to note that this PR is now merged and scheduled for release (without any serious c

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

2022-11-11 Thread Michael Siebert
Hi all, an advantage of sub-byte datatypes is the potential for accelerated computing. For GPUs, int4 is already happening. Or take int1 for example: if one had two arrays of size 64, that would be eight bytes. Now, if one wanted to add those two arrays, one could simply xor them as a uint64 (o

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

2022-11-11 Thread Sebastian Berg
On Fri, 2022-11-11 at 09:13 -0700, Greg Lucas wrote: > > > > OK, more below.  But unfortunately `int2` and `int4` *are* > > problematic, > > because the NumPy array uses a byte-sized strided layout, so you > > would > > have to store them in a full byte, which is probably not what you > > want. >

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

2022-11-11 Thread Greg Lucas
> > OK, more below. But unfortunately `int2` and `int4` *are* problematic, > because the NumPy array uses a byte-sized strided layout, so you would > have to store them in a full byte, which is probably not what you want. > I am always thinking of adding a provision for it in the DTypes so that

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

2022-11-11 Thread Sebastian Berg
On Fri, 2022-11-11 at 14:55 +0100, Oscar Gustafsson wrote: > Thanks! That does indeed look like a promising approach! And for sure > it > would be better to avoid having to reimplement the whole array-part > and > only focus on the data types. (If successful, my idea of a project > would > basicall

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

2022-11-11 Thread Oscar Gustafsson
Thanks! That does indeed look like a promising approach! And for sure it would be better to avoid having to reimplement the whole array-part and only focus on the data types. (If successful, my idea of a project would basically solve all the custom numerical types discussed, bfloat16, int2, int4 et

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

2022-11-10 Thread Francesc Alted
On Tue, Nov 8, 2022 at 11:43 AM Sebastian Berg wrote: > > I suspect that this would be more something for a project similar to > Warrens ufunclab: > > https://github.com/WarrenWeckesser/ufunclab > > I.e. written as a NumPy ufunc, but not in NumPy iself. > Hey, ufunclab is really cool and ins

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

2022-11-10 Thread Sebastian Berg
On Thu, 2022-11-10 at 14:55 +0100, Oscar Gustafsson wrote: > Den tors 10 nov. 2022 kl 13:10 skrev Sebastian Berg < > sebast...@sipsolutions.net>: > > > On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote: > > > > > > > > I'm not an expert, but I never encountered rounding floating > > > > p

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

2022-11-10 Thread Oscar Gustafsson
Den tors 10 nov. 2022 kl 13:10 skrev Sebastian Berg < sebast...@sipsolutions.net>: > On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote: > > > > > > I'm not an expert, but I never encountered rounding floating point > > > numbers > > > in bases different from 2 and 10. > > > > > > > I agree

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

2022-11-10 Thread Sebastian Berg
On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote: > > > > I'm not an expert, but I never encountered rounding floating point > > numbers > > in bases different from 2 and 10. > > > > I agree that this is probably not very common. More a possibility if > one > would supply a base argumen

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

2022-11-10 Thread Oscar Gustafsson
> > I'm not an expert, but I never encountered rounding floating point numbers > in bases different from 2 and 10. > I agree that this is probably not very common. More a possibility if one would supply a base argument to around. However, it is worth noting that Matlab has the quant function, htt

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

2022-11-10 Thread Stefano Miccoli
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: New feature: binary (arbitrary base) rounding

2022-11-10 Thread Oscar Gustafsson
Den tis 8 nov. 2022 kl 11:44 skrev Sebastian Berg < sebast...@sipsolutions.net>: > On Thu, 2022-11-03 at 11:37 +0100, Oscar Gustafsson wrote: > > Hi all, > > > > I hope this is the correct way to propose a new feature. > > https://github.com/numpy/numpy/issues/22522 > > > > Thanks for the proposal

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

2022-11-08 Thread Sebastian Berg
On Thu, 2022-11-03 at 11:37 +0100, Oscar Gustafsson wrote: > Hi all, > > I hope this is the correct way to propose a new feature. > https://github.com/numpy/numpy/issues/22522 > Thanks for the proposal. I don't have much of an opinion on this and right now I am mainly wondering whether there is

[Numpy-discussion] Re: New stable documentation

2022-05-21 Thread matti picus
On Sat, 21 May 2022 at 16:26, Charles R Harris wrote: > > > On Sat, May 21, 2022 at 5:38 AM Sebastian Berg > wrote: > >> On Sat, 2022-05-21 at 10:33 +0300, matti picus wrote: >> > On Sat, 21 May 2022 at 08:46, Ralf Gommers >> > wrote: >> > >> > > >> > > >> > > On Sat, May 21, 2022 at 3:40 AM Ch

[Numpy-discussion] Re: New stable documentation

2022-05-21 Thread Charles R Harris
On Sat, May 21, 2022 at 5:38 AM Sebastian Berg wrote: > On Sat, 2022-05-21 at 10:33 +0300, matti picus wrote: > > On Sat, 21 May 2022 at 08:46, Ralf Gommers > > wrote: > > > > > > > > > > > On Sat, May 21, 2022 at 3:40 AM Charles R Harris < > > > charlesr.har...@gmail.com> wrote: > > > > > > > H

[Numpy-discussion] Re: New stable documentation

2022-05-21 Thread Sebastian Berg
On Sat, 2022-05-21 at 10:33 +0300, matti picus wrote: > On Sat, 21 May 2022 at 08:46, Ralf Gommers > wrote: > > > > > > > On Sat, May 21, 2022 at 3:40 AM Charles R Harris < > > charlesr.har...@gmail.com> wrote: > > > > > Hi All, > > > > > > I've put up new stable documentation for NumPy 1.22.

[Numpy-discussion] Re: New stable documentation

2022-05-21 Thread matti picus
On Sat, 21 May 2022 at 08:46, Ralf Gommers wrote: > > > On Sat, May 21, 2022 at 3:40 AM Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> Hi All, >> >> I've put up new stable documentation for NumPy 1.22.4. I'd appreciate it >> if those familiar with how they want the documentation to l

[Numpy-discussion] Re: New stable documentation

2022-05-20 Thread Ralf Gommers
On Sat, May 21, 2022 at 3:40 AM Charles R Harris wrote: > Hi All, > > I've put up new stable documentation for NumPy 1.22.4. I'd appreciate it > if those familiar with how they want the documentation to look could take a > look at it so that fixes can be made while I'm still in the documentation

[Numpy-discussion] Re: New

2021-12-27 Thread Ralf Gommers
On Sun, Dec 26, 2021 at 2:13 PM Isha Verma wrote: > Hello I am new to NumPy and I would like to contribute. Can someone please > help me with the ways I can contribute ! > Hi Isha, welcome! We have extensive contributor documentation, and guidance on what types of contributions you can make at h

[Numpy-discussion] Re: new time for community meetings

2021-11-14 Thread Inessa Pawson
Thanks to everyone who participated in the poll. Starting November 24th, bi-weekly NumPy community meetings will be held at 7 pm GMT. On Wed, Nov 10, 2021 at 9:10 PM Inessa Pawson wrote: > It’s that time of the year again when most of us have to adjust our > clocks. For some of us the fun doesn’