numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Konrad H. <hi...@cn...>]

> Could you give a quick explanation why?  I thought the whole point of
> the "extern" specifier was to flag that this variable was defined
> elsewhere.

Right, but with most platforms' shared library systems, this means
"in another source file that is part of the same shared library",
not "in another shared library" or "in the main executable".

> Otherwise, doesn't it imply that the API pointer is
> defined in each file that includes arrayobject.h?
> 
> i.e. shouldn't headers declare "extern double x" for everything except
> the file that actually defines x?

If a dynamically loaded module consists of more than one source file,
then all but one of them (the one which calls import_array()) must
define NO_IMPORT_ARRAY before including arrayobject.h. This is also
the answer to Kevin Rodgers' question.


However, it seems to me that the current arrangement in NumPy has
another serious drawback: it should be impossible to link NumPy
statically with the Python interpreter, due to multiply defined
symbols. And I am rather sure that this was possible many versions
ago, since I used NumPy on a Cray T3E, which does not have shared
libraries.

I checked my own extension modules that export a C API, and they all
declare the API pointer static. This is also what the C API export
section in the "Extending & Embedding" manual recommends. (OK, I admit
that I wrote that section, so that is not a coincidence!)


So perhaps the best solution is to make this static. Client modules
that consist of more than one source code file with PyArray... calls
must then call import_array() once in every such file, or equivalently
pass on the PyArray_API pointer explicitly between the files. That
sounds quite acceptable to me.

BTW, extension modules with more than one source file create a risk of
portability problems in any case, as the symbols shared between the
files must necessarily be global. On platforms such as MacOS, or with
static linking, this means they are global to the interpreter and all
extension modules, with a resulting risk of name clashes.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Konrad H. <hi...@cn...>]

> All I did was insert a
> 
> #define NO_IMPORT_ARRAY

That works only if all symbols are globally visible, which is not true
on most platforms.

Does anyone know how shared libraries work in detail under MacOS X?
Many systems allow the main executable (Python in our case) to choose
what symbols are globally visible. Making changes at this level looks
like the best solution to me, if possible.

A simple solution would be to change line 262 in Numeric/arrayobject.h from

    void **PyArray_API;

to

    static void **PyArray_API;

This would break all client modules that consist of more than one
source code file and make array-related calls in more than the main
file. We have no such modules in the current NumPy, but there might of
course be third-party modules out there that are affected.

Another solution would be to add 

   #define PyArray_API PyArray_API_umath

in module umath just before including arrayobject.h, and add similar
lines to other client modules. But this would require a modification
to all client modules, including third-party modules, to make them
work under MacOS.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] Sparse Arrays

[<vi...@id...>]

I found by looking up through Google that Travis O. has written a
package called SparsePy for manipulating sparse arrays.  However, when
I tried to download it I was asked for a userid and password.  Is this
not yet publicly available?  Are there any other packages for this
that are available?
-- 
Victor S. Miller     | " ... Meanwhile, those of us who can compute can hardly
vi...@id...    | be expected to keep writing papers saying 'I can do the
CCR, Princeton, NJ   | following useless calculation in 2 seconds', and indeed
    08540 USA        | what editor would publish them?"  -- Oliver Atkin

[Numpy-discussion] Cephes Docs

[Charles G W. <cg...@al...>]

Scott Ransom writes:

 > I've had the following done for awhile and hadn't thought to release it
 > for general use.  It is the standard Cephesmodule 1.3 that Travis
 > Oliphant has had available for some time at http://pylab.sourceforge.net
 > with the addition of docstrings for all the functions.  I modified the
 > original documentation a bit and simply converted it to docstrings.


This message brought me a strange sense of deja vu.  A year ago I did
the same thing - I submitted a patch which allowed ufuncs to have
docstrings, for exactly this reason - the function names in Cephes
being a bit cryptic.  I also wrote a silly little script to generate
the Cephes docstrings from the HTML doc.

Please see:

http://lists.sourceforge.net/archives/numpy-discussion/2000-March/000091.html

[Numpy-discussion] Cephes Docs

[Scott R. <ra...@cf...>]

Hi Everyone,

I've had the following done for awhile and hadn't thought to release it
for general use.  It is the standard Cephesmodule 1.3 that Travis
Oliphant has had available for some time at http://pylab.sourceforge.net
with the addition of docstrings for all the functions.  I modified the
original documentation a bit and simply converted it to docstrings.

