You can subscribe to this list here.
2000 
_{Jan}
(8) 
_{Feb}
(49) 
_{Mar}
(48) 
_{Apr}
(28) 
_{May}
(37) 
_{Jun}
(28) 
_{Jul}
(16) 
_{Aug}
(16) 
_{Sep}
(44) 
_{Oct}
(61) 
_{Nov}
(31) 
_{Dec}
(24) 

2001 
_{Jan}
(56) 
_{Feb}
(54) 
_{Mar}
(41) 
_{Apr}
(71) 
_{May}
(48) 
_{Jun}
(32) 
_{Jul}
(53) 
_{Aug}
(91) 
_{Sep}
(56) 
_{Oct}
(33) 
_{Nov}
(81) 
_{Dec}
(54) 
2002 
_{Jan}
(72) 
_{Feb}
(37) 
_{Mar}
(126) 
_{Apr}
(62) 
_{May}
(34) 
_{Jun}
(124) 
_{Jul}
(36) 
_{Aug}
(34) 
_{Sep}
(60) 
_{Oct}
(37) 
_{Nov}
(23) 
_{Dec}
(104) 
2003 
_{Jan}
(110) 
_{Feb}
(73) 
_{Mar}
(42) 
_{Apr}
(8) 
_{May}
(76) 
_{Jun}
(14) 
_{Jul}
(52) 
_{Aug}
(26) 
_{Sep}
(108) 
_{Oct}
(82) 
_{Nov}
(89) 
_{Dec}
(94) 
2004 
_{Jan}
(117) 
_{Feb}
(86) 
_{Mar}
(75) 
_{Apr}
(55) 
_{May}
(75) 
_{Jun}
(160) 
_{Jul}
(152) 
_{Aug}
(86) 
_{Sep}
(75) 
_{Oct}
(134) 
_{Nov}
(62) 
_{Dec}
(60) 
2005 
_{Jan}
(187) 
_{Feb}
(318) 
_{Mar}
(296) 
_{Apr}
(205) 
_{May}
(84) 
_{Jun}
(63) 
_{Jul}
(122) 
_{Aug}
(59) 
_{Sep}
(66) 
_{Oct}
(148) 
_{Nov}
(120) 
_{Dec}
(70) 
2006 
_{Jan}
(460) 
_{Feb}
(683) 
_{Mar}
(589) 
_{Apr}
(559) 
_{May}
(445) 
_{Jun}
(712) 
_{Jul}
(815) 
_{Aug}
(663) 
_{Sep}
(559) 
_{Oct}
(930) 
_{Nov}
(373) 
_{Dec}

S  M  T  W  T  F  S 





1

2
(12) 
3
(2) 
4

5
(7) 
6
(2) 
7

8

9

10

11

12

13

14

15
(1) 
16

17

18

19

20

21

22

23
(1) 
24

25
(2) 
26
(1) 
27

28

29

30


From: <hinsen@di...>  20000626 17:58:10

> Did somebody already treat such problems?? Within Numpy or outside > Numpy. Do I have to install the full blown version of Lapack?? Yes, but it's not a big deal. If you then want a nicer highlevel interface, look at the module LinearAlgebra for guidance; input parameters to LAPACK are treated rather consistently, so you shouldn't have to invent anything reallly new.   Konrad Hinsen  EMail: hinsen@... Centre de Biophysique Moleculaire (CNRS)  Tel.: +332.38.25.55.69 Rue Charles Sadron  Fax: +332.38.63.15.17 45071 Orleans Cedex 2  Deutsch/Esperanto/English/ France  Nederlands/Francais  
From: Vanroose Wim <vanroose@ru...>  20000625 13:09:22

Dear NumPythoneers, I have to solve the generalized Eigenvalue problem A u = lambda B u There are lapack procedures http://netlib2.cs.utk.edu/lapack/lug/node37.html. These procedures are not present in the lite versions included in the NumPy distribution. Did somebody already treat such problems?? Within Numpy or outside Numpy. Do I have to install the full blown version of Lapack?? Wim Vanroose 
From: Chris Myers <myers@tc...>  20000625 00:02:51

