Hi All, Julian has raised the question of including numpy_ufunc in numpy 1.9. I don't feel strongly one way or the other, but it doesn't seem to be finished yet and 1.10 might be a better place to work out the remaining problems along with the astropy folks testing possible uses. Thoughts? Chuck
Perhaps a bit of context might be useful? How is numpy_ufunc different from
the ufuncs that we know and love? What are the known implications? What are
the known shortcomings? Are there ABI and/or API concerns between 1.9 and
1.10?
Ben Root
On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris wrote: Hi All, Julian has raised the question of including numpy_ufunc in numpy 1.9. I
don't feel strongly one way or the other, but it doesn't seem to be
finished yet and 1.10 might be a better place to work out the remaining
problems along with the astropy folks testing possible uses. Thoughts? Chuck _______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Weirdly, I never received Chuck's original email in this thread. Should
some list admin be informed?
I also am not sure what/where Julian's comments were, so I second the call
for context :-). Putting it off until 1.10 doesn't seem like an obviously
bad idea to me, but specifics would help...
(__numpy_ufunc__ is the new system for allowing arbitrary third party
objects to override how ufuncs are applied to them, i.e. it means
np.sin(sparsemat) and np.sin(gpuarray) can be defined to do something
sensible. Conceptually it replaces the old __array_prepare__/__array_wrap__
system, which was limited to ndarray subclasses and has major limits on
what you can do. Of course __array_prepare/wrap__ will also continue to be
supported for compatibility.)
-n
On 16 Jul 2014 00:10, "Benjamin Root"
Perhaps a bit of context might be useful? How is numpy_ufunc different from the ufuncs that we know and love? What are the known implications? What are the known shortcomings? Are there ABI and/or API concerns between 1.9 and 1.10?
Ben Root
On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
Julian has raised the question of including numpy_ufunc in numpy 1.9. I don't feel strongly one way or the other, but it doesn't seem to be finished yet and 1.10 might be a better place to work out the remaining problems along with the astropy folks testing possible uses.
Thoughts?
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mi, 2014-07-16 at 09:07 +0100, Nathaniel Smith wrote:
Weirdly, I never received Chuck's original email in this thread. Should some list admin be informed?
I send some mails yesterday and they never arrived... Not sure if it is a problem on my side or not.
I also am not sure what/where Julian's comments were, so I second the call for context :-). Putting it off until 1.10 doesn't seem like an obviously bad idea to me, but specifics would help...
(__numpy_ufunc__ is the new system for allowing arbitrary third party objects to override how ufuncs are applied to them, i.e. it means np.sin(sparsemat) and np.sin(gpuarray) can be defined to do something sensible. Conceptually it replaces the old __array_prepare__/__array_wrap__ system, which was limited to ndarray subclasses and has major limits on what you can do. Of course __array_prepare/wrap__ will also continue to be supported for compatibility.)
-n
On 16 Jul 2014 00:10, "Benjamin Root"
wrote: Perhaps a bit of context might be useful? How is numpy_ufunc different from the ufuncs that we know and love? What are the known implications? What are the known shortcomings? Are there ABI and/or API concerns between 1.9 and 1.10? Ben Root
On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris
wrote: Hi All, Julian has raised the question of including numpy_ufunc in numpy 1.9. I don't feel strongly one way or the other, but it doesn't seem to be finished yet and 1.10 might be a better place to work out the remaining problems along with the astropy folks testing possible uses.
Thoughts?
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Jul 16, 2014 at 10:07 AM, Nathaniel Smith
Weirdly, I never received Chuck's original email in this thread. Should some list admin be informed?
Also weirdly, my reply didn't show up on gmane. Not sure if it got through, so re-sending: It's already in, so do you mean not using? Would help to know what the issue is, because it's finished enough that it's already used in a released version of scipy (in sparse matrices). Ralf I also am not sure what/where Julian's comments were, so I second the call
for context :-). Putting it off until 1.10 doesn't seem like an obviously bad idea to me, but specifics would help...
(__numpy_ufunc__ is the new system for allowing arbitrary third party objects to override how ufuncs are applied to them, i.e. it means np.sin(sparsemat) and np.sin(gpuarray) can be defined to do something sensible. Conceptually it replaces the old __array_prepare__/__array_wrap__ system, which was limited to ndarray subclasses and has major limits on what you can do. Of course __array_prepare/wrap__ will also continue to be supported for compatibility.)
-n
On 16 Jul 2014 00:10, "Benjamin Root"
wrote: Perhaps a bit of context might be useful? How is numpy_ufunc different from the ufuncs that we know and love? What are the known implications? What are the known shortcomings? Are there ABI and/or API concerns between 1.9 and 1.10?
Ben Root
On Mon, Jul 14, 2014 at 2:22 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
Julian has raised the question of including numpy_ufunc in numpy 1.9. I don't feel strongly one way or the other, but it doesn't seem to be finished yet and 1.10 might be a better place to work out the remaining problems along with the astropy folks testing possible uses.
Thoughts?
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Jul 16, 2014 at 12:53 PM, Ralf Gommers
On Wed, Jul 16, 2014 at 10:07 AM, Nathaniel Smith
wrote: Weirdly, I never received Chuck's original email in this thread. Should some list admin be informed?
Also weirdly, my reply didn't show up on gmane. Not sure if it got through, so re-sending:
It's already in, so do you mean not using? Would help to know what the issue is, because it's finished enough that it's already used in a released version of scipy (in sparse matrices).
My own feeling is that we should leave it in as it is fairly useable and just needs to have some problematic case worked out. The fact that scipy already uses it is a strong argument to keep it in. I think Julian's concern is that they won't be worked out. Julian has started another thread on the topic and that is probably where the conversation should continue. <snip> Chuck
On Mon, Jul 14, 2014 at 8:22 PM, Charles R Harris wrote: Hi All, Julian has raised the question of including numpy_ufunc in numpy 1.9. I
don't feel strongly one way or the other, but it doesn't seem to be
finished yet and 1.10 might be a better place to work out the remaining
problems along with the astropy folks testing possible uses. Thoughts? It's already in, so do you mean not using? Would help to know what the
issue is, because it's finished enough that it's already used in a released
version of scipy (in sparse matrices).
Ralf
participants (5)
-
Benjamin Root
-
Charles R Harris
-
Nathaniel Smith
-
Ralf Gommers
-
Sebastian Berg