Re: [Numpy-discussion] GPU Numpy

[Olivier Grisel]

2009/8/6 David Cournapeau :
> Olivier Grisel wrote:
>> OpenCL is definitely the way to go for a cross platform solution with
>> both nvidia and AMD having released beta runtimes to their respective
>> developer networks (free as in beer subscription required for the beta
>> dowload pages). Final public releases to be expected around 2009 Q3.
>>
>
> What's the status of opencl on windows ? Will MS have its own direct-x
> specific implementation ?

As usual, MS reinvents the wheel with DirectX Compute but vendors such
as AMD and nvidia propose both the OpenCL API +runtime binaries for
windows and their DirectX Compute counterpart, based on mostly the
same underlying implementation, e.g. CUDA in nvidia's case.

-- 
Olivier
http://twitter.com/ogrisel - http://code.oliviergrisel.name
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[David Cournapeau]

Olivier Grisel wrote:
> OpenCL is definitely the way to go for a cross platform solution with
> both nvidia and AMD having released beta runtimes to their respective
> developer networks (free as in beer subscription required for the beta
> dowload pages). Final public releases to be expected around 2009 Q3.
>   

What's the status of opencl on windows ? Will MS have its own direct-x
specific implementation ?

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[Olivier Grisel]

OpenCL is definitely the way to go for a cross platform solution with
both nvidia and AMD having released beta runtimes to their respective
developer networks (free as in beer subscription required for the beta
dowload pages). Final public releases to be expected around 2009 Q3.

OpenCL is an open royalty free standardized API and runtime
specification for heterogeneous  with a mix of CPU and GPU cores. The
nvidia implementation is based on the CUDA runtime and programming
OpenCL is very similar to programming in C for CUDA.

The developer of PyCUDA is also working on PyOpenCL

  http://pypi.python.org/pypi/pyopencl/

Both nvidia and AMD use llvm to compile the OpenCL cross-platform
kernel sources into device specific binaries loaded at runtime.

Official OpenCL specs:

 http://www.khronos.org/registry/cl/specs/opencl-1.0.29.pdf

Wikipedia page:

  http://en.wikipedia.org/wiki/OpenCL

nvidia runtime:

  http://www.nvidia.com/object/cuda_opencl.html

AMD runtime: only working with x86 and x86_64 with SSE3 for now:

  http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx

Intel and IBM were also a members of the standard comity so we can
reasonably expect runtime for there chips in the future (e.g. larabee
and Cell BE).

-- 
Olivier
http://twitter.com/ogrisel - http://code.oliviergrisel.name
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Wiki page: food options at the SciPy'09 conference

[Fernando Perez]

Hi all,

this is a message mostly for those attending the conference who know
Caltech and its surroundings well.

We've created a page to list easy-to-access food options from the
campus, but I don't really know what to put there.  Anyone who has
some knowledge of local options is welcome to add to this wiki page,
and will earn the gratitude of all attendees:

http://conference.scipy.org/food

Thanks!

Cheers,

f
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[David Warde-Farley]

A friend of mine wrote a simple wrapper around CUBLAS using ctypes  
that basically exposes a Python class that keeps a 2D array of single- 
precision floats on the GPU for you, and lets you I keep telling him  
to release it, but he thinks it's too hackish.

It did inspire some of our colleagues in Montreal to create this,  
though:

http://code.google.com/p/cuda-ndarray/

I gather it is VERY early in development, but I'm sure they'd love  
contributions!

David

On 5-Aug-09, at 6:45 AM, Romain Brette wrote:

> Hi everyone,
>
> I was wondering if you had any plan to incorporate some GPU support  
> to numpy, or
> perhaps as a separate module. What I have in mind is something that  
> would mimick
> the syntax of numpy arrays, with a new dtype (gpufloat), like this:
>
> from gpunumpy import *
> x=zeros(100,dtype='gpufloat') # Creates an array of 100 elements on  
> the GPU
> y=ones(100,dtype='gpufloat')
> z=exp(2*x+y) # z in on the GPU, all operations on GPU with no transfer
> z_cpu=array(z,dtype='float') # z is copied to the CPU
> i=(z>2.3).nonzero()[0] # operation on GPU, returns a CPU integer array


> There is a library named GPULib (http://www.txcorp.com/products/GPULib/ 
> ) that
> does similar things, but unfortunately they don't support Python (I  
> think their
> main Python developer left).
> I think this would be very useful for many people. For our project  
> (a neural
> network simulator, http://www.briansimulator.org) we use PyCuda
> (http://mathema.tician.de/software/pycuda)

Neat project, though at first I was sure that was a typo :) "He can't  
be simulating Brians"

- David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[Trevor Clarke]

With OpenCL implementations making their way into the wild, that's probably
a better target than CUDA.

On Wed, Aug 5, 2009 at 3:39 PM, Ian Mallett  wrote:

> On Wed, Aug 5, 2009 at 11:34 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> It could be you could slip in a small mod that would do what you want.
>
> I'll help, if you want.  I'm good with GPUs, and I'd appreciate the
> numerical power it would afford.
>
>> The main problems with using GPUs were that CUDA was only available for
>> nvidia video cards and there didn't seem to be any hope for a CUDA version
>> of LAPACK.
>
> You don't have to use CUDA, although it would make it easier.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] improved NumPy support for boolean arrays?

[Robert Kern]

On Wed, Aug 5, 2009 at 16:02, Sturla Molden wrote:
>
>>  If x and y are numpy
>> arrays of bools, I'd like to be able to create expressions like the
>> following:
>>
>> not x (to invert each element of x)
>> x and y
>> x or y
>> x xor y
>> (not x) or y
>>
>> The usual array broadcasting rules should apply.  Is there any chance of
>> getting something like this into NumPy?
> There is a reason for this related to Python. In Python an object will
> often have a boolean truth value. How would you cast an ndarray to bool?
> If you write something like (x and y) the Python interpreter expects
> this to evaluate to True or False. Thus is cannot evaluate to an ndarray
> with booleans. NumPy cannot change the syntax of Python.
>
> Another thing: An empty list evaluates to False in a boolean context,
> whereas a non-empty list evaluates to True. ndarrays behave differently.
> Why?

Numeric used to evaluate bool(some_array) as True if any of the
elements were nonzero and False if all of them were zero. This
confused some people who expected that bool(some_array) to be True iff
*all* of the elements were nonzero and False otherwise. People had
bugs in their code for years without realizing it. They would try one
example, get their expected result, and not test the other corner
cases that would demonstrate that their mental model of what was going
on was incorrect.

By the time that numarray was being designed, the numarray team
decided to make array always raise an exception instead of returning
any truth value. numpy followed this decision.

There really aren't many use cases for following the list object's
semantics with arrays. Empty arrays aren't nearly as common as empty
lists or even tuples. I know of no case where it is useful to test
specifically for emptiness versus non-emptiness. In any case, directly
checking the .size or .shape attributes would be sufficient and far
more clear because there are other plausible interpretations of
bool(some_array) like Numeric's.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] improved NumPy support for boolean arrays?

[Sturla Molden]

>  If x and y are numpy
> arrays of bools, I'd like to be able to create expressions like the
> following:
>
> not x (to invert each element of x)
> x and y
> x or y
> x xor y
> (not x) or y
>
> The usual array broadcasting rules should apply.  Is there any chance of
> getting something like this into NumPy?
There is a reason for this related to Python. In Python an object will 
often have a boolean truth value. How would you cast an ndarray to bool? 
If you write something like (x and y) the Python interpreter expects 
this to evaluate to True or False. Thus is cannot evaluate to an ndarray 
with booleans. NumPy cannot change the syntax of Python.

Another thing: An empty list evaluates to False in a boolean context, 
whereas a non-empty list evaluates to True. ndarrays behave differently. 
Why?

Sturla Moldem

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] improved NumPy support for boolean arrays?

