Reading the tutorial
http://scipy.org/Cookbook/Theoretical_Ecology/Hastings_and_Powell
I've tried to run the provided code.
But compiling the fortran module with the line command given in the
tuto, I've got the following traceback (you can see it with syntax
highlighting at
rex wrote:
This is the 3rd time I have reported this problem and a fix.
There is no need for a fix, this can be done wo touching distutils. See
site.cfg.example, there is a mention at the end.
cheers,
David
___
Numpy-discussion mailing list
rex wrote:
After doing the necessary fix for distutils, svn4774 builds with
gcc, but trying to build with icc with:
python setup.py config --compiler=intel build_clib --compiler=intel build_ext
--compiler=intel install inst.log
fails with:
Running from numpy source directory.
David Huard wrote:
Jarrod and David,
I am reporting a success on FC8, Xeon. Some tests don't pass, but I
don't believe it is related to the build process.
If you did not have tests failing before, then it may be a regression,
so do not hesitate to open a ticket,
cheers,
David
A Friday 08 February 2008, Charles R Harris escrigué:
On Feb 8, 2008 8:58 AM, Francesc Altet [EMAIL PROTECTED] wrote:
A Friday 08 February 2008, Charles R Harris escrigué:
Also, in the context of my work in indexing, and because of the
slowness of the current implementation in NumPy,
A Friday 08 February 2008, Charles R Harris escrigué:
On Feb 8, 2008 10:31 AM, Francesc Altet [EMAIL PROTECTED] wrote:
A Friday 08 February 2008, Francesc Altet escrigué:
A Friday 08 February 2008, Charles R Harris escrigué:
Also, in the context of my work in indexing, and because of
On Feb 9, 2008 6:47 AM, Francesc Altet [EMAIL PROTECTED] wrote:
A Friday 08 February 2008, Charles R Harris escrigué:
On Feb 8, 2008 10:31 AM, Francesc Altet [EMAIL PROTECTED] wrote:
A Friday 08 February 2008, Francesc Altet escrigué:
A Friday 08 February 2008, Charles R Harris
David,
When I try to build numscons-0.3.4 from the tarball, I get:
Traceback (most recent call last):
File setup.py, line 74, in module
import release as R
ImportError: No module named release
Where should the release module be coming from? I've never heard of
it before.
Eric
David
A Saturday 09 February 2008, Charles R Harris escrigué:
Well, for the unicode case it wouldn't be enough by replacing
'char' by 'Py_ArrayUCS4'? Maybe this afternoon I can do some
benchmarking too in this regard.
Looks like that for Numpy. The problem I was thinking about is that
for wide
Eric Firing wrote:
David,
When I try to build numscons-0.3.4 from the tarball, I get:
Traceback (most recent call last):
File setup.py, line 74, in module
import release as R
ImportError: No module named release
Where should the release module be coming from? I've never heard of
On Feb 9, 2008 11:50 AM, Francesc Altet [EMAIL PROTECTED] wrote:
A Saturday 09 February 2008, Charles R Harris escrigué:
Well, for the unicode case it wouldn't be enough by replacing
'char' by 'Py_ArrayUCS4'? Maybe this afternoon I can do some
benchmarking too in this regard.
Looks
On Feb 9, 2008 2:07 PM, Francesc Altet [EMAIL PROTECTED] wrote:
A Saturday 09 February 2008, Charles R Harris escrigué:
So, strncmp1 is not only faster than its C counterpart, but also
the one doing the correct job with NumPy (unicode) strings.
Ah, in that case the current indirect
On Feb 9, 2008 2:29 PM, Francesc Altet [EMAIL PROTECTED] wrote:
Chuck,
One more thing on this. I've been doing some benchmarking with my
opt_memcpy() macro in the quicksort_string function, and I should say
that while it is definitely more efficient than my system memcpy for
small values
On Feb 9, 2008 2:42 PM, Charles R Harris [EMAIL PROTECTED] wrote:
On Feb 9, 2008 2:29 PM, Francesc Altet [EMAIL PROTECTED] wrote:
Chuck,
One more thing on this. I've been doing some benchmarking with my
opt_memcpy() macro in the quicksort_string function, and I should say
that
A Saturday 09 February 2008, Charles R Harris escrigué:
On Feb 9, 2008 2:07 PM, Francesc Altet [EMAIL PROTECTED] wrote:
A Saturday 09 February 2008, Charles R Harris escrigué:
So, strncmp1 is not only faster than its C counterpart, but
also the one doing the correct job with NumPy
Chuck,
One more thing on this. I've been doing some benchmarking with my
opt_memcpy() macro in the quicksort_string function, and I should say
that while it is definitely more efficient than my system memcpy for
small values of n (the number of bytes to copy), this doesn't keep true
for all
A Saturday 09 February 2008, Charles R Harris escrigué:
I'm also thinking that at some point it becomes more efficient to do
a indirect sort followed by take than to move all those big strings
around. But I guess we won't know where that point is until we have
both versions available.
I've
On Feb 9, 2008 3:19 PM, Francesc Altet [EMAIL PROTECTED] wrote:
A Saturday 09 February 2008, Charles R Harris escrigué:
I'm also thinking that at some point it becomes more efficient to do
a indirect sort followed by take than to move all those big strings
around. But I guess we won't know
Question,
The current string compare doesn't work correctly with strings containing
zeros, so I have replaced it in various spots with a working version. I
think this should be added to the array_api to match up with
PyArray_CompareUCS4. However, I notice that that the multiarray_api_order
and
There is some ugly code in _compiled_base.c and what look to be duplicate
functions. Do we really need it?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
20 matches
Mail list logo
