Hi Nathaniel,
Thanks for the detailed reply; it helped a lot to understand how one could,
indeed, have dtypes contain units. And if one had not just on-the-fly
conversion from int to float as part of an internal loop, but also
on-the-fly multiplication, then it would even be remarkably fast. Will
>From my perspective, a major advantage to dtypes is composability. For
example, it's hard to write a library like dask.array (out of core arrays)
that can suppose holding any conceivable ndarray subclass (like MaskedArray
or quantity), but handling arbitrary dtypes is quite straightforward -- and
On Sun, Aug 30, 2015 at 9:12 PM, Marten van Kerkwijk
wrote:
> Hi Nathaniel, others,
>
> I read the discussion of plans with interest. One item that struck me is
> that while there are great plans to have a proper extensible and presumably
> subclassable dtype, it is
Hi Nathaniel, others,
I read the discussion of plans with interest. One item that struck me is
that while there are great plans to have a proper extensible and presumably
subclassable dtype, it is discouraged to subclass ndarray itself (rather,
it is encouraged to use a broader array interface).
On Wed, Aug 26, 2015 at 10:06 AM, Travis Oliphant tra...@continuum.io
wrote:
On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith n...@pobox.com wrote:
Hi Travis,
Thanks for taking the time to write up your thoughts!
I have many thoughts in return, but I will try to restrict myself to two
I thought I'd add a little more specifically about the kind of
graphics/point cloud work I'm doing right now at Thinkbox, and how it
relates. To echo Francesc's point about NumPy already being an industry
standard, within the VFX/graphics industry there is a reference platform
definition on Linux,
On Tue, Aug 25, 2015 at 12:21 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 25 Aug 2015 03:03:41 -0700
Nathaniel Smith n...@pobox.com wrote:
Supporting third-party dtypes
~
[...]
Some features that would become straightforward to implement
(e.g.
Hi Travis,
Thanks for taking the time to write up your thoughts!
I have many thoughts in return, but I will try to restrict myself to two
main ones :-).
1) On the question of whether work should be directed towards improving
NumPy-as-it-is or instead towards a compatibility-breaking
On Tue, Aug 25, 2015 at 5:53 PM, David Cournapeau courn...@gmail.com wrote:
Thanks for the good summary Nathaniel.
Regarding dtype machinery, I agree casting is the hardest part. Unless the
code has changed dramatically, this was the main reason why you could not
make most of the dtypes
On Wed, Aug 26, 2015 at 10:11 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Wed, 26 Aug 2015 16:45:51 + (UTC)
Irwin Zaid iz...@continuum.io wrote:
So, we see DyND is having a twofold purpose. The first is to expand upon
the
kinds of data that NumPy can represent and do
On Wed, 26 Aug 2015 16:45:51 + (UTC)
Irwin Zaid iz...@continuum.io wrote:
So, we see DyND is having a twofold purpose. The first is to expand upon the
kinds of data that NumPy can represent and do computations upon. The second
is to provide a standard array package that can cross the
26.08.2015, 14:14, Francesc Alted kirjoitti:
[clip]
2015-08-25 12:03 GMT+02:00 Nathaniel Smith n...@pobox.com:
Let's focus on evolving numpy as far as we can without major
break-the-world changes (no numpy 2.0, at least in the foreseeable
future).
And, as a target for that evolution,
On Wed, Aug 26, 2015 at 6:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
One possible limitation is that the lingua franca for language
interoperability is C, not C++. DyND doesn't have to be written in C,
but exposing a nice C API may help make it attractive to the various
language
Hello everyone,
Mark and I thought it would be good to weigh in here and also be explicitly
around to discuss DyND. To be clear, neither of us has strong feelings on
what NumPy *should* do -- we are both long-time NumPy users and we both see
NumPy being around for a while. But, as Francesc
On Mi, 2015-08-26 at 00:05 -0700, Nathaniel Smith wrote:
On Tue, Aug 25, 2015 at 5:53 PM, David Cournapeau courn...@gmail.com wrote:
Thanks for the good summary Nathaniel.
Regarding dtype machinery, I agree casting is the hardest part. Unless the
code has changed dramatically, this was
Hi,
Thanks Nathaniel and others for sparking this discussion as I think it is
very timely.
2015-08-25 12:03 GMT+02:00 Nathaniel Smith n...@pobox.com:
Let's focus on evolving numpy as far as we can without major
break-the-world changes (no numpy 2.0, at least in the foreseeable
future).
On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith n...@pobox.com wrote:
Hi Travis,
Thanks for taking the time to write up your thoughts!
I have many thoughts in return, but I will try to restrict myself to two
main ones :-).
1) On the question of whether work should be directed towards
On Tue, Aug 25, 2015 at 5:03 AM, Nathaniel Smith n...@pobox.com wrote:
Hi all,
These are the notes from the NumPy dev meeting held July 7, 2015, at
the SciPy conference in Austin, presented here so the list can keep up
with what happens, and so you can give feedback. Please do give
On Tue, Aug 25, 2015 at 4:03 AM, Nathaniel Smith n...@pobox.com wrote:
Hi all,
These are the notes from the NumPy dev meeting held July 7, 2015, at
the SciPy conference in Austin, presented here so the list can keep up
with what happens, and so you can give feedback. Please do give
On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant tra...@continuum.io
wrote:
Thanks for the write-up Nathaniel. There is a lot of great detail and
interesting ideas here.
snip
I think that summarizes
On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant tra...@continuum.io
wrote:
Thanks for the write-up Nathaniel. There is a lot of great detail and
interesting ideas here.
snip
There are at least 3
Thanks for the write-up Nathaniel. There is a lot of great detail and
interesting ideas here.
I've am very eager to understand how to help NumPy and the wider community
move forward however I can (my passions on this have not changed since
1999, though what I myself spend time on has changed).
On Tue, 25 Aug 2015 03:03:41 -0700
Nathaniel Smith n...@pobox.com wrote:
Supporting third-party dtypes
~
[...]
Some features that would become straightforward to implement
(e.g. even in third-party libraries) if this were fixed:
- missing value support
Hi all,
These are the notes from the NumPy dev meeting held July 7, 2015, at
the SciPy conference in Austin, presented here so the list can keep up
with what happens, and so you can give feedback. Please do give
feedback, none of this is final!
(Also, if anyone who was there notices anything I
On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant tra...@continuum.io
wrote:
Thanks for the write-up Nathaniel. There is a lot of great detail and
interesting ideas here.
I've am very eager to understand how to help NumPy and the wider community
move forward however I can (my passions on
Hi Nathaniel,
Thanks for the notes.
In some sense, the new dtype class(es) will provided a way of
formalizing these `weird` metadata, and probably exposing them to
Python.
May I add that please consider adding a way to declare the sorting
order (priority and direction) of fields in a structured
Thanks for the good summary Nathaniel.
Regarding dtype machinery, I agree casting is the hardest part. Unless the
code has changed dramatically, this was the main reason why you could not
make most of the dtypes separate from numpy codebase (I tried to move the
datetime dtype out of multiarray
27 matches
Mail list logo