[josef . pktd]

On Wed, Aug 5, 2009 at 4:04 PM, Robert Kern wrote:
> On Wed, Aug 5, 2009 at 15:01, Dr. Phillip M.
> Feldman wrote:
>>
>> Although I've used Matlab for many years and am quite new to Python, I'm
>> already convinced that the Python/NumPy combination is more powerful and
>> flexible than the Matlab base, and that it generally takes less Python code
>> to get the same job done. There is, however, at least one thing that is much
>> cleaner in Matlab-- operations on boolean arrays. If x and y are numpy
>> arrays of bools, I'd like to be able to create expressions like the
>> following:
>>
>> not x (to invert each element of x)
>
> ~x
>
>> x and y
>
> x & y
>
>> x or y
>
> x | y
>
>> x xor y
>
> x ^ y
>
>> (not x) or y
>
> (~x) | y

See also

logical_and, logical_or, logical_not, logical_xor

Josef



>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] maximum value and corresponding index

[David Goldsmith]

But you can "cheat" and put them on one line (if that's all you're after):

>>> x = np.array([1, 2, 3])
>>> maxi = x.argmax(); maxv = x[maxi]
>>> maxi, maxv
(2, 3)

DG

--- On Wed, 8/5/09, Robert Kern  wrote:

> From: Robert Kern 
> Subject: Re: [Numpy-discussion] maximum value and corresponding index
> To: "Discussion of Numerical Python" 
> Date: Wednesday, August 5, 2009, 12:59 PM
> On Wed, Aug 5, 2009 at 14:57, Dr.
> Phillip M.
> Feldman
> wrote:
> >
> > With Python/NumPy, is there a way to get the maximum
> element of an array and
> > also the index of the element having that value, at a
> single shot?
> 
> Not in one shot.
> 
> maxi = x.argmax()
> maxv = x[maxi]
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an enigma,
> a harmless
> enigma that is made terrible by our own mad attempt to
> interpret it as
> though it had an underlying truth."
>   -- Umberto Eco
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


  
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] improved NumPy support for boolean arrays?

[Robert Kern]

On Wed, Aug 5, 2009 at 15:01, Dr. Phillip M.
Feldman wrote:
>
> Although I've used Matlab for many years and am quite new to Python, I'm
> already convinced that the Python/NumPy combination is more powerful and
> flexible than the Matlab base, and that it generally takes less Python code
> to get the same job done. There is, however, at least one thing that is much
> cleaner in Matlab-- operations on boolean arrays. If x and y are numpy
> arrays of bools, I'd like to be able to create expressions like the
> following:
>
> not x (to invert each element of x)

~x

> x and y

x & y

> x or y

x | y

> x xor y

x ^ y

> (not x) or y

(~x) | y

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] improved NumPy support for boolean arrays?

[Dr. Phillip M. Feldman]

Although I've used Matlab for many years and am quite new to Python, I'm
already convinced that the Python/NumPy combination is more powerful and
flexible than the Matlab base, and that it generally takes less Python code
to get the same job done. There is, however, at least one thing that is much
cleaner in Matlab-- operations on boolean arrays. If x and y are numpy
arrays of bools, I'd like to be able to create expressions like the
following:

not x (to invert each element of x)
x and y
x or y
x xor y
(not x) or y

The usual array broadcasting rules should apply.  Is there any chance of
getting something like this into NumPy?
-- 
View this message in context: 
http://www.nabble.com/improved-NumPy-support-for-boolean-arrays--tp24835199p24835199.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] maximum value and corresponding index

[Robert Kern]

On Wed, Aug 5, 2009 at 14:57, Dr. Phillip M.
Feldman wrote:
>
> With Python/NumPy, is there a way to get the maximum element of an array and
> also the index of the element having that value, at a single shot?

Not in one shot.

maxi = x.argmax()
maxv = x[maxi]

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] maximum value and corresponding index

[Dr. Phillip M. Feldman]