Simply substitute the new cephesmodule.c file with the one in the Cephes
distro and compile as per usual.  The docstrings have been a huge
beneift for me, as I find the cephes function names a bit cryptic...

You can find the file here:

http://cfa160.harvard.edu/~ransom/cephesmodule.c

Hope it will be useful for some of you as well.

Scott

-- 
Scott M. Ransom                   Address:  Harvard-Smithsonian CfA
Phone:  (617) 495-4142                      60 Garden St.  MS 10 
email:  ra...@cf...              Cambridge, MA  02138
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

[Numpy-discussion] Python 2.1 / Numeric-19.1.0 / kinds

[Paul F. D. <pa...@pf...>]

I haven't been able to get into the SourceForge ftp site all day, it has
maxed out its users. I suspect the Python has become too popular...? Anyway,
Pete's zip isn't there yet.

Pete, could you tell me privately the method you use for making the zips? I
have trouble getting the paths right.

I have what will probably be 19.1.0 in CVS now. I have added a package,
kinds, which is a reference implementation of PEP 0424 for your exploration.
It does not install by default on Unix; you have to edit setup_all.py to
make it do that.
I plan to add a floating 32-bit scalar type to this module before
completion.
Here is the current text of the PEP:

PEP: 242
Title: Numeric Kinds
Version: $Revision: 1.1 $
Author: pa...@pf... (Paul F. Dubois)
Status: Draft
Type: Standards Track
Created: 17-Mar-2001
Python-Version: 2.2
Post-History:


Abstract

    This proposal gives the user optional control over the precision
    and range of numeric computations so that a computation can be
    written once and run anywhere with at least the desired precision
    and range.  It is backward compatible with existing code.  The
    meaning of decimal literals is clarified.


Rationale

    Currently it is impossible in every language except Fortran 90 to
    write a program in a portable way that uses floating point and
    gets roughly the same answer regardless of platform -- or refuses
    to compile if that is not possible.  Python currently has only one
    floating point type, equal to a C double in the C implementation.

    No type exists corresponding to single or quad floats.  It would
    complicate the language to try to introduce such types directly
    and their subsequent use would not be portable.  This proposal is
    similar to the Fortran 90 "kind" solution, adapted to the Python
    environment.  With this facility an entire calculation can be
    switched from one level of precision to another by changing a
    single line.  If the desired precision does not exist on a
    particular machine, the program will fail rather than get the
    wrong answer.  Since coding in this style would involve an early
    call to the routine that will fail, this is the next best thing to
    not compiling.


Supported Kinds of Ints and Floats

    Complex numbers are treated separately below, since Python
    can be built without them.

    Each Python compiler may define as many "kinds" of integer and
    floating point numbers as it likes, except that it must support at
    least two kinds of integer corresponding to the existing int and
    long, and must support at least one kind of floating point number,
    equivalent to the present float.

    The range and precision of the these required kinds are processor
    dependent, as at present, except for the "long integer" kind,
    which can hold an arbitrary integer.

    The built-in functions int(), long(), and float() convert
    inputs to these default kinds as they do at present.  (Note that a
    Unicode string is actually a different "kind" of string and that a
    sufficiently knowledgeable person might be able to expand this PEP
    to cover that case.)

    Within each type (integer, floating) the compiler
    supports a linearly-ordered set of kinds, with the ordering
    determined by the ability to hold numbers of an increased range
    and/or precision.


