Hi David,
Sounds very interesting, have you noticed any improvement in performance ove
using the builtin numpy blas lite?
If you need someone to test on Windows 64 I would be happy to do so.
Hanni
2009/6/29 David Cournapeau
> Hi,
>
>I started working on a new approach for windows 64 bits
On Mon, Jun 29, 2009 at 4:09 PM, Hanni Ali wrote:
> Hi David,
>
> Sounds very interesting, have you noticed any improvement in performance ove
> using the builtin numpy blas lite?
For now, I focus on building and passing the test suite. That's
already a lot of work since MS compilers are very crap
Hi,
I am doing a little test using numpy and numexpr to do a particle simulation. I
never used either of them much and this is the first time I have to go deeper.
Here is the code:
import numpy as np
import numexpr as nexpr
class Particle( object ):
def __init__( self, id ):
s
Hi,
I'm trying to understand how integer types are upcast for add/multiply
operations for my GSoC project (Implementing Ufuncs using CorePy).
The documentation says that for reduction with add/multiply operations,
integer types are 'upcast' to the int_ type (int64 on my system). What
exactly
On Mon, Jun 29, 2009 at 8:20 AM, Prashant Saxena wrote:
> Hi,
>
> I am doing a little test using numpy and numexpr to do a particle
> simulation. I never used either of them much and this is the first time I
> have to go deeper. Here is the code:
>
> import numpy as np
> import numexpr as nexpr
>
>
As an off-topic solution, there's always the GPU to do the the particle
updating. With half decent optimization, I've gotten over a million
particles in *real-time*. You could presumably run several of these at the
same time to get as many particles as you want. Downside would be
ease-of-impleme
On Mon, Jun 29, 2009 at 00:34, David
Cournapeau wrote:
> Hi,
>
> I started working on a new approach for windows 64 bits support, to
> be able to combine gfortran and visual studio. Basically, I am
> reimplementing the needed functions from libgfortran so that it can be
> built with MS compiler,
On Tue, Jun 30, 2009 at 2:15 AM, Robert Kern wrote:
> On Mon, Jun 29, 2009 at 00:34, David
> Cournapeau wrote:
>> Hi,
>>
>> I started working on a new approach for windows 64 bits support, to
>> be able to combine gfortran and visual studio. Basically, I am
>> reimplementing the needed functions
On 06/29/2009 12:15 PM, Robert Kern wrote:
On Mon, Jun 29, 2009 at 00:34, David
Cournapeau wrote:
Hi,
I started working on a new approach for windows 64 bits support, to
be able to combine gfortran and visual studio. Basically, I am
reimplementing the needed functions from libgfortran
I have an old Numarray C extension (or, rather, a Python package
containing a C extension) that I would like to convert to numpy
(in a way that is likely to be supported long-term).
Options I have found include:
- Use the new numpy extension. This seems likely to be fast and
future-proof. But I
On Mon, Jun 29, 2009 at 3:03 PM, Russell E. Owen wrote:
> I have an old Numarray C extension (or, rather, a Python package
> containing a C extension) that I would like to convert to numpy
> (in a way that is likely to be supported long-term).
>
> Options I have found include:
>
> - Use the new nu
Hi,
There was some discussion (e.g.
http://article.gmane.org/gmane.comp.python.numeric.general/30629)
about changes to the arraysetops module to consolidate the separate
unique/non-unique functions and rename setmember1d to in1d. There's a
patch that makes these changes in ticket 1133
(http://proj
Hi Russell,
Have you looked at the example in our interactive data analysis
tutorial where we compute radial profiles in Python? It's not as fast
as C because of the sort, but perhaps that's fast enough for your
purposes. I wasn't sure if you had already seen that approach or not.
(I think
In article
,
Charles R Harris wrote:
> On Mon, Jun 29, 2009 at 3:03 PM, Russell E. Owen
> wrote:
>
> > I have an old Numarray C extension (or, rather, a Python package
> > containing a C extension) that I would like to convert to numpy
> > (in a way that is likely to be supported long-term).
In article <4d2b04ed-4612-4244-a8b8-3ff0c8659...@stsci.edu>,
Perry Greenfield wrote:
> Hi Russell,
>
> Have you looked at the example in our interactive data analysis
> tutorial where we compute radial profiles in Python? It's not as fast
> as C because of the sort, but perhaps that's fast
On Mon, Jun 29, 2009 at 4:17 PM, Russell E. Owen wrote:
> In article
> ,
> Charles R Harris wrote:
>
> > On Mon, Jun 29, 2009 at 3:03 PM, Russell E. Owen
> > wrote:
> >
> > > I have an old Numarray C extension (or, rather, a Python package
> > > containing a C extension) that I would like to con
On Mon, Jun 29, 2009 at 6:10 PM, Charles R Harris wrote:
>
>
> On Mon, Jun 29, 2009 at 4:17 PM, Russell E. Owen
> wrote:
>
>> In article
>> ,
>> Charles R Harris wrote:
>>
>> > On Mon, Jun 29, 2009 at 3:03 PM, Russell E. Owen
>> > wrote:
>> >
>> > > I have an old Numarray C extension (or, rath
On Tue, Jun 30, 2009 at 3:06 AM, Bruce Southey wrote:
>
> I would think that you could just provide an appropriately licensed package
> that combines a separately downloaded numpy/scipy with the separately
> downloaded/installed gfortran to install the new version of numpy/scipy.
That's exactly
18 matches
Mail list logo