Michel Sanner wrote: > I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran > it I witnessed strange behavior. > > a = Numeric.identity(4) > a.shape = (16,) > > would raise an exception about the size of the array needing to remain > the same ??? I have seen the same behavior on a Dec Alpha running RedHat Linux, with Numeric compiled with gcc. The other random pieces of Numeric that I tried seemed to work correctly. Chris ========================================================================== Chris Myers Cornell Theory Center  636 Rhodes Hall email: myers@... Cornell University phone: (607) 2555894 / fax: (607) 2548888 Ithaca, NY 14853 http://www.tc.cornell.edu/~myers  "To thine own self be blue."  Polonious Funk ========================================================================== On Sat, 24 Jun 2000 numpydiscussionadmin@... wrote: > Date: Sat, 24 Jun 2000 12:19:28 0700 > From: numpydiscussionadmin@... > ReplyTo: numpydiscussion@... > To: numpydiscussion@... > Subject: Numpydiscussion digest, Vol 1 #70  1 msg > > > Send Numpydiscussion mailing list submissions to > numpydiscussion@... > > To subscribe or unsubscribe via the web, visit > http://lists.sourceforge.net/mailman/listinfo/numpydiscussion > or, via email, send a message with subject or body 'help' to > numpydiscussionrequest@... > You can reach the person managing the list at > numpydiscussionadmin@... > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Numpydiscussion digest..." > > > Today's Topics: > > 1. Numeric on Dec Alpha (Michel Sanner) > > ____ > > Message: 1 > From: "Michel Sanner" <sanner@...> > Date: Fri, 23 Jun 2000 12:22:24 0700 > To: numpydiscussion@... > Subject: [Numpydiscussion] Numeric on Dec Alpha > > Hi, I posted this message on the pythonlist a while ago and did not hear > anything .. so I try here :) > > I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it > I witnessed strange behavior. > > a = Numeric.identity(4) > a.shape = (16,) > > would raise an exception about the size of the array needing to remain the same > ??? > > Using the debugger I found in arrayobject.c:2201 > > if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == 1) > return NULL; > > After this call shape [0] is 4 BUT shape[1] is 0 ! > > I changed the code to > if (PyArray_As1D(&shape, (char **)&dimensions, &n, > PyArray_INT) == 1) return NULL; > > and got the right result. > > Did anyone else run into this kind of preblems ? what is the correct way to fix > that ? > > thanks > > Michel > > >  > >  > > >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! > > Michel F. Sanner Ph.D. The Scripps Research Institute > Assistant Professor Department of Molecular Biology > 10550 North Torrey Pines Road > Tel. (858) 7842341 La Jolla, CA 92037 > Fax. (858) 7842860 > sanner@... http://www.scripps.edu/sanner >  > > > > > ____ > > _______________________________________________ > Numpydiscussion mailing list > Numpydiscussion@... > http://lists.sourceforge.net/mailman/listinfo/numpydiscussion > > > End of Numpydiscussion Digest > 
From: Michel Sanner <sanner@sc...>  20000623 19:26:55

Hi, I posted this message on the pythonlist a while ago and did not hear anything .. so I try here :) I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it I witnessed strange behavior. a = Numeric.identity(4) a.shape = (16,) would raise an exception about the size of the array needing to remain the same ??? Using the debugger I found in arrayobject.c:2201 if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == 1) return NULL; After this call shape [0] is 4 BUT shape[1] is 0 ! I changed the code to if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_INT) == 1) return NULL; and got the right result. Did anyone else run into this kind of preblems ? what is the correct way to fix that ? thanks Michel   >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 7842341 La Jolla, CA 92037 Fax. (858) 7842860 sanner@... http://www.scripps.edu/sanner  
From: <hinsen@di...>  20000615 18:25:22