With Python/NumPy, is there a way to get the maximum element of an array and
also the index of the element having that value, at a single shot?  (One can
do this in Matlab via a statement like the following:

[x_max,ndx]= max(x)
-- 
View this message in context: 
http://www.nabble.com/maximum-value-and-corresponding-index-tp24834930p24834930.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[Ian Mallett]

On Wed, Aug 5, 2009 at 11:34 AM, Charles R Harris  wrote:

> It could be you could slip in a small mod that would do what you want.

I'll help, if you want.  I'm good with GPUs, and I'd appreciate the
numerical power it would afford.

> The main problems with using GPUs were that CUDA was only available for
> nvidia video cards and there didn't seem to be any hope for a CUDA version
> of LAPACK.

You don't have to use CUDA, although it would make it easier.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] BOF c coders.

[David Goldsmith]

So far, no one's proposed a BoF I wouldn't be interested in attending. :-) 
(except for fact that at least some will have to overlap, yes? :-( ).

DG

--- On Wed, 8/5/09, Charles R Harris  wrote:

> From: Charles R Harris 
> Subject: [Numpy-discussion] BOF c coders.
> To: "numpy-discussion" 
> Date: Wednesday, August 5, 2009, 11:47 AM
> Hi All,
> 
> At the present time David C. and myself are doing most of
> the work in the numpy c code base. I am wondering if there
> are more people out there who might want to get involved in
> that end of things and if there are ways we can help them
> get started. If folks are interested we could have a BOF
> meeting at the SciPy conference.
> 
> 
> Chuck
> 
> 
> -Inline Attachment Follows-
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


  
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Keith Goodman]

On Wed, Aug 5, 2009 at 12:14 PM, Robert Kern wrote:
> On Wed, Aug 5, 2009 at 14:11, Pierre GM wrote:
>>
>>  And, er... masked arrays anyone ? 
>
> That was what I suggested. The very first response, even.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco

Is the enigma in your sig enough to invoke Godwin's Law on this thread?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Pierre GM]

On Aug 5, 2009, at 3:14 PM, Robert Kern wrote:

> On Wed, Aug 5, 2009 at 14:11, Pierre GM wrote:
>>
>>  And, er... masked arrays anyone ? 
>
> That was what I suggested. The very first response, even.

I know, Robert, and I thank you for that. My comment was intended to  
the later posters...

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Robert Kern]

On Wed, Aug 5, 2009 at 14:11, Pierre GM wrote:
>
>  And, er... masked arrays anyone ? 

That was what I suggested. The very first response, even.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Pierre GM]

 And, er... masked arrays anyone ? 

On Aug 5, 2009, at 11:20 AM, Bruce Southey wrote:

> On 08/05/2009 09:18 AM, Keith Goodman wrote:
>>
>> On Wed, Aug 5, 2009 at 1:40 AM, Bruce Southey  
>> wrote:
>>
>>> On Tue, Aug 4, 2009 at 4:05 PM, Keith Goodman  
>>> wrote:
>>>
 On Tue, Aug 4, 2009 at 1:53 PM, Bruce Southey  
 wrote:

> On Tue, Aug 4, 2009 at 1:40 PM, Gökhan  
> Sever wrote:
>
>> This is the loveliest of all solutions:
>>
>> c[isfinite(c)].mean()
>>
> This handling of nonfinite elements has come up before.
> Please remember that this only for 1d or flatten array so it not  
> work
> in general especially along an axis.
>
 If you don't want to use nanmean from scipy.stats you could use:

 np.nansum(c, axis=0) / (~np.isnan(c)).sum(axis=0)

 or

 np.nansum(c, axis=0) / (c == c).sum(axis=0)

 But if c contains ints then you'll run into trouble with the  
 division,
 so you'll need to protect against that.

>>> That is not a problem because nan and infinity are only defined for
>>> floating point numbers not integers. So any array that have  
>>> nonfinite
>>> elements like nans and infinity must have a floating point dtype.
>>>
>>
>> That is true. But I was thnking of this case (no nans or infs):
>>
>>
 c

>> array([[1, 2, 3],
>>[4, 5, 6]])
>>
 c.mean(0)

>>array([ 2.5,  3.5,  4.5])  <--- good
>>
 np.nansum(c, axis=0) / (c == c).sum(axis=0)

>>array([2, 3, 4])  <--- bad
>>
 np.nansum(c, axis=0) / (c == c).sum(axis=0, dtype=np.float)

>>array([ 2.5,  3.5,  4.5])  <--- good
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> Sure but that is about ints versus floats and not about nans or  
> infs. Your 'good' examples are really about first converting an int  
> array into a float array and your 'bad' example maintains int dtype  
> (same result if you cast the arrays from 'good' approaches back to  
> an int dtype).
>
> The correct answer depends on what you want the dtype to be. For  
> example,
> With floating point division:
> np.mean(c/0.0,axis=0)
>
> gives the expected floating point answer:
> array([ Inf,  Inf,  Inf])
>
> With integer division:
> np.mean(c/0,axis=0)
>
> gives the expected integer answer:
> array([ 0.,  0.,  0.])
>
> Note the default action of mean is to convert ints to float64 which  
> is why the output is a float instead of an int. Although the  
> numpy.mean dtype argument does not appear to work for int dtypes.
>
>
> Bruce
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] BOF c coders.

[Charles R Harris]

Hi All,

At the present time David C. and myself are doing most of the work in the
numpy c code base. I am wondering if there are more people out there who
might want to get involved in that end of things and if there are ways we
can help them get started. If folks are interested we could have a BOF
meeting at the SciPy conference.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PDE BoF at SciPy2009

[David Goldsmith]

Lot's of food and alcohol!  (Just kidding.)

DG

--- On Wed, 8/5/09, Chris Kees  wrote:

