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
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
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
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
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
> (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
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
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, 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
>
> 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, 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.
>
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
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
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
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
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
16 matches
Mail list logo