Kind Objects

    Two new standard functions are defined in a module named
    "kinds".  They return callable objects called kind objects.  Each
    int or floating kind object f has the signature result = f(x), and
    each complex kind object has the signature result = f(x, y=0.).

    int_kind(n)
        For an integer argument n >= 1, return a callable object whose
        result is an integer kind that will hold an integer number in the
        open interval (-10**n,10**n). The kind object
        accepts arguments that are integers including longs.
        If n == 0, returns the kind object corresponding to the Python
        literal 0.

    float_kind(nd, n)
        For nd >= 0 and n >= 1, return a callable object whose result
        is a floating point kind that will hold a floating-point
        number with at least nd digits of precision and a base-10
        exponent in the closed interval [-n, n].  The kind object
        accepts arguments that are integer or float.

        If nd and n are both zero, returns the kind object corresponding
        to the Python literal 0.0.

    The compiler will return a kind object corresponding to the least
    of its available set of kinds for that type that has the desired
    properties.  If no kind with the desired qualities exists in a
    given implementation an OverflowError exception is thrown.  A kind
    function converts its argument to the target kind, but if the
    result does not fit in the target kind's range, an OverflowError
    exception is thrown.

    Besides their callable behavior, kind objects have attributes
    giving the traits of the kind in question.
    1. name is the name of the kind. The standard kinds are called
       int, long, double.
    2. typecode is a single-letter string that would be appropriate
       for use with Numeric or module array to form an array of this
       kind. The standard types' typecodes are 'i', 'O', 'd'
       respectively.
    3. Integer kinds have these additional attributes:
       MAX, equal to the maximum permissible integer of this kind, or
       None for the long kind.
       MIN, equal to the most negative permissible integer of this kind,
       or None for the long kind.
    4. Float kinds have these additional attributes whose properties are
       equal to the corresponding value for the corresponding C type
       in the standard header file "float.h".
       MAX, MIN, DIG, MANT_DIG, EPSILON, MAX_EXP, MAX_10_EXP,
       MIN_EXP, MIN_10_EXP,
       RADIX, ROUNDS (== FLT_RADIX, FLT_ROUNDS in float.h)
       These values are of type integer except for MAX, MIN, and EPSILON,
       which are of the Python floating type to which the kind
       corresponds.


Attributes of Module kinds

    int_kinds is a list of the available integer kinds, sorted from lowest
              to highest kind.
              By definition, int_kinds[-1] is the long kind.

    float_kinds is a list of the available floating point kinds, sorted
                from lowest to highest kind.

    default_int_kind is the kind object corresponding to the Python
                     literal 0

    default_long_kind is the kind object corresponding to the Python
                      literal 0L

    default_float_kind is the kind object corresponding to the Python
                       literal 0.0


Complex Numbers

    If supported, omplex numbers have real and imaginary parts that are
    floating-point numbers with the same kind.  A Python compiler must
    support a complex analog of each floating point kind it supports,
    if it supports complex numbers at all.

    If complex numbers are supported, the following are available in
    module kinds:

    complex_kind(nd, n)
        Return a callable object whose result is a complex kind that
        will hold a complex number each of whose components
        (.real, .imag) is of kind float_kind(nd, n).  The kind object
        will accept one argument that is of any integer, real, or
        complex kind, or two arguments, each integer or real.

    complex_kinds is a list of the available complex kinds, sorted
                  from lowest to highest kind.

    default_complex_kind = is the kind object corresponding to the
                           Python literal 0.0j.
                           The name of this kind is doublecomplex,
                           and its typecode is 'D'.

    Complex kind objects have these addition attributes:
       floatkind is the kind object of the corresponding float type.


Examples

    In module myprecision.py:

        import kinds
        tinyint = kinds.int_kind(1)
        single = kinds.float_kind(6, 90)
        double = kinds.float_kind(15, 300)
        csingle = kinds.complex_kind(6, 90)

    In the rest of my code:

        from myprecision import tinyint, single, double, csingle
        n = tinyint(3)
        x = double(1.e20)
        z = 1.2
        # builtin float gets you the default float kind, properties unknown
        w = x * float(x)
        # but in the following case we know w has kind "double".
        w = x * double(z)

        u = csingle(x + z * 1.0j)
        u2 = csingle(x+z, 1.0)

    Note how that entire code can then be changed to a higher
    precision by changing the arguments in myprecision.py.

    Comment: note that you aren't promised that single != double; but
    you are promised that double(1.e20) will hold a number with 15
    decimal digits of precision and a range up to 10**300 or that the
    float_kind call will fail.


Open Issues

    No open issues have been raised at this time.

Copyright

    This document has been placed in the public domain.

Re: [Numpy-discussion] more on MA not pickling

[Tavis R. <ta...@ca...>]

