I cd'd out of numpy and site-packages and re-ran the package
tests. both numpy.test() and scipy.test() ran without serious
errors. Some DeprecationWarnings and integrals that are probably
divergent or slowly convergent...
It's looking much more promising. Two gotchas on top of each other -
Maybe the following will also be useful... Recall that I completely
deleted numpy and scipy and reinstalled each from their respective
superpacks, then ran:
>>> import numpy; numpy.__file__
'D:\\Programs\\Python25\\lib\\site-packages\\numpy\\__init__.pyc'
>>> import scipy; scipy.__file__
'D:
Josef (sorry about spelling your name wrong in a previous post),
Thanks for the continued suggestions. I deleted the site-packages:
numpy and scipy, and reinstalled each using the current release
superpacks (numpy first, then scipy).
then I ran:
python -c 'import numpy; numpy.test()'
and got
running "python -c 'import scipy; scipy.test()' "
finding one of the earliest errors referencing a bad_path, I found
scipy's INSTALL.txt, paragraph 5, under the TROUBLESHOOTING says to
"cd scipy/Lib/linalg" so you can run:
'python setup_atlas_version.py build_ext --inplace --force'
[ setup_atlas
oadTestsFromName
That was with nose-0.10.3-py2.5. I upgrades to the latest
nose-0.10.4-py2.5, but it still produced an armload of (what look
like the same) errors.
Does this symptomology point to anything (configuration error,
package out of date, ???)
At 10:50 AM 1/3/2009, you wrote:
>On S
vironment
running.
Thanks to all who provided suggestions, particularly David
Cournapeau.
At 01:30 AM 1/3/2009, you wrote:
On Sat, Jan 3, 2009 at 1:07 AM,
Mike Landis wrote:
> Cygwin is present, so not just the dumbed down Windows CMD
available.
>
> I ran the numpy-1.2.1 superpak. Verified that i
Cygwin is present, so not just the dumbed down Windows CMD
available.
I ran the numpy-1.2.1 superpak. Verified that it installed (cause
you don't get near as much output as you do from a shell prompt) by
running:
"python -c 'import numpy; print numpy.__version__
'"
and got the numpy version n
This time I included both ATLAS and MKL in the site.cfg file and got
a little further... D:\temp\numpy-1.2.1\site.cfg now looks like:
[atlas]
library_dirs = d:\Docs\ATLAS\build\lib
atlas_libs = lapack, f77blas, cblas, atlas
[mkl]
include_dirs = D:\Programs\Intel\MKL\10.1.0.018\include
library_d
n Jan 2, 2009, at 11:26 PM, Mike Landis wrote:
>
> > Have to use Pyton 2.5 because I'm also using web2py. Python 2.5 and
> > a bunch of packages that depend on it are already installed.
> >
> > At 11:05 PM 1/2/2009, you wrote:
> >> Is there any reason why
Have to use Pyton 2.5 because I'm also using web2py. Python 2.5 and
a bunch of packages that depend on it are already installed.
At 11:05 PM 1/2/2009, you wrote:
> >
>
>Is there any reason why you can not use the numpy-1.2.1-win32-
>superpack-python2.4.exe
>from the
>http://sourceforge.net/proj
Maybe the reason I'm having trouble is that I'm trying to get it
working on Windows, when almost everyone else is running on Linux? I
have cygwin with f77, g++, make, ... installed, but it's definitely
not a Linux machine. I'm working from the windows install
documentation page. Maybe there
d blas_mkl_info and help python find
ptf77blas, ptcblas, atlas, f77blas, cblas, and blas?
At 01:43 PM 1/2/2009, you wrote:
On Sat, Jan 3, 2009 at 3:29 AM,
Mike Landis wrote:
> Some of the install instructions are kind of ambiguous.
>
> When a library name ends in .a or .dll, it's obv
u wrote:
On Sat, Jan 3, 2009 at 3:29 AM,
Mike Landis wrote:
> Some of the install instructions are kind of ambiguous.
>
> When a library name ends in .a or .dll, it's obvious what it is,
but
> 'library' is sometimes used generically without indicating
whether
> you
Some of the install instructions are kind of ambiguous.
When a library name ends in .a or .dll, it's obvious what it is, but
'library' is sometimes used generically without indicating whether
you're talking about static or dynamic, e.g. how does numpy/scipy
link to MKL? Is it statically or dyn
14 matches
Mail list logo
