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

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

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.

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.

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

[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

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.

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

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