On Fri, Jul 27, 2012 at 6:47 AM, Ralf Gommers
wrote:
>
>
> On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau
> wrote:
>>
>> On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau
>> wrote:
>> > On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant
>> > wrote:
>> >> Hey all,
>> >>
>> >> I'm wondering who
On Fri, Jul 27, 2012 at 4:10 PM, Benjamin Root wrote:
>
>
> On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller > wrote:
>
>> Hi Everybody.
>> The bug is that no error is raised, right?
>> The docs say
>>
>> where(condition, [x, y])
>>
>> x, y : array_like, optional
>> Values from which to cho
On 07/27/2012 09:10 PM, Benjamin Root wrote:
On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller
mailto:amuel...@ais.uni-bonn.de>> wrote:
Hi Everybody.
The bug is that no error is raised, right?
The docs say
where(condition, [x, y])
x, y : array_like, optional
Val
On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller
wrote:
> Hi Everybody.
> The bug is that no error is raised, right?
> The docs say
>
> where(condition, [x, y])
>
> x, y : array_like, optional
> Values from which to choose. `x` and `y` need to have the same
> shape as `condition`
>
> In
Hi Everybody.
The bug is that no error is raised, right?
The docs say
where(condition, [x, y])
x, y : array_like, optional
Values from which to choose. `x` and `y` need to have the same
shape as `condition`
In the example you gave, x was a scalar.
Cheers,
Andy
On 27.07.2012, at 8:30PM, Fernando Perez wrote:
> On Fri, Jul 27, 2012 at 9:43 AM, Derek Homeier
> wrote:
>> thanks, that was exactly what I was looking for - together with
>>
>> c.TerminalIPythonApp.exec_lines = ['import sys',
>> 'import numpy as np',
>>
On Fri, Jul 27, 2012 at 9:43 AM, Derek Homeier
wrote:
> thanks, that was exactly what I was looking for - together with
>
> c.TerminalIPythonApp.exec_lines = ['import sys',
>'import numpy as np',
>'import matplotlib as mpl',
>
On Fri, Jul 27, 2012 at 2:01 PM, Benjamin Root wrote:
>
>
> On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge wrote:
>
>> On a Linux machine:
>>
>> > uname -srvop
>> Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64
>> GNU/Linux
>>
>> this example shows an apparent problem with the
On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge wrote:
> On a Linux machine:
>
> > uname -srvop
> Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64
> GNU/Linux
>
> this example shows an apparent problem with the where function:
>
> Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43)
>
On 27 Jul 2012, at 17:58, Tony Yu wrote:
> On Fri, Jul 27, 2012 at 11:39 AM, Derek Homeier
> wrote:
> On 27.07.2012, at 3:27PM, Benjamin Root wrote:
>
> > > I would prefer not to use: from xxx import *,
> > >
> > > because of the name pollution.
> > >
> > > The name convention that I copied a
On Fri, Jul 27, 2012 at 11:39 AM, Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:
> On 27.07.2012, at 3:27PM, Benjamin Root wrote:
>
> > > I would prefer not to use: from xxx import *,
> > >
> > > because of the name pollution.
> > >
> > > The name convention that I copied above fac
On 27.07.2012, at 3:27PM, Benjamin Root wrote:
> > I would prefer not to use: from xxx import *,
> >
> > because of the name pollution.
> >
> > The name convention that I copied above facilitates avoiding the pollution.
> >
> > In the same spirit, I've used:
> > import pylab as plb
>
> But in t
On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau
> wrote:
> > On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant
> wrote:
> >> Hey all,
> >>
> >> I'm wondering who has tried to make NumPy work with Python 3.3. The
> Unicode handling wa
On Thu, Jul 26, 2012 at 7:12 PM, Robert Kern wrote:
> On Fri, Jul 27, 2012 at 12:05 AM, Colin J. Williams
> wrote:
> > On 26/07/2012 4:57 PM, Benjamin Root wrote:
> >
> >
> > On Thu, Jul 26, 2012 at 4:45 PM, Colin J. Williams wrote:
> >>
> >> It seems that these standards have been adopted, whi
Dear numpy historians,
When multiplying two arrays with numpy.dot, the summation is made over
the last index of the first argument, and over the *second-to-last*
index of the second argument. I wonder why the convention has been
chosen like this?
The only reason I can think of is that this allow
On Fri, Jul 27, 2012 at 5:15 AM, Charles R Harris
wrote:
> I would support accumulating in 64 bits but, IIRC, the function will need to
> be rewritten so that it works by adding 32 bit floats to the accumulator to
> save space. There are also more stable methods that could also be
> investigated.
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
>> Hey all,
>>
>> I'm wondering who has tried to make NumPy work with Python 3.3. The
>> Unicode handling was significantly improved in Python 3.3 and the
>> array-scalar code (w
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau wrote:
> On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
>> Hey all,
>>
>> I'm wondering who has tried to make NumPy work with Python 3.3. The
>> Unicode handling was significantly improved in Python 3.3 and the
>> array-scalar code (w
On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant wrote:
> Hey all,
>
> I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode
> handling was significantly improved in Python 3.3 and the array-scalar code
> (which assumed a certain structure for UnicodeObjects) is not worki
On Thu, 2012-07-26 at 22:15 -0600, Charles R Harris wrote:
> I would support accumulating in 64 bits but, IIRC, the function will
> need to be rewritten so that it works by adding 32 bit floats to the
> accumulator to save space. There are also more stable methods that
> could also be investigated.
20 matches
Mail list logo
