>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
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
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 discouraged to subclass ndarray
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). F
On Wed, Aug 26, 2015 at 10:06 AM, Travis Oliphant
wrote:
>
>
> On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith 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 :-).
>>
>
26.08.2015, 14:14, Francesc Alted kirjoitti:
[clip]
> 2015-08-25 12:03 GMT+02:00 Nathaniel Smith :
>> 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, l
On Wed, Aug 26, 2015 at 10:11 AM, Antoine Pitrou
wrote:
> On Wed, 26 Aug 2015 16:45:51 + (UTC)
> Irwin Zaid 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 t
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 Wed, Aug 26, 2015 at 6:11 PM, Antoine Pitrou 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 runtimes out there.
>
On Wed, 26 Aug 2015 16:45:51 + (UTC)
Irwin Zaid 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 language barrier
>
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 mention
On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith 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 improving
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 :
> 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
On Mi, 2015-08-26 at 00:05 -0700, Nathaniel Smith wrote:
> On Tue, Aug 25, 2015 at 5:53 PM, David Cournapeau 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 rea
On Tue, Aug 25, 2015 at 5:53 PM, David Cournapeau 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 separate from numpy
On Tue, Aug 25, 2015 at 12:21 PM, Antoine Pitrou wrote:
> On Tue, 25 Aug 2015 03:03:41 -0700
> Nathaniel Smith wrote:
>>
>> Supporting third-party dtypes
>> ~
>>
> [...]
>>
>> Some features that would become straightforward to implement
>> (e.g. even in third-party
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 replacement:
On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris wrote:
>
>
> On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant
> wrote:
>
>> Thanks for the write-up Nathaniel. There is a lot of great detail and
>> interesting ideas here.
>>
>>
>>
>
> I think that summarizes my main concerns. I will write-
On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris wrote:
>
>
> On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant
> wrote:
>
>> Thanks for the write-up Nathaniel. There is a lot of great detail and
>> interesting ideas here.
>>
>>
>>
>
> There are at least 3 areas of compatibility (ABI, API, a
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 int
On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant
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 this have not cha
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
On Tue, 25 Aug 2015 03:03:41 -0700
Nathaniel Smith 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
> - p
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, Aug 25, 2015 at 5:03 AM, Nathaniel Smith 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
> feedback, none of
On Tue, Aug 25, 2015 at 4:03 AM, Nathaniel Smith 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
> feedback, none of
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 le
27 matches
Mail list logo