> If I move things like FFT out of the core and make them separate packages, I > am left with a choice: make them real packages, which means their usage > would change, or structure the packages so that everything gets installed in > the Python search path the way it does now. > > The first choice is better for the future, walling everything off into > namespaces properly. The second choice doesn't break any existing code. There's a compromise: Change everything to a nice package structure, and provide a compatibility module for some transition period. Then everyone can adapt their code in a reasonable time. Ultimately the compatibility modules can disappear.   Konrad Hinsen  EMail: hinsen@... Centre de Biophysique Moleculaire (CNRS)  Tel.: +332.38.25.55.69 Rue Charles Sadron  Fax: +332.38.63.15.17 45071 Orleans Cedex 2  Deutsch/Esperanto/English/ France  Nederlands/Francais  
From: Janko Hauser <jhauser@if...>  20000606 13:48:35

Hello, I started to use PyUnit to build another test framework for NumPy. The ideas behind this approach are:  Build on a known and maybe standard framework.  Make tests in such a way that they can be handled with Python so helper functions can be written to perform single tests from the commandline.  The framework should facilitate the writing of new tests by everyone, not only for NumPy routines but also for more complex or derived programs.  The tests should be self contained, each test is done in a clean environment.  The hole test suite can be run, also if some tests are failing. This is important for all these cases, where there are known errors in the system libraries.  Define and document what actually is tested. There are different criteria for tests on numerical functions, like testing the interface, the numerical valid input range, type coercions, the algorithm and so on. In the end I want to have a module which can be imported and the contained classes can be used to write new tests, perform tests and generate reports. Together with a naming convention it should be possible to automate the testing of new modules. I have written some ideas down at: http://lisboa.ifm.unikiel.de:80080/NumPy/NaFwiki/TestFramework There is also a module which is NOT the proposed framework, but which demonstrates how the code of the tests looks like. Are there some comments, objections or new ideas? With regards, __Janko 
From: Huaiyu Zhu <HZ<hu@kn...>  20000606 01:03:09

Are you craving for Matlab/Octave style expressions in Python? (For example, A*B is matrix multiplication, not elementwise.) Now you can. I've just made a package MatPy and started a SourceForge project for it. It is implemented as wrappers around the Numeric and Gnuplot packages. You can find the source codes, tests and docs on the home page http://MatPy.sourceforge.net The main reason I have written this package is that I'm tired of dealing with NewAxis and have "Frame not aligned" exceptions. Now matrices and vectors behave as one would expect from linear algebra. Examples: >>> from MatPy.Matrix import * >>> A = rand((20,5)) >>> x = rand((5,1)) >>> y = A*x >>> b = solve(A,y) >>> norm(bx) 1.16043535672e15 >>> print x [ 0.276 0.553 0.733 0.388 0.5 ] >>> print x.T() [ 0.276 0.553 0.733 0.388 0.5 ] >>> print x.T()*x [ 1.32 ] >>> print x*x.T() [ 0.0763 0.153 0.203 0.107 0.138 0.153 0.306 0.406 0.214 0.277 0.203 0.406 0.538 0.284 0.367 0.107 0.214 0.284 0.15 0.194 0.138 0.277 0.367 0.194 0.25 ] >>> z = x + rand(x.shape)*1j >>> z.H() [ 0.2760.606j 0.5530.376j 0.7330.933j 0.3880.636j 0.50.314j ] >>> z.H()*z [ 3.2+0j ] >>> norm(z)**2 3.2026003449 There are also matrix and elementwise versions of functions: expm and exp, sqrtm and sqrt, etc. Questions, comments, suggestions and helps are all very welcome. It is a future plan to have an efficient interface to Octave to leverage its large code base. Enjoy! Huaiyu <hzhu@...> 
From: Paul Gettings <gettings@mi...>  20000605 17:58:45

> I would dare to say that what you really need is > C=A[:,NewAxis]*B > C will be shaped as (7731,220), which is what you probably need. Based on a simple (small) test, this is exactly what I want; the result of the NewAxis computation is identical to a matrix multiply of the fullsized matrices. Thanks. Now I just have to read the docs until I understand precisely how and why this works. :)  101 USES FOR A DEAD MICROPROCESSOR (62) Fungus trellis 
From: JeanBernard Addor <jbaddor@ph...>  20000605 17:46:33