> From: Chris Kees 
> Subject: Re: [Numpy-discussion] PDE BoF at SciPy2009
> To: "Discussion of Numerical Python" 
> Date: Wednesday, August 5, 2009, 11:23 AM
> OK.  I contacted several
> attendees who are not on the numpy list, and  
> it looks like we've got six or seven people interested.
> 
> I've never been to the conference or organized  a
> session like this.    
> Any guidance?
> 
> Chris
> 
> On Aug 5, 2009, at 12:12 PM, David Goldsmith wrote:
> 
> > I already replied to OP, but I'll say publically:
> >
> > "+1", as long as it's not at the same time as the
> as-yet-potential  
> > BoF on "the Future of SciPy".
> >
> > DG
> >
> > --- On Wed, 8/5/09, Daniel Wheeler 
> wrote:
> >
> >> From: Daniel Wheeler 
> >> Subject: Re: [Numpy-discussion] PDE BoF at
> SciPy2009
> >> To: "Discussion of Numerical Python" 
> >> Date: Wednesday, August 5, 2009, 7:20 AM
> >> On Mon, Aug 3, 2009 at 3:57 PM, Chris
> >> Kees
> >> wrote:
> >>> Is there any interest in a BoF session on
> implementing
> >> numerical
> >>> methods for partial differential equations
> using
> >> modules like numpy,
> >>> cython, mpi4py, etc.?
> >>
> >> Yes! My colleague, Jon Guyer, will be attending
> the meeting
> >> and
> >> speaking on this subject. He isn't on this list.
> He will be
> >> there from
> >> midday the Wednesday of the conference. Is this
> BoF still
> >> of interest?
> >>
> >> -- 
> >> Daniel Wheeler
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


  
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GPU Numpy

[Charles R Harris]

On Wed, Aug 5, 2009 at 4:45 AM, Romain Brette  wrote:

