On Tue, Jul 16, 2013 at 3:50 AM, Charles R Harris wrote:
>
>
> On Mon, Jul 15, 2013 at 6:58 PM, Benjamin Root wrote:
>
>> To add a bit of context to the question of nansum on empty results, we
>> currently differ from MATLAB and R in this respect, they return zero no
>> matter what. Personally,
On Mon, Jul 15, 2013 at 6:58 PM, Benjamin Root wrote:
> To add a bit of context to the question of nansum on empty results, we
> currently differ from MATLAB and R in this respect, they return zero no
> matter what. Personally, I think it should return zero, but our current
> behavior of returnin
On 7/15/13, Moroney, Catherine M (398D)
wrote:
> I know that there's an easy way to solve this problem, but I'm not
> sufficiently knowledgeable
> about numpy indexing to figure it out.
>
> Here is the problem:
>
> Take a 2-d array a, of any size.
> Sort it in ascending order using, I presume, arg
I know that there's an easy way to solve this problem, but I'm not sufficiently
knowledgeable
about numpy indexing to figure it out.
Here is the problem:
Take a 2-d array a, of any size.
Sort it in ascending order using, I presume, argsort.
Step through the sorted array in order, and for each el
To add a bit of context to the question of nansum on empty results, we
currently differ from MATLAB and R in this respect, they return zero no
matter what. Personally, I think it should return zero, but our current
behavior of returning nans has existed for a long time.
Personally, I think we need
On Mon, 15 Jul 2013 18:46:33 -0600, Charles R Harris wrote:
> So nansum should return zeros rather than the current NaNs?
Yes, my feeling is that nansum([]) should be 0.
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.s
On Mon, Jul 15, 2013 at 6:22 PM, Stéfan van der Walt wrote:
> On Mon, 15 Jul 2013 08:33:47 -0600, Charles R Harris wrote:
> > On Mon, Jul 15, 2013 at 8:25 AM, Benjamin Root wrote:
> >
> > > This is going to need to be heavily documented with doctests. Also,
> just
> > > to clarify, are we talking
On Mon, 15 Jul 2013 08:33:47 -0600, Charles R Harris wrote:
> On Mon, Jul 15, 2013 at 8:25 AM, Benjamin Root wrote:
>
> > This is going to need to be heavily documented with doctests. Also, just
> > to clarify, are we talking about a ValueError for doing a nansum on an
> > empty array as well, or
On Mon, Jul 15, 2013 at 3:57 PM, wrote:
> On Mon, Jul 15, 2013 at 5:34 PM, Charles R Harris
> wrote:
> >
> >
> > On Mon, Jul 15, 2013 at 2:44 PM, wrote:
> >>
> >> On Mon, Jul 15, 2013 at 4:24 PM, wrote:
> >> > On Mon, Jul 15, 2013 at 2:55 PM, Nathaniel Smith
> wrote:
> >> >> On Mon, Jul 15,
On Mon, Jul 15, 2013 at 5:34 PM, Charles R Harris
wrote:
>
>
> On Mon, Jul 15, 2013 at 2:44 PM, wrote:
>>
>> On Mon, Jul 15, 2013 at 4:24 PM, wrote:
>> > On Mon, Jul 15, 2013 at 2:55 PM, Nathaniel Smith wrote:
>> >> On Mon, Jul 15, 2013 at 6:29 PM, Charles R Harris
>> >> wrote:
>> >>> Let me
On Mon, Jul 15, 2013 at 2:44 PM, wrote:
> On Mon, Jul 15, 2013 at 4:24 PM, wrote:
> > On Mon, Jul 15, 2013 at 2:55 PM, Nathaniel Smith wrote:
> >> On Mon, Jul 15, 2013 at 6:29 PM, Charles R Harris
> >> wrote:
> >>> Let me try to summarize. To begin with, the environment of the nan
> functions
On Mon, Jul 15, 2013 at 4:24 PM, wrote:
> On Mon, Jul 15, 2013 at 2:55 PM, Nathaniel Smith wrote:
>> On Mon, Jul 15, 2013 at 6:29 PM, Charles R Harris
>> wrote:
>>> Let me try to summarize. To begin with, the environment of the nan functions
>>> is rather special.
>>>
>>> 1) if the array is of
On Mon, Jul 15, 2013 at 2:55 PM, Nathaniel Smith wrote:
> On Mon, Jul 15, 2013 at 6:29 PM, Charles R Harris
> wrote:
>> Let me try to summarize. To begin with, the environment of the nan functions
>> is rather special.
>>
>> 1) if the array is of not of inexact type, they punt to the non-nan
>> v
On Mon, Jul 15, 2013 at 6:29 PM, Charles R Harris
wrote:
> Let me try to summarize. To begin with, the environment of the nan functions
> is rather special.
>
> 1) if the array is of not of inexact type, they punt to the non-nan
> versions.
> 2) if the array is of inexact type, then out and dtype
On Mon, Jul 15, 2013 at 9:55 AM, Sebastian Berg
wrote:
> On Mon, 2013-07-15 at 08:47 -0600, Charles R Harris wrote:
> >
> >
> > On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg
> > wrote:
> > On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
> > >
> > >
> >
> Ouch…
> Quick workaround: use `x.harden_mask()` *then* `x.mask.flags.writeable=False`
Thanks for the update and the detailed explanation. I'll try this trick.
> This may change in the future, depending on a yet-to-be-achieved consensus on
> the definition of 'least-surprising behaviour'. Rig
Dear Brady
On Fri, 12 Jul 2013 22:00:08 -0500, Brady McCary wrote:
>
> I want to load images with PIL and then operate on them with NumPy.
> According to the PIL and NumPy documentation, I would expect the
> following to work, but it is not.
Reading images as PIL is a little bit trickier than one
On Mon, 2013-07-15 at 17:12 +0200, bruno Piguet wrote:
>
>
>
> 2013/7/15 Frédéric Bastien
> Just a question, should == behave like a ufunc or like python
> == for tuple?
>
>
>
> That's what I was also wondering.
I am not sure I understand the question. Of course == s
On Mon, 2013-07-15 at 08:47 -0600, Charles R Harris wrote:
>
>
> On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg
> wrote:
> On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
> >
> >
> > On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris
> > wrote:
On Jul 15, 2013 11:47 AM, "Charles R Harris"
wrote:
>
>
> On Mon, Jul 15, 2013 at 8:58 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg <
>> sebast...@sipsolutions.net> wrote:
>>
>>> On Mon, 2013-07-15 at 07:52 -0600, Charles R
On Mon, Jul 15, 2013 at 8:58 AM, Charles R Harris wrote:
>
>
> On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
>
>> On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
>> >
>> >
>> > On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris
>> > wrote:
>> >
On Jul 15, 2013, at 14:40 , Gregorio Bastardo
wrote:
> Hi Pierre,
>
>> Note as well that hardening the mask only prevents unmasking: you can still
>> grow the mask, which may not be what you want. Use
>> `x.mask.flags.writeable=False` to make the mask really read-only.
>
> I ran into an unm
2013/7/15 Frédéric Bastien
> Just a question, should == behave like a ufunc or like python == for tuple?
>
That's what I was also wondering.
I see the advantage of consistency for newcomers.
I'm not experienced enough to see if this is a problem for numerical
practitionners Maybe they wouldn't
On Jul 12, 2013, at 8:51 PM, Brady McCary wrote:
>
> something to do with an alpha channel being present.
I'd check and see how PIL is storing the alpha channel. If it's RGBA,
then I'd expect it to work.
But I'd PIL is storing the alpha channel as a separate band, then I'm
not surprised you hav
Thank-you for your explanations.
So, if the operator "==" applied to np.arrays is a shorthand for the
ufunc np.equal, it should definitly behave exactly as np.equal(), and raise
an error.
One side question about style : In case you would like to protect a "x ==
y" test by a try/except clause, w
On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg
wrote:
> On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
> >
> >
> > On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris
> > wrote:
> >
>
>
>
> >
> > For nansum, I would expect 0 even in the case of all
> >
Just a question, should == behave like a ufunc or like python == for tuple?
I think that all ndarray comparision (==, !=, <=, ...) should behave the
same. If they don't (like it was said), making them consistent is good.
What is the minimal change to have them behave the same? From my
understandin
On Mon, Jul 15, 2013 at 8:34 AM, Sebastian Berg
wrote:
> On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
> >
> >
> > On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris
> > wrote:
> >
>
>
>
> >
> > For nansum, I would expect 0 even in the case of all
> >
On Mon, Jul 15, 2013 at 8:25 AM, Benjamin Root wrote:
> This is going to need to be heavily documented with doctests. Also, just
> to clarify, are we talking about a ValueError for doing a nansum on an
> empty array as well, or will that now return a zero?
>
>
I was going to leave nansum as is, a
On Mon, 2013-07-15 at 07:52 -0600, Charles R Harris wrote:
>
>
> On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris
> wrote:
>
>
> For nansum, I would expect 0 even in the case of all
> nans. The point
> of these functi
This is going to need to be heavily documented with doctests. Also, just to
clarify, are we talking about a ValueError for doing a nansum on an empty
array as well, or will that now return a zero?
Ben Root
On Mon, Jul 15, 2013 at 9:52 AM, Charles R Harris wrote:
>
>
> On Sun, Jul 14, 2013 at 3
On Mon, 2013-07-15 at 15:09 +0200, bruno Piguet wrote:
> Python itself doesn't raise an exception in such cases :
>
> >>> (3,4) != (2, 3, 4)
> True
> >>> (3,4) == (2, 3, 4)
> False
>
> Should numpy behave differently ?
>
Yes, because Python tests whether the tuple is different, not whether
the
On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet wrote:
> Python itself doesn't raise an exception in such cases :
>
(3,4) != (2, 3, 4)
> True
(3,4) == (2, 3, 4)
> False
>
> Should numpy behave differently ?
The numpy equivalent to Python's scalar "==" is called array_equal,
and that does
On Sun, Jul 14, 2013 at 3:35 PM, Charles R Harris wrote:
>
>
> On Sun, Jul 14, 2013 at 2:55 PM, Warren Weckesser <
> warren.weckes...@gmail.com> wrote:
>
>> On 7/14/13, Charles R Harris wrote:
>> > Some corner cases in the mean, var, std.
>> >
>> > *Empty arrays*
>> >
>> > I think these cases sh
Hi,
On Mon, Jun 10, 2013 at 3:47 PM, Nathaniel Smith wrote:
> Hi all,
>
> Is there anyone out there using numpy masked arrays, who has an
> opinion on how empty_like (and its friends ones_like, zeros_like)
> should handle the mask?
>
> Right now apparently if you call np.ma.empty_like on a masked
Python itself doesn't raise an exception in such cases :
>>> (3,4) != (2, 3, 4)
True
>>> (3,4) == (2, 3, 4)
False
Should numpy behave differently ?
Bruno.
2013/7/12 Frédéric Bastien
> I also don't like that idea, but I'm not able to come to a good reasoning
> like Benjamin.
>
> I don't see
Hi Pierre,
> Note as well that hardening the mask only prevents unmasking: you can still
> grow the mask, which may not be what you want. Use
> `x.mask.flags.writeable=False` to make the mask really read-only.
I ran into an unmasking problem with the suggested approach:
>>> np.version.version
On Jul 15, 2013, at 10:04 , Gregorio Bastardo
wrote:
> Hi Pierre,
>
>> I'm a bit surprised, though. Here's what I tried
>>
> np.version.version
>> <<< 1.7.0
> x = np.ma.array([1,2,3], mask=[0,1,0])
> x.flags.writeable=False
> x[0]=-1
>> <<< ValueError: assignment destination i
Hi Pierre,
> I'm a bit surprised, though. Here's what I tried
>
np.version.version
> <<< 1.7.0
x = np.ma.array([1,2,3], mask=[0,1,0])
x.flags.writeable=False
x[0]=-1
> <<< ValueError: assignment destination is read-only
Thanks, it works perfectly =) Sorry, probably have overlo
39 matches
Mail list logo