Hy Numeric people! Thank you very much Janne for your suggestion of a compilation problem. I just recompiled with debug option and the Numeric.arange(2)*1j problem disapeared. Further testing of my Numeric 1.7 code shows that the code still breaks: Python 1.5.2 (#9, May 30 2000, 15:08:12) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Hello from .pythonrc.py >>> from Numeric import * >>> import Numeric >>> Numeric.__version__ '11' >>> a = arange(2, typecode=Complex) % 2 >>> a.typecode() 'O' >>> add.outer(a**2,a**2) Program received signal SIGSEGV, Segmentation fault. 0x4006b570 in malloc () (gdb) where (see at the end of message for debug info) I have no idea if it is another bug or another compilation problem. If this is an installation or compilation problem, I am surprised it occures with standart linux, gcc. But I understand it can happens. Proposal : a test for these problems should be included in test_all.py or other test of the module. I installed with Distutils0.8.2 and tested with test_all.py without notification of any problem. PS: I have the problem with Numeric 11 (distribution 14 compiled with egcc) Thanks a lot for your help, JeanBernard On 2 Jun 2000, Janne Sinkkonen wrote: > Charles G Waldman <cgw@...> writes: > > > > >>> Numeric.__version__ > > > '11' > > > >>> Numeric.__version__ > > '15.2' > > >>> Numeric.arange(2)*1j > > array([ 0.+0.j, 0.+1.j]) > > I tested for the bug in the Numeric version 11 on the following: > > Python 1.5.2+ (#7, Nov 13 1999, 17:39:22) [GCC egcs2.91.66 19990314/Linux (egcs1.1.2 release)] on linux2 > Python 1.5.2+ (#4, Oct 6 1999, 22:18:42) [C] on linux2 (alpha with cc) > Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc2.91.60 19981201 (egcs1.1.1 on linux2 > > The bug was not present on these, nor in Numeric 15.2 in an SGI. So the > problem seems to be not in the source but in the installation (or the > compiler). > >  > Janne > GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486pclinuxgnu"... (gdb) run Starting program: /users/jbaddor/bin/python Python 1.5.2 (#9, May 30 2000, 15:08:12) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Hello from .pythonrc.py >>> from Numeric import * >>> import Numeric >>> Numeric.__version__ '11' >>> a = arange(2, typecode=Complex) % 2 >>> a.typecode() 'O' >>> add.outer(a**2,a**2) Program received signal SIGSEGV, Segmentation fault. 0x4006b570 in malloc () (gdb) where #0 0x4006b570 in malloc () #1 0x4006b0f5 in malloc () #2 0x8070c16 in PyString_FromStringAndSize (str=0x80d982c "[0j , (1+0j) , ", size=14) at stringobject.c:95 #3 0x80711b9 in string_slice (a=0x80d9818, i=0, j=14) at stringobject.c:381 #4 0x80621ca in PySequence_GetSlice (s=0x80d9818, i1=0, i2=1) at abstract.c:869 #5 0x807920e in apply_slice (u=0x80d9818, v=0x0, w=0x80a39cc) at ceval.c:2552 #6 0x807699c in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, args=0x8102758, argcount=5, kws=0x810276c, kwcount=1, defs=0x80e1554, defcount=2, owner=0x0) at ceval.c:938 #7 0x8077bbc in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, args=0x80d32cc, argcount=6, kws=0x80d32e4, kwcount=0, defs=0x80e1554, defcount=2, owner=0x0) at ceval.c:1612 #8 0x8077bbc in eval_code2 (co=0x80e7818, globals=0x80b4d78, locals=0x0, args=0x80d8ba0, argcount=6, kws=0x80d8bb8, kwcount=0, defs=0x80e19bc, defcount=5, owner=0x0) at ceval.c:1612 #9 0x8077bbc in eval_code2 (co=0x80d5870, globals=0x80d95b0, locals=0x0, args=0x8102a0c, argcount=1, kws=0x0, kwcount=0, defs=0x80e65c4, defcount=3, owner=0x0) at ceval.c:1612 #10 0x807909d in call_function (func=0x80b4d58, arg=0x8102a00, kw=0x0) at ceval.c:2484 #11 0x8078c4d in PyEval_CallObjectWithKeywords (func=0x80b4d58, arg=0x8102a00, kw=0x0) at ceval.c:2322 #12 0x4014d405 in array_repr (self=0x80d3000) at Src/arrayobject.c:1119 #13 0x806ff52 in PyObject_Repr (v=0x80d3000) at object.c:237 #14 0x806fe5b in PyObject_Print (op=0x80d3000, fp=0x809f0c8, flags=0) at object.c:188 #15 0x8067e2e in PyFile_WriteObject (v=0x80d3000, f=0x80a2880, flags=0) at fileobject.c:1044 #16 0x8076c55 in eval_code2 (co=0x80d3598, globals=0x80a37e8, locals=0x80a37e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1030 #17 0x8076008 in PyEval_EvalCode (co=0x80d3598, globals=0x80a37e8, locals=0x80a37e8) at ceval.c:324 #18 0x805c957 in run_node (n=0x80c7798, filename=0x8088027 "<stdin>", globals=0x80a37e8, locals=0x80a37e8) at pythonrun.c:887 #19 0x805bdf8 in PyRun_InteractiveOne (fp=0x809f170, filename=0x8088027 "<stdin>") at pythonrun.c:528 #20 0x805bc6f in PyRun_InteractiveLoop (fp=0x809f170, filename=0x8088027 "<stdin>") at pythonrun.c:472 #21 0x805bbb2 in PyRun_AnyFile (fp=0x809f170, filename=0x8088027 "<stdin>") at pythonrun.c:449 #22 0x804efd9 in Py_Main (argc=1, argv=0xbffffbb4) at main.c:287 #23 0x804ea5a in main (argc=1, argv=0xbffffbb4) at python.c:12 (gdb) 
From: Jon Saenz <jsaenz@wm...>  20000605 17:25:57

I don't know if I am missing something, but: Let's suppose you have A so that A.shape is (7731,). It is diagonal, so, obviously, you don't need to save it all. Just a vector. You also have B, shaped like this: (7731,220) And you want to multiply A*B (the matrix way). I would dare to say that what you really need is C=A[:,NewAxis]*B C will be shaped as (7731,220), which is what you probably need. Jon Saenz.  Tfno: +34 946012470 Depto. Fisica Aplicada II  Fax: +34 944648500 Facultad de Ciencias. \\ Universidad del Pais Vasco \\ Apdo. 644 \\ 48080  Bilbao \\ SPAIN On Mon, 5 Jun 2000, Paul Gettings wrote: > > But memory is so cheap these days! ;) > I am a grad student, and have no money. :( > > > > However, the matrix is empty except for the main diagonal. > > Multiplying by a diagonalized matrix is just vectorized multiplication: > > a 0 0 > > 0 b 0 . <x, y, z> = <az, by, cz> > > 0 0 c > My mistake  I need to multiply the 7731x7731 by a 7731x220 element matrix  > square matrix times rectangular matrix, not just 2 diagonal matrices. > Otherwise, the problem wouldn't be so hard. :) > >  > That which does not kill you, didn't try hard enough. > > > _______________________________________________ > Numpydiscussion mailing list > Numpydiscussion@... > http://lists.sourceforge.net/mailman/listinfo/numpydiscussion > 
From: Charles G Waldman <cgw@fn...>  20000605 17:24:14

