Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-09-03 Thread Marten van Kerkwijk
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-09-03 Thread Stephan Hoyer
>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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-09-01 Thread Nathaniel Smith
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-30 Thread Marten van Kerkwijk
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).

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-27 Thread josef.pktd
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Mark Wiebe
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,

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Nathaniel Smith
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.

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Nathaniel Smith
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Nathaniel Smith
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Mark Wiebe
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Antoine Pitrou
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Pauli Virtanen
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,

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Irwin Zaid
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Irwin Zaid
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Sebastian Berg
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Francesc Alted
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).

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-26 Thread Travis Oliphant
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Nathan Goldbaum
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Charles R Harris
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Travis Oliphant
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Travis Oliphant
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Travis Oliphant
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).

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Antoine Pitrou
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

[Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Nathaniel Smith
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Charles R Harris
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread Feng Yu
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

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

2015-08-25 Thread David Cournapeau
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