Re: [Numpy-discussion] Documentation: objects.inv ?
Thu, 29 Jan 2009 00:28:46 -0500, Pierre GM wrote: Is there an objects.inv lying around for the numpy reference guide, or should I start one from scratch ? It's automatically generated by Sphinx, and can be found at http://docs.scipy.org/doc/numpy/objects.inv Let's make the promise that it shall be found there in the future, too. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation: objects.inv ?
On Jan 29, 2009, at 3:17 AM, Pauli Virtanen wrote: Thu, 29 Jan 2009 00:28:46 -0500, Pierre GM wrote: Is there an objects.inv lying around for the numpy reference guide, or should I start one from scratch ? It's automatically generated by Sphinx, and can be found at http://docs.scipy.org/doc/numpy/objects.inv Let's make the promise that it shall be found there in the future, too. Got it, thanks a lot. Pauli, how often is the documentation on docs.scipy.org updated from SVN ? Thx again P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation: objects.inv ?
2009/1/29 Pierre GM pgmdevl...@gmail.com: Pauli, how often is the documentation on docs.scipy.org updated from SVN ? My understanding is the following: SVN - doc-wiki - updated once daily at around 10:00 (UTC?). doc-wiki - SVN - infrequently, when someone applies one or more doc patches produced from the doc-wiki to SVN. Documentation on docs.scipy.org - infrequently, when someone builds the docs and posts them. Cheers, Scott ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] porting NumPy to Python 3
Hi, I am interested in contributing to the port of NumPy to Python 3. Who I should coordinate effort with? I have started at the Python end of the problem (as opposed to http://www.scipy.org/Python3k), e.g. I have several patches to get 2to3 to work on NumPy's Python source code. James. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Ironclad 0.8 released
Hi all I'm delighted to announce the release of Ironclad v0.8 -- the all-singing, all-dancing CPython API compatibility layer for IronPython -- available now from http://code.google.com/p/ironclad/ . Notable improvements over the last release include: * Ironclad is now a neatly self-contained package -- just copy to your site-packages and 'import ironclad'. * No more silly requirement to call ironclad.shutdown() when you're finished. * A few performance improvements. * Over 900 NumPy tests now pass: in fact, almost all the tests from the core, fft, lib, linalg, ma, oldnumeric and random subpackages. * Over half the .pyds distributed with CPython 2.5 now import cleanly; some of them appear to actually work, including _hashlib and _elementtree. Ironclad grows more stable and mature with every release, and I urge IronPython users to try it out and share their impressions: feedback, whether positive or negative, is always welcomed. Cheers William ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A buildbot farm with shell access - for free ?
David Cournapeau wrote: It is said in the email that this is reserved to the python project, and prominent python projects like Twisted and Django. Would it be ok to try to be qualified as a prominent python project as well ? Give it some time. Nobody - not even the Python core devs - have access to the machines. It's going to take at least several weeks to get the infrastructure running and to establish a policy. From my perspective NumPy and Sage both count as prominent Python projects. Heck, you are in competition with tools like Matlab and you ain't looking bad! Furthermore you could make better use of the machines than Django because you are using way more C extensions and esoteric libraries. I recommend you subscribe to the snakebite list and bring up your interest. You got my +1 already. For now the list is snakebite-l...@googlegroups.com but it will move to another server (probably Python.org) eventually. Christian ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
OK, some progress here. I have two questions: 1) Let's forget about the Intel compiler(s) for the moment and focus on a standard Windows build. Python 2.6 comes with two classes in distutils: msvccompiler.py and msvc9compiler.py. In reading through these, it appears msvc9compiler.py is ideally suited for what I'm trying to do (use VS 2008 tools). Is it possible to select this via command line flags with config --compiler=xxx? Choosing msvc *seems* to go for msvccompiler.py (I'm just tyring to trace the magic as things build). 2) when using the standard msvc setup, things do seem to work re: setting up the build environemnt (see below). Now, the VS compiler kicks out a syntax error (output copied below). Any thoughts? This looks like a peculiarity of the VS compiler but I'm not sure. (I tend to prefer the Intel C compiler because it is more Linux-like and seems to be happier with cross-platform code.) Thanks, ~Mike C. --- [copying output edited for bevity] running build_ext No module named msvccompiler in numpy.distutils; trying from distutils customize MSVCCompiler customize MSVCCompiler using build_ext building 'numpy.core.multiarray' extension compiling C sources creating build\temp.win-amd64-2.6 creating build\temp.win-amd64-2.6\Release creating build\temp.win-amd64-2.6\Release\numpy creating build\temp.win-amd64-2.6\Release\numpy\core creating build\temp.win-amd64-2.6\Release\numpy\core\src C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c /nolog o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src -Inumpy\cor e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -Inumpy\core\src -I numpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcnumpy\core\src\mult iarraymodule.c /Fobuild\temp.win-amd64-2.6\Release\numpy\core\src\multiarraymodu le.obj C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe /DLL /n ologo /INCREMENTAL:NO /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd 64 /EXPORT:initmultiarray build\temp.win-amd64-2.6\Release\numpy\core\src\multia rraymodule.obj /OUT:build\lib.win-amd64-2.6\numpy\core\multiarray.pyd /IMPLIB:bu ild\temp.win-amd64-2.6\Release\numpy\core\src\multiarray.lib /MANIFESTFILE:build \temp.win-amd64-2.6\Release\numpy\core\src\multiarray.pyd.manifest mt.exe -nologo -manifest build\temp.win-amd64-2.6\Release\numpy\core\src\multiar ray.pyd.manifest -outputresource:build\lib.win-amd64-2.6\numpy\core\multiarray.p yd;2 building 'numpy.core.umath' extension compiling C sources creating build\temp.win-amd64-2.6\Release\build creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6 creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c /nolog o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src -Inumpy\cor e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -Inumpy\core\src -I numpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcbuild\src.win-amd64 -2.6\numpy\core\src\umathmodule.c /Fobuild\temp.win-amd64-2.6\Release\build\src. win-amd64-2.6\numpy\core\src\umathmodule.obj umathmodule.c numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type' numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type' numpy\core\src\ufuncobject.c(1704) : warning C4244: '=' : conversion from 'npy_i ntp' to 'int', possible loss of data numpy\core\src\ufuncobject.c(2425) : warning C4244: '=' : conversion from 'npy_i ntp' to 'int', possible loss of data error: Command C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\ cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core \src -Inumpy\core\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -In umpy\core\src -Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC /Tcbui ld\src.win-amd64-2.6\numpy\core\src\umathmodule.c /Fobuild\temp.win-amd64-2.6\Re lease\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj failed with exit s tatus 2 --- On Wed, Jan 28, 2009 at 4:36 PM, David Cournapeau courn...@gmail.comwrote: On Thu, Jan 29, 2009 at 1:18 AM, Michael Colonno mcolo...@gmail.com wrote: I think this is doable; thankfully the Intel compilers on Windows and Linux are very similar in behavior. The problem is that distutils does not abstract this kind of things: you have a CCompiler class, and a subclass Unix C Compiler, and then Intel Compiler. OTOH, the MS compiler is its own class which inherit from CCompiler - all windows specifics are encoded in this class. So I am afraid you will need to recreate all this class implementation for Intel C Compiler, because contrary to the Linux case, nothing is abstracted for windows. As an
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
Michael Colonno wrote: OK, some progress here. I have two questions: 1) Let's forget about the Intel compiler(s) for the moment and focus on a standard Windows build. Python 2.6 comes with two classes in distutils: msvccompiler.py and msvc9compiler.py. In reading through these, it appears msvc9compiler.py is ideally suited for what I'm trying to do (use VS 2008 tools). Is it possible to select this via command line flags with config --compiler=xxx? No - python-distutils normally builds extensions with the same compiler as the one used to build python itself. Which means VS 2008 for python 2.6, VS 2003 .Net for 2.5 (except for 64 bits which uses a variant of VS 2005). You *cannot* build an extension with VS 2008 for a python built with VS 2003, for various fundamental reasons. Any thoughts? This looks like a peculiarity of the VS compiler but I'm not sure. (I tend to prefer the Intel C compiler because it is more Linux-like and seems to be happier with cross-platform code.) Most numpy/scipy developers use gcc compilers on most platforms, so sometimes some things which do not pass with another compiler slip in. It is possible that this is the case here - but I could build numpy with VS 2008 on windows x64 a few weeks ago, so it should only be a relatively small regression. I will look at it, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] convolution axis
The first option doesn't accept complex data. -gideon On Jan 29, 2009, at 1:18 AM, Nadav Horesh wrote: There are at least two options: 1. use convolve1d from numpy.numarray.nd_image (or scipy.ndimage) 2. use scipy.signal.convolve and adjust the dimensions of the convolution kenel to align it along the desired axis. Nadav -הודעה מקורית- מאת: numpy-discussion-boun...@scipy.org בשם Gideon Simpson נשלח: ה 29-ינואר-09 06:59 אל: Discussion of Numerical Python נושא: [Numpy-discussion] convolution axis Is there an easy way to perform convolutions along a particular axis of an array? -gideon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
OK, I think I have a much better understanding of how this all gets
assembled now. I've got the build environment using both Intel compilers
(C++ and Fortran) and linked to the Intel MKL. Using the Intel C compiler
(icl.exe, more gcc-like) as a replacement cl.exe (it supports the same
options, flags, and such thankfully), the build proceeds further, but
eventually kicks out with the syntax / parsing error copied below. Let me
know what you think.
Thanks!
~Mike C.
--
[edited]
building 'numpy.core.umath' extension
compiling C sources
creating build\temp.win-amd64-2.6\Release\build
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core
creating
build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src
C:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\Bin\intel64\icl.exe /c
/nolog
o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
-Inumpy\cor
e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy
-Inumpy\core\src -I
numpy\core\include -IC:\Python26\include -IC:\Python26\PC
/Tcbuild\src.win-amd64
-2.6\numpy\core\src\umathmodule.c
/Fobuild\temp.win-amd64-2.6\Release\build\src.
win-amd64-2.6\numpy\core\src\umathmodule.obj
umathmodule.c
numpy\core\src\umathmodule.c.src(64): error: expected an identifier
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(64): error: expected a )
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(65): error: expected a ;
{
^
numpy\core\src\umathmodule.c.src(84): warning #12: parsing restarts here
after p
revious syntax error
double log1p(double);
^
numpy\core\include\numpy/ufuncobject.h(358): warning #177: function
generate_ov
erflow_error was declared but never referenced
static void generate_overflow_error(void) {
^
compilation aborted for build\src.win-amd64-2.6\numpy\core\src\umathmodule.c
(co
de 2)
error: Command C:\Program Files
(x86)\Intel\Compiler\11.0\061\cpp\Bin\intel64\i
cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG
-Ibuild\src.win-amd64-2.6\numpy\core
\src -Inumpy\core\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy
-In
umpy\core\src -Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC
/Tcbui
ld\src.win-amd64-2.6\numpy\core\src\umathmodule.c
/Fobuild\temp.win-amd64-2.6\Re
lease\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj failed with
exit s
tatus 2
--
On Thu, Jan 29, 2009 at 7:59 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Michael Colonno wrote:
OK, some progress here. I have two questions: 1) Let's forget about
the Intel compiler(s) for the moment and focus on a standard Windows
build. Python 2.6 comes with two classes in distutils: msvccompiler.py
and msvc9compiler.py. In reading through these, it appears
msvc9compiler.py is ideally suited for what I'm trying to do (use VS
2008 tools). Is it possible to select this via command line flags with
config --compiler=xxx?
No - python-distutils normally builds extensions with the same compiler
as the one used to build python itself. Which means VS 2008 for python
2.6, VS 2003 .Net for 2.5 (except for 64 bits which uses a variant of VS
2005). You *cannot* build an extension with VS 2008 for a python built
with VS 2003, for various fundamental reasons.
Any thoughts? This looks like a peculiarity of the VS compiler but
I'm not sure. (I tend to prefer the Intel C compiler because it is
more Linux-like and seems to be happier with cross-platform code.)
Most numpy/scipy developers use gcc compilers on most platforms, so
sometimes some things which do not pass with another compiler slip in.
It is possible that this is the case here - but I could build numpy with
VS 2008 on windows x64 a few weeks ago, so it should only be a
relatively small regression. I will look at it,
David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
numpy\core\src\umathmodule.c.src(64): error: expected an identifier
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(64): error: expected a )
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(65): error: expected a ;
{
^
Perhaps a macro that is replaced? Visual Studio defines min, max as
macros. Maybe it is the same for frexpf? Could you check in the
preprocessed C++ file ? /E to generate it Intel Compiler, I think.
Matthieu
--
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
Not sure if it's a VS thing since I get different compile errors with
either the MS or Intel C compiler under the same environment (Visual Studio
for x64 console). Let me start with a more basic question: I'm using the
package available on SourceForge (1.2.1, 2008-10-29 14:36). If it can be
confirmed this package builds happily via VS 2008 x64 console, can I get a
look at the build log and/or configuration? I should be able to duplicate
this with identical tools (I hope). If it makes a difference I will try to
grab the latest greatest source instead.
Thanks,
~Mike C.
On Thu, Jan 29, 2009 at 8:50 AM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:
numpy\core\src\umathmodule.c.src(64): error: expected an identifier
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(64): error: expected a )
static float frexpf(float x, int * i)
^
numpy\core\src\umathmodule.c.src(65): error: expected a ;
{
^
Perhaps a macro that is replaced? Visual Studio defines min, max as
macros. Maybe it is the same for frexpf? Could you check in the
preprocessed C++ file ? /E to generate it Intel Compiler, I think.
Matthieu
--
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
On Fri, Jan 30, 2009 at 2:43 AM, Michael Colonno mcolo...@gmail.com wrote: Not sure if it's a VS thing since I get different compile errors with either the MS or Intel C compiler under the same environment (Visual Studio for x64 console). Let me start with a more basic question: I'm using the package available on SourceForge (1.2.1, 2008-10-29 14:36). If it can be confirmed this package builds happily via VS 2008 x64 console, can I get a look at the build log and/or configuration? I should be able to duplicate this with identical tools (I hope). If it makes a difference I will try to grab the latest greatest source instead. Oh, you should forget about 1.2.1 for windows x64. A lot of fixes have been applied since then, and in any case, I won't try to fix 1.2.1 build problems. You should definitely use svn if you care about windows x64 - I hope 1.3.0 will be fully supported on that platform. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ironclad 0.8 released
Hello William, * A few performance improvements. * Over 900 NumPy tests now pass: in fact, almost all the tests from the core, fft, lib, linalg, ma, oldnumeric and random subpackages. I have some questions here for the science interested. I hope that they are not too specific: * Can you also use scipy with IronClad/ResolverOne (RO)? * Can you recognize arrays with datetime objects in RO? * How is datetime information handled in RO? * What about rpy? If all the above were working in RO, it would be terrific! Ironclad grows more stable and mature with every release, and I urge IronPython users to try it out and share their impressions: feedback, whether positive or negative, is always welcomed. You may find some information here: http://groups.google.com/group/python-excel/msg/eb349c229696c7f7 I would also recommend this nice straightforward video http://www.resolversystems.com/screencasts/numpy/ Kind regards, Timmie ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
OK, I'm on the cusp of success now. I updated to the most recent code and
get to a sequence of errors surround math functions. This must be due to
linking the MKL libs. I tried various combinations (including those
recommended by the MKL docs) but could not get around the errors. Looks like
a missing header file(?) In any event, I hope this can be fixed by getting
the right into in site.cfg. Currently I have:
[mkl]
include_dirs = C:\Program Files
(x86)\Intel\Compiler\11.0\061\cpp\mkl\include
library_dirs = C:\Program Files
(x86)\Intel\Compiler\11.0\061\cpp\mkl\em64t\lib
mkl_libs = mkl_em64t, mkl_dll, mkl_core# various combinations of other
tried...
lapack_libs = mkl_lapack
Below is the relevant portion of the output. During config the libraries
check in as FOUND so I'm pretty sure the paths above are good.
Thanks,
~Mike C.
---
[edited]
numpy\core\src\umath_funcs.inc.src(557): warning #266: function sinhl
declared
implicitly
shr = sinhl(xr);
^
numpy\core\src\umath_funcs.inc.src(558): warning #266: function coshl
declared
implicitly
chr = coshl(xr);
^
numpy\core\src\umath_loops.inc.src(913): warning #266: function floorl
declare
d implicitly
*((longdouble *)op1) = floorl(in1/in2);
^
numpy\core\src\umath_loops.inc.src(923): warning #266: function fmodl
declared
implicitly
const longdouble res = fmodl(in1,in2);
^
numpy\core\src\umath_loops.inc.src(1003): warning #266: function modfl
declare
d implicitly
*((longdouble *)op1) = modfl(in1, (longdouble *)op2);
^
numpy\core\src\umath_loops.inc.src(1207): warning #266: function fabsf
declare
d implicitly
if (fabsf(in1i) = fabsf(in1r)) {
^
numpy\core\src\umath_loops.inc.src(1110): warning #266: function floorl
declar
ed implicitly
((longdouble *)op1)[0] = floorl((in1r*in2r + in1i*in2i)/d);
^
numpy\core\src\umath_loops.inc.src(1207): warning #266: function fabsl
declare
d implicitly
if (fabsl(in1i) = fabsl(in1r)) {
^
numpy\core\src\umath_loops.inc.src(1246): warning #266: function sqrtl
declare
d implicitly
*((longdouble *)op1) = sqrtl(in1r*in1r + in1i*in1i);
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(244):
error
: identifier acosl is undefined
arccos_data[2] = (void *) acosl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(253):
error
: identifier acoshf is undefined
arccosh_data[0] = (void *) acoshf;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(257):
error
: identifier acoshl is undefined
arccosh_data[2] = (void *) acoshl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(270):
error
: identifier asinl is undefined
arcsin_data[2] = (void *) asinl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(279):
error
: identifier asinhf is undefined
arcsinh_data[0] = (void *) asinhf;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(283):
error
: identifier asinhl is undefined
arcsinh_data[2] = (void *) asinhl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(296):
error
: identifier atanl is undefined
arctan_data[2] = (void *) atanl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(309):
error
: identifier atan2l is undefined
arctan2_data[2] = (void *) atan2l;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(312):
error
: identifier atanhf is undefined
arctanh_data[0] = (void *) atanhf;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(316):
error
: identifier atanhl is undefined
arctanh_data[2] = (void *) atanhl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(335):
error
: identifier ceill is undefined
ceil_data[2] = (void *) ceill;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(343):
error
: identifier cosl is undefined
cos_data[2] = (void *) cosl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(356):
error
: identifier coshl is undefined
cosh_data[2] = (void *) coshl;
^
build\src.win-amd64-2.6\numpy\core\include/numpy/__umath_generated.c(385):
error
: identifier expl is undefined
exp_data[2] = (void *) expl;
Re: [Numpy-discussion] Ironclad 0.8 released
Hello William, once again. I just noticed that Resolver One can only import data from Excel. In science, the common low level data exchange format is ASCII text like: CSV or tab separated. You may consider adding this. I did not find any installation instructions contained in the docs for the IronClad binaries. Where am I to put the files? Can Resolver One also recognize the python installation which is already installed on the system? Thanks in advance for answering! Kind regards, Timmie ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
This is the first failure in the build log: _configtest.c _configtest.c(1): catastrophic error: could not open source file inttypes.h #include inttypes.h ^ compilation aborted for _configtest.c (code 4) failure. I don't have this file anywhere on my system; it appears to be a gcc header file. Any suggestions? Thanks, ~Mike C. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ironclad 0.8 released
Hi Tim Thank you for your interest! To answer your various questions order of approximately increasing complexity: Most importantly: the currently available version of Resolver One does not have numpy support built in, and for various reasons I wouldn't advise trying to integrate Ironclad with v1.3; please wait for 1.4 :-). I just downloaded R and rpy2; they don't work with Ironclad at the moment, and I'm not yet sure why. Ironclad shouldn't require any special installation: just copy the ironclad package (containing __init__.py, python25.dll and ironclad.dll) to wherever you normally put packages for IronPython (I personally have my IRONPYTHONPATH pointing to the appropriate subdirectories of a standard Python 2.5 install). Clearly my documentation is currently inadequate; I'll have to work on that for the next release. RO uses .NET DateTime objects by default, but it's perfectly possible to use python datetime objects instead; I can confirm that you can put both those datatypes into numpy arrays. While RO doesn't have an explicit CSV/TSV import option, you should be able to paste data in those formats directly into your worksheets; and, as soon as we have numpy integration out in the wild, you should be able to create ndarrays directly from your data files. Scipy support is coming along surprisingly nicely; I'd sort of forgotten about it until a couple of people asked me about it earlier today, and it turns out -- to my surprise and delight -- that it took very little work to get the SVN head running over 800 of the scipy tests (even if you can't just 'import scipy' without errors). Sadly, a lot of the modules seem to use scipy.sparse, which I can't import... yet ;-). So, we haven't built any scipy support into Resolver One yet, but hopefully we'll be able to do so without too much pain. Finally, I'm glad you like my screencast :-). I hope I haven't missed anything; let me know if I have, or if I can help with anything else. William On 29 Jan 2009, at 23:46, Tim Michelsen wrote: Hello William, * A few performance improvements. * Over 900 NumPy tests now pass: in fact, almost all the tests from the core, fft, lib, linalg, ma, oldnumeric and random subpackages. I have some questions here for the science interested. I hope that they are not too specific: * Can you also use scipy with IronClad/ResolverOne (RO)? * Can you recognize arrays with datetime objects in RO? * How is datetime information handled in RO? * What about rpy? If all the above were working in RO, it would be terrific! Ironclad grows more stable and mature with every release, and I urge IronPython users to try it out and share their impressions: feedback, whether positive or negative, is always welcomed. You may find some information here: http://groups.google.com/group/python-excel/msg/eb349c229696c7f7 I would also recommend this nice straightforward video http://www.resolversystems.com/screencasts/numpy/ Kind regards, Timmie ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building on WinXP 64-bit, Intel Compilers
On Fri, Jan 30, 2009 at 9:41 AM, Michael Colonno mcolo...@gmail.com wrote: This is the first failure in the build log: _configtest.c _configtest.c(1): catastrophic error: could not open source file inttypes.h #include inttypes.h ^ compilation aborted for _configtest.c (code 4) failure. That's strange, because configtest.c means it is a configuration test, and failure just means the tested feature is not available on the platform - it should certainly not stop the build process. Is this with Intel compiler ? I think I remembered having seen some bug either in python or Intel Compiler in the error return code when launching intel compiler in a subprocess. I just checked the last svn version on windows 64: it builds OK with compiler version 15 (either VS 2008 for 64 bits, which I don't have access to, or with the Platform SDK 6.1, which is free). David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