> Hi everyone,
>
> I was wondering if you had any plan to incorporate some GPU support to
> numpy, or
> perhaps as a separate module. What I have in mind is something that would
> mimick
> the syntax of numpy arrays, with a new dtype (gpufloat), like this:
>
> from gpunumpy import *
> x=zeros(100,dtype='gpufloat') # Creates an array of 100 elements on the GPU
> y=ones(100,dtype='gpufloat')
> z=exp(2*x+y) # z in on the GPU, all operations on GPU with no transfer
> z_cpu=array(z,dtype='float') # z is copied to the CPU
> i=(z>2.3).nonzero()[0] # operation on GPU, returns a CPU integer array
>
> I came across a paper about something like that but couldn't find any
> public
> release:
> http://www.tricity.wsu.edu/~bobl/personal/mypubs/2009_gpupy_toms.pdf
>
> There is a library named GPULib (http://www.txcorp.com/products/GPULib/)
> that
> does similar things, but unfortunately they don't support Python (I think
> their
> main Python developer left).
> I think this would be very useful for many people. For our project (a
> neural
> network simulator, http://www.briansimulator.org) we use PyCuda
> (http://mathema.tician.de/software/pycuda), which is great, but it is
> mainly for
> low-level GPU programming.
>

What sort of functionality are you looking for? It could be you could slip
in a small mod that would do what you want. In the larger picture, the use
of GPUs has been discussed on the list several times going back at least a
year. The main problems with using GPUs were that CUDA was only available
for nvidia video cards and there didn't seem to be any hope for a CUDA
version of LAPACK.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PDE BoF at SciPy2009

[Gael Varoquaux]

On Wed, Aug 05, 2009 at 01:23:40PM -0500, Chris Kees wrote:
> OK.  I contacted several attendees who are not on the numpy list, and  
> it looks like we've got six or seven people interested.

> I've never been to the conference or organized  a session like this.
> Any guidance?

Just contact one of the organisers during the conference (as early as
possible) and we'll sort out the room. It will happen in the one of the
two evenings, preferably on Thursday.

Gaël
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PDE BoF at SciPy2009

[Chris Kees]

OK.  I contacted several attendees who are not on the numpy list, and  
it looks like we've got six or seven people interested.

I've never been to the conference or organized  a session like this.
Any guidance?

Chris

On Aug 5, 2009, at 12:12 PM, David Goldsmith wrote:

> I already replied to OP, but I'll say publically:
>
> "+1", as long as it's not at the same time as the as-yet-potential  
> BoF on "the Future of SciPy".
>
> DG
>
> --- On Wed, 8/5/09, Daniel Wheeler  wrote:
>
>> From: Daniel Wheeler 
>> Subject: Re: [Numpy-discussion] PDE BoF at SciPy2009
>> To: "Discussion of Numerical Python" 
>> Date: Wednesday, August 5, 2009, 7:20 AM
>> On Mon, Aug 3, 2009 at 3:57 PM, Chris
>> Kees
>> wrote:
>>> Is there any interest in a BoF session on implementing
>> numerical
>>> methods for partial differential equations using
>> modules like numpy,
>>> cython, mpi4py, etc.?
>>
>> Yes! My colleague, Jon Guyer, will be attending the meeting
>> and
>> speaking on this subject. He isn't on this list. He will be
>> there from
>> midday the Wednesday of the conference. Is this BoF still
>> of interest?
>>
>> -- 
>> Daniel Wheeler
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GPU Numpy

[Romain Brette]

Hi everyone,

I was wondering if you had any plan to incorporate some GPU support to numpy, or
perhaps as a separate module. What I have in mind is something that would mimick
the syntax of numpy arrays, with a new dtype (gpufloat), like this:

from gpunumpy import *
x=zeros(100,dtype='gpufloat') # Creates an array of 100 elements on the GPU
y=ones(100,dtype='gpufloat')
z=exp(2*x+y) # z in on the GPU, all operations on GPU with no transfer
z_cpu=array(z,dtype='float') # z is copied to the CPU
i=(z>2.3).nonzero()[0] # operation on GPU, returns a CPU integer array

I came across a paper about something like that but couldn't find any public
release:
http://www.tricity.wsu.edu/~bobl/personal/mypubs/2009_gpupy_toms.pdf

There is a library named GPULib (http://www.txcorp.com/products/GPULib/) that
does similar things, but unfortunately they don't support Python (I think their
main Python developer left).
I think this would be very useful for many people. For our project (a neural
network simulator, http://www.briansimulator.org) we use PyCuda
(http://mathema.tician.de/software/pycuda), which is great, but it is mainly for
low-level GPU programming.

Cheers
Romain


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PDE BoF at SciPy2009

[David Goldsmith]

I already replied to OP, but I'll say publically:

"+1", as long as it's not at the same time as the as-yet-potential BoF on "the 
Future of SciPy".

DG

--- On Wed, 8/5/09, Daniel Wheeler  wrote:

> From: Daniel Wheeler 
> Subject: Re: [Numpy-discussion] PDE BoF at SciPy2009
> To: "Discussion of Numerical Python" 
> Date: Wednesday, August 5, 2009, 7:20 AM
> On Mon, Aug 3, 2009 at 3:57 PM, Chris
> Kees
> wrote:
> > Is there any interest in a BoF session on implementing
> numerical
> > methods for partial differential equations using
> modules like numpy,
> > cython, mpi4py, etc.?
> 
> Yes! My colleague, Jon Guyer, will be attending the meeting
> and
> speaking on this subject. He isn't on this list. He will be
> there from
> midday the Wednesday of the conference. Is this BoF still
> of interest?
> 
> -- 
> Daniel Wheeler
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


  
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] strange sin/cos performance

[Scott Sinclair]

> 2009/8/5 Andrew Friedley :
>
>> Is anyone with this problem *not* running ubuntu?
>
> Me - RHEL 5.2 opteron:
>
> Python 2.6.1 (r261:67515, Jan  5 2009, 10:19:01)
> [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
>
> Fedora 9 PS3/PPC:
>
> Python 2.5.1 (r251:54863, Jul 17 2008, 13:25:23)
> [GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2
>
>
> Actually I now have some interesting results that indicate the issue isn't
> in Python or NumPy at all.  I just wrote a C program to try to reproduce the
> error, and was able to do so (actually the difference is even larger).
>
> Opteron:
>
> float (32) time in usecs: 179698
> double (64) time in usecs: 13795
>
> PS3/PPC:
>
> float (32) time in usecs: 614821
> double (64) time in usecs: 37163
>
> I've attached the code for others to review and/or try out.  I guess this is
> worth showing to the libc people?

For whatever it's worth, not much difference on my machine 32-bit
Ubuntu, GCC 4.3.3.

float (32) time in usecs: 13804
double (64) time in usecs: 15394

Cheers,
Scott
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Bruce Southey]

On 08/05/2009 09:18 AM, Keith Goodman wrote:

On Wed, Aug 5, 2009 at 1:40 AM, Bruce Southey  wrote:
   

On Tue, Aug 4, 2009 at 4:05 PM, Keith Goodman  wrote:
 

On Tue, Aug 4, 2009 at 1:53 PM, Bruce Southey  wrote:
   

On Tue, Aug 4, 2009 at 1:40 PM, Gökhan Sever  wrote:
 

This is the loveliest of all solutions:

c[isfinite(c)].mean()
   

This handling of nonfinite elements has come up before.
Please remember that this only for 1d or flatten array so it not work
in general especially along an axis.
 

If you don't want to use nanmean from scipy.stats you could use:

np.nansum(c, axis=0) / (~np.isnan(c)).sum(axis=0)

or

np.nansum(c, axis=0) / (c == c).sum(axis=0)

But if c contains ints then you'll run into trouble with the division,
so you'll need to protect against that.
   

That is not a problem because nan and infinity are only defined for
floating point numbers not integers. So any array that have nonfinite
elements like nans and infinity must have a floating point dtype.
 


That is true. But I was thnking of this case (no nans or infs):

   

c
   

array([[1, 2, 3],
[4, 5, 6]])
   

c.mean(0)
   

array([ 2.5,  3.5,  4.5])<--- good
   

np.nansum(c, axis=0) / (c == c).sum(axis=0)
   

array([2, 3, 4])<--- bad
   

np.nansum(c, axis=0) / (c == c).sum(axis=0, dtype=np.float)
   

array([ 2.5,  3.5,  4.5])<--- good
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
   
Sure but that is about ints versus floats and not about nans or infs. 
Your 'good' examples are really about first converting an int array into 
a float array and your 'bad' example maintains int dtype (same result if 
you cast the arrays from 'good' approaches back to an int dtype).


The correct answer depends on what you want the dtype to be. For example,
With floating point division:
np.mean(c/0.0,axis=0)

gives the expected floating point answer:
array([ Inf,  Inf,  Inf])

With integer division:
np.mean(c/0,axis=0)

gives the expected integer answer:
array([ 0.,  0.,  0.])

Note the default action of mean is to convert ints to float64 which is 
why the output is a float instead of an int. Although the numpy.mean 
dtype argument does not appear to work for int dtypes.



Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] strange sin/cos performance

[Andrew Friedley]

Is anyone with this problem *not* running ubuntu?


Me - RHEL 5.2 opteron:

Python 2.6.1 (r261:67515, Jan  5 2009, 10:19:01)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2

Fedora 9 PS3/PPC:

Python 2.5.1 (r251:54863, Jul 17 2008, 13:25:23)
[GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2


Actually I now have some interesting results that indicate the issue 
isn't in Python or NumPy at all.  I just wrote a C program to try to 
reproduce the error, and was able to do so (actually the difference is 
even larger).


Opteron:

float (32) time in usecs: 179698
double (64) time in usecs: 13795

PS3/PPC:

float (32) time in usecs: 614821
double (64) time in usecs: 37163

I've attached the code for others to review and/or try out.  I guess 
this is worth showing to the libc people?


Andrew
#include 
#include 
#include 

#define LEN 159161

float inp32[LEN];
float out32[LEN];

double inp64[LEN];
double out64[LEN];

int main(int argc, char** argv)
{
struct timeval tv_start;
struct timeval tv_stop;
int i;

for(i = 0; i < LEN; i++) {
//inp32[i] = ((float)i / (float)LEN) *  (2 * M_PI);
inp32[i] = (float)i;
out32[i] = 0.0;
}

gettimeofday(&tv_start, NULL);
for(i = 0; i < LEN; i++) {
out32[i] = (float)cosf((float)inp32[i]);
}
gettimeofday(&tv_stop, NULL);

if(tv_start.tv_sec != tv_stop.tv_sec) {
puts("seconds changed, re-run the benchmark");
}

printf("float (32) time in usecs: %d\n", tv_stop.tv_usec - 
tv_start.tv_usec);


for(i = 0; i < LEN; i++) {
//inp32[i] = ((double)i / (double)LEN) *  (2 * M_PI);
inp64[i] = (float)i;
out64[i] = 0.0;
}

gettimeofday(&tv_start, NULL);
for(i = 0; i < LEN; i++) {
out64[i] = (double)cos((double)inp64[i]);
}
gettimeofday(&tv_stop, NULL);

if(tv_start.tv_sec != tv_stop.tv_sec) {
puts("seconds changed, re-run the benchmark");
}

printf("double (64) time in usecs: %d\n", tv_stop.tv_usec - 
tv_start.tv_usec);

return 0;
}

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Funded work on Numpy: proposed improvements and request for feedback

[Bruce Southey]

On 08/05/2009 06:45 AM, David Cournapeau wrote:

Bruce Southey wrote:
   

So if 'C99-like' is going to be the near term future, is there any
point in supporting non-C99 environments with this work?

 


There may be a misunderstanding:

Really ignorance :-)

if the platform support C99 complex,
then we will use it, and otherwise, we will do as today, that is define
our own type.
   

Actually I did understand that  much.

The advantages of reusing the C99 complex type if available:
 - if yourself do not care about portability, you can use the numpy
complex typedef as a C99 complex, using addition, division, etc...
operators.
 - we can reuse the math library.
I also need some sort of proper C99 support for windows 64 (more exactly
to reimplement a minimal libgfortran buildable by MS compiler).

   

That is, is the limitation in the compiler, operating system,
processor or some combination of these?

 


That's purely a compiler issue. Of course, the main culprit is MS
compiler. MS explicitly stated they did not care about proper C support.
   
Obviously complicated by the distribution of the official Python MS 
compiled binaries.


Ultimately,  my view is looking at long term maintenance when people 
have moved on and the code gets somewhat stale. Definitely your proposal 
would help long term maintenance of Numpy using C99 supported compilers 
if included. So my concern is avoiding divergence of the code base 
between the Numpy and the library so there is no unnecessary code 
duplication, no need to merge code in the future and fixes (bugs or 
enhancements) get fixed once that applies to both aspects. Provided 
these aspects are addressed I have no problems with the proposal.



Bruce



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] yubnub and numpy examples

[josef . pktd]

On Wed, Aug 5, 2009 at 10:30 AM,  wrote:
> On Wed, Aug 5, 2009 at 9:44 AM, John Hunter wrote:
>> yubnub is pretty cool -- it's a command line interface for the web.
>> You can enable it in firefox by typing "about:config" in the URL bar,
>> scrolling down to "keyword.URL", right click on the line and choose
>> modify, and set the value to be
>>
>> http://www.yubnub.org/parser/parse?default=g2&command=
>>
>> Then, you can type yubnub commands in the URL bar, eg, to see all
>> commands related to python, type "ls python" in the URL bar.
>>
>> It's easy to create new commands; I just created a new command to load
>> the docs for a numpy function; just type in the URL bar:
>>
>>  npfunc convolve
>>
>> which takes you directly to
>> http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html

Still, it is a lot slower than windows htmlhelp, which is available
for numy and scipy but not for others.

"y mplcodex histogram"  takes pretty long to load


>>
>> I was hoping to create a similar command for the numpy examples, but
>> the URL links in http://www.scipy.org/Numpy_Example_List_With_Doc are
>> some md5 gobbledy-gook.  Is it possible to have nice URLs on this
>> page, so they can be more readily yubnub-ized?

my impression of the example list page:
This page is not really maintained anymore, it is still at numpy 1.2.1
and mostly superseded by the new docs, with examples as part of the
docstrings. (Also because of it's page size, I think it's more
appropriate for browsing than for quick lookups.)

Josef

>>
>> JDH
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> looks pretty good, but I would recommend a safe install, instead of
> overwriting the keyword default. This requires typing one additional
> letter, e.g "y npfunc convolve", (and avoids invalidating the firefox
> warranty, and you can do the same with other search/link shortcuts)
>
> Josef
>
>
> from http://www.yubnub.org/documentation/describe_installation
>
> """
>
> Safe Firefox Installation. The safest way to install YubNub is to make
> a Firefox keyword for it. If you're using the Firefox web browser:
>
>    * Right-click the input box at the top of the page (the one under
> the words "Type in a command")
>    * Click "Add a Keyword for this Search"
>    * For the Name, enter "YubNub", and for the Keyword, enter "y"
>    * Press OK
>
> Now you can use YubNub directly from the address bar. For example, try
> typing "y gim porsche 911" into your address bar. Don't forget the "y"
> in front!
> You may have noticed that I said that this is the "safest way" to
> install YubNub. Why safest? Because you must explicitly enter a "y"
> before the YubNub command. This prevents "command spoofing".
>
> For example, suppose someone made a "michael" command. If you typed
> "michael jordan" into YubNub, intending to do a search, you would
> instead go to the site of the person who made the "michael" command.
> Rats! But if you installed YubNub into your Firefox address bar as
> described above, typing "michael jordan" into your address bar would
> do a search for "michael jordan", as you intended. The only way to get
> to that other person's site would be to type "y michael".
>
> If you like to live on the edge like me, you can try one of the other
> installation methods, many of which do not require an initial keyword
> like "y".
>
> """
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] yubnub and numpy examples

[Ralf Gommers]

On Wed, Aug 5, 2009 at 9:44 AM, John Hunter  wrote:

> yubnub is pretty cool -- it's a command line interface for the web.
> You can enable it in firefox by typing "about:config" in the URL bar,
> scrolling down to "keyword.URL", right click on the line and choose
> modify, and set the value to be
>
> http://www.yubnub.org/parser/parse?default=g2&command=
>
> Then, you can type yubnub commands in the URL bar, eg, to see all
> commands related to python, type "ls python" in the URL bar.
>
> It's easy to create new commands; I just created a new command to load
> the docs for a numpy function; just type in the URL bar:
>
>  npfunc convolve


very cool, thanks!

>
>
> which takes you directly to
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html
>
> I was hoping to create a similar command for the numpy examples, but
> the URL links in http://www.scipy.org/Numpy_Example_List_With_Doc are
> some md5 gobbledy-gook.  Is it possible to have nice URLs on this
> page, so they can be more readily yubnub-ized?


Most of those examples have been integrated in the docstrings, and many more
have been written in the doc wiki. They also use "from numpy import *"
instead of the np namespace. So instead of spending time fixing links, it
might make more sense to generate a new version of this page (with more
useful links) from the docstrings themselves.

Cheers,
Ralf


>
> JDH
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Hans Meine]

