=
Announcing NumExpr 2.10.0
=
Hi everyone,
NumExpr 2.10.0 is a release offering support for latest versions of NumPy 2.0.
This is still experimental, so please report any issues you find. Thanks to
Clément Robert and Thomas Caswell for the work.
Announcing NumExpr 2.9.0
Hi everyone,
NumExpr 2.9.0 is a release offering support for latest versions of PyPy.
The full test suite should pass now, at least for the Python 3.10 version.
Thanks to @27rabbitlt for most of the work and @mgorny and
f any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/l
w of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman
mPy-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: fal...@gmail.com
>
--
Francesc Alted
__
On Wed, Feb 8, 2023 at 5:28 PM Sebastian Berg
wrote:
> On Wed, 2023-02-08 at 17:08 +0100, Francesc Alted wrote:
> > On Wed, Feb 8, 2023 at 3:19 PM Sebastian Berg <
> > sebast...@sipsolutions.net>
> > wrote:
> >
> > > On Wed, 2023-02-08 at 14:31 +0100, F
On Wed, Feb 8, 2023 at 3:19 PM Sebastian Berg
wrote:
> On Wed, 2023-02-08 at 14:31 +0100, Francesc Alted wrote:
> > On Wed, Feb 8, 2023 at 1:42 PM Sebastian Berg <
> > sebast...@sipsolutions.net>
> > wrote:
> >
> > > On Wed, 2023-02-08 at 12:
On Wed, Feb 8, 2023 at 1:42 PM Sebastian Berg
wrote:
> On Wed, 2023-02-08 at 12:48 +0100, Francesc Alted wrote:
> > Hi,
> >
> >
>
>
>
> > Is there a way (or an ongoing effort) to express the variety of data
> > types
> > in NumPy that beats the ab
'V':
repr = str(dtype)
else:
repr = dtype.str
Is there a way (or an ongoing effort) to express the variety of data types
in NumPy that beats the above (which seems somewhat inconsistent to me)?
Thanks!
--
Francesc Alted
___
NumPy-Discussion ma
;>
> ___
> 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: fal...@gmai
ufunclab is really cool and inspiring! I just wonder why this has not
been announced more broadly :-)
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://
roblem is if there is a method to avoid this kind of
>> overhead?* I 've learned that in Numpy we could create our own ufunc
>> with: *frompyfunc*, but it seems that there is no SIMD optimization nor
>> multi-threads utilized since this is 100 times slower than *"d = a * b +
>&g
Hi,
On Thu, Sep 1, 2022 at 6:18 AM Qianqian Fang wrote:
> On 8/30/22 06:29, Francesc Alted wrote:
>
>
> Not exactly. What we've done is to encode the header and the trailer
> (i.e. where the metadata is) of the frame with msgpack. The chunks
> section
> <https://github
well as the data markers ([,{,U, S, ...) and string values (
> "double","lzma", ...) are all directly readable. There are garbled text
> in the binary stream that may also be printed to make it hard to read, but
> it's readability is still way better than most other
optimization.
>
>
> Qianqian
>
>
> ___
> 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.p
On Mon, Jan 24, 2022 at 1:42 PM Francesc Alted wrote:
> On Mon, Jan 24, 2022 at 11:01 AM Francesc Alted wrote:
>
>> On Mon, Jan 24, 2022 at 2:15 AM Warren Weckesser <
>> warren.weckes...@gmail.com> wrote:
>>
>>> Thanks Sebastian for pointing out th
On Mon, Jan 24, 2022 at 11:01 AM Francesc Alted wrote:
> On Mon, Jan 24, 2022 at 2:15 AM Warren Weckesser <
> warren.weckes...@gmail.com> wrote:
>
>> Thanks Sebastian for pointing out that the issue is (minor) page
>> faults, and thanks Francesc for providing
ing for each of the
temporary that the OS makes for the anonymous mmap() that it has to make.
All in all, hats off to Warren for this entertaining piece of investigation!
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
in NumPy, so it should be straight
> forward to write a small package/module that tweaks the allocation
> strategy here.
>
That's good to hear.
Cheers,
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscrib
On Wed, Jan 19, 2022 at 7:48 PM Francesc Alted wrote:
> On Wed, Jan 19, 2022 at 6:58 PM Stanley Seibert
> wrote:
>
>> Given that this seems to be Linux only, is this related to how glibc does
>> large allocations (>128kB) using mmap()?
>>
>> https://stacko
1
times, which is plenty of time for doing the allocation (just should
require just a single iteration).
>
>
> On Wed, Jan 19, 2022 at 9:06 AM Sebastian Berg
> wrote:
>
>> On Wed, 2022-01-19 at 11:49 +0100, Francesc Alted wrote:
>> > On Wed, Jan 19, 2022
imag
for _ in range(3):
t = timeit.timeit(expr, globals=globals(), number=timeit_reps)
print(f"{1e6*t/timeit_reps:9.4f} microseconds")
print()
"""
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussio
Very well written article! Congratulations everybody, most specially Travis
and Chuck for their outstanding work!
El dc., 16 set. 2020, 19.54, Ralf Gommers va
escriure:
> Hi all,
>
> Nature published our first official paper:
> https://www.nature.com/articles/s41586-020-2649-2
>
> And here is
On Tue, Mar 24, 2020 at 12:12 PM Matti Picus wrote:
>
> On 24/3/20 11:48 am, Francesc Alted wrote:
> >
> > What I am trying to say is that NumPy should be rather agnostic about
> > providing data types beyond the relatively simple set that already
> > supports.
On Mon, Mar 23, 2020 at 9:49 PM Sebastian Berg
wrote:
> On Mon, 2020-03-23 at 18:23 +0100, Francesc Alted wrote:
>
> > > If we were designing a new programming language around array
> > > computing
> > > principles, I do think that would be the approach I
C-API seem to be used rarely,
> > > possibly never, by downstream projects.
> > >
> > >
> > >
> > > Detailed Description
> > >
> > >
> > > This section details the d
ld allow numexpr to have a more Pythonic syntax?
> eg.
>
> with numexpr:
> y = np.sin(x) * np.exp(newfactor * x)
>
> ?
>
> Juan.
>
>
> On 24 Jul 2019, at 6:39 pm, Francesc Alted wrote:
>
> (disclosure: I have been a long time maintainer of numexpr)
>
>
it? Isn't that wasteful?
> > > Does Numpy provide an efficient way of doing that without creating
> > > a redundant array?
> > >
> > >
> > >
> > > Thanks for your help,
> > >
> > > Ram Rachum.
> > >
> >
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
--
Francesc Alted
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
* Franziska Horn +
> * Yevhenii Hyzyla +
> * Vladislav Iakovlev +
> * Marvin Kastner +
> * Mher Kazandjian
> * Thomas Keck
> * Adam Kurkiewicz +
> * Ronan Lamy +
> * J.L. Lanfranchi +
> * Eric Larson
> * Denis Laxalde
> * Gregory R. Lee
> * Felix Lenders +
30 matches
Mail list logo
