Hi,
I would like know the opinion from other people on the best way to
customize compilation flags for building numpy. I am talking about the
end-user point of view (e.g. I want to use the
--optimize--so-aggressively-that-my-cpu-burns-into-flames flags, but
without breaking build of python
Am Freitag, 09. November 2007 00:16:12 schrieb Travis E. Oliphant:
> C-order is "special" in NumPy due to the history. I agree that it
> doesn't need to be and we have taken significant steps in that
> direction.
Thanks for this clarifying statement.
> Right now, the fundamental problem is proba
Hi,
this comment might be counterproductive to this discussion:
However.
I'm also using numpy as a basis for putting together an image analysis
"platform"/library.
This includes both 2D and higher dimensional images.
Since all my code, if not n Python, is written in C or C++ and not
Fortran, I deci
Am Freitag, 09. November 2007 13:04:24 schrieb Sebastian Haase:
> Since all my code, if not n Python, is written in C or C++ and not
> Fortran, I decided early on that I had to get used to "invese
> indexing", as in
> image[y,x] or image[z,y,x]
We cannot do that here, since
a) we use the opposite
On Nov 9, 2007 1:43 PM, Hans Meine <[EMAIL PROTECTED]> wrote:
> Am Freitag, 09. November 2007 13:04:24 schrieb Sebastian Haase:
> Of course, we want to have the same order in both languages in order to
> facilitate porting algorithms after rapid prototyping.
>
Yes, I understand your situation.
On Nov 8, 2007 10:06 PM, David Cournapeau <[EMAIL PROTECTED]> wrote:
>
> Geoffrey Zhu wrote:
> > On Nov 8, 2007 12:12 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> >> Geoffrey Zhu wrote:
> >>
> >>> Good morning.
> >>>
> >>> I just installed the Windows binary of numpy 1.04. When I ran
> >>> nump
Hans Meine wrote:
>
>
>
>> Fortran order arrays can be preserved but it takes a little extra work
>> because backward compatible expectations had to be met. See for example
>> the order argument to the copy method of arrays.
>>
>
> What do you mean exactly (if you have something specific i
On Nov 9, 2007 10:14 AM, Geoffrey Zhu <[EMAIL PROTECTED]> wrote:
>
> On Nov 8, 2007 10:06 PM, David Cournapeau <[EMAIL PROTECTED]> wrote:
> >
> > Geoffrey Zhu wrote:
> > > On Nov 8, 2007 12:12 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> > >
> > >> Geoffrey Zhu wrote:
> > >>
> > >>> Good morning.
>
Very interesting! If I use the MSI file, numpy.test() hangs. If,
however, I use the EGG file, it is actually fine.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 9 Nov 2007 11:31:54 -0600
"Geoffrey Zhu" <[EMAIL PROTECTED]> wrote:
> Very interesting! If I use the MSI file, numpy.test()
>hangs. If,
> however, I use the EGG file, it is actually fine.
> ___
> Numpy-discussion mailing list
> Numpy-discussion
Geoffrey Zhu wrote:
> Very interesting! If I use the MSI file, numpy.test() hangs. If,
> however, I use the EGG file, it is actually fine.
>
Can you find the md5sum of these files?
There is a md5sum.exe at
http://www.etree.org/md5com.html
It would be good to verify that you have the correct
On Nov 9, 2007 11:45 AM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Geoffrey Zhu wrote:
> > Very interesting! If I use the MSI file, numpy.test() hangs. If,
> > however, I use the EGG file, it is actually fine.
> >
>
> Can you find the md5sum of these files?
>
> There is a md5sum.exe at
>
> ht
On Nov 9, 2007 11:42 AM, Nils Wagner <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Nov 2007 11:31:54 -0600
> "Geoffrey Zhu" <[EMAIL PROTECTED]> wrote:
>
> > Very interesting! If I use the MSI file, numpy.test()
> >hangs. If,
> > however, I use the EGG file, it is actually fine.
> > __
Build was successful after a change in distutils.
Core 2 Duo, Debian Etch-32, Python 2.5, icc 10.1, ifort 10.1, & mkl
10.0. MKL & the compilers were installed to their default
locations: /opt/intel/mkl/, /opt/intel/cc/, /opt/intel/fc/
Installation will not interfere with earlier versions.
NumPy
On Freitag 09 November 2007, Travis E. Oliphant wrote:
> > While this is
> > a good idea (also probably quite some work), the real thing bugging me is
> > that the above DOUBLE_add could (and should!) be called by the ufunc
> > framework in such a way that it is equally efficient for C and Fortran
On Nov 10, 2007 1:12 AM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Hans Meine wrote:
> > | static void
> > | DOUBLE_add(char **args, intp *dimensions, intp *steps, void *func)
> > | {
> > | register intp i;
> > | intp is1=steps[0],is2=steps[1],os=steps[2], n=dimensions[0];
> > | c
On Nov 10, 2007 4:39 AM, Hans Meine <[EMAIL PROTECTED]> wrote:
> On Freitag 09 November 2007, Travis E. Oliphant wrote:
> > > While this is
> > > a good idea (also probably quite some work), the real thing bugging me is
> > > that the above DOUBLE_add could (and should!) be called by the ufunc
> >
On Nov 10, 2007 11:23 AM, David Cournapeau <[EMAIL PROTECTED]> wrote:
>
> This would need some benchmarks, but I have always read that using
> pointer arithmetics should be avoided when speed matters (e.g. *a + n
> * sizeof(*a) compared to a[n]), because it becomes much more difficult
> for the com
On Nov 9, 2007 7:23 PM, David Cournapeau <[EMAIL PROTECTED]> wrote:
> On Nov 10, 2007 1:12 AM, Travis E. Oliphant <[EMAIL PROTECTED]>
> wrote:
> > Hans Meine wrote:
> > > | static void
> > > | DOUBLE_add(char **args, intp *dimensions, intp *steps, void *func)
> > > | {
> > > | register intp i;
19 matches
Mail list logo