On Tuesday 04 August 2009 22:06:38 Keith Goodman wrote:
> On Tue, Aug 4, 2009 at 12:59 PM, Gael
>
> Varoquaux wrote:
> > On Tue, Aug 04, 2009 at 01:54:49PM -0500, Gökhan Sever wrote:
> >>I see that you should have a browser embedding plugin for Ipyhon
> >> which you don't want to share with us :)
> >
> > No, I answer e-mail using vim.
>
> Yeah, I'm trying that right now. :wq :q! :dammit

Vim?  Isn't that the editor with the two modes, one which destroys your text 
and one that beeps?  ;-)

Have a nice day,
  Hans

PS: Yes, it's a free translation of a German chat (IRC/bash?) citation..
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] yubnub and numpy examples

[josef . pktd]

On Wed, Aug 5, 2009 at 9:44 AM, John Hunter wrote:
> yubnub is pretty cool -- it's a command line interface for the web.
> You can enable it in firefox by typing "about:config" in the URL bar,
> scrolling down to "keyword.URL", right click on the line and choose
> modify, and set the value to be
>
> http://www.yubnub.org/parser/parse?default=g2&command=
>
> Then, you can type yubnub commands in the URL bar, eg, to see all
> commands related to python, type "ls python" in the URL bar.
>
> It's easy to create new commands; I just created a new command to load
> the docs for a numpy function; just type in the URL bar:
>
>  npfunc convolve
>
> which takes you directly to
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html
>
> I was hoping to create a similar command for the numpy examples, but
> the URL links in http://www.scipy.org/Numpy_Example_List_With_Doc are
> some md5 gobbledy-gook.  Is it possible to have nice URLs on this
> page, so they can be more readily yubnub-ized?
>
> JDH
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

