Mailman 3 April 2007 - NumPy-Discussion

cannot compile under centos 5 after weekend svn update
by Gennan Chen 30 Apr '07

30 Apr '07

Hi! All, I cannot compile numpy anymore after last weekend's update. Anyone know what's wrong?? [gnchen@cortechs25:numpy]$ python setup.py config Running from numpy source directory. F2PY Version 2_3730 blas_opt_info: blas_mkl_info: Traceback (most recent call last): File "setup.py", line 89, in ? setup_package() File "setup.py", line 82, in setup_package configuration=configuration ) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/core.py", line 144, in setup config = configuration() File "setup.py", line 48, in configuration config.add_subpackage('numpy') File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 765, in add_subpackage caller_level = 2) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 748, in get_subpackage caller_level = caller_level + 1) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 695, in _get_configuration_from_setup_py config = setup_module.configuration(*args) File "./numpy/setup.py", line 9, in configuration config.add_subpackage('core') File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 765, in add_subpackage caller_level = 2) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 748, in get_subpackage caller_level = caller_level + 1) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ misc_util.py", line 695, in _get_configuration_from_setup_py config = setup_module.configuration(*args) File "numpy/core/setup.py", line 228, in configuration blas_info = get_info('blas_opt',0) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 256, in get_info return cl().get_info(notfound_action) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 399, in get_info self.calc_info() File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 1287, in calc_info blas_mkl_info = get_info('blas_mkl') File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 256, in get_info return cl().get_info(notfound_action) File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 399, in get_info self.calc_info() File "/snap/c02_raid0/other_src/numpy/numpy/distutils/ system_info.py", line 819, in calc_info dict_append(libraries = ['pthread']) TypeError: dict_append() takes exactly 1 non-keyword argument (0 given) Gen-Nan Chen, PhD Chief Scientific Officer Research and Development Group CorTechs Labs Inc (www.cortechs.net) 1020 Prospect St., #304, La Jolla, CA, 92037 Tel: 1-858-459-9703 Fax: 1-858-459-9705 Email: gnchen(a)cortechs.net

1 0

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
by Jeffrey Yasskin 30 Apr '07

30 Apr '07

On 4/28/07, Baptiste Carvello <baptiste13(a)altern.org> wrote: > 2) In the PEP, the concepts are used *inconsistently*. Complex derives from Ring > because the set of complex numbers *is a* ring. Int derives from Complex because > integer are complex numbers (or, alternatively, the set of integers *is included > in* the set of complex numbers). The consistent way could be to make the Complex > class an instance of Ring, not a subclass. Good point. In this structure, isinstance(3, Ring) really means that 3 is a member of some (unspecified) ring, not that 3 isa Ring, but the ambiguity there is probably the root cause of the problem with mixed-mode operations. We should also say that isinstance(3, Complex) means that 3 is a member of some subring of the complex numbers, which preserves the claim that Complex is a subtype of Ring. Up to here, things make sense, but because of how ABCs work, we need issubclass(rational, Complex). I suppose that's true too, since isinstance(3.4, rational) means "3.4 is a member of the rational subring of the complex numbers", which implies that "3.4 is a member of some subring of the complex numbers." There may be better names for these concepts. Perhaps suffixing every numeric ABC with "Element"? Do you have suggestions? Jason Orendorff points out that Haskell typeclasses capture the fact that complex is an instance of Ring. I think imitating them as much as possible would indeed imply making the numeric ABCs into metaclasses (in Haskell terminology, "kinds"). To tell if the arguments to a function were in the same total order, you'd check if they had any common superclasses that were themselves instances of TotallyOrdered. I don't know enough about how metaclasses are typically used to know how that would conflict. -- Namasté, Jeffrey Yasskin

6 10

arctan2 with complex args
by lorenzo bolla 30 Apr '07

30 Apr '07

Weird behaviour with arctan2(complex,complex). Take a look at this: In [11]: numpy.arctan2(1.,1.) Out[11]: 0.785398163397 In [12]: numpy.arctan2(1j,1j) --------------------------------------------------------------------------- exceptions.AttributeError Traceback (most recent call last) AttributeError: 'complex' object has no attribute 'arctan2' same error for: In [13]: numpy.arctan2(1j,1.) In [14]: numpy.arctan2(1.,1j) But arctan2 is defined for complex arguments, as far as Octave knows :-) : octave:7> atan2(1,1) ans = 0.78540 octave:8> atan2(1j,1j) ans = 0 octave:9> atan2(1j,1) ans = 0 octave:10> atan2(1,1j) ans = 1.5708 bug or wanted behaviour? Lorenzo.

