[Numpy-discussion] tensordot and axes argument
Shouldn't the axes argument in tensordot be named axis? L. -- Lorenzo Bolla [EMAIL PROTECTED] http://lorenzobolla.emurse.com/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] scipy build error - ./numpy/distutils/ccompiler.py bug ? - Was (Numpy-discussion Digest, Vol 16, Issue 59 )
Given: AIX 5.3 xlc v8 xlf v10 essl v4.2 Build and installed: numpy 1.0.4 Build and installed: lapack 3.1.1 with CCI and essl support Task: Trying to build scipy 0.6.0 Error: Get the following error which seems to be numpy related: ... ... File /usr/local/lib/python2.5/site-packages/numpy/distutils/ccompiler.py, line 303, in CCompiler_cxx_compiler + cxx.linker_so[2:] TypeError: can only concatenate list (not str) to list ... Current Solution: Changed line 303 in /usr/local/lib/python2.5/site-packages/numpy/distutils/ccompiler.py from: ... cxx.linker_so = [cxx.linker_so[0]] + cxx.compiler_cxx[0] \ + cxx.linker_so[2:] ... to ... cxx.linker_so = [cxx.linker_so[0]] + [cxx.compiler_cxx[0]] \ + cxx.linker_so[2:] ... Is that change OK for the logic ? Must be a bug report opened for that ? BTW: Has somebody build scipy for AIX 5.3 with the xlc xlf compilers ? If yes - Could she/he provide some information regarding the requirements tia Hajo ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Read-only mercurial mirror of numpy trunk available
On Jan 27, 2008 6:57 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: la, 2008-01-19 kello 14:15 +0900, David Cournapeau kirjoitti: Pauli Virtanen wrote: pe, 2008-01-18 kello 18:06 +0900, David Cournapeau kirjoitti: Hi there, I got a mercurial mirror of numpy available. I put some basic info on the wiki http://scipy.org/scipy/numpy/wiki/HgMirror Nice! Don't hesitate to put more info there. Although I would consider myself relatively proficient with bzr, mercurial has some few important differences that I am still not sure to understand (in particular the lack of one branch is one directory concept) I think I don't have edit access to the Trac Wiki... Anyway, it'd be useful to also have either hg or bzr read-only mirror of scipy too! I'd actually like to see these mirrors hosted at some single official place (svn.scipy.org?): If everyone maintains their own SVN mirror, the resulting repositories typically turn out unrelated as far as the SCM programs are concerned (because of different start points, different conversion tools etc.), and one cannot easily pull and merge changes from other people's repositories. hgsvn makes only repository-local svn tags. They go in .hg/localtags, from where they can be copied manually. I don't think hgsvn has an option to put the tags into .hgtags (from where they would be passed on automatically when the repository is cloned). Since tags seem to be handled through plain files in mercurial, would copying localtags into .hgtags work ? It will work by just pasting the contents of localtags to .hgtags and committing. However, this would need to be done periodically and would pollute the history a bit. Better solution is to keep the tags in a Mercurial Queues patch, as I did. See for yourself: http://hg.certik.cz/numpy-hg/ BTW this mirror is much faster for me. You can browse the full history with tags online, you can clone like this: hg clone http://hg.certik.cz/numpy-hg/ It will convert the MQ patch to a regular commit, so you won't see the difference. But I, on the server, will just do: $ hg qpop Patch queue now empty $ hg pull pulling from /home/ondra/scipy/trunk searching for changes no changes found $ hg qpush applying tags.patch Now at: tags.patch Then I'll copy the updated localtags to .hgtags and do: $ hg qrefresh and that's it. No history pollution. If I decide I don't wont't the tags, I just do hg qpop and tags are gone. Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Error during scipy.fftpack._fftpack compilation ( AIX/cc_r)
Given: AIX 5.3 xlc v8 xlf v10 During the build scipy the following error shows up: . building 'scipy.fftpack._fftpack' extension compiling C sources C compiler: cc_r -DNDEBUG -O2 -qmaxmem=-1 ... scipy/fftpack/src/zfftnd_fftpack.c, line 92.5: 1506-046 (S) Syntax error. scipy/fftpack/src/zfftnd_fftpack.c, line 93.5: 1506-046 (S) Syntax error. scipy/fftpack/src/zfftnd_fftpack.c, line 115.13: 1506-046 (S) Syntax error. error: Command cc_r -DNDEBUG -O2 -qmaxmem=-1 -Ibuild/src.aix-5.3-2.5 -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include/python2.5 -c scipy/fftpack/src/zfftnd.c -o build/temp.aix-5.3-2.5/scipy/fftpack/src/zfftnd.o failed with exit status 1 The problem comes from C++ comment lines within c-code. The IBM Compiler v8 invoked as cc_r will complain and stop compilation. Solution: 1) Remove C++ comments from source code or 2) add the option -qcpluscmt for the cc_r compiler into the /etc/vac.cfg file or build python with this option. ( -qcpluscmt should be the default for cc_r but it does not afaics ) From xlc ... -qcpluscmt | -qnocpluscmt Permits the usage of // to introduce a comment that lasts until the end of the current source line, as in C++. The default is -qcpluscmt when you invoke the compiler with xlc, xlc_r, cc, or cc_r, or when -qlanglvl is set to stdc99 or extc99. Otherwise, the default setting is -qnocpluscmt. regards Hajo BTW: Is there any way to add C-compiler options to the scipy build process. I could figure this out for the fortran compiler but for the c compiler i did not. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] /usr/bin/xlf: 1501-210 command option NO_ATLAS_INFO=1 contains an incorrect subargument
Given: scipy-0.6.4 numpy 1.0.4 python 2.5.1 AIX 5.3 xlc v8 xlf v10 essel 4.2 lapack 3.1.1 with CCI Problem: During the scipy build - python setyp.py build - the following error shows up: building 'scipy.lib.blas.fblas' extension compiling C sources C compiler: cc_r -DNDEBUG -O2 -qmaxmem=-1 compile options: '-DNO_ATLAS_INFO=1 -Ibuild/src.aix-5.3-2.5 -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include/python2.5 -c' compiling Fortran sources Fortran f77 compiler: /usr/bin/xlf -qextname -O5 Fortran f90 compiler: /usr/bin/xlf90 -qextname -O5 Fortran fix compiler: /usr/bin/xlf90 -qfixed -qextname -O5 compile options: '-DNO_ATLAS_INFO=1 -Ibuild/src.aix-5.3-2.5 -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include/python2.5 -c' xlf:f77: build/src.aix-5.3-2.5/build/src.aix-5.3-2.5/scipy/lib/blas/fblas-f2pywrappers.f /usr/bin/xlf: 1501-210 command option NO_ATLAS_INFO=1 contains an incorrect subargument /usr/bin/xlf: 1501-210 command option NO_ATLAS_INFO=1 contains an incorrect subargument error: Command /usr/bin/xlf -qextname -O5 -DNO_ATLAS_INFO=1 -Ibuild/src.aix-5.3-2.5 -I/usr/local/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include/python2.5 -c -c build/src.aix-5.3-2.5/build/src.aix-5.3-2.5/scipy/lib/blas/fblas-f2pywrappers.f -o build/temp.aix-5.3-2.5/build/src.aix-5.3-2.5/build/src.aix-5.3-2.5/scipy/lib/blas/fblas-f2pywrappers.o failed with exit status 40 I found a reference regarding the IBM XLF compiler running on mac http://projects.scipy.org/pipermail/scipy-user/2004-May/002884.html where Pearu says: ... it turns out that -D/-U options to xlf compiler are not for defining cpp macros... The following information from the xlf Compiler says regarding the -D option : ... -D Specifies whether the compiler compiles fixed source form lines with a D in column 1 or treats them as comments. Please note that in order to pass C-style -D macro definitions to the C preprocessor (e.g. compiling a file that ends with .F) use the -W option. For example: -WF,-DDEFINE_THIS -D is the short form of -qdlines ... -U Makes the compiler case-sensitive to identifier names. By default the compiler interprets all names as if they were lower-case. Solution: Changeing the Command line from : /usr/bin/xlf -qextname -O5 -DNO_ATLAS_INFO=1 ../fblas-f2pywrappers.o to /usr/bin/xlf -qextname -O5 -WF,-DNO_ATLAS_INFO=1 /fblas-f2pywrappers.o allowed the command line to succed without an error. But i do not know if the -WF,DNO_ATLAS_INFO=1 will change the program logic nor where to change ( in case the -WF, is the solution ) this permanently. The only reference i found regarding -DNO_ATLAS_INFO=1 was within the file: ../site-packages/numpy/distutils/system_info.py tia Hajo ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] tensordot and axes argument
On Jan 28, 2008 3:17 AM, lorenzo bolla [EMAIL PROTECTED] wrote: Shouldn't the axes argument in tensordot be named axis? Axes is the plural of axis. Because tensordot sums over lists of axes, axes is the best word. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] preparing for 1.0.5 release
Hello, I am pushing back the NumPy 1.0.5 release by at least 1 week (http://projects.scipy.org/scipy/numpy/milestone/1.0.5). After speaking with Travis O., we would like to see the following branches merged this week: http://projects.scipy.org/scipy/numpy/browser/branches/maskedarray http://projects.scipy.org/scipy/numpy/browser/branches/build_with_scons/ Once these merges occur we would like to wait at least 1 week, before branching for the 1.0.5 release. This will give us an opportunity to see much wider testing of this work before making the new release. Please let me know if there is any reason that we should delay merging these two branches. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] major bug in fromstring, ascii mode
On Jan 28, 2008 4:09 PM, Eric Firing [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
Reading the code in arraytypes.inc.src and multiarraymodule.c, it
appears that numpy is using strtol(str, tailptr, 0) for the string
to
integer conversion. Calling strtol with BASE == 0 enables the
automatic
base detection from the prefix.
However, as you say, scanf does not do this. Numpy appears to use
fscanf
when reading data from files, so there is a discrepancy here:
from numpy import fromfile, fromstring
f = open('test.dat', 'w')
f.write(20:09:21)
f.close()
fromfile('test.dat', dtype=int, sep=':')
array([20, 9, 21])
fromstring('20:09:21', dtype=int, sep=':')
array([20, 0])
I vote for fromstring working like fromfile.
I agree. Can we get this change into 1.05? I could make a patch if
that would help. Although I was wrong in calling this a major bug, I
think it is an inconsistency that should be removed. The fromfile and
fromstring docstrings could also state explicitly what the behavior is.
Your best bet is to file a ticket. I you don't, I will, but I'll wait a bit.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] major bug in fromstring, ascii mode
Charles R Harris wrote:
On Jan 28, 2008 4:09 PM, Eric Firing [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
Reading the code in arraytypes.inc.src and multiarraymodule.c, it
appears that numpy is using strtol(str, tailptr, 0) for the
string to
integer conversion. Calling strtol with BASE == 0 enables the
automatic
base detection from the prefix.
However, as you say, scanf does not do this. Numpy appears to
use fscanf
when reading data from files, so there is a discrepancy here:
from numpy import fromfile, fromstring
f = open('test.dat', 'w')
f.write(20:09:21)
f.close()
fromfile('test.dat', dtype=int, sep=':')
array([20, 9, 21])
fromstring('20:09:21', dtype=int, sep=':')
array([20, 0])
I vote for fromstring working like fromfile.
I agree. Can we get this change into 1.05? I could make a patch if
that would help. Although I was wrong in calling this a major bug, I
think it is an inconsistency that should be removed. The fromfile and
fromstring docstrings could also state explicitly what the behavior is.
Your best bet is to file a ticket. I you don't, I will, but I'll wait a bit.
It is ticket #650.
Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Read-only mercurial mirror of numpy trunk available
Ondrej Certik wrote: On Jan 27, 2008 6:57 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: la, 2008-01-19 kello 14:15 +0900, David Cournapeau kirjoitti: Pauli Virtanen wrote: pe, 2008-01-18 kello 18:06 +0900, David Cournapeau kirjoitti: Hi there, I got a mercurial mirror of numpy available. I put some basic info on the wiki http://scipy.org/scipy/numpy/wiki/HgMirror Nice! Don't hesitate to put more info there. Although I would consider myself relatively proficient with bzr, mercurial has some few important differences that I am still not sure to understand (in particular the lack of one branch is one directory concept) I think I don't have edit access to the Trac Wiki... Anyway, it'd be useful to also have either hg or bzr read-only mirror of scipy too! I'd actually like to see these mirrors hosted at some single official place (svn.scipy.org?): If everyone maintains their own SVN mirror, the resulting repositories typically turn out unrelated as far as the SCM programs are concerned (because of different start points, different conversion tools etc.), and one cannot easily pull and merge changes from other people's repositories. hgsvn makes only repository-local svn tags. They go in .hg/localtags, from where they can be copied manually. I don't think hgsvn has an option to put the tags into .hgtags (from where they would be passed on automatically when the repository is cloned). Since tags seem to be handled through plain files in mercurial, would copying localtags into .hgtags work ? It will work by just pasting the contents of localtags to .hgtags and committing. However, this would need to be done periodically and would pollute the history a bit. Better solution is to keep the tags in a Mercurial Queues patch, as I did. Good. As I said, I know bzr much better than hg, and I did the mirror to get something started (and get used to hg, too). Since you know hg, it is better than you maintain this for a while for people to try it out. See for yourself: http://hg.certik.cz/numpy-hg/ BTW this mirror is much faster for me. Not surprising: my mirror is pure http (static-http as hg puts it), I can only upload files to it, meaning that I cannot launch any hg server. Same for bzr, by the way. thanks for doing this, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
