Robert Kern wrote:
> David Cournapeau wrote:
>> Hi,
>>
>> I try to compile numpy using gfortran, using:
>>
>> python setup.py config --fcompiler=gnu
>>
>> But this does not work. Whatever option I try, numpy build system
>> uses g77, and as a result, I have problems with my ATLAS libra
On 25 Feb 2007 01:44:01 +, Alexander Schmolck <[EMAIL PROTECTED]>
wrote:
"Charles R Harris" <[EMAIL PROTECTED]> writes:
> > Unfortunately I don't see an easy way to use the same approach the
other
> > way
> > (matlab doesn't seem to offer much on the C level to manipulate
arrays),
> > so
>
"Charles R Harris" <[EMAIL PROTECTED]> writes:
> > Unfortunately I don't see an easy way to use the same approach the other
> > way
> > (matlab doesn't seem to offer much on the C level to manipulate arrays),
> > so
> > I'd presumably need something like:
> >
> > stuff_into_matlab_array(a.T.resh
Andrew Straw <[EMAIL PROTECTED]> writes:
> Alexander Schmolck wrote:
> > 2. Despite this overhead, copying around large arrays (e.g. >=1e5 elements)
> > in
> >above way causes notable additional overhead. Whilst I don't think
> > there's
> >a sane way to avoid copying by sharing data bet
Hi folks,
I've been doing a lot of web-reading on the subject, but have not
been completely able to synthesize all of the disparate bits of
advice about building python extensions as Mac-PPC and Mac-Intel fat
binaries, so I'm turning to the wisdom of this list for a few questions.
My genera
David Cournapeau wrote:
> Hi,
>
> I try to compile numpy using gfortran, using:
>
> python setup.py config --fcompiler=gnu
>
> But this does not work. Whatever option I try, numpy build system
> uses g77, and as a result, I have problems with my ATLAS library
> compiled with gfortr
Hi,
I try to compile numpy using gfortran, using:
python setup.py config --fcompiler=gnu
But this does not work. Whatever option I try, numpy build system
uses g77, and as a result, I have problems with my ATLAS library
compiled with gfortran. What should I do to compiler numpy wit
Alexander Schmolck wrote:
> 2. Despite this overhead, copying around large arrays (e.g. >=1e5 elements) in
>above way causes notable additional overhead. Whilst I don't think there's
>a sane way to avoid copying by sharing data between numpy and matlab the
>copying could likely be done