4 12

can't import repmat from numpy
by dmitrey 30 Apr '07

30 Apr '07

What's wrong? start python shell; from numpy import sin => all ok from numpy import repmat => Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: cannot import name repmat D.

4 4

bug in http://www.scipy.org/NumPy_for_Matlab_Users
by dmitrey 30 Apr '07

30 Apr '07

now there is MATLAB NDArray Matrix size(a,n) a.shape[n] a.shape[n] but it should be size(a,n) a.shape[n-1] a.shape[n-1] WBR, D.

6 7

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
by Jeffrey Yasskin 29 Apr '07

29 Apr '07

Thanks for the comments! On 4/26/07, Travis E. Oliphant <oliphant.travis(a)ieee.org> wrote: > > Forgive my ignorance, but I'm not really sure what this PEP is trying to > do. I don't want to sound negative, I really just don't understand the > purpose. I've just never encountered a problem this that I can see how > this PEP will help me solve. It's trying to do the same thing for numbers as Guido is doing for collections in PEP 3119: let people make the useful distinctions between them for whatever purposes people need to make distinctions. It looks like the community is a lot more comfortable with overloading than static typing, so some of the distinctions I proposed are probably too fine. > That doesn't mean it's not worthwhile, I just don't understand it. > > > > > Abstract > > ======== > > > > This proposal defines a hierarchy of Abstract Base Classes (ABCs) > > [#pep3119] to represent numbers and other algebraic entities similar > > to numbers. It proposes: > > > > * A hierarchy of algebraic concepts, including monoids, groups, rings, > > and fields with successively more operators and constraints on their > > operators. This will be added as a new library module named > > "algebra". > > > > The SAGE people may be interested in this, but I doubt there will more > than a handful of users of these algebraic base classes. I expected that if someone overloads a function between integers and rationals, the numeric people would be happier if the integer overload triggered for square matrices as well, in which case we'd want to encourage people to overload on Ring vs Field instead of Integral vs FractionalReal. You'd know better whether that's actually true. If not, I guess I'd better stop claiming that they'll be useful for the numpy people. :) > > * A hierarchy of specifically numeric types, which can be converted to > > and from the native Python types. This will be added as a new > > library module named "numbers". > > > > I could see having a hierarchy of "numbers" we have one in NumPy. All > the NumPy array scalars fall under a hierarchy of types so that it is > easy to check whether or not you have signed or unsigned integers, or > inexact numbers. > > > Object oriented systems have a general problem in constraining > > functions that take two arguments. To take addition as an example, > > ``int(3) + int(4)`` is defined, and ``vector(1,2,3) + vector(3,4,5)`` > > is defined, but ``int(3) + vector(3,4,5)`` doesn't make much sense. > > In NumPy, this kind of operation makes sense we just broadcast int(3) to > the equivalent vector(3,3,3) and do the element-by-element operation. > > This is how most array packages outside of Python do it as well. Oops; I found a bad example. Does vector(3,3,3) + matrix([4,5],[6,7]) work? Are there other good examples of the addition having to be from the "same" group? > I think adding the abstract base-classes for "algebras" is more > complicated than has been discussed if you are going to start treating > arrays as elements in their own algebra. There is a lot of flexibility > in how arrays can be viewed in an algebraic context. Really? Since the operators work element-wise, I would think that a numpy array would have exactly the same algebraic structure as its elements. One could wrap an array to put it into a particular algebraic context, but the array itself seems pretty simple. > The author gives a valiant go at defining base classes for generic > algebras, but I didn't see everything I've encountered in my travels > through algebra, and I don't understand the motivation for trying to > include these things in Python specifically. > > Therefore, I would stick with defining a hierarchy of numbers and leave > it at that for now (if I even went that far). > > For numbers, several suggestions have been offered. In NumPy we use > abstract base classes that look like this > > Number > Integer > SignedInteger > UnsignedInteger > Inexact > Floating > ComplexFloating > > But, this is because the array scalars in NumPy are based on > C-data-types and not on general-purpose integers or floats. In NumPy it > is useful to check if you have an integer-typed array and so the > base-classes become useful. Do you have an example of when you'd want to check for an integer-typed array? At one point, Guido was asking for reasons to include Cardinal (aka Natural, aka Unsigned) in the hierarchy. Is UnsignedInteger only present in NumPy because it describes some native C types, or does it have some other purpose? > For general purpose Python, I would do something like > > Complex > Rational_Complex > Integer_Complex > Floating_Complex # uses hardware float > Decimal_Complex > Real > Rational > Integer > Floating # uses hardware float > Decimal Are you specifying an abstract Floating type to incorporate both floats and doubles? Glancing over the Decimal spec, and trying a few things with the implementation, it looks like Decimal objects have a specific precision for each thread, which can be changed for future operations at any time. Is there still a reason to separate Floating and Decimal, or will a modification of FloatingReal suffice? Thanks again, Jeffrey

1 0

Re: [Numpy-discussion] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
by Dan Christensen 29 Apr '07

29 Apr '07

[sage list added] "Travis E. Oliphant" <oliphant.travis(a)ieee.org> writes: > The SAGE people may be interested in this, but I doubt there will more > than a handful of users of these algebraic base classes. SAGE has quite a sophisticated type hierarchy, and a sophisticated set of coercion methods. What is done in SAGE should definitely be consulted, since it is probably the most complex set of mathematical types yet written in python. The SAGE tutorial is at http://www.sagemath.org/doc/html/tut/tut.html and Section 2.2 gives a brief introduction to numbers: http://www.sagemath.org/doc/html/tut/node9.html The SAGE reference manual is at http://www.sagemath.org/doc/html/ref/index.html Chapter 20: http://www.sagemath.org/doc/html/ref/node198.html and nearby chapters are quite relevant for this discussion. > For general purpose Python, I would do something like > > Complex > Rational_Complex > Integer_Complex > Floating_Complex # uses hardware float > Decimal_Complex > Real > Rational > Integer > Floating # uses hardware float > Decimal Note also that double-precision reals are a subset of the rationals, since each double precision real is exactly representable as a rational number, but many rational numbers are not exactly representable as double precision reals. Not sure if this means that reals should be a subclass of the rationals. I believe that in SAGE these relationships aren't expressed using subclassing. Dan

7 10

Building numpy - setting the run path
by Peter C. Norton 28 Apr '07

28 Apr '07

Building numpy for my company's solaris distribution involves requring a run_path for the lapack+blas libraries we're using (libsunperf, though I'm considering swapping out for gsl since we may use that). The situation we're in is that we need gcc to get the -R for paths like /usr/local/gnu/lib /usr/local/python2.5.1/lib, etc. but the default python distutils raise a not implemented exception on this. Since it doesn't appear that the numpy distutils subclass the ccompiler, my solution is this for now (in numpy/distutils/ccomiler): def gen_lib_options(compiler, library_dirs, runtime_library_dirs, libraries): r = _distutils_gen_lib_options(compiler, library_dirs, [], libraries) if len(runtime_library_dirs) > 0: r.extend([ "-R%s" % lib for lib in runtime_library_dirs ]) lib_opts = [] for i in r: if is_sequence(i): lib_opts.extend(list(i)) else: lib_opts.append(i) return lib_opts This allows me to specify -R options on the command line with build_ext without destroying the build. I'm pretty sure that "-R" should be replaced with a lookup somewhere for the platform-appropriate way to do this, but this does work. Let me know if there's a better way to do this, but if not can this be incorporated into numpy's distutils? Thanks, -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.

4 3

fft and roll
by Ross Harder 28 Apr '07

28 Apr '07

Hi, I'm new to Numpy, just bought the guide last week. I've been disappointed by the difficulty I'm having finding functions that are documented in the guide. So far I've had to spend a lot of time tracking down that the fft2 and fftn functions from the fftpack library, which are documented in the numpy guide, are actually in scipy. I've also not been able to find the roll function documented on page 99 of the guide. Did I just buy the guide at a time when it's particularly out of date and there will be an update soon? Ross __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

numpy endian question
by Russell E. Owen 28 Apr '07

28 Apr '07

In converting some code from numarray to numpy I had this: isBigendian = (arr.isbyteswapped() != numarray.isBigEndian) The only numpy version I've come up with is: isBigEndian = (arr.dtype.descr[0][1][0] == '>') which is short but very obscure. Has anyone got a suggestion for a clearer test? I found lots of *almost* useful flags and methods. -- Russell

7 13