Hi,
Thanks everybody for all the answers that make perfect sense when axis=0.
Now suppose I want to sort the array in such a way that each row is
sorted individually. Then I suppose I should do this:
from numpy import *
v = array([[4,3],
[1,12],
[23,7],
On Wed, Jan 16, 2013 at 9:30 AM, Mads Ipsen madsip...@gmail.com wrote:
Hi,
Thanks everybody for all the answers that make perfect sense when axis=0.
Now suppose I want to sort the array in such a way that each row is sorted
individually. Then I suppose I should do this:
from numpy import *
On 01/14/2013 02:44 PM, Matthew Brett wrote:
On Mon, Jan 14, 2013 at 10:35 AM, Jaakko Luttinen
jaakko.lutti...@aalto.fi wrote:
On 01/14/2013 12:53 AM, Matthew Brett wrote:
You might be able to get away without 2to3, using the kind of stuff
that Pauli has used for scipy recently:
On Thu, Dec 20, 2012 at 6:32 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Dec 20, 2012 at 6:25 PM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Thu, Dec 13, 2012 at 4:39 PM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
Hi,
I found these recent weird failures in
Hi,
go to the site tracis-ci(the the next.travis-ci.org part):
https://next.travis-ci.org/numpy/numpy/jobs/4118113
When you go that way, in a drop-down menu in the screen, when you are
autorized, you can ask travis-ci to rerun the tests. You can do it in
the particular test or in the commit
Any suggestion how to take a 2d complex array and find the set of points that
are unique within some tolerance? (My preferred metric here would be Euclidean
distance)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
14.01.2013 14:44, Matthew Brett kirjoitti:
[clip]
Pierre's suggestion is good; you can also do something like this:
# -*- coding: utf8 -*-
import sys
if sys.version_info[0] = 3:
a = 'öäöäöäöäö'
else:
a = unicode('öäöäöäöäö', 'utf8')
The 'coding' line has to be the
Hi,
In a recent thread
http://article.gmane.org/gmane.comp.python.numeric.general/52772 it was
proposed that .fill(.) should return self as an alternative for a trivial
two-liner.
I'm raising now the question: what if all in-place operations indeed could
return self? How bad this would be? A
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
On Wed, Jan 16, 2013 at 7:11 PM, eat e.antero.ta...@gmail.com wrote:
Hi,
In a recent thread
http://article.gmane.org/gmane.comp.python.numeric.general/52772 it was
proposed that .fill(.) should return self as an alternative for a trivial
two-liner.
I'm raising now the question: what if all
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 16 Jan 2013 17:54, josef.p...@gmail.com wrote:
a = np.random.random_integers(0, 5, size=5)
b = a.sort()
b
a
array([0, 1, 2, 5, 5])
b = np.random.shuffle(a)
b
b = np.random.permutation(a)
b
array([0, 5, 5, 2, 1])
How do I remember if shuffle shuffles or permutes ?
Do we
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
18 matches
Mail list logo
