Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau 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 someon

Re: [Numpy-discussion] Fwd: numpy test fails with "Illegal instruction'

On 17 January 2013 16:59, Gerhard Burger 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 > numpy again, i

Re: [Numpy-discussion] Casting Bug or a "Feature"?

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

Re: [Numpy-discussion] New numpy functions: filled, filled_like

On Jan 17, 2013 8:01 PM, "Olivier Delalleau" wrote: > > 2013/1/17 Matthew Brett : > > Hi, > > > > On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe wrote: > >> > >> On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root wrote: > >>> > >>> > >>> > >>> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing wrote: > >>>

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

2013/1/17 Matthew Brett : > Hi, > > On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal > wrote: >> On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett >> wrote: >> >>> I am starting to wonder if we should aim for making >>> >>> * scalar and array casting rules the same; >>> * Python int / f

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

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 > wrote: > >> I am starting

Re: [Numpy-discussion] Casting Bug or a "Feature"?

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

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

Hi, On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal wrote: > On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett > 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 float6

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

On Thu, Jan 17, 2013 at 5:04 PM, Chris Barker - NOAA Federal wrote: > So in the in the spirit of "practicality beats purity" -- I"d 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 consistency! -Chris --

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett 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. > This has the benefi

Re: [Numpy-discussion] New numpy functions: filled, filled_like

2013/1/17 Matthew Brett : > Hi, > > On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe wrote: >> >> On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root wrote: >>> >>> >>> >>> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing wrote: On 2013/01/17 4:13 AM, Pierre Haessig wrote: > Hi, > >

Re: [Numpy-discussion] New numpy functions: filled, filled_like

Hi, On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe wrote: > > On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root wrote: >> >> >> >> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing wrote: >>> >>> On 2013/01/17 4:13 AM, Pierre Haessig wrote: >>> > Hi, >>> > >>> > Le 14/01/2013 20:05, Benjamin Root a écrit

Re: [Numpy-discussion] New numpy functions: filled, filled_like

On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root wrote: > > > On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing 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

Re: [Numpy-discussion] New numpy functions: filled, filled_like

Hi, On Thu, Jan 17, 2013 at 10:10 PM, Benjamin Root wrote: > > > On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing 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 broadca

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Thu, Jan 17, 2013 at 10:27 AM, Charles R Harris wrote: > > > On Wed, Jan 16, 2013 at 5:11 PM, eat 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 >>

Re: [Numpy-discussion] New numpy functions: filled, filled_like

On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing 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 mean

Re: [Numpy-discussion] New numpy functions: filled, filled_like

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 a

[Numpy-discussion] memory leak in 1.7

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 http://mail.scipy.org/mailman

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

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 l

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On 01/17/2013 05:33 PM, Nathaniel Smith wrote: > On Thu, Jan 17, 2013 at 2:32 PM, Alan G Isaac 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,

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Thu, Jan 17, 2013 at 2:32 PM, Alan G Isaac 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 practice everyone who us

Re: [Numpy-discussion] Casting Bug or a "Feature"?

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

Re: [Numpy-discussion] phase unwrapping (1d)

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_li

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Thu, Jan 17, 2013 at 10:24 AM, wrote: > On Thu, Jan 17, 2013 at 9:49 AM, Benjamin Root wrote: >> >> >> On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy wrote: >>> >>> On 1/16/2013 11:41 PM, Nathaniel Smith wrote: >>> >>> On 16 Jan 2013 17:54, wrote: >>> > >>> a = np.random.random_integers(0, 5,

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Wed, Jan 16, 2013 at 5:11 PM, eat 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 in-place operat

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Thu, Jan 17, 2013 at 9:49 AM, Benjamin Root wrote: > > > On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy wrote: >> >> On 1/16/2013 11:41 PM, Nathaniel Smith wrote: >> >> On 16 Jan 2013 17:54, wrote: >> > >>> a = np.random.random_integers(0, 5, size=5) >> > >>> b = a.sort() >> > >>> b >> > >>> a

Re: [Numpy-discussion] Fwd: numpy test fails with "Illegal instruction'

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 PM

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On Thu, Jan 17, 2013 at 8:54 AM, Jim Vickroy wrote: > On 1/16/2013 11:41 PM, Nathaniel Smith wrote: > > On 16 Jan 2013 17:54, 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) > > >

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

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 i

Re: [Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

Hi, On Wed, Jan 9, 2013 at 6:07 PM, Dag Sverre Seljebotn wrote: > On 01/09/2013 06:22 PM, Chris Barker - NOAA Federal wrote: >> On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith wrote: This is a general issue applying to data which is read from real-world external sources. For example,

Re: [Numpy-discussion] Fwd: numpy test fails with "Illegal instruction'

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 wrote: > On 17 January 2013 12:01, Gerhard Burger wrote: > > Whe

Re: [Numpy-discussion] New numpy functions: filled, filled_like

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 broadcasti

Re: [Numpy-discussion] Fwd: numpy test fails with "Illegal instruction'

On 17 January 2013 12:01, Gerhard Burger 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): > > os.name = '

Re: [Numpy-discussion] New numpy functions: filled, filled_like

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

Re: [Numpy-discussion] Shouldn't all in-place operations simply return self?

On 1/16/2013 11:41 PM, Nathaniel Smith wrote: On 16 Jan 2013 17:54, > 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) > >

Re: [Numpy-discussion] Casting Bug or a "Feature"?

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

Re: [Numpy-discussion] Casting Bug or a "Feature"?

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

[Numpy-discussion] Fwd: numpy test fails with "Illegal instruction'

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 12.