Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
> On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau
> >
> wrote:
> > 2013/1/16 >:
> >> On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
> >> > wrote:
>
> >> I could live with an exception for lossy down casting in this case.
>
>
Am 17.01.2013 17:21, schrieb Chris Barker - NOAA Federal:
> On Wed, Jan 16, 2013 at 11:34 PM, Matthieu Brucher
>
>> Of course a += b is not the same as a = a + b. The first one modifies the
>> object a, the second one creates a new object and puts it inside a. The
>> behavior IS consistent.
>
> E
On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau wrote:
> 2013/1/16 :
>> On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
>> wrote:
>> I could live with an exception for lossy down casting in this case.
I'm not sure what the idea here is -- would you only get an exception
if the value was suc
2013/1/16 :
> On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
> wrote:
>> Thanks, everyone for chiming in. Now that I know this behavior exists, I
>> can explicitly prevent it in my code. However, it would be nice if a warning
>> or something was generated to alert users about the inconsistency
On Wed, Jan 16, 2013 at 11:34 PM, Matthieu Brucher
> Of course a += b is not the same as a = a + b. The first one modifies the
> object a, the second one creates a new object and puts it inside a. The
> behavior IS consistent.
Exactly -- if you ask me, the bug is that Python allows "in_place"
ope
On 01/17/2013 01:27 PM, josef.p...@gmail.com wrote:
> On Thu, Jan 17, 2013 at 2:34 AM, Matthieu Brucher
> wrote:
>> Hi,
>>
>> Actually, this behavior is already present in other languages, so I'm -1 on
>> additional verbosity.
>> Of course a += b is not the same as a = a + b. The first one modifie
On Thu, Jan 17, 2013 at 2:34 AM, Matthieu Brucher
wrote:
> Hi,
>
> Actually, this behavior is already present in other languages, so I'm -1 on
> additional verbosity.
> Of course a += b is not the same as a = a + b. The first one modifies the
> object a, the second one creates a new object and put
Hi,
Actually, this behavior is already present in other languages, so I'm -1 on
additional verbosity.
Of course a += b is not the same as a = a + b. The first one modifies the
object a, the second one creates a new object and puts it inside a. The
behavior IS consistent.
Cheers,
Matthieu
2013/
On 17.01.2013 04:43, Patrick Marsh wrote:
> Thanks, everyone for chiming in. Now that I know this behavior
> exists, I can explicitly prevent it in my code. However, it would be
> nice if a warning or something was generated to alert users about the
> inconsistency between var += ... and var =
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
wrote:
> Thanks, everyone for chiming in. Now that I know this behavior exists, I
> can explicitly prevent it in my code. However, it would be nice if a warning
> or something was generated to alert users about the inconsistency between
> var += ...
Thanks, everyone for chiming in. Now that I know this behavior exists, I
can explicitly prevent it in my code. However, it would be nice if a
warning or something was generated to alert users about the inconsistency
between var += ... and var = var + ...
Patrick
---
Patrick Marsh
Ph.D. Candida
This is separate from the scalar casting thing. This is a disguised version
of the discussion about what we should do with implicit casts caused by
assignment:
into_array[i] = 0.5
Traditionally numpy just happily casts this stuff, possibly mangling data
in the process, and this has caused many a
Patrick,
Not a bug but is it a mis-feature?
See the recent thread: "Do we want scalar casting to behave as it does
at the moment"
In short, this is an complex issue with no easy answer...
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R
Hi Patrick:
I think it is the behavior I have come to expect. The only "gotcha" here
might be the difference between "var = var + 0.5" and "var += 0.5"
For example:
>>> import numpy as np
>>> x = np.arange(5); x += 0.5; x
array([0, 1, 2, 3, 4])
>>> x = np.arange(5); x = x + 0.5; x
array([ 0.5
Greetings,
I spent a couple hours today tracking down a bug in one of my programs. I
was getting different answers depending on whether I passed in a numpy
array or a single number. Ultimately, I tracked it down to something I
would consider a bug, but I'm not sure if others do. The case comes fro
Thanks Robert,
I thought it was something like that but couldn't figure it out.
C.
On May 26, 2009, at 4:50 PM, Robert Kern wrote:
> 2009/5/26 Charles سمير Doutriaux :
>> Hi there,
>>
>> One of our users just found a bug in numpy that has to do with
>> casting.
>>
>> Consider the attached exam
2009/5/26 Charles سمير Doutriaux :
> Hi there,
>
> One of our users just found a bug in numpy that has to do with casting.
>
> Consider the attached example.
>
> The difference at the end should be 0 (zero) everywhere.
>
> But it's not by default.
>
> Casting the data to 'float64' at reading and a
Hi there,
One of our users just found a bug in numpy that has to do with casting.
Consider the attached example.
The difference at the end should be 0 (zero) everywhere.
But it's not by default.
Casting the data to 'float64' at reading and assiging to the arrays
works
Defining the arrays
18 matches
Mail list logo
