=
Announcing NumExpr 2.11.0
=
Hi everyone,
NumExpr 2.11.0 Initial support for free-threaded Python 3.13t has been
added.
This is still experimental, so please report any issues you find.
Finally, Python 3.10 is now the minimum supported version.
Pr
tmul()``).
Install it with::
pip install blosc2 --update # if you prefer wheels
conda install -c conda-forge python-blosc2 mkl # if you prefer conda
and MKL
For more info, you can have a look at the release notes in:
https://github.com/Blosc/python-blosc2/releases
Have fun!
--
Francesc A
Announcing Python-Blosc2 3.0.0 (final release)
==
The Blosc development team is pleased to announce the final release of
Python-Blosc2 3.0.0. Now, we will be producing conda(-forge) packages,
as well as providing wheels for the most common platforms, as
shiny new
computation engine and its enhanced capabilities to deal with large
datasets.
Thanks and see you there!
--
Francesc Alted
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le..
Hi,
The Blosc development team is pleased to announce the first beta release of
Python-Blosc2 3.0.0. We have been working hard to provide a new evaluation
engine (based on numexpr) for NDArray instances, and we would like to get
feedback from the community before the final release.
Now, you can
=
Announcing NumExpr 2.10.1
=
Hi everyone,
NumExpr 2.10.1 continues to stabilize the support for NumPy 2.0.0.
Also, the default number of 'safe' threads has been upgraded to 16
(instead of previous 8). Finally, preliminary support for Python 3.13;
t
=
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.
P
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 @m
Let us know 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
Let us know 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://mai
_
> 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...@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
wrapper) we are going in this direction:
if dtype.kind == '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
meu...@gmail.com
>>
> ___
> 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
nclab 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://
>
>>
>>
>> *So another problem 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
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://g
n see, the subfields of the data (_ArraySize_, _ArrayType_,
> ...), as 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 h
the native python parser,
> suggesting rooms for further optimization.
>
>
> Qianqian
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
&g
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 that 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 the links
s the zeroing 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@
rray data allocation 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-discu
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://stackove
3*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,
rate_sample(n, rng)
zreal = z.real
zimag = z.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
___
Num
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 th
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. I
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 would
ed with functions taking DType classes instead.
> > > Although public, large parts of this C-API seem to be used rarely,
> > > possibly never, by downstream projects.
> > >
> > >
> > >
> > > Detailed Desc
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)
>
>
wouldn't 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 mailing list
> > 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
* Gaute Hope +
> * Guillaume Horel +
> * 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.
one of my reasons to go to PyData Barcelona.
>
Exactly, and IMO it is precisely this balance between teaching
fundamentals and new technologies what makes a conference to stand out and
fullfill different expectations. And I must say that PyData Barcelona was
pretty good at that.
Francesc
2017-04-27 18:18 GMT+02:00 Chris Barker :
> On Thu, Apr 27, 2017 at 4:10 AM, Francesc Alted wrote:
>
>> I remember advocating for UCS-4 adoption in the HDF5 library many years
>> ago (2007?), but I had no success and UTF-8 was decided to be the best
>> candidate. So,
>> space that is required by compressed UTF-8 (I won't go into detail, but
>> basically this is possible by using the shuffle filter).
>>
>> I remember advocating for UCS-4 adoption in the HDF5 library many years
>> ago (2007?), but I had no success and UTF-8 was
users (and I think
this is the case), a solution for representing Unicode characters by using
UTF-8 in NumPy would be desirable (at the risk of making the implementation
more complex).
Francesc
>
> ___
> 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
40 matches
Mail list logo
