On Mon, Mar 17, 2014 at 1:18 PM, wrote:
>
>
>
> On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky wrote:
>
>>
>> On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith wrote:
>>
>>> In practice all
>>> well-behaved classes have to make sure that they implement __special__
>>> methods in such a w
On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky wrote:
>
> On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith wrote:
>
>> In practice all
>> well-behaved classes have to make sure that they implement __special__
>> methods in such a way that all the different variations work, no
>> matter w
On Sun, Mar 16, 2014 at 10:54 AM, Nathaniel Smith wrote:
> On Sun, Mar 16, 2014 at 2:39 PM, Eelco Hoogendoorn
> wrote:
> > Note that I am not opposed to extra operators in python, and only mildly
> > opposed to a matrix multiplication operator in numpy; but let me lay out
> the
> > case against,
On Sat, Mar 15, 2014 at 11:30 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
>
> On Sat, Mar 15, 2014 at 7:20 PM, wrote:
>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
>>
>>> Hi all,
>>>
>>> Here's the main blocker for adding a matrix multiply operator '@' t
On Sat, Mar 15, 2014 at 8:47 PM, Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
> On Sat, Mar 15, 2014 at 8:38 PM, wrote:
>
>> I think I wouldn't use anything like @@ often enough to remember it's
>> meaning. I'd rather see english names for anything that is not **very**
>> common.
>>
>>
On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
> Hi all,
>
> Here's the main blocker for adding a matrix multiply operator '@' to
> Python: we need to decide what we think its precedence and associativity
> should be. I'll explain what that means so we're on the same page, and what
> th
I think I wouldn't use anything like @@ often enough to remember it's
meaning. I'd rather see english names for anything that is not **very**
common.
I find A@@-1 pretty ugly compared to inv(A)
A@@(-0.5) might be nice (do we have matrix_sqrt ?)
Josef
On Sat, Mar 15, 2014 at 5:11 PM, Stephan
On Fri, Mar 7, 2014 at 12:06 AM, wrote:
> On Thu, Mar 6, 2014 at 2:51 PM, Nathaniel Smith wrote:
>> On Wed, Mar 5, 2014 at 4:45 PM, Sebastian Berg
>> wrote:
>>>
>>> Hi all,
>>>
>>> in Pull Request https://github.com/numpy/numpy/pull/3864 Neol Dawe
>>> suggested adding new parameters to our `cov
On Thu, Mar 6, 2014 at 2:51 PM, Nathaniel Smith wrote:
> On Wed, Mar 5, 2014 at 4:45 PM, Sebastian Berg
> wrote:
>>
>> Hi all,
>>
>> in Pull Request https://github.com/numpy/numpy/pull/3864 Neol Dawe
>> suggested adding new parameters to our `cov` and `corrcoef` functions to
>> implement weights,
On Thu, Mar 6, 2014 at 8:38 PM, Sturla Molden wrote:
> Sebastian Berg wrote:
>
>> I am right now a bit unsure about whether or not the "weights" would be
>> "aweights" or different... R seems to not care about the scale of the
>> weights which seems a bit odd to me for an unbiased estimator? I al
On Thu, Mar 6, 2014 at 3:49 PM, Ralf Gommers wrote:
>
>
>
> On Thu, Mar 6, 2014 at 1:40 PM, Sebastian Berg
> wrote:
>>
>> On Mi, 2014-03-05 at 10:21 -0800, David Goldsmith wrote:
>> >
>> >
>> >
>> > Date: Wed, 05 Mar 2014 17:45:47 +0100
>> > From: Sebastian Berg
>> > Subject: [Nu
On Sat, Feb 22, 2014 at 5:17 PM, Matthew Brett wrote:
> Hi,
>
> On Sat, Feb 22, 2014 at 2:03 PM, Nathaniel Smith wrote:
>> Hi all,
>>
>> Currently numpy's 'dot' acts a bit weird for ndim>2 or ndim<1. In
>> practice this doesn't usually matter much, because these are very
>> rarely used. But, I wo
On Tue, Feb 18, 2014 at 9:42 AM, Robert Kern wrote:
> On Tue, Feb 18, 2014 at 2:37 PM, wrote:
>> On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern wrote:
>>> On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote:
On 18 Feb 2014 07:07, "Robert Kern" wrote:
>
> On Tue, Feb 18, 2014 at
On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern wrote:
> On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote:
>> On 18 Feb 2014 07:07, "Robert Kern" wrote:
>>>
>>> On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote:
>>> > Perhaps integer power should raise an error on negative powers? That
On Mon, Feb 17, 2014 at 4:57 PM, wrote:
> On Mon, Feb 17, 2014 at 4:39 PM, Stefan Otte wrote:
>> Hey guys,
>>
>> I wrote myself a little helper function `mdot` which chains np.dot for
>> multiple arrays. So I can write
>>
>> mdot(A, B, C, D, E)
>>
>> instead of these
>>
>> A.dot(B).dot(C
On Mon, Feb 17, 2014 at 4:39 PM, Stefan Otte wrote:
> Hey guys,
>
> I wrote myself a little helper function `mdot` which chains np.dot for
> multiple arrays. So I can write
>
> mdot(A, B, C, D, E)
>
> instead of these
>
> A.dot(B).dot(C).dot(D).dot(E)
> np.dot(np.dot(np.dot(np.dot(A, B
On Mon, Feb 17, 2014 at 10:03 AM, alex wrote:
> On Mon, Feb 17, 2014 at 4:49 AM, Dave Hirschfeld wrote:
>> alex ncsu.edu> writes:
>>
>>>
>>> Hello list,
>>>
>>> Here's another idea resurrection from numpy github comments that I've
>>> been advised could be posted here for re-discussion.
>>>
>>>
On Mon, Feb 17, 2014 at 9:18 AM, Francesc Alted wrote:
> On 2/17/14, 1:08 AM, josef.p...@gmail.com wrote:
>> On Sun, Feb 16, 2014 at 6:12 PM, Daπid wrote:
>>> On 16 February 2014 23:43, wrote:
What's the fastest argsort for a 1d array with around 28 Million
elements, roughly uniformly
On Sun, Feb 16, 2014 at 7:13 PM, Charles R Harris
wrote:
>
>
>
> On Sun, Feb 16, 2014 at 4:18 PM, wrote:
>>
>> On Sun, Feb 16, 2014 at 6:15 PM, wrote:
>> > On Sun, Feb 16, 2014 at 5:50 PM, Eelco Hoogendoorn
>> > wrote:
>> >>
>> >> My guess;
>> >>
>> >> First of all, you are actually manipulati
On Sun, Feb 16, 2014 at 6:12 PM, Daπid wrote:
> On 16 February 2014 23:43, wrote:
>>
>> What's the fastest argsort for a 1d array with around 28 Million
>> elements, roughly uniformly distributed, random order?
>
>
> On numpy latest version:
>
> for kind in ['quicksort', 'mergesort', 'heapsort']:
On Sun, Feb 16, 2014 at 6:15 PM, wrote:
> On Sun, Feb 16, 2014 at 5:50 PM, Eelco Hoogendoorn
> wrote:
>>
>> My guess;
>>
>> First of all, you are actually manipulating twice as much data as opposed to
>> an inplace sort.
>>
>> Moreover, an inplace sort gains locality as it is being sorted, where
On Sun, Feb 16, 2014 at 5:50 PM, Eelco Hoogendoorn
wrote:
>
> My guess;
>
> First of all, you are actually manipulating twice as much data as opposed to
> an inplace sort.
>
> Moreover, an inplace sort gains locality as it is being sorted, whereas the
> argsort is continuously making completely ra
currently using numpy 1.6.1
What's the fastest argsort for a 1d array with around 28 Million
elements, roughly uniformly distributed, random order?
Is there a reason that np.argsort is almost 3 times slower than np.sort?
I'm doing semi-systematic timing for a stats(models) algorithm.
Josef
On Sat, Feb 15, 2014 at 5:18 PM, alex wrote:
> On Sat, Feb 15, 2014 at 5:08 PM, wrote:
>> On Sat, Feb 15, 2014 at 4:56 PM, Sebastian Berg
>> wrote:
>>> On Sa, 2014-02-15 at 16:37 -0500, alex wrote:
Hello list,
Here's another idea resurrection from numpy github comments that I've
On Sat, Feb 15, 2014 at 5:12 PM, Skipper Seabold wrote:
> On Sat, Feb 15, 2014 at 5:08 PM, wrote:
>>
>> On Sat, Feb 15, 2014 at 4:56 PM, Sebastian Berg
>> wrote:
>> > On Sa, 2014-02-15 at 16:37 -0500, alex wrote:
>> >> Hello list,
>> >>
>> >> Here's another idea resurrection from numpy github co
On Sat, Feb 15, 2014 at 4:56 PM, Sebastian Berg
wrote:
> On Sa, 2014-02-15 at 16:37 -0500, alex wrote:
>> Hello list,
>>
>> Here's another idea resurrection from numpy github comments that I've
>> been advised could be posted here for re-discussion.
>>
>> The proposal would be to make np.linalg.sv
On Thu, Feb 13, 2014 at 2:44 PM, Pauli Virtanen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 13.02.2014 20:59, josef.p...@gmail.com kirjoitti:
> [clip]
>> I assume numpy/scipy will participate under the PSF umbrella. So
>> this deadline is for the PSF. However, Terri, the organizer
On Thu, Feb 13, 2014 at 1:27 PM, Jennifer stone wrote:
>
>
>
> On Thu, Feb 13, 2014 at 10:18 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Thought I'd forward this to the lists in case we need to do something.
>>
>> Hi everyone,
>>>
>>> Just a friendly reminder that applications
On Tue, Feb 11, 2014 at 12:14 PM, Chris Barker wrote:
> On Tue, Feb 11, 2014 at 8:25 AM, Matthew Brett wrote:
>
>> > Anyway, I would say that there is a clear use for the matrix class:
>> readability of linear algebra code and hence a lower chance of errors, so
>> higher productivity.
>>
>> Yes, b
On Tue, Feb 11, 2014 at 11:25 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Feb 11, 2014 at 4:16 AM, Jacco Hoekstra - LR
> wrote:
> > For our students, the matrix class is really appealing as we use a lot
> of linear algebra and expressions with matrices simply look better with an
> operator instead
On Mon, Feb 10, 2014 at 6:39 PM, wrote:
>
>
> On Mon, Feb 10, 2014 at 6:29 PM, Pauli Virtanen wrote:
>
>> 11.02.2014 00:31, Alan G Isaac kirjoitti:
>> > On 2/10/2014 5:11 PM, Pauli Virtanen wrote:
>> >> The existence of np.matrix messes up the general agreement on ndarray
>> >> semantics in Pyth
On Mon, Feb 10, 2014 at 6:29 PM, Pauli Virtanen wrote:
> 11.02.2014 00:31, Alan G Isaac kirjoitti:
> > On 2/10/2014 5:11 PM, Pauli Virtanen wrote:
> >> The existence of np.matrix messes up the general agreement on ndarray
> >> semantics in Python. The meaning of very basic code such as
> >>
> >>
On Mon, Feb 10, 2014 at 3:39 PM, wrote:
>
>
> On Mon, Feb 10, 2014 at 3:04 PM, Matthew Brett wrote:
>
>> Hi,
>>
>> On Mon, Feb 10, 2014 at 7:09 AM, Alan G Isaac
>> wrote:
>> [snip]
>> > Just to forestall the usual "just start them with arrays, eventually
>> they'll
>> > be grateful" reply, I wou
On Mon, Feb 10, 2014 at 3:45 PM, alex wrote:
> On Mon, Feb 10, 2014 at 2:36 PM, Matthew Brett
> wrote:
> > Hi,
> >
> > On Mon, Feb 10, 2014 at 6:26 AM, Nathaniel Smith wrote:
> >> On Sun, Feb 9, 2014 at 4:59 PM, alex wrote:
> >>> Hello list,
> >>>
> >>> I wrote this mini-nep for numpy but I've
On Mon, Feb 10, 2014 at 3:04 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Feb 10, 2014 at 7:09 AM, Alan G Isaac
> wrote:
> [snip]
> > Just to forestall the usual "just start them with arrays, eventually
> they'll
> > be grateful" reply, I would want to hear that suggestion only from
> someone
> > w
On Mon, Feb 10, 2014 at 2:49 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Feb 10, 2014 at 11:44 AM, wrote:
> >
> >
> > On Mon, Feb 10, 2014 at 2:12 PM, eat wrote:
> >>
> >>
> >>
> >>
> >> On Mon, Feb 10, 2014 at 9:08 PM, alex wrote:
> >>>
> >>> On Mon, Feb 10, 2014 at 2:03 PM, eat wrote:
> >>>
On Mon, Feb 10, 2014 at 10:09 AM, Alan G Isaac wrote:
> On 2/9/2014 5:55 PM, alex wrote:
> > I'm working on the same kinds of problems in scipy development
> > (functions involving sparse matrices and abstract linear operators)
>
>
> And how is numpy's matrix object getting in your way?
> Your in
On Mon, Feb 10, 2014 at 2:12 PM, eat wrote:
>
>
>
> On Mon, Feb 10, 2014 at 9:08 PM, alex wrote:
>
>> On Mon, Feb 10, 2014 at 2:03 PM, eat wrote:
>> > Rhetorical or not, but FWIW I'll prefer to take singular value
>> decomposition
>> > (u, s, vt= svd(x)) and then based on the singular values s
On Mon, Feb 10, 2014 at 10:09 AM, Alan G Isaac wrote:
> On 2/9/2014 5:55 PM, alex wrote:
> > I'm working on the same kinds of problems in scipy development
> > (functions involving sparse matrices and abstract linear operators)
>
>
> And how is numpy's matrix object getting in your way?
> Your in
On Fri, Jan 24, 2014 at 5:43 PM, Chris Barker wrote:
> Oscar,
>
> Cool stuff, thanks!
>
> I'm wondering though what the use-case really is. The P3 text model
> (actually the py2 one, too), is quite clear that you want users to think of,
> and work with, text as text -- and not care how things are
On Fri, Jan 24, 2014 at 11:30 AM, Emanuele Olivetti
wrote:
> Hi,
>
> I just came across this unexpected behaviour when creating
> a np.array() from two other np.arrays of different shape.
> Have a look at this example:
>
> import numpy as np
> a = np.zeros(3)
> b = np.zeros((2,3))
> c = np.ze
On Thu, Jan 23, 2014 at 4:51 PM, Chris Barker wrote:
> On Thu, Jan 23, 2014 at 12:10 PM, wrote:
>>
>> > Exactly -- but what should those conversion/casting rules be? We can't
>> > decide that unless we decide if 'S' is for text or for arbitrary bytes
>> > -- it
>> > can't be both. I say text, tha
On Thu, Jan 23, 2014 at 1:36 PM, Oscar Benjamin
wrote:
> On 23 January 2014 17:42, wrote:
>> On Thu, Jan 23, 2014 at 12:13 PM, wrote:
>>> On Thu, Jan 23, 2014 at 11:58 AM, wrote:
No, a view doesn't change the memory, it just changes the
interpretation and there shouldn't be an
On Thu, Jan 23, 2014 at 2:45 PM, Chris Barker wrote:
> On Thu, Jan 23, 2014 at 11:18 AM, wrote:
>
>>
>> I think this is just inconsistent casting rules in numpy,
>>
>> numpy should either refuse to assign the wrong type, instead of using
>> the repr as in some of the earlier examples of Oscar
>>
>> > numpy arrays need a decode and encode method
>
>
>> I'm not sure that they do. Rather there needs to be a text dtype that
>> knows what encoding to use in order to have a binary interface as
>> exposed by .tostring() and friends and but produce unicode strings
>> when indexed from Python code.
On Thu, Jan 23, 2014 at 1:49 PM, Chris Barker wrote:
>
> s = 'a string'
> np.array((s,), dtype='S')[0] == s
>
> Gives you False, rather than True on py2. This is because a py3 string is
> translated to the 'S' type (presumable with the default encoding, another
> maybe not a good idea, but return
truncating null bytes in 'S' breaks decoding that needs them
>>> a = np.array([si.encode('utf-16LE') for si in ['Õsc', 'zxc']], dtype='S')
>>> a
array([b'\xd5\x00s\x00c', b'z\x00x\x00c'],
dtype='|S6')
>>> [ai.decode('utf-16LE') for ai in a]
Traceback (most recent call last):
File "", line
On Thu, Jan 23, 2014 at 12:13 PM, wrote:
> On Thu, Jan 23, 2014 at 11:58 AM, wrote:
>> On Thu, Jan 23, 2014 at 11:43 AM, Oscar Benjamin
>> wrote:
>>> On Thu, Jan 23, 2014 at 11:23:09AM -0500, josef.p...@gmail.com wrote:
another curious example, encode utf-8 to latin-1 bytes
On Thu, Jan 23, 2014 at 11:58 AM, wrote:
> On Thu, Jan 23, 2014 at 11:43 AM, Oscar Benjamin
> wrote:
>> On Thu, Jan 23, 2014 at 11:23:09AM -0500, josef.p...@gmail.com wrote:
>>>
>>> another curious example, encode utf-8 to latin-1 bytes
>>>
>>> >>> b
>>> array(['Õsc', 'zxc'],
>>> dtype='>>
On Thu, Jan 23, 2014 at 11:43 AM, Oscar Benjamin
wrote:
> On Thu, Jan 23, 2014 at 11:23:09AM -0500, josef.p...@gmail.com wrote:
>>
>> another curious example, encode utf-8 to latin-1 bytes
>>
>> >>> b
>> array(['Õsc', 'zxc'],
>> dtype='> >>> b[0].encode('utf8')
>> b'\xc3\x95sc'
>> >>> b[0].e
On Thu, Jan 23, 2014 at 10:41 AM, wrote:
> On Thu, Jan 23, 2014 at 5:45 AM, Oscar Benjamin
> wrote:
>> On Wed, Jan 22, 2014 at 05:53:26PM -0800, Chris Barker - NOAA Federal wrote:
>>> On Jan 22, 2014, at 1:13 PM, Oscar Benjamin
>>> wrote:
>>>
>>> >
>>> > It's not safe to stop removing the null
On Thu, Jan 23, 2014 at 5:45 AM, Oscar Benjamin
wrote:
> On Wed, Jan 22, 2014 at 05:53:26PM -0800, Chris Barker - NOAA Federal wrote:
>> On Jan 22, 2014, at 1:13 PM, Oscar Benjamin
>> wrote:
>>
>> >
>> > It's not safe to stop removing the null bytes. This is how numpy determines
>> > the length
On Thu, Jan 23, 2014 at 5:45 AM, Oscar Benjamin
wrote:
> On Wed, Jan 22, 2014 at 05:53:26PM -0800, Chris Barker - NOAA Federal wrote:
>> On Jan 22, 2014, at 1:13 PM, Oscar Benjamin
>> wrote:
>>
>> >
>> > It's not safe to stop removing the null bytes. This is how numpy determines
>> > the length
On Mon, Jan 20, 2014 at 12:12 PM, Aldcroft, Thomas
wrote:
>
>
>
> On Mon, Jan 20, 2014 at 10:40 AM, Oscar Benjamin
> wrote:
>>
>> On Mon, Jan 20, 2014 at 10:00:55AM -0500, Aldcroft, Thomas wrote:
>> > On Mon, Jan 20, 2014 at 5:11 AM, Oscar Benjamin
>> > wrote:
>> > > How significant are the perfo
It looks like both recfromtxt and loadtxt are flexible enough to
handle string/bytes en/decoding, - with a bit of work and using enough
information
>>> dtype=[('f0', '>> data = numpy.recfromtxt(open('Õscar_3.txt',"rb"), dtype=dtype,
>>> delimiter=',',converters={3:lambda x: x.decode('utf8')})
>>>
On Fri, Jan 17, 2014 at 4:20 PM, Chris Barker wrote:
> On Fri, Jan 17, 2014 at 12:36 PM, wrote:
>>
>> > ('S' ?) -- which is probably not what you want particularly if you
>> > specify
>> > an encoding. Though I can't figure out at the moment why the previous
>> > one
>> > failed -- where did the
On Fri, Jan 17, 2014 at 3:17 PM, Chris Barker wrote:
> >>> numpy.recfromtxt(open('Õscar_3.txt',"r", encoding='utf8'),
> delimiter=',')
>>
>> Traceback (most recent call last):
>> File "", line 1, in
>> numpy.recfromtxt(open('Õscar_3.txt',"r", encoding='utf8'),
>> delimiter=',')
>> File "
On Fri, Jan 17, 2014 at 2:18 PM, Julian Taylor
wrote:
> On 17.01.2014 15:12, Julian Taylor wrote:
>> On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
>> mailto:oscar.j.benja...@gmail.com>> wrote:
>>
>> On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
>> > On Fri, Jan 17, 2014
On Fri, Jan 17, 2014 at 10:26 AM, Oscar Benjamin
wrote:
> On Fri, Jan 17, 2014 at 03:12:32PM +0100, Julian Taylor wrote:
>> On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
>> wrote:
>>
>> > On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
>> > >
>> > > no, the right solution is to ad
On Fri, Jan 17, 2014 at 8:40 AM, Oscar Benjamin
wrote:
> On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
>> On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
>> wrote:
>>
>> > On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen wrote:
>> > > Julian Taylor googlemail.com> writes:
On Fri, Jan 17, 2014 at 5:59 AM, Pauli Virtanen wrote:
> Julian Taylor googlemail.com> writes:
> [clip]
>> - inconvenience in dealing with strings in python 3.
>>
>> bytes are not strings in python3 which means ascii data is either a byte
>> array which can be inconvenient to deal with or 4 byte
On Fri, Dec 6, 2013 at 11:25 PM, Charles R Harris
wrote:
>
>
>
> On Fri, Dec 6, 2013 at 2:14 PM, wrote:
>>
>> On Fri, Dec 6, 2013 at 3:50 PM, Sebastian Berg
>> wrote:
>> > On Fri, 2013-12-06 at 15:30 -0500, josef.p...@gmail.com wrote:
>> >> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith wrote:
On Fri, Dec 6, 2013 at 5:45 PM, Nathaniel Smith wrote:
> Not sure how much time it's worth spending on coming up with new
> definitions for boolean subtraction, since even if we deprecate the
> current behavior now we won't be able to implement any of them for a
> year+, and then we'll end up havi
On Fri, Dec 6, 2013 at 4:14 PM, wrote:
> On Fri, Dec 6, 2013 at 3:50 PM, Sebastian Berg
> wrote:
>> On Fri, 2013-12-06 at 15:30 -0500, josef.p...@gmail.com wrote:
>>> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith wrote:
>>> > On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky
>>> > wrote
On Fri, Dec 6, 2013 at 3:50 PM, Sebastian Berg
wrote:
> On Fri, 2013-12-06 at 15:30 -0500, josef.p...@gmail.com wrote:
>> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith wrote:
>> > On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Dec 6, 2013 at
On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith wrote:
> On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky wrote:
>>
>>
>>
>> On Fri, Dec 6, 2013 at 1:46 PM, Alan G Isaac wrote:
>>>
>>> On 12/6/2013 1:35 PM, josef.p...@gmail.com wrote:
>>> > unary versus binary minus
>>>
>>> Oh right; I cons
On Fri, Dec 6, 2013 at 1:46 PM, Alan G Isaac wrote:
> On 12/6/2013 1:35 PM, josef.p...@gmail.com wrote:
>> unary versus binary minus
>
> Oh right; I consider binary `-` broken for
> Boolean arrays. (Sorry Alexander; I did not
> see your entire issue.)
>
>
>> I'd rather write ~ than unary - if that
On Fri, Dec 6, 2013 at 1:16 PM, Alan G Isaac wrote:
> On 12/6/2013 12:23 PM, Alexander Belopolsky wrote:
>> What is the rationale for this:
>>
>> >>> -array(True) + array(True)
>> True
>
>
> The minus is complementation.
> So you are just writing
> False or True
unary versus binary minus
On Fri, Dec 6, 2013 at 12:23 PM, Alexander Belopolsky wrote:
> On Fri, Dec 6, 2013 at 11:13 AM, Alan G Isaac wrote:
>
>> On 12/5/2013 11:14 PM, Alexander Belopolsky wrote:
>> > did you find minus to be as useful?
>>
>>
>> It is also a correct usage.
>>
>
> Can you provide a reference?
>
>
>>
>> I
On Fri, Dec 6, 2013 at 11:13 AM, Alan G Isaac wrote:
> On 12/5/2013 11:14 PM, Alexander Belopolsky wrote:
>> did you find minus to be as useful?
>
>
> It is also a correct usage.
>
> I think a good approach to this is to first realize that
> there were good reasons for the current behavior.
What'
On Fri, Dec 6, 2013 at 9:32 AM, wrote:
> On Fri, Dec 6, 2013 at 4:39 AM, Sebastian Berg
> wrote:
>> On Thu, 2013-12-05 at 23:02 -0500, josef.p...@gmail.com wrote:
>>> On Thu, Dec 5, 2013 at 10:56 PM, Alexander Belopolsky
>>> wrote:
>>> > On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
>>> >
>
On Fri, Dec 6, 2013 at 4:39 AM, Sebastian Berg
wrote:
> On Thu, 2013-12-05 at 23:02 -0500, josef.p...@gmail.com wrote:
>> On Thu, Dec 5, 2013 at 10:56 PM, Alexander Belopolsky
>> wrote:
>> > On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
>> > wrote:
>> >> there was a discussion that for numpy b
On Thu, Dec 5, 2013 at 11:00 PM, Alexander Belopolsky wrote:
>
> On Thu, Dec 5, 2013 at 10:35 PM, wrote:
>>
>> what about np.dot,np.dot(mask, x) which is the same as (mask *
>> x).sum(0) ?
>
>
> I am not sure which way your argument goes, but I don't think you would find
> the following natur
On Thu, Dec 5, 2013 at 10:56 PM, Alexander Belopolsky wrote:
> On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
> wrote:
>> there was a discussion that for numpy booleans math operators +,-,* (and
>> the unary -), while defined, are not very helpful.
>
> It has been suggested at the Github that the
On Thu, Dec 5, 2013 at 10:33 PM, wrote:
> On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
> wrote:
>> Hey,
>>
>> there was a discussion that for numpy booleans math operators +,-,* (and
>> the unary -), while defined, are not very helpful. I have set up a quick
>> PR with start (needs some fixes
On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
wrote:
> Hey,
>
> there was a discussion that for numpy booleans math operators +,-,* (and
> the unary -), while defined, are not very helpful. I have set up a quick
> PR with start (needs some fixes inside numpy still):
>
> https://github.com/numpy/n
np.diff has keyword for `n-th order discrete difference`
but cumsum has different arguments and cannot integrate n times
What's the best "inverse function" for np.diff with n>1?
I briefly tried polynomial, but without success so far.
need two starting values to integrate for n=2
>>> a = np.rand
On Wed, Nov 27, 2013 at 7:01 AM, Sudheer Joseph
wrote:
> Hi,
>I have a numpy array which is masked ( bathymetry), as seen
> below
>
> [ True]
> [ True]
> [ True]
> [ True]],
>fill_value = -.0)
>
>
> In [10]: depth[:,1130:1131]
>
> I need to find the indices where l
On Sun, Oct 27, 2013 at 4:22 PM, wrote:
> On Sun, Oct 27, 2013 at 3:22 PM, Freddie Witherden
> wrote:
>> On 27/10/13 18:54, Daniele Nicolodi wrote:
>>> On 27/10/2013 19:42, Freddie Witherden wrote:
On 27/10/13 18:35, Nathaniel Smith wrote:
> On Sun, Oct 27, 2013 at 6:28 PM, Freddie With
On Sun, Oct 27, 2013 at 3:22 PM, Freddie Witherden
wrote:
> On 27/10/13 18:54, Daniele Nicolodi wrote:
>> On 27/10/2013 19:42, Freddie Witherden wrote:
>>> On 27/10/13 18:35, Nathaniel Smith wrote:
On Sun, Oct 27, 2013 at 6:28 PM, Freddie Witherden
wrote:
> Hi all,
>
> This
My first stop is always pypi to find the link to binaries.
https://pypi.python.org/pypi/scipy
however the direct download link points to 0.11
Josef
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
On Wed, Oct 2, 2013 at 2:49 PM, wrote:
> On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote:
>> On 2 Oct 2013 19:14, "Benjamin Root" wrote:
>>>
>>> And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a)
>>> (ignoring the silly detail that you can't do an equality on nans)
On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote:
> On 2 Oct 2013 19:14, "Benjamin Root" wrote:
>>
>> And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a)
>> (ignoring the silly detail that you can't do an equality on nans).
>
> Why do you call this a silly detail? It s
On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt wrote:
> On 2 Oct 2013 18:04, "Charles R Harris" wrote:
>>
>> The question is what to do when all-nan slices are encountered in the
>> nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first
>> returns nan and raises a warnin
On Tue, Oct 1, 2013 at 4:13 PM, Nathaniel Smith wrote:
> On 1 Oct 2013 17:34, "Charles R Harris" wrote:
>>
>>
>>
>>
>> On Tue, Oct 1, 2013 at 10:19 AM, wrote:
>>>
>>> On Tue, Oct 1, 2013 at 10:47 AM, Nathaniel Smith wrote:
>>> > On Tue, Oct 1, 2013 at 3:20 PM, Charles R Harris
>>> > wrote:
>>>
On Tue, Oct 1, 2013 at 10:47 AM, Nathaniel Smith wrote:
> On Tue, Oct 1, 2013 at 3:20 PM, Charles R Harris
> wrote:
>>
>>
>>
>> On Tue, Oct 1, 2013 at 8:12 AM, Nathaniel Smith wrote:
>>>
>>> [switching subject to break out from the giant 1.8.0rc1 thread]
>>>
>>> On Tue, Oct 1, 2013 at 2:52 PM, C
On Mon, Sep 30, 2013 at 9:38 PM, Charles R Harris
wrote:
>
>
>
> On Mon, Sep 30, 2013 at 7:05 PM, Ondřej Čertík
> wrote:
>>
>> Hi,
>>
>> What is the rationale for using False in 'mask' for elements that
>> should be included?
>>
>> http://docs.scipy.org/doc/numpy/reference/maskedarray.generic.htm
On Thu, Sep 26, 2013 at 6:42 PM, Nathaniel Smith wrote:
> On 26 Sep 2013 21:59, "Faraz Mirzaei" wrote:
>>
>> Thanks Josef and Nathaniel for your responses.
>>
>> In the application that I have, I don't use the correlation coefficient
>> matrix as a whole (so I don't care if it is PSD or not). I s
On Thu, Sep 26, 2013 at 7:35 AM, Nathaniel Smith wrote:
> On Thu, Sep 26, 2013 at 11:51 AM, wrote:
>> On Thu, Sep 26, 2013 at 4:21 AM, Nathaniel Smith wrote:
>>> If you want a proper self-consistent correlation/covariance matrix, then
>>> pairwise deletion just makes no sense period, I don't se
On Thu, Sep 26, 2013 at 6:51 AM, wrote:
> On Thu, Sep 26, 2013 at 4:21 AM, Nathaniel Smith wrote:
>> If you want a proper self-consistent correlation/covariance matrix, then
>> pairwise deletion just makes no sense period, I don't see how postprocessing
>> can help.
>
> clipping to [-1, 1] and f
On Thu, Sep 26, 2013 at 4:21 AM, Nathaniel Smith wrote:
> If you want a proper self-consistent correlation/covariance matrix, then
> pairwise deletion just makes no sense period, I don't see how postprocessing
> can help.
clipping to [-1, 1] and finding the nearest positive semi-definite matrix.
On Wed, Sep 25, 2013 at 11:05 PM, wrote:
> On Wed, Sep 25, 2013 at 8:26 PM, Faraz Mirzaei wrote:
>> Hi everyone,
>>
>> I'm using np.ma.corrcoef to compute the correlation coefficients among rows
>> of a masked matrix, where the masked elements are the missing data. I've
>> observed that in some
On Wed, Sep 25, 2013 at 8:26 PM, Faraz Mirzaei wrote:
> Hi everyone,
>
> I'm using np.ma.corrcoef to compute the correlation coefficients among rows
> of a masked matrix, where the masked elements are the missing data. I've
> observed that in some cases, the np.ma.corrcoef gives invalid coefficien
On Mon, Sep 23, 2013 at 1:40 PM, Jeremy Hetzel wrote:
> On Sun, Sep 22, 2013 at 9:47 AM, Mark Szepieniec wrote:
>>
>>
>> On Sun, Sep 22, 2013 at 1:24 PM, wrote:
>>>
>>>
>>> I don't see a reason that numpy.random shouldn't get new
>>> distributions. It would also be useful to add the correspondin
On Mon, Sep 23, 2013 at 8:22 PM, David Cournapeau wrote:
> Ok, so I've looked a bit into it tonight:
>
> - used mingw-w64 4.8.1 (32 bits host)
> - openblas binaries available on the official website (seem to be built
> with mingw w64)
> - used -static-libgcc, -static-libstdc++ and -static-libgf
On Sat, Sep 21, 2013 at 1:55 PM, Jeremy Hetzel wrote:
> I've added a trapezoidal distribution to numpy.random for consideration,
> pull request 3770:
> https://github.com/numpy/numpy/pull/3770
>
> Similar to the triangular distribution, the trapezoidal distribution may be
> used where the underlyi
On Sun, Sep 15, 2013 at 9:04 PM, Charles R Harris
wrote:
> Hi All,
>
> Numpy 1.8 is about ready for an rc1, which brings up the question of which
> binary builds so put up on sourceforge. For Windows maybe
>
> 32 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC
> 64 bit windows, python 2
On Tue, Sep 10, 2013 at 9:59 AM, Andreas Hilboll wrote:
> On 10.09.2013 15:52, David Reed wrote:
>> Hi there,
>>
>> Is there a faster way to perform a 2D Histogram from a 2D matrix than
>> what I have below:
>>
>> def spatial_histogram(frame, n_bins):
>> shape = frame.shape
>>
>> h_len = shape[0]/
On Mon, Sep 9, 2013 at 11:35 AM, Nathaniel Smith wrote:
> On 9 Sep 2013 15:50, wrote:
>>
>> On Mon, Sep 9, 2013 at 9:52 AM, Nathaniel Smith wrote:
>> > One list has 6 entries and one has 7, so they can't be aligned into a
>> > single
>> > array. Possibly it would be better to raise an error here
On Mon, Sep 9, 2013 at 9:52 AM, Nathaniel Smith wrote:
> One list has 6 entries and one has 7, so they can't be aligned into a single
> array. Possibly it would be better to raise an error here instead of
> returning an object array, but that's what's going on.
It did at some point (and I relied
101 - 200 of 1288 matches
Mail list logo
