Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau
sh...@keba.bejavascript:;
wrote:
2013/1/16 josef.p...@gmail.com javascript:;:
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
patrickmars...@gmail.com javascript:;
On Thu, Jan 17, 2013 at 2:34 AM, Matthieu Brucher
matthieu.bruc...@gmail.com 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
On 01/17/2013 01:27 PM, josef.p...@gmail.com wrote:
On Thu, Jan 17, 2013 at 2:34 AM, Matthieu Brucher
matthieu.bruc...@gmail.com 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
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
2013/1/16 josef.p...@gmail.com:
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
patrickmars...@gmail.com 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
On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau sh...@keba.be wrote:
2013/1/16 josef.p...@gmail.com:
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
patrickmars...@gmail.com wrote:
I could live with an exception for lossy down casting in this case.
I'm not sure what the idea here is --
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
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, 1.5, 2.5,
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/ORR
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
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.
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
patrickmars...@gmail.com 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
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 = var
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
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 doutria...@llnl.gov:
Hi there,
One of our users just found a bug in numpy that has to do with
casting.
Consider the
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
2009/5/26 Charles سمير Doutriaux doutria...@llnl.gov:
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
17 matches
Mail list logo