Mailman 3 - NumPy-Discussion

Re: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array
by Konrad Hinsen Feb. 25, 2000

Feb. 25, 2000

> We get the type error from trying to set the matrix element with a matrix > element (apparently). In the old version (1.9) on our NT box, > temp=a[kwd,kwd] results in temp being an int type. How can we either cast > the temp to an int or enable what we really want, which is to add an int to > a[kwd,kwd], as in a[kwd,kwd] = a[kwd,kwd] + jwd ? > > Do we have a bad version of Numeric? Maybe an experimental version. If you check the archives of this mailing list, you can … [View More]

1 0

Numeric Python under IRIX646
by Michel Sanner Feb. 21, 2000

Feb. 21, 2000

Hi There, I just tried to add SGI running IRIX6.5 to the collection of Unix boxes I will support and I ran into the following problem: If I compile Python -O2 loading the Numeric extensions dumps the core, if I compile Python -g it works just fine and this regardless if Numeric is compile -g or -O2. After I re-compiled Objects/complexobject.o using -g (everything else being compiled -O2) I got it to work ... did anyone else out there see this kind of behavior ? I also post this to psa-… [View More]

2 1

Re: [Numpy-discussion] numpy documentation - alternative format?
by Herbert L. Roitblat Feb. 18, 2000

Feb. 18, 2000

Adobe Acrobat has a shrink to fit option in their print menu. I'm not sure if it comes with their free-reader. Try printing as a 1up. It seems a small adaptation. HLR -----Original Message----- From: Peter Chang <peter(a)eexpc.eee.nott.ac.uk> To: Numpy-discussion(a)lists.sourceforge.net <Numpy-discussion(a)lists.sourceforge.net> Date: Friday, February 18, 2000 7:09 AM Subject: [Numpy-discussion] numpy documentation - alternative format? > >Hi there, > >I've just … [View More]

2 1

numpy documentation - alternative format?
by Peter Chang Feb. 18, 2000

Feb. 18, 2000

Hi there, I've just started to use python and numpy and want to print out the numpy document but the PDF file has a strange aspect ratio which makes it hard to print it as 2up on A4 paper. (I've tried hacking about with the postscript generated by xpdf but it seems that there is no global setting for page size!) Could the authors please provide alternative formats for the doc, eg. as postscript files sized for A4 and letter so that people can print them out easier? Thanks Peter

1 0

more speed?
by andrew x swan Feb. 17, 2000

Feb. 17, 2000

This message was sent from Geocrawler.com by "andrew x swan" <a.swan(a)anprod.csiro.au> Be sure to reply to that address. hi - i've only just started using python and numpy... the program i wrote below runs much more slowly than a fortran equivalent. ie. on a dataset where the order of the matrix is (3325,3325), python took this long: 362.25user 0.74system 6:09.78elapsed 98%CPU and fortran took this long: 2.68user 1.12system 0:03.89elapsed 97%CPU is this because the element by … [View More]

3 2

re: scientific Python publishing venue
by gvwilson＠nevex.com Feb. 10, 2000

Feb. 10, 2000

Hi, folks. A former colleague of mine is now editing a magazine devoted to scientific computing, and is looking for articles. If you're doing something scientific with Python, and want to tell the world about it, please give me a shout, and I'll forward more information. Greg Wilson http://www.software-carpentry.com

1 0

An Experiment in code-cleanup.
by Travis Oliphant Feb. 10, 2000

Feb. 10, 2000

I wanted to let users of the community know (so they can help if they want, or offer criticism or comments) that over the next several months I will be experimenting with a branch of the main Numerical source tree and endeavoring to "clean-up" the code for Numerical Python. I have in mind a few (in my opinion minor) alterations to the current code-base which necessitates a branch. Guido has made some good suggestions for improving the code base, and both David Ascher and Paul Dubois have … [View More]expressed concerns over the current state of the source code and given suggestions as to how to improve it. That said, I should emphasize that my work is not authorized, or endorsed, by any of the people mentioned above. It is simply my little experiment. My intent is not to re-create Numerical Python --- I like most of the current functionality --- but to merely, clean-up the code, comment it, and change the underlying structure just a bit and add some features I want. One goal I have is to create something that can go into Python 1.7 at some future point, so this incarnation of Numerical Python may not be completely C-source compatible with current Numerical Python (but it will be close). This means C-extensions that access the underlying structure of the current arrayobject may need some alterations to use this experimental branch if it every becomes useful. I don't know how long this will take me. I'm not promising anything. The purpose of this announcement is just to invite interested parties into the discussion. These are the (somewhat negotiable) directions I will be pursuing. 1) Still written in C but heavily (in my opinion) commented. 2) Addition of bit-types and unsigned integer types. 3) Facility for memory-mapped dataspace in arrays. 4) Slices become copies with the addition of methods for current strict referencing behavior. 5) Handling of sliceobjects which consist of sequences of indices (so that setting and getting elements of arrays using their index is possible). 6) Rank-0 arrays will not be autoconverted to Python scalars, but will still behave as Python scalars whenever Python allows general scalar-like objects in it's operations. Methods will allow the user-controlled conversion to the Python scalars. 7) Addition of attributes so that different users can configure aspects of the math behavior, to their hearts content. If their is anyone interested in helping in this "unofficial branch work" let me know and we'll see about setting up someplace to work. Be warned, however, that I like actual code or code-templates more than just great ideas (truly great ideas are never turned away however ;-) ) If something I do benefits the current NumPy source in a non-invasive, backwards compatible way, I will try to place it in the current CVS tree, but that won't be a priority, as my time does have limitations, and I'm scratching my own itch at this point. Best regards, Travis Oliphant [View Less]

