No comment on the separate namespace for exceptions, but +1 to more
specific exceptions like BroadcastError or InvalidPromotion. They are
more informative, allow users to catch specific errors without pattern
matching the message string, and they would allow putting the relevant
error information i
On Fri, Nov 11, 2022 at 10:07 PM Stefan van der Walt
wrote:
> 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.
>
It actually
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 lis
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
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
> * M
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.
>
>
> 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
On Fri, Nov 11, 2022 at 3:43 PM Sebastian Berg
wrote:
> On Fri, 2022-11-11 at 17:03 +0300, Evgeni Burovski wrote:
> > > (2) a more important one, the `.c.src` format. In SciPy we got rid
> > > of it, and we're not going to make Meson understand an ad-hoc
> > > templating method that only NumPy us
On Fri, 2022-11-11 at 17:03 +0300, Evgeni Burovski wrote:
> > (2) a more important one, the `.c.src` format. In SciPy we got rid
> > of it, and we're not going to make Meson understand an ad-hoc
> > templating method that only NumPy uses. So we have two choices:
> > also get rid of it, or write a n
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
> (2) a more important one, the `.c.src` format. In SciPy we got rid of it, and
> we're not going to make Meson understand an ad-hoc templating method that
> only NumPy uses. So we have two choices: also get rid of it, or write a new
> custom preprocessing utility for NumPy's Meson build. I thin
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
Hi all,
I want to add a new exception or two. It is a longer story, that you
can find at the bottom :).
Lets create a namespace for custom errors! I don't want to propose new
exceptions that just get dumped in to the main namespace, so why not
make one like `errors` in pandas or `exceptions` in
On Fri, Nov 11, 2022 at 1:52 PM Sebastian Berg
wrote:
> On Fri, 2022-11-11 at 12:27 +0100, Ralf Gommers wrote:
> > Hi all,
> >
> > With distutils now removed from the stdlib in the Python 3.12 release
> > cycle, the clock is ticking a bit for dealing with our build system
> > situation. With SciP
On Fri, 2022-11-11 at 12:27 +0100, Ralf Gommers wrote:
> Hi all,
>
> With distutils now removed from the stdlib in the Python 3.12 release
> cycle, the clock is ticking a bit for dealing with our build system
> situation. With SciPy's move to Meson now basically complete - there
> are
> always loo
Hi all,
With distutils now removed from the stdlib in the Python 3.12 release
cycle, the clock is ticking a bit for dealing with our build system
situation. With SciPy's move to Meson now basically complete - there are
always loose ends & improvements, but the 1.9 releases have gone well -
it's ti
16 matches
Mail list logo