> Unfortunately, *my* application does this. (:->.
damn, I was hoping you wouldn't say that ;-)

> Maybe MA needs to define some special methods to make
> this work, so that the objects are pickled without these
> attributes and they are restored after being unpickled?
do you mean __getstate__ and __setstate__?

> There may be another solution but it will take more
> effort to develop.
I've got a vague idea for another solution that uses the 
.im_func attribute of methods.  I'll toy with it this 
afternoon and see if I can get it working.

Tavis

Re: [Numpy-discussion] more on MA not pickling

[Tim C. <tc...@op...>]

Tavis Rudd wrote:
> 
> Hi,
> I posted something about this a few weeks ago, but got
> distracted before I had a chance to look into it further
> ...
> Revisions 1.5 and up of activeattr.py in the MA package
> cause a fatal error when pickling is attempted. The pickle
> and cPickle modules don't allow unbound instance methods to
> be pickled and the ActiveAttributes mixin is storing
> attribute handlers, such as ActiveAttribute.basic_get, as
> unbound instance methods.
> 
> Revision 1.4 works fine if basic_get is modified so that
> an AttributeError is raised instead of a KeyError when an
> attribute is not found.
> 
> This bug was introduced in an attempt to allow child
> classes of MA to be able to modify activeattributes. I
> suggest reverting back to rev 1.4 of activeattr with a
> modified basic_get method and forgetting about allowing
> child classes to do this.

Can I add my voice to Tavis' suggestion? The ability to cPickle MA
arrays is absolutely essential. In the health sciences, where some data
are **always** missing, MA is a godsend, but it needs to be able to be
made a persistent godsend.

Cheers,

Tim C

[Numpy-discussion] Win32 19.0.0 for Python-2.1

[Pete S. <pe...@sh...>]

I've built a compiled Numeric-19.0.0 for Python2.1 on Win32.
This should be exactly the same as the other version i built
for Python-2.0, just built with a different python version.

I've put the file up here, hopefully it can soon be moved into
the Numeric sourceforge project.

http://pygame.seul.org/ftp/contrib/Numeric-19.0.0-Python-2.1.zip

[Numpy-discussion] PyArray_API, NO_IMPORT, and NO_IMPORT_ARRAY

[Rodgers, K. <KRo...@ry...>]

I'm working on a project where I'm embedding Python and NumPy (on Win32).
For various reasons, I need to have all of my source files as C++, even
though I'm not using any C++ features (just using it as a "better C").  When
Visual C++ goes to link, I get the following error:

Linking...
vtuav_sim_wrap.obj : error LNK2005: _PyArray_API already defined in
vtuav_sim.obj
vtuav_sim_wrap.obj : warning LNK4006: _PyArray_API already defined in
vtuav_sim.obj; second definition ignored
   Creating library Release/vtuav_simc.lib and object Release/vtuav_simc.exp
Release/vtuav_simc.dll : fatal error LNK1169: one or more multiply defined
symbols found
Error executing link.exe.

The error is caused by the following lines in arrayobject.h:

/* C API address pointer */ 
#if defined(NO_IMPORT) || defined(NO_IMPORT_ARRAY)
extern void **PyArray_API;
#else
void **PyArray_API;
#define NO_PYARRAY_API
#endif

Because I'm including the arrayobject.h header in two different source code
modules, and neither NO_IMPORT or NO_IMPORT_ARRAY are defined, the "else"
clause gets executed, which causes the "multiply defined symbol" error.
This also appears to be the root cause of the problems currently being
discussed on the list about MacOS X.

So, how can this problem be fixed?  I must confess that I don't understand
the code in arrayobject.h that uses PyArray_API. Any ideas?  Thanks in
advance . . .

--
Kevin Rodgers  Northrop Grumman Ryan Aeronautical  kro...@ry...
"This one goes up to eleven." -- Nigel Tufnel

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Johann H. <jo...@ph...>]

Paul F Dubois writes:

> On Tue, 17 Apr 2001, Johann Hibschman wrote:
>> 
>> All I did was insert a
>> 
>> #define NO_IMPORT_ARRAY
>> before the
>> #include "arrayobject.h"
>> in umathmodule.c

> Such a change breaks other platforms... 

Could you give a quick explanation why?  I thought the whole point of
the "extern" specifier was to flag that this variable was defined
elsewhere.  Otherwise, doesn't it imply that the API pointer is
defined in each file that includes arrayobject.h?

i.e. shouldn't headers declare "extern double x" for everything except
the file that actually defines x?

I should go back and read my copy of K&R...

--Johann

-- 
Johann Hibschman                           jo...@ph...

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Paul F. D. <du...@ll...>]