10 18

digest
by Les Schaffer Feb. 9, 2000

Feb. 9, 2000

just switched over from matrix-sig to numpy-discussion. in the process i changed to the digest version and got my first issue. is it possible to distribute the digests properly formatted as multipart/digests as per rfc822 and company? having such a formatted digest makes it very easy when using an emailer like VM in emacs: VM automatically displays the digest as a virtual folder, allowing one to browse all the posts in a given digest very quickly and easily. don't know whether the other (… [View More]

2 1

RE: [Matrix-SIG] An Experiment in code-cleanup.
by Beausoleil, Raymond Feb. 9, 2000

Feb. 9, 2000

From: Konrad Hinsen [mailto:hinsen@cnrs-orleans.fr] > > (1) The extent of the support for LAPACK. Do we want to stick > > with LAPACK Lite? > > There has been a full LAPACK interface for a long while, of which > LAPACK Lite is just the subset that is needed for supporting the > high-level routines in the module LinearAlgebra. I seem to have lost > the URL to the full version, but it's on my disk, so I can put it > onto my FTP server if there is a need. Yes, I'd … [View More]

2 1

Upcasting
by Pitts, Todd A., Ph.D. Feb. 9, 2000

Feb. 9, 2000

Here are my two cents worth on the subject... Most of what has been said in this thread (at least what I have read) I find very valuable. Apparently, many people have been thinking about the subject. I view this problem as inherent in a language without an Lvalue (like C) that allows a very explicit and clear definition from the programmer's point of view as to the size of the container you are going put things in. The language in many cases simply returns an object to you and has made … [View More]some decision as to what you "needed" or "wanted". Of course, this is one of the things that makes languages such an Numerical Python, Matlab, IDL, etc. very nice for protyping and investigating. In many cases this decision will be adequate or acceptable. In some, quite simply, it will not be. At this point the programmer has to have a good means of managing this decision himself. If memory is not a constraint, I can think of very few situations (none, actually) where I would choose to go with something other than the Numerical Python default of double. In general, that is what you get when creating python arrays unless you make some effort to obtain some other type. However, in some important (read "cases that affect the author") situations memory is a very critical constraint. Typically, in Numerical Python I use 4-byte floats. In fact, one of the reasons I use Numerical Python is because I don't *need* doubles and matlab for example is really only setup to work gracefully with doubles. I do *need* to conserve memory as I deal with very large data sets. It seems the question we are discussing is not really "what *should* be done in terms of casting?" but "what provides good enough decisions much of the time *and* a gracefull way to manage the decisions when "good enough" no longer applies to you?" Currently, this is not a trivial thing to manage. Reading in a 100 MB data set and multiplying by the python scalar 2 produces a 200 MB data set. I manage this by wrapping the 2 in an array. This happens, of course, all the time. Having to do this once is not a big deal, but doing everywhere in code that uses floats makes for cluttered code -- not something which I expect to have to write in an otherwise very elegant and concise language. Also, I often find myself trudging through code looking for the subtlety that converted my floats to doubles, doubled my memory usage and then caused subsequent float only routines to error out. To those who are constrained to use floats this is awkward and time consuming. To those who are not I would say -- use doubles. The flag that causes an array to be a "space saving array" seems to be a temporary fix (that doesn't mean it was a bad idea -- just that it feels messy and effectively adds complexity that shouldn't be there). It also, mearly postpones the problem as I understand it -- what happens when I multiply two space saving arrays? We simply will never get away from situations where we have to manage the interaction ourselves and so we should be careful not to make that management so awkward (and currently I think it is awkward) that the floats, bytes, shorts, etc. become marginalized in their utility. My suggestion is to go with the rule that a simple hirearchy (in which downcasting is the rule) longs integers shorts bytes cardinals booleans doubles complex doubles <--- default floats complex floats for the most part makes good decisions: Principally because people who are not constrained to conserve memory will use the larger, default types all the time and not wince. They don't *need* floats or bytes. If anyone gives them a float a simple astype('d') or astype('D') to make sure it becomes a double lets them go on their way. Types like integers and bytes are effectively treated as being precise. If you are constrained to conserve memory by staying with floats or bytes instead of just reading things in from disk and making them doubles it will not be so awkward to manage the types in large programs. If I use someones code and they have a scalar anywhere in it at some point, even if I (or they) cast the output, memory usage swells at least for intermediate calculations. Effectively, python *has* 4-byte floats but programming with them is awkward. This means, of course, that multiplying a float array by a double array produces a float. Multiplying a double array by anything above it produces a double. etc. For my work, if I have a float anywhere in the calculation I don't believe precision beyond that in the output so getting a float back is reasonable. I know that some operations produce "more precision" and so I would cast the array if I needed to take advantage of that. Perhaps the downcasting is *not* the way to go. However, I definately think the current awkwardness should be eliminated. I hope my comments will not be percieved as being critical of the original language designers. I find python to be very useful or I wouldn't have bothered to make the comments at all. -Todd Pitts [View Less]

1 0