looks pretty good, but I would recommend a safe install, instead of
overwriting the keyword default. This requires typing one additional
letter, e.g "y npfunc convolve", (and avoids invalidating the firefox
warranty, and you can do the same with other search/link shortcuts)

Josef


from http://www.yubnub.org/documentation/describe_installation

"""

Safe Firefox Installation. The safest way to install YubNub is to make
a Firefox keyword for it. If you're using the Firefox web browser:

* Right-click the input box at the top of the page (the one under
the words "Type in a command")
* Click "Add a Keyword for this Search"
* For the Name, enter "YubNub", and for the Keyword, enter "y"
* Press OK

Now you can use YubNub directly from the address bar. For example, try
typing "y gim porsche 911" into your address bar. Don't forget the "y"
in front!
You may have noticed that I said that this is the "safest way" to
install YubNub. Why safest? Because you must explicitly enter a "y"
before the YubNub command. This prevents "command spoofing".

For example, suppose someone made a "michael" command. If you typed
"michael jordan" into YubNub, intending to do a search, you would
instead go to the site of the person who made the "michael" command.
Rats! But if you installed YubNub into your Firefox address bar as
described above, typing "michael jordan" into your address bar would
do a search for "michael jordan", as you intended. The only way to get
to that other person's site would be to type "y michael".

If you like to live on the edge like me, you can try one of the other
installation methods, many of which do not require an initial keyword
like "y".

"""
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Keith Goodman]

On Wed, Aug 5, 2009 at 1:40 AM, Bruce Southey wrote:
> On Tue, Aug 4, 2009 at 4:05 PM, Keith Goodman wrote:
>> On Tue, Aug 4, 2009 at 1:53 PM, Bruce Southey wrote:
>>> On Tue, Aug 4, 2009 at 1:40 PM, Gökhan Sever wrote:
 This is the loveliest of all solutions:

 c[isfinite(c)].mean()
>>>
>>> This handling of nonfinite elements has come up before.
>>> Please remember that this only for 1d or flatten array so it not work
>>> in general especially along an axis.
>>
>> If you don't want to use nanmean from scipy.stats you could use:
>>
>> np.nansum(c, axis=0) / (~np.isnan(c)).sum(axis=0)
>>
>> or
>>
>> np.nansum(c, axis=0) / (c == c).sum(axis=0)
>>
>> But if c contains ints then you'll run into trouble with the division,
>> so you'll need to protect against that.
>
> That is not a problem because nan and infinity are only defined for
> floating point numbers not integers. So any array that have nonfinite
> elements like nans and infinity must have a floating point dtype.

That is true. But I was thnking of this case (no nans or infs):

>> c
array([[1, 2, 3],
   [4, 5, 6]])
>> c.mean(0)
   array([ 2.5,  3.5,  4.5])  <--- good
>> np.nansum(c, axis=0) / (c == c).sum(axis=0)
   array([2, 3, 4])  <--- bad
>> np.nansum(c, axis=0) / (c == c).sum(axis=0, dtype=np.float)
   array([ 2.5,  3.5,  4.5])  <--- good
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PDE BoF at SciPy2009

[Daniel Wheeler]

On Mon, Aug 3, 2009 at 3:57 PM, Chris Kees wrote:
> Is there any interest in a BoF session on implementing numerical
> methods for partial differential equations using modules like numpy,
> cython, mpi4py, etc.?

Yes! My colleague, Jon Guyer, will be attending the meeting and
speaking on this subject. He isn't on this list. He will be there from
midday the Wednesday of the conference. Is this BoF still of interest?

-- 
Daniel Wheeler
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] yubnub and numpy examples

[John Hunter]

