Mailman 3 December 2002 - SciPy-User

`linewidth` and `pointsize` options in gplt
by Nils Wagner Dec. 11, 2002

Dec. 11, 2002

Hi all, Is it possible to use the options `linewidth` and `pointsize` in gplt.plot/gplt.output ? Nils

1 0

Trouble w/ fastumath
by ferrell＠diablotech.com Dec. 10, 2002

Dec. 10, 2002

I'm having trouble with scipy on my windows2k box running Cygwin. I installed the latest version of Numeric (22.0). I then installed the latest Cygwin binaries (SciPy-0.2.0_alpha_145.4426.cygwin_py.tar). By "install" I mean I untarred them into site-packages, as per the web-site installation instructions. Everything seemed to go fine, but when I try to import scipy I get an exception raised when it's it tries to import fastumath. Any suggestions of what I might have done wrong? I looked through the archives and saw a number of messages about fastumath. However, I couldn't make any connection between those messages and the trouble I'm running into. thanks -robert => python Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> Numeric.__version__ '22.0' >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 36, in ? from scipy_base import * File "/usr/lib/python2.2/site-packages/scipy_base/__init__.py", line 110, in ? raise ImportError,mess ImportError: dlopen: Win32 error 126 >

2 2

FW: Vector orientation (pedantry?)
by Perry Greenfield Dec. 10, 2002

Dec. 10, 2002

Since Stephen was unable to post this directly, he asked me to do so for him -- Perry -----Original Message----- From: Stephen Walton [mailto:stephen.walton@csun.edu] Sent: Thursday, November 21, 2002 2:02 PM To: scipy-user(a)scipy.net Subject: Vector orientation (pedantry?) This is probably a historical thing but I had to ask. MATLAB distinguishes between row and column vectors, so that the inner (dot) and outer products are a simple matter of switching the order of multiplication. Numeric forces one to use outerproduct(); matrixmultiply() always returns the inner product of two vectors whether they are row, column, or a mixture. MATLAB is mathematically correct, in my opinion. How much pain would it cause for matrixmultiply() to return the inner product for a row times a column vector and the outer product for a column times a row and get rid of outerproduct() altogether? Along the same lines, shouldn't transpose() applied to a row vector yield a column vector and vice versa? Don't shout at me---I'm just asking :-) -- Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State Northridge stephen.walton(a)csun.edu

4 7

scipy installation problem
by Dave Bazell Dec. 10, 2002

Dec. 10, 2002

I installed Numeric20 and solved some of the problems I was having with Numeric20. Now, when I import Numeric, I don't get any errors. However, when import scipy (.1 not .2) I get the following messages. Is this a problem with the distribution or with my installation? Any pointers would be appreciated. Dave Python 2.2.2 (#1, Oct 21 2002, 12:22:55) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 42, in ? from misc import * File "/usr/local/lib/python2.2/site-packages/scipy/misc.py", line 21, in ? import scipy.stats File "/usr/local/lib/python2.2/site-packages/scipy/stats/__init__.py", line 4, in ? from stats import * File "/usr/local/lib/python2.2/site-packages/scipy/stats/stats.py", line 204, in ? import math, string, sys, pstat, copy File "/usr/local/lib/python2.2/site-packages/scipy/stats/pstat.py", line 176 exec execstring SyntaxError: unqualified exec is not allowed in function 'colex' it contains a nested function with free variables >>> >>>

3 2

Interpolation
by Frank Gibbons Dec. 10, 2002

Dec. 10, 2002

Travis, Thanks for the pointers. I'll try this, and see if I can figure out what's going wrong. In the meantime, and in response to Pearu Peterson's message yesterday about Python not having a standard for documentation processing. I don't know about you guys, but one of the first things I do with a new package, even before I install it, is check out the docs, to get an idea of what it does, and how it does it. 'info' is fine, once you've got the system installed (and this is not trivial for scipy, what with ATLAS, LAPACK and BLAS), but it is of no help to those who don't have it installed. Furthermore, I find it handy to have printed documentation. Not only can I find things more easily and quickly than most online help systems, but it allows me to work in my SciPy interactive window, and still keep the documentation in front of me. Without something written, I have to keep interrupting my typing with "info(this)" and "info(that)". For those who know SciPy from the inside out, info is probably all you'll ever need. But for those coming from the outside, I think something more is necessary, and I think the sooner SciPy has this (well formatted online HTML/PDF docs, and something printable, both viewable without having to install), the better for it. I offer this not as a criticism, simply as a user observation. Thanks again for the tips. -Frank At 01:00 PM 12/10/2002, you wrote: >Note, that splev should accept xvals (i.e. you shouldn't have to do the >list comprehension) > >spline = splev(xvals, tck) > >should work fine. > >Try > >info(interpolate) > >to get an overview of the interpolate package. > >Try > >info(scipy) > >to get an overview of scipy PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons

2 1

gplt.plot ?
by Nils Wagner Dec. 10, 2002

Dec. 10, 2002

Hi all, Is it possible to plot y versus x by points which are n o t connected by a line ? y and x are arrays >>> x array([ 1.00000000e+00, 9.91444861e-01, 9.65925826e-01, 9.23879533e-01, 8.66025404e-01, 7.93353340e-01, 7.07106781e-01, 6.08761429e-01, 5.00000000e-01, 3.82683432e-01, 2.58819045e-01, 1.30526192e-01, 6.12303177e-17, -1.30526192e-01, -2.58819045e-01, -3.82683432e-01, -5.00000000e-01, -6.08761429e-01, -7.07106781e-01, -7.93353340e-01, -8.66025404e-01, -9.23879533e-01, -9.65925826e-01, -9.91444861e-01, -1.00000000e+00, -9.91444861e-01, -9.65925826e-01, -9.23879533e-01, -8.66025404e-01, -7.93353340e-01, -7.07106781e-01, -6.08761429e-01, -5.00000000e-01, -3.82683432e-01, -2.58819045e-01, -1.30526192e-01, -1.83690953e-16, 1.30526192e-01, 2.58819045e-01, 3.82683432e-01, 5.00000000e-01, 6.08761429e-01, 7.07106781e-01, 7.93353340e-01, 8.66025404e-01, 9.23879533e-01, 9.65925826e-01, 9.91444861e-01]) >>> y array([ 0.00000000e+00, 1.30526192e-01, 2.58819045e-01, 3.82683432e-01, 5.00000000e-01, 6.08761429e-01, 7.07106781e-01, 7.93353340e-01, 8.66025404e-01, 9.23879533e-01, 9.65925826e-01, 9.91444861e-01, 1.00000000e+00, 9.91444861e-01, 9.65925826e-01, 9.23879533e-01, 8.66025404e-01, 7.93353340e-01, 7.07106781e-01, 6.08761429e-01, 5.00000000e-01, 3.82683432e-01, 2.58819045e-01, 1.30526192e-01, 1.22460635e-16, -1.30526192e-01, -2.58819045e-01, -3.82683432e-01, -5.00000000e-01, -6.08761429e-01, -7.07106781e-01, -7.93353340e-01, -8.66025404e-01, -9.23879533e-01, -9.65925826e-01, -9.91444861e-01, -1.00000000e+00, -9.91444861e-01, -9.65925826e-01, -9.23879533e-01, -8.66025404e-01, -7.93353340e-01, -7.07106781e-01, -6.08761429e-01, -5.00000000e-01, -3.82683432e-01, -2.58819045e-01, -1.30526192e-01]) >>> Nils

1 0

Interpolation/Documentation woes...
by Frank Gibbons Dec. 10, 2002

Dec. 10, 2002

Travis, At 01:00 PM 12/7/2002, you wrote: > > I must confess I'm not much of an expert on interpolation. However, I was > > playing around with the interpolate package today, trying to figure out why > > the quality of the spline returned appears to vary with the scale of the > > data: some data (set of (x,y) pairs) that produce a good spline, when the > > y's are divided by a factor of 100, produce a really poor one. > >Could you send an example of which commands you are using? Just this: import scipy from scipy.interpolate import splrep, splev, splint tck = splrep(xvals, hvals) spline = [ splev(p, tck) for p in xvals] > > Regarding docs for that package, they're very hard to read in their current > > form, because each argument's description runs into that of the one that > > follows it. > > > >Can you use > > >>> from scipy import * > > >>> info(my command) > >Info is a scipy-specific help function that can be expanded in the future >independent of what python's help does. Currently it works very >similarly. Well, I could. But I wanted to get an overview of the package, not just an individual command. This 'info' sounds useful, but I think a complete set of docs is just as important, since that's how newbies (like me) learn what's possible in broad terms. The 'info' command sounds more useful when you know what you want to do, you just need to be reminded of the arglist, or that optional parameter that you rarely use. > > This will cause the output to be run together: "x -- first arg y -- > second arg" > > x -- first arg > > y -- second arg > > > > Putting a space between those lines generates: > > > > x > > first arg > > y > > second arg > > > >This sure puts in a lot of whitespace into the docstrings. But, I'm sure >that most documentation does not do this (a lot of it was written prior to >HappyDoc) I don't know about that - a single line to delineate arguments with distinct meanings doesn't sound too extreme to me. But 'info' probably just prints out the doc string, in which case I can see how that would seem like a lot of whitespace. I only assumed HappyDoc was the default because I think that's how the docs are provided in the tarball I downloaded. I'm not sure about that, I just remember I tried browsing them when I first downloaded about 6 weeks ago, but gave up because they were too hard to read. Then in unrelated work, I came across HappyDoc, and realized that it looked just like SciPy's docs, so I went back and played around a little. > > Readable docs are important in my opinion. Is this a problem with other > > packages too? Perhaps we can come up with a script to fix it SciPy-wide. > >I think everybody agrees with you. But, I don't think everybody uses >HappyDoc and therefore doesn't see this problem. It would be nice if >there were a pre-filter that could be used before HappyDoc so that the >docstrings don't actually have to be changed. I'm still learning about HappyDoc, so I'm not in a position right now to suggest how to deal with this problem. Does SciPy have a standard for documentation? (Perhaps 'info' is it?) I was just trying to do some interpolation, and noticed that performance was really poor for small (~0.01 or smaller) y-values, but really good for large ones (~10 or more). I'll get back with more precise details once I understand better what's going on.... Thanks for your response. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons

3 2

numarray equality testing
by Perry Greenfield Dec. 10, 2002

Dec. 10, 2002

This is a Numeric/numarray compatibility question. Numeric currently allows the equals ufunc to compare arrays of unequal sizes and returns a scalar 0 in such cases. When arrays have consistent shapes, an array of ints is returned. We argue that this is inconsistent with normal ufunc behavior and that it should generate an exception as do all non-equality ufuncs. (numarray currently does not allow comparison of shape-inconsistent arrays including for equality). Instead we propose a function whose purpose is to determine if two arrays are shape consistent (i.e., can be broadcast against each other) and have all values equal to each other. >>> array_equal(arange(2), arange(4)) 0 >>> array_equal(array([1,2,3]), array([1,2,0])) 0 >>> array_equal( arange(2), None ) 0 >>> array_equal( arange(2), not_an_ndarray_instance) 0 >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3])) 1 Comments? Perry Greenfield

5 5

Sparse Matrices (SciPy or elsewhere)?
by Costas Malamas Dec. 10, 2002

Dec. 10, 2002

I use SciPy, mostly for fun (check out my toy at memigo.com). For a new project, I am looking for a way to do sparse matrix algebra in NumPy/SciPy. I notice that SciPy/sparse has been pretty much abandoned. Is it functional? if not, are there alternatives? A working win32 implementation would be a plus (linux required though). Thanks in advance, Costas _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

numarray rank-0 array issues
by Perry Greenfield Dec. 9, 2002

Dec. 9, 2002

A little while ago we tackled the issue of whether indexing numarray arrays should return Python scalars or rank-0 arrays. For reasons gone into at great length previously on this list we decided to always return Python scalars when no precision is lost by conversion to Python scalars (Float128 may be an exception to this rule, but we'll deal with that later). We consider this issue closed. But there are some loose ends. There was an opinion that reduction operations (e.g., add.reduce) should always return arrays. However, some desired that the rank-0 arrays returned when reducing a rank-1 array should be indexable and have a length. In particular: >>> x = arange(10) >>> v = add.reduce(x) >>> print v 55 >>> v array(55) >>> len(v) 1 >>> v[0] 55 The great majority objected to len(rank-0) being allowed as well as rank-0[0] working. We agree. We propose that at least one version of the reduction operations always return arrays, but that the array "end-point" always be a rank-1 len-1 array instead of a rank-0 array. This is because a rank-1 len-1 array 1) has a len() = 1 2) can be indexed. 3) because of broadcasting, behaves like a scalar in expressions with arrays (i.e., as was intended for rank-0 arrays) Thus, if one repeatedly reduces an N-dimensional array, one eventually gets a rank-1 len-1 array, and reducing a rank-1 len-1 array simply generates a new rank-1 len-1 array with the same value. >>> x = arange(10) >>> v = add.areduce(x) >>> v array([55]) >>> add.areduce(v) array([55]) Is there any reason why this behavior would not serve the purposes of those that wanted rank-0 arrays returned from reduction operations? Likewise, we could provide a function to wrap scalars as rank-1 len-1 arrays (much like array(5) produces a rank-0 array) for the purposes of more generic functions and routines so that checks for scalars do not need to be made. This function would convert scalars to arrays, but simply return the arrays themselves if passed as arguments. One possibility is that we eliminate rank-0 arrays and use rank-1 len-1 arrays in their place (e.g., array(5) returns a rank-1 len-1 array). The problem is that there may be some who already dependon rank-0 properties and this probably will break existing code. Any opinions? Finally, the default reduction operation (i.e., add.reduce) could be given the behavior described above. We are inclined to leave it as is, i.e., to return scalars when reducing 1-d arrays and provide a different operator method (areduce) to always return arrays. Any disagreements? Perry Greenfield

2 1