On Tue, 17 Apr 2001, Johann Hibschman wrote:
> Konrad Hinsen writes:
>=20
> > You'd have to declare PyArray_API static in each module, but that
> > won't be easy as some modules consist of more than one C source file.
>=20
>=20
> All I did was insert a
>=20
> #define NO_IMPORT_ARRAY
>=20
> before the
> #include "arrayobject.h"
>=20
> in umathmodule.c
>=20
> I repeated this for all the Packages, and it seems to work just fine.
>=20
> --Johann
>=20
> --=20
> Johann Hibschman                           jo...@ph...
>=20
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/lists/listinfo/numpy-discussion

Such a change breaks other platforms...=20

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Johann H. <jo...@ph...>]

Konrad Hinsen writes:

> You'd have to declare PyArray_API static in each module, but that
> won't be easy as some modules consist of more than one C source file.


All I did was insert a

#define NO_IMPORT_ARRAY

before the
#include "arrayobject.h"

in umathmodule.c

I repeated this for all the Packages, and it seems to work just fine.

--Johann

-- 
Johann Hibschman                           jo...@ph...

[Numpy-discussion] more on MA not pickling

[Tavis R. <ta...@ca...>]

Hi, 
I posted something about this a few weeks ago, but got 
distracted before I had a chance to look into it further
...
Revisions 1.5 and up of activeattr.py in the MA package 
cause a fatal error when pickling is attempted. The pickle 
and cPickle modules don't allow unbound instance methods to 
be pickled and the ActiveAttributes mixin is storing 
attribute handlers, such as ActiveAttribute.basic_get, as 
unbound instance methods.  

Revision 1.4 works fine if basic_get is modified so that 
an AttributeError is raised instead of a KeyError when an 
attribute is not found. 

This bug was introduced in an attempt to allow child 
classes of MA to be able to modify activeattributes. I 
suggest reverting back to rev 1.4 of activeattr with a 
modified basic_get method and forgetting about allowing 
child classes to do this.

Cheers
Tavis

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Konrad H. <hi...@cn...>]

> dyld: python multiple definitions of symbol _PyArray_API
> /usr/local/lib/python2.1/site-packages/Numeric/multiarray.so definition 
> of _PyArray_API
> /usr/local/lib/python2.1/site-packages/Numeric/umath.so definition of 
> _PyArray_API
> 
> At this point, I get returned to the command line (python exits). It
> appears that the dynamic linker mechanism under OS X doesn't like
> symbols with the same name. Anyone have a way around this ?

You'd have to declare PyArray_API static in each module, but that
won't be easy as some modules consist of more than one C source file.

A more complicated solution would be to construct different names
for this variable in different modules using preprocessor tricks
in Numeric/arrayobject.h.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[John A. T. <tu...@bl...>]

>>>>> "TC" == Tim Churches <tc...@op...>:

TC> If anyone can get it to work, some impressions of the performance
TC> available on a G4-based Mac would be welcome. They are reputedly a lot
TC> faster than a Pentium 4 and are much cheaper than an Alpha box, at least
TC> they are here in Australia.

I'd be interested in Athlon performance as well...

-- 
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Tim C. <tc...@op...>]

Tim Lahey wrote:
> I've been trying to get the Numeric-19.0.0 working on Python 2.1b2 under
> OS X.

If anyone can get it to work, some impressions of the performance
available on a G4-based Mac would be welcome. They are reputedly a lot
faster than a Pentium 4 and are much cheaper than an Alpha box, at least
they are here in Australia.

Which begs the question: are there any Numpy benchmarks available to
compare Numpy on different platforms, or to compare Numpy with its
alternatives on the same platform (Numpy would have to be proven a lot
slower for me to change!).

Tim C
Sydney, Australia

[Numpy-discussion] Numeric on OS X - Anyone get it to work ?

[Tim L. <tj...@sy...>]

All,

I've been trying to get the Numeric-19.0.0 working on Python 2.1b2 under 
OS X. I've successfully
install python and have success with most of the modules, but I have 
problems with Numeric. I
can't get it to even load. The following is what I get when I import 
Numeric.

