I see this as a regression. We don't keep regressions around for backwards
compatibility, we fix them.
Ben
On Thu, Oct 16, 2014 at 10:25 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Thu, Oct 16, 2014 at 6:38 PM, Benjamin Root ben.r...@ou.edu wrote:
That isn't what I meant.
On 17 Oct 2014 02:38, Benjamin Root ben.r...@ou.edu wrote:
That isn't what I meant. Higher order doesn't necessarily mean more
accurate. The results simply have different properties. The user needs to
choose the differentiation order that they need. One interesting effect in
data
On Tue, Oct 14, 2014 at 10:33 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Oct 14, 2014 at 11:50 AM, Nathaniel Smith n...@pobox.com wrote:
On 14 Oct 2014 18:29, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith
On Thu, Oct 16, 2014 at 10:22 AM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Oct 14, 2014 at 10:33 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Oct 14, 2014 at 11:50 AM, Nathaniel Smith n...@pobox.com wrote:
On 14 Oct 2014 18:29, Charles R Harris
It isn't really a question of accuracy. It breaks unit tests and
reproducibility elsewhere. My vote is to revert to the old behavior in
1.9.1.
Ben Root
On Thu, Oct 16, 2014 at 6:10 PM, Ariel Rokem aro...@gmail.com wrote:
On Thu, Oct 16, 2014 at 10:22 AM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Oct 17, 2014 at 2:23 AM, Benjamin Root ben.r...@ou.edu wrote:
It isn't really a question of accuracy. It breaks unit tests and
reproducibility elsewhere. My vote is to revert to the old behavior in
1.9.1.
Why would one want the 2nd order differences at all, if they're not
more
That isn't what I meant. Higher order doesn't necessarily mean more
accurate. The results simply have different properties. The user needs to
choose the differentiation order that they need. One interesting effect in
data assimilation/modeling is that even-order differentiation can often
have
Hi,
On Thu, Oct 16, 2014 at 6:38 PM, Benjamin Root ben.r...@ou.edu wrote:
That isn't what I meant. Higher order doesn't necessarily mean more
accurate. The results simply have different properties. The user needs to
choose the differentiation order that they need. One interesting effect in
On Thu, Oct 16, 2014 at 8:25 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Thu, Oct 16, 2014 at 6:38 PM, Benjamin Root ben.r...@ou.edu wrote:
That isn't what I meant. Higher order doesn't necessarily mean more
accurate. The results simply have different properties. The user needs
On Sat, Oct 4, 2014 at 3:16 PM, Stéfan van der Walt ste...@sun.ac.za
wrote:
On Oct 4, 2014 10:14 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
+1 for an order=2 or maxorder=2 flag
If you parameterize that flag, users will want to change its value (above
two). Perhaps
On 4 Oct 2014 22:17, Stéfan van der Walt ste...@sun.ac.za wrote:
On Oct 4, 2014 10:14 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
+1 for an order=2 or maxorder=2 flag
If you parameterize that flag, users will want to change its value (above
two). Perhaps rather use a
On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith n...@pobox.com wrote:
On 4 Oct 2014 22:17, Stéfan van der Walt ste...@sun.ac.za wrote:
On Oct 4, 2014 10:14 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
+1 for an order=2 or maxorder=2 flag
If you parameterize
On 14 Oct 2014 18:29, Charles R Harris charlesr.har...@gmail.com wrote:
On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith n...@pobox.com wrote:
On 4 Oct 2014 22:17, Stéfan van der Walt ste...@sun.ac.za wrote:
On Oct 4, 2014 10:14 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de
On Tue, Oct 14, 2014 at 11:50 AM, Nathaniel Smith n...@pobox.com wrote:
On 14 Oct 2014 18:29, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith n...@pobox.com wrote:
On 4 Oct 2014 22:17, Stéfan van der Walt ste...@sun.ac.za wrote:
Hi everyone,
import numpy as np
np.__version__
'1.9.0'
np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float))
[array([[ 2., 2., -1.],
[ 2., 2., -1.]]), array([[-0.5, 2.5, 5.5],
[ 1. , 1. , 1. ]])]
On the other hand:
import numpy as np
np.__version__
On 4 Oct 2014, at 08:37 pm, Ariel Rokem aro...@gmail.com wrote:
import numpy as np
np.__version__
'1.9.0'
np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float))
[array([[ 2., 2., -1.],
[ 2., 2., -1.]]), array([[-0.5, 2.5, 5.5],
[ 1. , 1. , 1. ]])]
On the
On Sat, Oct 4, 2014 at 12:29 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
On 4 Oct 2014, at 08:37 pm, Ariel Rokem aro...@gmail.com wrote:
import numpy as np
np.__version__
'1.9.0'
np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float))
[array([[ 2., 2.,
Hi Ariel,
I think that the docstring in 1.9 is fine (has the 1.9 result). The docs
online (for all of numpy) are still on version 1.8, though.
I think that enabling the old behavior might be useful, if only so that I can
write code that behaves consistently across these two versions of
On Oct 4, 2014 10:14 PM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
+1 for an order=2 or maxorder=2 flag
If you parameterize that flag, users will want to change its value (above
two). Perhaps rather use a boolean flag such as second_order or
high_order, unless it seems feasible
19 matches
Mail list logo
