Charles R Harris wrote:
On Jan 7, 2008 8:47 AM, Ryan May [EMAIL PROTECTED] mailto:[EMAIL
PROTECTED] wrote:
Stuart Brorson wrote:
I realize NumPy != Matlab, but I'd wager that most users would think
that this is the natural behavior..
Well, that behavior won't
For large arrays, it makes since to do automatic
conversions, as is also the case in functions taking output arrays,
because the typecast can be pushed down into C where it is time and
space efficient, whereas explicitly converting the array uses up
temporary space. However, I can imagine an
On 07/01/2008, Charles R Harris [EMAIL PROTECTED] wrote:
One place where Numpy differs from MatLab is the way memory is handled.
MatLab is always generating new arrays, so for efficiency it is worth
preallocating arrays and then filling in the parts. This is not the case in
Numpy where lists
On Jan 7, 2008 12:08 PM, Anne Archibald [EMAIL PROTECTED] wrote:
On 07/01/2008, Charles R Harris [EMAIL PROTECTED] wrote:
One place where Numpy differs from MatLab is the way memory is handled.
MatLab is always generating new arrays, so for efficiency it is worth
preallocating arrays and
I wasn't at all arguing that having complex data chopped and
downcast into an int or float container was the right thing to do.
indeed, it is an clearly bad thing to do -- but a bug magnet? I'm not so
sure, surely, anyone that had any idea at all what they were doing with
complex numbers
There are two related hierarchies of datatypes: different kinds
(integer,
floating point, complex floating point) and different precisions
within a given
kind (int8, int16, int32, int64). The term downcasting should
probably be
reserved for the latter only.
It seems to me that Zach
On Fri, 4 Jan 2008, Stuart Brorson wrote:
I just discovered this today. It looks like a bug to me. Please
flame me mercilessly if I am wrong! :-)
FWIW, here's what Matlab does:
A = rand(1, 4) + rand(1, 4)*i
A =
Columns 1 through 3
0.7833 + 0.7942i 0.6808 + 0.0592i 0.4611 +
I just discovered this today. It looks like a bug to me. Please
flame me mercilessly if I am wrong! :-)
H after a little more playing around, I think it's indeed true
that NumPy does a typecast to make the resulting assignment have the
same type as the LHS, regardless of the type of
On Friday 04 January 2008 16:08:54 Stuart Brorson wrote:
Sometimes you need to initialize an array using zeros() before doing
an assignment to it in a loop. If you assign a complex value to the
initialized array, the imaginary part of the array is dropped. Does
NumPy do a silent type-cast
NumPy gurus --
I just discovered this today. It looks like a bug to me. Please
flame me mercilessly if I am wrong! :-)
Sometimes you need to initialize an array using zeros() before doing
an assignment to it in a loop. If you assign a complex value to the
initialized array, the imaginary
Stuart Brorson wrote:
On Fri, 4 Jan 2008, Stuart Brorson wrote:
I just discovered this today. It looks like a bug to me. Please
flame me mercilessly if I am wrong! :-)
FWIW, here's what Matlab does:
A = rand(1, 4) + rand(1, 4)*i
A =
Columns 1 through 3
0.7833 +
I realize NumPy != Matlab, but I'd wager that most users would think
that this is the natural behavior..
Well, that behavior won't happen. We won't mutate the dtype of the array
because
of assignment. Matlab has copy(-on-write) semantics for things like slices
while
we have view
On Friday 04 January 2008 05:17:56 pm Stuart Brorson wrote:
I realize NumPy != Matlab, but I'd wager that most users would
think that this is the natural behavior..
Well, that behavior won't happen. We won't mutate the dtype of the
array because of assignment. Matlab has
On Fri, Jan 04, 2008 at 03:53:41PM -0700, Charles R Harris wrote:
Matlab support for different types was sort of kludged on. Matlab was
intended for computational convenience, not control of data types, and
started out as pretty much all doubles and double complex, it didn't
On Jan 4, 2008 3:28 PM, Scott Ransom [EMAIL PROTECTED] wrote:
On Friday 04 January 2008 05:17:56 pm Stuart Brorson wrote:
I realize NumPy != Matlab, but I'd wager that most users would
think that this is the natural behavior..
Well, that behavior won't happen. We won't mutate the
Hello all,
That's well and good. But NumPy should *never* automatically -- and
silently -- chop the imaginary part off your complex array elements,
particularly if you are just doing an innocent assignment!
Doing something drastic like silently throwing half your data away can
lead to all
Zachary Pincus wrote:
Hello all,
That's well and good. But NumPy should *never* automatically -- and
silently -- chop the imaginary part off your complex array elements,
particularly if you are just doing an innocent assignment!
Doing something drastic like silently throwing half your data
Scott Ransom wrote:
I wasn't at all arguing that having complex data chopped and
downcast into an int or float container was the right thing to do.
indeed, it is an clearly bad thing to do -- but a bug magnet? I'm not so
sure, surely, anyone that had any idea at all what they were doing with
18 matches
Mail list logo