Python 2.1b2 (#1, 04/09/01, 22:37:35)
[GCC Apple DevKit-based CPP 6.0alpha] on darwin1
Type "copyright", "credits" or "license" for more information.
 >>> import Numeric
dyld: python multiple definitions of symbol _PyArray_API
/usr/local/lib/python2.1/site-packages/Numeric/multiarray.so definition 
of _PyArray_API
/usr/local/lib/python2.1/site-packages/Numeric/umath.so definition of 
_PyArray_API

At this point, I get returned to the command line (python exits). It 
appears that the dynamic linker mechanism under OS X doesn't like 
symbols with the same name. Anyone have a way around
this ?

Thanks,

Tim Lahey
tj...@sy...

Re: [Numpy-discussion] bugs

[Warren F. <fo...@sl...>]

224100 was fixed (by a patch that was incorrectly labeled as being for
124100), but now it's broken again.  I'll re-fix it.

Warren Focke

On Fri, 13 Apr 2001, Paul F. Dubois wrote:
> I am approaching a point where I will cut 19.1. I have reduced the number of
> bugs in the bug list to six. Please examine this list and see if there is
> one you could volunteer to fix. Developers, please make fixes directly.
> Users, please post patches rather than sending email.

[Numpy-discussion] ?POOMA and Boost?

[Norman S. (rrdn60) <rr...@em...>]

o How would a Python version of POOMA compare/contrast to Numpy?

POOMA (Parallel Object-Oriented Methods and Applications) a C++ high
performance simulation infrastructure package
 http://www.acl.lanl.gov/pooma/


Would boost add anything advantages to the current Numpy methodology?
 http://www.boost.org/


Thanks,
Norman Shelley

[Numpy-discussion] bugs

[Paul F. D. <pa...@pf...>]

I am approaching a point where I will cut 19.1. I have reduced the number of
bugs in the bug list to six. Please examine this list and see if there is
one you could volunteer to fix. Developers, please make fixes directly.
Users, please post patches rather than sending email.

There are no outstanding patches.

RE: [Numpy-discussion] RandArray initialization and docs

[Paul F. D. <pa...@pf...>]

-----Original Message-----
From: num...@li...
[mailto:num...@li...]On Behalf Of Clay
Spence
Sent: Thursday, April 12, 2001 8:13 AM
To: numpy-discussion
Subject: [Numpy-discussion] RandArray initialization and docs


<snip>

2) The example in the documentation on negative strides in slices is
incorrect, or old.  It says:
>>> a = reshape(arrayrange(9),(3,3))
>>> print a[2:-1, 0]
[6 3 0]

That's not the result I get.  I think two colons were wanted there.

--- Corrected in my sources, thank you. The change will migrate into the
next release of the manual.

[Numpy-discussion] RandArray initialization and docs

[Clay S. <cs...@sa...>]

Hi,

I have occasionally dabbled with numpy in the past, but I'm starting to
use it more heavily now.  I have two (minor, I think) question/comments:

1) RandomArray seems to be initialized from the time.  At least when I
repeatedly execute a script that uses RandomArray.uniform, the first
number generated changes very little from one invocation to another.
For example, with the following file:

---------
# testRA.py
from RandomArray import *
print uniform(-1.0, 1.0)
---------

I get:

--------
cholla 192% python testRA.py
0.434084415436
cholla 193% python testRA.py
0.433970689774
cholla 194% python testRA.py
0.433856964111
cholla 195% python testRA.py
0.433781266212
--------

Is that really desirable behavior?  It is easily fixed in my script; I
just generate one random number first and throw it away.  (I'm running
on a sparc under solaris 2.6.)

2) The example in the documentation on negative strides in slices is
incorrect, or old.  It says:
>>> a = reshape(arrayrange(9),(3,3))
>>> print a[2:-1, 0]
[6 3 0]

That's not the result I get.  I think two colons were wanted there.

Clay

[Numpy-discussion] wavelets

[Tariq R. <ta...@en...>]

I'm about to start work on a wavelets module for python... don't know how
far i want to go yet....

is there an existsing project?

i couldn't find one!

tariq

RE: [Numpy-discussion] redirection?

[John A. T. <tu...@bl...>]

>>>>> "PFD" == Paul F Dubois <du...@us...>:

PFD> It works! Thanks for coming to my aid.

however, that didn't seem to help the http://www.numpy.org/ redirection, as
reported here:

>>>>> "KB" == Karl Bellve <Kar...@um...>:

KB> When you go to www.numpy.org, it tries to redirect you to
KB> www.numpy.org/numeric/ which it can't find...

I've fixed it so it now redirects to http://pfdubois.com/numpy, and seems
to be working

sorry for the delay in updating

-- 
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319