Paul Gettings writes: > > > > However, the matrix is empty except for the main diagonal. > > Multiplying by a diagonalized matrix is just vectorized multiplication: > > a 0 0 > > 0 b 0 . <x, y, z> = <az, by, cz> > > 0 0 c > My mistake  I need to multiply the 7731x7731 by a 7731x220 element matrix  > square matrix times rectangular matrix, not just 2 diagonal matrices. > Otherwise, the problem wouldn't be so hard. :) Still it's not so bad, you just need to break the 7731x220 matrix into 220 vectors of length 7731 and multiply each of them by the diagonal "matrix", one at a time, and glue the results back together. The 7731x220 matrix should weigh in at about 6MB, hopefully you have enough memory for this... 
From: Paul Gettings <gettings@mi...>  20000605 17:11:15

> But memory is so cheap these days! ;) I am a grad student, and have no money. :( > > However, the matrix is empty except for the main diagonal. > Multiplying by a diagonalized matrix is just vectorized multiplication: > a 0 0 > 0 b 0 . <x, y, z> = <az, by, cz> > 0 0 c My mistake  I need to multiply the 7731x7731 by a 7731x220 element matrix  square matrix times rectangular matrix, not just 2 diagonal matrices. Otherwise, the problem wouldn't be so hard. :)  That which does not kill you, didn't try hard enough. 
From: Herbert L. Roitblat <roitblat@ha...>  20000605 17:10:54

Unless I am misunderstanding something, you have a vector, which is the diagonal of a square matrix, and thus contains 7731 elements. You want to multiply it by another vector, which has 7731 columns. Element by element by element multiplication will, I think, give you the result that you want. In matlab you would use the diag command and then use the .* operator to get element by element multiplication. In NumPY you would simply use the * operator to multiply the two vectors. Travis Oliphant has sparse matrix classes that you might want to check out, but I don't see why you would need them for this task. HLR  Original Message  From: "Paul Gettings" <gettings@...> To: <numpydiscussion@...> Sent: Monday, June 05, 2000 6:49 AM Subject: [Numpydiscussion] Sparse matrices in NumPy? > I have a problem where I need to do matrix multiplication of a 7731x7731 > matrix; storing this thing would take over 250 MB of memory, which is more > than my machine has. :( However, the matrix is empty except for the main > diagonal. Ideally, all that needs to be stored is a single vector 7731 > elements long, and then tweak matrix multiplication algorithms to account for > this. Are there any facilities in NumPy to do this sort of thing, or do I > have to roll my own? Is there a way to effeciently store a very sparse > matrix and do standard matrix multiplies? Thanks. > > Paul Gettings > Dep't of Geology & Geophysics > University of Utah >  > But Your Honor, they needed killin'. > > > _______________________________________________ > Numpydiscussion mailing list > Numpydiscussion@... > http://lists.sourceforge.net/mailman/listinfo/numpydiscussion > 
From: Paul Gettings <gettings@mi...>  20000605 16:49:55

I have a problem where I need to do matrix multiplication of a 7731x7731 matrix; storing this thing would take over 250 MB of memory, which is more than my machine has. :( However, the matrix is empty except for the main diagonal. Ideally, all that needs to be stored is a single vector 7731 elements long, and then tweak matrix multiplication algorithms to account for this. Are there any facilities in NumPy to do this sort of thing, or do I have to roll my own? Is there a way to effeciently store a very sparse matrix and do standard matrix multiplies? Thanks. Paul Gettings Dep't of Geology & Geophysics University of Utah  But Your Honor, they needed killin'. 
From: Paul F. Dubois <pauldubois@ho...>  20000603 13:40:56

> Also in the case of a Numeric package which goes into the standard > distribution should the other packages be integrated in the Numeric > namespace or build under an external tree in the sitepackages > directory? I do not know the proposed scheme, is there something > written down somewhere? > > __Janko > I didn't make a proposal; I was trying to gauge whether people would freak at a change that required modification of existing scripts, or not. My thoughts, however, were along the lines of two packages, Numeric and MathPack. Then I would put a substructure under MathPack by subject area. Already, however, we see ugliness on the horizon: the module RandomArray imports both ranlib and a linear algebra package, so we have Package Dependencies and all the glorious ugliness of real life. I'm sure we'd have more in the future. There are competing packages for some things, such as random numbers. Ugh, how to make this easy for a random scientist who drops by... 
From: Janko Hauser <jhauser@if...>  20000603 08:34:14

David Ascher writes: > > An important thing to keep in mind is the possibility that part of > > Numeric.py can become a standard part of Python, this would mean that > > it has the same status as the string module. > > Why? Packagizing of the standard library is a longterm goal. > Also in the case of a Numeric package which goes into the standard distribution should the other packages be integrated in the Numeric namespace or build under an external tree in the sitepackages directory? I do not know the proposed scheme, is there something written down somewhere? __Janko 
From: David Ascher <DavidA@ActiveState.com>  20000602 22:20:39

> An important thing to keep in mind is the possibility that part of > Numeric.py can become a standard part of Python, this would mean that > it has the same status as the string module. Why? Packagizing of the standard library is a longterm goal. 
From: Janko Hauser <jhauser@if...>  20000602 21:41:59

An important thing to keep in mind is the possibility that part of Numeric.py can become a standard part of Python, this would mean that it has the same status as the string module. This would speak against a package structure for Numeric itself. So if packages are used, the structure should not be a subtree of Numeric. Second thought: Should every module be it's own package? Or should there be a structure so that third party modules can be sorted into this structure (for example sorted by problem domains, math, data, IO, physics/natural science, image processing etc.) One problem is, if some libraries with a broader spectrum are wrapped, like GSL, the sorting becomes obsolete. This would suggest to have a package for every module. I would also say, that it is not easy to aim at complete environment if there is not a refactoring by a maintainer. As long as the modules are only (not meant in a bad way) provided by different authors there will be no kitchen sink application. This would also suggest a package for every module. __Janko 
From: Paul F. Dubois <pauldubois@ho...>  20000602 20:56:24

If I move things like FFT out of the core and make them separate packages, I am left with a choice: make them real packages, which means their usage would change, or structure the packages so that everything gets installed in the Python search path the way it does now. The first choice is better for the future, walling everything off into namespaces properly. The second choice doesn't break any existing code. The changes involve just namespace issues. Right now all of Numeric is installed as separate toplevel modules. The same considerations apply somewhat to Numeric itself. By making the existing Numeric.py into the __init__.py for a Numeric package, nothing would break except imports of Precision and ArrayPrinter, which would have to become Numeric.Precision, etc. How much pain is the future worth? 
From: Janne Sinkkonen <janne@nn...>  20000602 18:40:33

Charles G Waldman <cgw@...> writes: > > >>> Numeric.__version__ > > '11' > >>> Numeric.__version__ > '15.2' > >>> Numeric.arange(2)*1j > array([ 0.+0.j, 0.+1.j]) I tested for the bug in the Numeric version 11 on the following: Python 1.5.2+ (#7, Nov 13 1999, 17:39:22) [GCC egcs2.91.66 19990314/Linux (egcs1.1.2 release)] on linux2 Python 1.5.2+ (#4, Oct 6 1999, 22:18:42) [C] on linux2 (alpha with cc) Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc2.91.60 19981201 (egcs1.1.1 on linux2 The bug was not present on these, nor in Numeric 15.2 in an SGI. So the problem seems to be not in the source but in the installation (or the compiler).  Janne 
From: JeanBernard Addor <jbaddor@ph...>  20000602 18:25:29

Hey Numpy people! On Fri, 2 Jun 2000, Charles G Waldman wrote: > This seems to be fixed in the current CVS version. I suggest you > either wait for the next release or grab the current version from CVS > if this is really a problem for you. I don't understand wich files I would need to take a new version from and wich command I have to issue to get a version of Numpy that correct the bug I just hit. Thanks for help. I would like my code to work with the next release. JeanBernard 
From: Charles G Waldman <cgw@fn...>  20000602 16:44:20

JeanBernard Addor writes: > Hey again! > > Why is (arange(2, typecode=Complex) % 2).typecode() object and not > complex? Looks like a bug to me! >>> x=arange(2, typecode=Complex) >>> x array([ 0.+0.j, 1.+0.j]) >>> x+10 array([ 10.+0.j, 11.+0.j]) >>> x*10 array([ 0.+0.j, 10.+0.j]) >>> x/10 array([ 0. +0.j, 0.1+0.j]) >>> x%10 array([0j , (1+0j) ],'O') I don't see (offhand) why other operations leave the array as complex, and "%" causes it to be an 'O'. Presumably complex arrays lack the "mod" method and are getting promoted to Object. However, for float and double arrays you get the expected behavior: >>> x=arange(2, typecode=Float) >>> x%10 array([ 0., 1.]) 
From: Charles G Waldman <cgw@fn...>  20000602 16:39:24

Czerminski, Ryszard writes: > > Is the behaviour illustrated below a bug or the Python's feature ? I don't know why you're posting this to the NumPy discussion list, since the "math" module is part of the standard Python distribution, not NumPy. Anyhow, the differing behaviors people are seeing are just coming from differences in the system math libraries: On Linux (Intel): Python 1.6a2 (#9, May 22 2000, 12:34:51) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Copyright 19952000 Corporation for National Research Initiatives (CNRI) >>> from math import exp >>> x = 706. >>> while x > 900: ... x = x  1 ... print 'x, exp(x) = %g %g' % (x, exp(x)) ... x, exp(x) = 707 8.99086e308 x, exp(x) = 708 3.30755e308 <snip> x, exp(x) = 745 4.94066e324 x, exp(x) = 746 0 <snip> x, exp(x) = 899 0 x, exp(x) = 900 0 >>> Wheras on Irix (MIPS): Python 1.6a2 (#8, Jun 1 2000, 20:01:55) [C] on irix646 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Copyright 19952000 Corporation for National Research Initiatives (CNRI) >>> from math import exp >>> x = 706. >>> while x > 900: ... x = x  1 ... print 'x, exp(x) = %g %g' % (x, exp(x)) ... x, exp(x) = 707 8.99086e308 x, exp(x) = 708 3.30755e308 x, exp(x) = 709 0 x, exp(x) = 710 0 <snip> x, exp(x) = 745 0 Traceback (most recent call last): File "<stdin>", line 3, in ? OverflowError: math range error From the Irix man page for exp(3M): The exp functions return HUGE_VAL when the correct value would overflow, and return zero if the correct value would underflow. The lm and lmx versions set the value of errno to ERANGE for both underflow and overflow. Since the Python math module sees errno set after the call to exp, it raises an exception. Whereas on Linux, exp(very big number) simply returns 0 and does not set errno. On the one hand, Python's behavior makes sense because it simply reflects the behavior of the system math libraries. On the other hand, these kinds of differences make it hard to write portable code  you could test on Linux and think everything is OK, then run on IRIX and get exceptions. Maybe that's just the way life is when you are using floatingpoint math... Tim Peters may have more to say on this topic <exp(900)wink> 
From: JeanBernard Addor <jbaddor@ph...>  20000602 16:32:39

Hey again! Why is (arange(2, typecode=Complex) % 2).typecode() object and not complex? JeanBernard Python 1.5.1 (#1, Dec 17 1998, 20:58:15) [GCC 2.7.2.3] on linux2 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Hello from .pythonrc.py >>> from Numeric import * >>> (arange(2, typecode=Complex) % 2).typecode() 'O' >>> arange(2, typecode=Complex) % 2 array([0j , (1+0j) ],'O') >>> arange(2) % 2 array([0, 1]) I have the same result python 1.5.2 and Numeric 11. 
From: Charles G Waldman <cgw@fn...>  20000602 16:02:07

JeanBernard Addor writes: > Hey Numeric people! > > Python 1.5.2 (#9, May 30 2000, 15:08:12) [GCC 2.95.2 19991024 (release)] > on linux2 > Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam > Hello from .pythonrc.py > >>> import Numeric > >>> Numeric.__version__ > '11' > >>> Numeric.arange(2)*1j > Segmentation fault > This seems to be fixed in the current CVS version. I suggest you either wait for the next release or grab the current version from CVS if this is really a problem for you. Python 1.6a2 (#9, May 22 2000, 12:34:51) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 19911995 Stichting Mathematisch Centrum, Amsterdam Copyright 19952000 Corporation for National Research Initiatives (CNRI) >>> import Numeric >>> Numeric.__version__ '15.2' >>> Numeric.arange(2)*1j array([ 0.+0.j, 0.+1.j]) 