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
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 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
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
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).
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
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
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
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 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
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 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,
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 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
>
>
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
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
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 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
18 matches
Mail list logo
