Dear numpy users,
I am trying to get numpy to work on my computer, but so far no luck.
When I run `numpy.test(verbose=10)` it crashes with
test_polyfit (test_polynomial.TestDocs) ... Illegal instruction
In the FAQ it states that I should provide the following information
(running Ubuntu
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 1/16/2013 11:41 PM, Nathaniel Smith wrote:
On 16 Jan 2013 17:54, josef.p...@gmail.com
mailto: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
Hi,
Le 14/01/2013 20:17, Alan G Isaac a écrit :
a = np.tile(5,(1,2,3))
a
array([[[5, 5, 5],
[5, 5, 5]]])
np.tile(1,a.shape)
array([[[1, 1, 1],
[1, 1, 1]]])
I had not realized a scalar first argument was possible.
I didn't know either ! I discovered this use in the
On 17 January 2013 12:01, Gerhard Burger burger...@gmail.com wrote:
When I run `numpy.test(verbose=10)` it crashes with
test_polyfit (test_polynomial.TestDocs) ... Illegal instruction
In the FAQ it states that I should provide the following information
(running Ubuntu 12.04 64bit):
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms of the broadcasting
semantics, but I wonder if that is a bit awkward. What I mean is, if
one were to use broadcasting semantics for creating an array, wouldn't
one have just simply used broadcasting
I read somewhere that it could have to do with the sse instructions that
your processor is capable of, but my processor is not that old, so I would
think that is not the problem...
On Thu, Jan 17, 2013 at 3:12 PM, Scott Sinclair scott.sinclair...@gmail.com
wrote:
On 17 January 2013 12:01,
Hi,
On Wed, Jan 9, 2013 at 6:07 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 01/09/2013 06:22 PM, Chris Barker - NOAA Federal wrote:
On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith n...@pobox.com wrote:
This is a general issue applying to data which is read from real-world
Is it really better to have `permute` and `permuted`
than to add a keyword? (Note that these are actually
still ambiguous, except by convention.)
Btw, two separate issues seem to be running side by side.
i. should in-place operations return their result?
ii. how can we signal that an operation
On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy jim.vick...@noaa.gov wrote:
On 1/16/2013 11:41 PM, Nathaniel Smith wrote:
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 =
Solved it, did a backtrace with gdb and the error came somewhere from an
old lapack version that was installed on my machine (I thought I wouldn't
have these issues in a virtualenv). but anyway after I removed it, and
installed numpy again, it ran without problems!
On Thu, Jan 17, 2013 at 3:18
On Thu, Jan 17, 2013 at 9:49 AM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy jim.vick...@noaa.gov wrote:
On 1/16/2013 11:41 PM, Nathaniel Smith wrote:
On 16 Jan 2013 17:54, josef.p...@gmail.com wrote:
a = np.random.random_integers(0, 5, size=5)
b
On Wed, Jan 16, 2013 at 5: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
On Thu, Jan 17, 2013 at 10:24 AM, josef.p...@gmail.com wrote:
On Thu, Jan 17, 2013 at 9:49 AM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy jim.vick...@noaa.gov wrote:
On 1/16/2013 11:41 PM, Nathaniel Smith wrote:
On 16 Jan 2013 17:54,
Hi Neal,
Le 14/01/2013 15:39, Neal Becker a écrit :
This code should explain all:
import numpy as np
arg = np.angle
def nint (x):
return int (x + 0.5) if x = 0 else int (x - 0.5)
def unwrap (inp, y=np.pi, init=0, cnt=0):
o = np.empty_like (inp)
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
On Thu, Jan 17, 2013 at 2:32 PM, Alan G Isaac alan.is...@gmail.com wrote:
Is it really better to have `permute` and `permuted`
than to add a keyword? (Note that these are actually
still ambiguous, except by convention.)
The convention in question, though, is that of English grammar. In
On 01/17/2013 05:33 PM, Nathaniel Smith wrote:
On Thu, Jan 17, 2013 at 2:32 PM, Alan G Isaac alan.is...@gmail.com wrote:
Is it really better to have `permute` and `permuted`
than to add a keyword? (Note that these are actually
still ambiguous, except by convention.)
The convention in
On Thu, Jan 17, 2013 at 6:08 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
In addition to the verb tense, I think it's important that mutators are
methods whereas functions do not mutate their arguments:
lst.sort()
sorted(lst)
Unfortunately this isn't really viable in a
I've tracked down and fixed a memory leak in 1.7 and master. The pull
request to check and backport is here:
https://github.com/numpy/numpy/pull/2928
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms of the broadcasting
semantics, but I wonder if that is a bit awkward. What I mean is, if
one were to use broadcasting semantics for creating an array,
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms of the broadcasting
semantics, but I wonder if that is a bit awkward. What I
On Thu, Jan 17, 2013 at 10:27 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Jan 16, 2013 at 5: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
Hi,
On Thu, Jan 17, 2013 at 10:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms of
Hi,
On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013
2013/1/17 Matthew Brett matthew.br...@gmail.com:
Hi,
On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM,
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com wrote:
I am starting to wonder if we should aim for making
* scalar and array casting rules the same;
* Python int / float scalars become int32 / 64 or float64;
aren't they already? I'm not sure what you are proposing.
On Thu, Jan 17, 2013 at 5:04 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
So in the in the spirit of practicality beats purity -- Id like
accidental upcasting to be hard to do.
and then:
arr = arr + scalar
would yield the same type as:
arr += scalar
so we buy some
Hi,
On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
wrote:
I am starting to wonder if we should aim for making
* scalar and array casting rules the same;
* Python int / float
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
I'd like to echo what Chris is saying. It was a big annoyance with Numeric to
make it so hard to preserve the array type in ordinary expressions.
Perry
On Jan 17, 2013, at 8:04 PM, Chris Barker - NOAA Federal wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
2013/1/17 Matthew Brett matthew.br...@gmail.com:
Hi,
On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
wrote:
I am starting to wonder if we should aim for making
* scalar and
On Jan 17, 2013 8:01 PM, Olivier Delalleau sh...@keba.be wrote:
2013/1/17 Matthew Brett matthew.br...@gmail.com:
Hi,
On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013
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 --
On 17 January 2013 16:59, Gerhard Burger burger...@gmail.com wrote:
Solved it, did a backtrace with gdb and the error came somewhere from an old
lapack version that was installed on my machine (I thought I wouldn't have
these issues in a virtualenv). but anyway after I removed it, and installed
On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau sh...@keba.be wrote:
Yes, I do understand that. The difference - as I understand it - is
that back in the day, numeric did not have the the float32 etc
scalars, so you could not do:
another_array = my_array * np.float32(4.0)
(please
38 matches
Mail list logo
