On Thu, 2021-10-07 at 15:41 -0700, Brock Mendel wrote:
> Will this have any impact on the difficulty of finding "where is
> np.foo or
> ndarray.bar implemented"?
>
I don't think so. It is always a bit annoying to step through the
python and then C-layer before you reach the computation part (or
Will this have any impact on the difficulty of finding "where is np.foo or
ndarray.bar implemented"?
On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg
wrote:
> On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
> > On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
> > > Hi folks,
> > >
>
On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote:
> On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
> > Hi folks,
> >
> > https://github.com/numpy/numpy/pull/19713 showcases what *could* be
> > a
> > first step
> > toward getting rid of generated C code within numpy, in favor of
> >
A couple of questions from a quick casual reading
1. radixsort (void *start...)
Do we really need void*? We don't know the type of start at compile time?
2. reinterpret_cast start (related to #1).
3. reinterpret_cast(malloc(num * sizeof(T)));
A C-ism. Would it work to use new T[num]?
On Tue,
Looks like a new world record and a satisfactory efforts!
https://bit.ly/3EVg4Ma
___
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/nump
On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:
> Hi folks,
>
> https://github.com/numpy/numpy/pull/19713 showcases what *could* be a
> first step
> toward getting rid of generated C code within numpy, in favor of some
> C++ code,
> coupled with a single macro trick.
It seems time to pic