yubnub is pretty cool -- it's a command line interface for the web.
You can enable it in firefox by typing "about:config" in the URL bar,
scrolling down to "keyword.URL", right click on the line and choose
modify, and set the value to be

http://www.yubnub.org/parser/parse?default=g2&command=

Then, you can type yubnub commands in the URL bar, eg, to see all
commands related to python, type "ls python" in the URL bar.

It's easy to create new commands; I just created a new command to load
the docs for a numpy function; just type in the URL bar:

  npfunc convolve

which takes you directly to
http://docs.scipy.org/doc/numpy/reference/generated/numpy.convolve.html

I was hoping to create a similar command for the numpy examples, but
the URL links in http://www.scipy.org/Numpy_Example_List_With_Doc are
some md5 gobbledy-gook.  Is it possible to have nice URLs on this
page, so they can be more readily yubnub-ized?

JDH
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Funded work on Numpy: proposed improvements and request for feedback

[David Cournapeau]

Bruce Southey wrote:
> So if 'C99-like' is going to be the near term future, is there any
> point in supporting non-C99 environments with this work?
>   

There may be a misunderstanding: if the platform support C99 complex,
then we will use it, and otherwise, we will do as today, that is define
our own type.

The advantages of reusing the C99 complex type if available:
- if yourself do not care about portability, you can use the numpy
complex typedef as a C99 complex, using addition, division, etc...
operators.
- we can reuse the math library.

I also need some sort of proper C99 support for windows 64 (more exactly
to reimplement a minimal libgfortran buildable by MS compiler).

> That is, is the limitation in the compiler, operating system,
> processor or some combination of these?
>   

That's purely a compiler issue. Of course, the main culprit is MS
compiler. MS explicitly stated they did not care about proper C support.

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] strange sin/cos performance

[Bruce Southey]

On Tue, Aug 4, 2009 at 9:42 PM, Charles R
Harris wrote:
>
>
> On Tue, Aug 4, 2009 at 7:18 PM, Jochen  wrote:
>>
>> Hi all,
>> I see something similar on my system.
>> OK I've just done a test. System is Ubuntu 9.04 AMD64
>> there seems to be a regression for float32 with high values:
>>
>> In [47]: a=np.random.rand(1).astype(np.float32)
>>
>> In [48]: b=np.random.rand(1).astype(np.float64)
>>
>> In [49]: c=1000*np.random.rand(1).astype(np.float32)
>>
>> In [50]: d=1000*np.random.rand(1000).astype(np.float64)
>>
>> In [51]: %timeit -n 10 np.sin(a)
>> 10 loops, best of 3: 251 µs per loop
>>
>> In [52]: %timeit -n 10 np.sin(b)
>> 10 loops, best of 3: 395 µs per loop
>>
>> In [53]: %timeit -n 10 np.sin(c)
>> 10 loops, best of 3: 5.65 ms per loop
>>
>> In [54]: %timeit -n 10 np.sin(d)
>> 10 loops, best of 3: 87.7 µs per loop
>>
>> In [55]: %timeit -n 10 np.sin(c.astype(np.float64)).astype(np.float32)
>> 10 loops, best of 3: 891 µs per loop
>
> Is anyone with this problem *not* running ubuntu?
>

Yes but I do not consider a 'problem'.

While not an expert in this, this looks to be related to 64 bit OSes
running on 64bit processors, probably compiler related, and probably a
feature of Python. As I have tried to show, I do not think that these
timing are being performed correctly because when you pass a single
argument to Python at the command prompt you get the comparable
timings.

The difference in timing occurs when you pass two arguments to Python.
I do not use IPython so I am only guessing but you need to do the
timing at the same time. Probably something like:

%timeit -n 10 np.sin(numpy.arange(0.0, 1000, (2 * 3.14159) / 1000,
dtype=np.float32))

Note there is a most likely a penalty involved in type conversion that
needs to be addressed in any timings.

Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why NaN?

[Bruce Southey]

On Tue, Aug 4, 2009 at 4:05 PM, Keith Goodman wrote:
> On Tue, Aug 4, 2009 at 1:53 PM, Bruce Southey wrote:
>> On Tue, Aug 4, 2009 at 1:40 PM, Gökhan Sever wrote:
>>> This is the loveliest of all solutions:
>>>
>>> c[isfinite(c)].mean()
>>
>> This handling of nonfinite elements has come up before.
>> Please remember that this only for 1d or flatten array so it not work
>> in general especially along an axis.
>
> If you don't want to use nanmean from scipy.stats you could use:
>
> np.nansum(c, axis=0) / (~np.isnan(c)).sum(axis=0)
>
> or
>
> np.nansum(c, axis=0) / (c == c).sum(axis=0)
>
> But if c contains ints then you'll run into trouble with the division,
> so you'll need to protect against that.

That is not a problem because nan and infinity are only defined for
floating point numbers not integers. So any array that have nonfinite
elements like nans and infinity must have a floating point dtype.

Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] strange sin/cos performance

[Dave]

Charles R Harris  gmail.com> writes:

> 
> 
> Is anyone with this problem *not* running ubuntu?Chuck 
> 

All I can say is that it (surprisingly?) doesn't appear to affect my windoze
(XP) box.


Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]

In [2]: a=np.random.rand(1).astype(np.float32)

In [3]: b=np.random.rand(1).astype(np.float64)

In [4]: c=1000*np.random.rand(1).astype(np.float32)

In [5]: d=1000*np.random.rand(1000).astype(np.float64)

In [6]: timeit -n 10 np.sin(a)
10 loops, best of 3: 442 us per loop

In [7]: timeit -n 10 np.sin(b)
10 loops, best of 3: 513 us per loop

In [8]: timeit -n 10 np.sin(c)
10 loops, best of 3: 474 us per loop

In [9]: timeit -n 10 np.sin(d)
10 loops, best of 3: 63.1 us per loop

In [10]: timeit -n 10 np.sin(c.astype(np.float64)).astype(np.float32)
10 loops, best of 3: 587 us per loop

In [11]: !gcc --version
gcc (GCC) 3.4.5 (mingw-vista special r3)



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion