From ptfenn@yahoo.com Mon Nov 1 15:33:19 1999 From: ptfenn@yahoo.com (Tom Fenn) Date: Mon, 1 Nov 1999 10:33:19 -0500 Subject: [Matrix-SIG] Using contiguous arrays with normal C syntax Message-ID: <02e001bf247e$70729560$14996382@mmm.com> Hello: I'm trying to use contiguous arrays using the normal C syntax. Here's some code that shows what I'm trying to do: PyObject *myfunction(PyObject *self,PyObject *args) { PyObject *input; PyArrayObject *array double **data; double x; int i,j; PyArg_ParseTuple(args,"O",&input); array = (PyArrayObject *) PyArray_ContiguousFromObject(input, PyArray_DOUBLE,2,2); data = (double **) array->data; for (i=0;i<10;i++) { for (j=0;j<10;j++) { x = data[i][j]; } } Py_INCREF(Py_None); return Py_None; } The data[i][j] line causes a seg fault. If I rewrite the line inside the loops as: x = *(double *) (array->data+i*array->strides[0]+j*array->strides[1]); then everything is fine. Seems I don't understand the relationship between pointers and arrays in C as well as I thought I did. Can anyone tell me what I'm doing wrong? Tom Fenn __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From dubois1@llnl.gov Mon Nov 1 16:00:04 1999 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 1 Nov 1999 08:00:04 -0800 Subject: [Matrix-SIG] Using contiguous arrays with normal C syntax References: <02e001bf247e$70729560$14996382@mmm.com> Message-ID: <000701bf2482$298e4000$3c810b18@plstn1.sfba.home.com> > data = (double **) array->data; Tom, Your problem is that array->data is a double*, not a double**. C allows you to create a two-dimensional array as an array of pointers, each pointing to an array of data, but that isn't how Numerical does it, for efficiency reasons. You don't want to be multiplying by strides in your "solution". Having made the data contiguous, treat it as if it were a one-dimensional array so the i, j 'th component is array->data[j + i * array->dimensions[0]] (I'm doing this off the top of my head so I may not have remembered the name of the dimension array correctly.) From pearu@ioc.ee Mon Nov 1 17:32:01 1999 From: pearu@ioc.ee (Pearu Peterson) Date: Mon, 1 Nov 1999 19:32:01 +0200 (EET) Subject: [Matrix-SIG] Bug in generating .pyc files? Message-ID: Hi, I have found the following problem: I have created a Python program and it works correctly on the first run. On the second (third,etc) run it works incorrectly. When I delete the .pyc file or edit the program, the same behaviour occurs: on the first run everything is OK, but on the following runs it works incorrectly again. So, I conclude that the code in .pyc file is incorrect (may be due to my incorrect program, but it shouldn't run on the first run, either). Unfortunately, I cannot give you much of details since my program is rather large and I don't know where to start looking for my or .pyc file bugs. Any ideas? I will sketch how my program works: There is two python files: sub.py, main.py. sub.py contains lots of useful functions that use global variables. main.py imports sub.py and calls these useful functions. Before the call, main.py changes the global variables in sub.py (In main.py 'sub.global_var=value', for example). My (pythons?) problem occures in the following: > python main.py Correct result > python main.py Incorrect result (meaning, strange behaviour) > rm sub.pyc > python main.py Correct result > python main.py Incorrect result etc. Again, any ideas what could be the problem? Thanks, Pearu Pearu Peterson , MSc, Researcher Department of Mechanics and Applied Mathematics http://koer.ioc.ee/~pearu/ Institute of Cybernetics at Tallinn Technical University Phone: (+372) 6204168 Akadeemia Rd. 21, 12618 Tallinn ESTONIA Fax: (+372) 6204161 *** the nonvalidity of rigorous causality is necessary and not just consistently possible (Heisenberg, 1925) *** From pearu@ioc.ee Mon Nov 1 18:12:12 1999 From: pearu@ioc.ee (Pearu Peterson) Date: Mon, 1 Nov 1999 20:12:12 +0200 (EET) Subject: [Matrix-SIG] Bug in generating .pyc files!!! Message-ID: I was able to track down where is the bug and I will demonstrate it below. Let main.py be: #!/usr/bin/env python import sub sub.sub() # EOF main.py and let sub.py be: def sub(): for l in ['1 2','3 4']: if l[1] is ' ': flag=1 else: flag=0 print flag,`l` #EOF sub.py Here are the results of repeated calls of main.py: > python main.py 1 '1 2' 1 '3 4' > python main.py 0 '1 2' 0 '3 4' > python main.py 0 '1 2' 0 '3 4' etc Note that program works correctly if line if l[1] is ' ': is replaced with if l[1]==' ': of course. I am using Python 1.5.2 (#4, Oct 26 1999, 18:40:59) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam So, it seems that 'is' is interpreted differently when .pyc file is used. I think this is a serious problem and should be fixed. With regards, Pearu Pearu Peterson , MSc, Researcher Department of Mechanics and Applied Mathematics http://koer.ioc.ee/~pearu/ Institute of Cybernetics at Tallinn Technical University Phone: (+372) 6204168 Akadeemia Rd. 21, 12618 Tallinn ESTONIA Fax: (+372) 6204161 *** the nonvalidity of rigorous causality is necessary and not just consistently possible (Heisenberg, 1925) *** From just@letterror.com Mon Nov 1 18:38:00 1999 From: just@letterror.com (Just van Rossum) Date: Mon, 1 Nov 1999 19:38:00 +0100 Subject: [Matrix-SIG] Bug in generating .pyc files!!! In-Reply-To: Message-ID: >So, it seems that 'is' is interpreted differently when .pyc file is used. >I think this is a serious problem and should be fixed. The 'is' operator tests for object identity, only use it when you know what you're doing ;-). You need the '==' operator. Just From da@ski.org Mon Nov 1 18:54:35 1999 From: da@ski.org (David Ascher) Date: Mon, 1 Nov 1999 10:54:35 -0800 (Pacific Standard Time) Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!! In-Reply-To: Message-ID: On Mon, 1 Nov 1999, Pearu Peterson wrote: [in the MATRIX-SIG, although i don't know why!] > I was able to track down where is the bug and I will demonstrate it below. > Let main.py be: #!/usr/bin/env python import sub sub.sub() # EOF main.py (here's DA's minimal version of Pearu's code): def sub(): l = ' ' print l[0] is l Here are the results of repeated calls of main.py: > python main.py 1 > python main.py 0 > python main.py 0 > So, it seems that 'is' is interpreted differently when .pyc file is used. > I think this is a serious problem and should be fixed. I agree. FWIW, IMO the right thing to do is to have the test return false all the time, but I agree that there should not be a dependence on byte-compilation. Guido? --david From guido@CNRI.Reston.VA.US Mon Nov 1 19:51:09 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 01 Nov 1999 14:51:09 -0500 Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!! In-Reply-To: Your message of "Mon, 01 Nov 1999 10:54:35 PST." References: Message-ID: <199911011951.OAA06335@eric.cnri.reston.va.us> > On Mon, 1 Nov 1999, Pearu Peterson wrote: [in the MATRIX-SIG, although i > don't know why!] > > > I was able to track down where is the bug and I will demonstrate it below. > > Let main.py be: > > #!/usr/bin/env python > import sub > sub.sub() > # EOF main.py > > (here's DA's minimal version of Pearu's code): > > def sub(): > l = ' ' > print l[0] is l > > Here are the results of repeated calls of main.py: > > > python main.py > 1 > > python main.py > 0 > > python main.py > 0 > > > So, it seems that 'is' is interpreted differently when .pyc file is used. > > I think this is a serious problem and should be fixed. > > I agree. FWIW, IMO the right thing to do is to have the test return false > all the time, but I agree that there should not be a dependence on > byte-compilation. > > Guido? The result of the 'is' operator on immutable objects (like strings) not well-defined. The Python VM is allowed but not required to cache objects with certain values and reuse them as the outcome of certain expressions (such as l[0] above) is it sees fit to optimize speed. The solution is not to use 'is' here but always to use '==' when comparing strings. This is definitely not a bug and definitely does not need to be fixed. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Tue Nov 2 04:18:55 1999 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 1 Nov 1999 23:18:55 -0500 Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!! In-Reply-To: Message-ID: <000601bf24e9$614428e0$0f2d153f@tim> [David Ascher, whittles down Pearu Peterson's "bug", which boils down to the unpredictability of "is" when applied to strings] [PP] > I think this is a serious problem and should be fixed. [DA] > I agree. FWIW, IMO the right thing to do is to have the test return false > all the time, but I agree that there should not be a dependence on > byte-compilation. > > Guido? Since he doesn't seem to be around, I'll channel him . "is" tests object identity, and so exposes accidents of the implementation if used in ill-advised ways. For immutable objects (like strings!) in particular, the implementation is free to reuse them *or* copy them at will, and whether e.g. "this works?"[-1] is "?" returns true can vary from release to release, platform to platform, or even from run to run. OTOH, constructors for *mutable* objects always create fresh objects, so [] is [] is guaranteed to return false everywhere. About the only guarantee you get for immutable objects is that x is y will return true if it follows x = y and neither name is rebound between them. If x and y are *computed* immutable values, nothing can be said a priori about the result of "x is y", beyond that x != y implies x is not y. IOW, the bug here was the use of "is" to begin with; object identity was simply not what the program intended to test. can't-remove-the-bug-without-removing-the-feature-too-ly y'rs - tim From skaller@maxtal.com.au Tue Nov 2 13:24:46 1999 From: skaller@maxtal.com.au (skaller) Date: Wed, 03 Nov 1999 00:24:46 +1100 Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!! References: <199911011951.OAA06335@eric.cnri.reston.va.us> Message-ID: <381EE61E.2CB58F2B@maxtal.com.au> Guido van Rossum wrote: > > The result of the 'is' operator on immutable objects (like strings) > not well-defined. The Python VM is allowed but not required to cache > objects with certain values and reuse them as the outcome of certain > expressions (such as l[0] above) is it sees fit to optimize speed. > > The solution is not to use 'is' here but always to use '==' when > comparing strings. > > This is definitely not a bug and definitely does not need to be fixed. FYI: Viper uses value comparisons on immutable objects; that is, 'is' and '==' are the same. -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller From olafb@pvv.org Tue Nov 2 12:57:02 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 02 Nov 1999 13:57:02 +0100 Subject: [Matrix-SIG] Optimization routines - anyone? Message-ID: Has someone coded a collection of optimization routines, e.g. SQP, for use with NumPy? Olaf janne@avocado.ps.helsinki.fi wrote 15 Mar 1999 23:09:22 +0200: |"Paul F. Dubois" writes: |> The conjugate gradient algorithm is probably about twenty lines or |> less of matrix/vector statements in Python, assuming you have a |> preconditioner you can express that way. So just code it up in |> Python. It will be fast enough, all the hard work is in the dot |> products and matrix multiplies. |I'm coding right now, just wanted to know if somebody has already |done it. |The hard work is often in the objective function, and from this |viewpoing C is unnecessary unless the objective function is very |fast. But a larger selection of optimization routines, either in |Python or in C, would be nice (and probably emerges) sooner or later. |-- |Janne -- * Olaf Trygve Berglihn From janne@nnets.fi Tue Nov 2 13:32:42 1999 From: janne@nnets.fi (Janne Sinkkonen) Date: 02 Nov 1999 15:32:42 +0200 Subject: [Matrix-SIG] Re: Optimization routines - anyone? In-Reply-To: Olaf Trygve Berglihn's message of "02 Nov 1999 13:57:02 +0100" References: Message-ID: Olaf Trygve Berglihn writes: > Has someone coded a collection of optimization routines, e.g. SQP, for > use with NumPy? Travis Oliphant has this: http://oliphant.netpedia.net/multipack.html I have a simple conjugate gradient and line minimization routines coded in Python (from Numeric Recipes). I'd also be interested in Python bindings to SQP. -- Janne From robin@jessikat.demon.co.uk Tue Nov 2 13:36:43 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 2 Nov 1999 13:36:43 +0000 Subject: [Matrix-SIG] Optimization routines - anyone? In-Reply-To: References: Message-ID: In article , Olaf Trygve Berglihn writes > >Has someone coded a collection of optimization routines, e.g. SQP, for >use with NumPy? > >Olaf > I've just been playing with Burke & Xu's non-interior point method for LCP's. I posted asking where this should be displayed/made available. Got no response. >janne@avocado.ps.helsinki.fi wrote 15 Mar 1999 23:09:22 +0200: >|"Paul F. Dubois" writes: > >|> The conjugate gradient algorithm is probably about twenty lines or >|> less of matrix/vector statements in Python, assuming you have a >|> preconditioner you can express that way. So just code it up in >|> Python. It will be fast enough, all the hard work is in the dot >|> products and matrix multiplies. > >|I'm coding right now, just wanted to know if somebody has already >|done it. > >|The hard work is often in the objective function, and from this >|viewpoing C is unnecessary unless the objective function is very >|fast. But a larger selection of optimization routines, either in >|Python or in C, would be nice (and probably emerges) sooner or later. > >|-- >|Janne > > -- Robin Becker From olafb@pvv.org Tue Nov 2 14:55:58 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 02 Nov 1999 15:55:58 +0100 Subject: [Matrix-SIG] Optimization routines - anyone? In-Reply-To: Robin Becker's message of "Tue, 2 Nov 1999 13:36:43 +0000" References: Message-ID: Hi, Robin. I don't know much about the method you are referring to, but you could possibly put it in ftp://ftp.python.org/pub/python/contrib/Math Look at instructions in ftp://ftp.python.org/incoming-instructions I guess that Travis Oliphant's multipack-site is a good place for optimization stuff. But if it's not convenient to put it there, I could make room for it at my place. It is not likely that I will make major contrubutions in this field, though. Optimization alorithms is not my speciality. Olaf * Robin Becker | In article , Olaf Trygve Berglihn | writes | > | >Has someone coded a collection of optimization routines, e.g. SQP, for | >use with NumPy? | > | >Olaf | > | | I've just been playing with Burke & Xu's non-interior point method for | LCP's. I posted asking where this should be displayed/made available. | Got no response. -- * Olaf Trygve Berglihn From Oliphant.Travis@mayo.edu Tue Nov 2 18:35:49 1999 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Tue, 2 Nov 1999 12:35:49 -0600 (CST) Subject: [Matrix-SIG] Optimization algorithms, etc. Message-ID: Robin, I remember your posting about Burke and Xu's LCP method and was interested, but October was a busy paper-writing month for me and so I spent all my time using Python and very little developing and communicating and none packaging. My vision for multipack is that it would be a community effort and your algorithm could find a very nice home there. Development of multipack takes place on a CVS server graciously provided by Pearu Peterson who has also contributed significantly to Multipack that I could get you access to. Alternatively, you could just send a tarball to me. But I have to admit that I'd prefer if authors took care of incorporating their own packages, as it would be more likely to show up in future editions. Multipack is very modular, so your wrapping could be dropped into the overall umbrella quite easily. There is documentation about how to do it in the release. I haven't checked this recently but you should be able to check out multipack from CVS anonymously (it's pretty big right now as it includes some alpha wrappings of all of the lapack and blas -- auto generated by Pearu's f2py code) so you might just want to get the tarball from my site. I'm very willing to receive improvements to Multipack from individuals anxious to see Numeric Python become a top-notch environment for general-purpose number crunching and algorithm development. I have not worked on Multipack actively for several months, and so my plan of incorporating all of my modules (signaltools, cephes, etc. into the multipack structure has not been realized...perhaps this is not such a good plan anyway (thoughts?) ) Sorry I did not get contact you sooner, it can be frustrating when you make this really neat algorithm available to Python and nobody seems to care. My experience is that people care quite a bit, but are pretty busy and don't have time to help so they are reluctant to comment. --Travis Oliphant P.S. For those on matrix-sig interested in the sparse matrix development: Currently, I'm improving the sparse matrix package that I discussed on this list several months ago so that it is actually useful to solve partial differential equations using finite elements and finite differences. I'm working on incorporating the package SuperLU for directly solving a sparse linear system and implementing at least the conjugate gradient algorithm (in Python) for iteratively solving the system. From robin@jessikat.demon.co.uk Tue Nov 2 16:31:34 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 2 Nov 1999 16:31:34 +0000 Subject: [Matrix-SIG] Optimization routines - anyone? In-Reply-To: References: Message-ID: In article , Olaf Trygve Berglihn writes >Hi, Robin. >I don't know much about the method you are referring to, but you could >possibly put it in ftp://ftp.python.org/pub/python/contrib/Math >Look at instructions in ftp://ftp.python.org/incoming-instructions > >I guess that Travis Oliphant's multipack-site is a good place for >optimization stuff. But if it's not convenient to put it there, I >could make room for it at my place. It is not likely that I will make >major contrubutions in this field, though. Optimization alorithms is >not my speciality. > >Olaf > others suggest I package it up and put it on my home page. I just thought there have been a few questions like yours recently. >* Robin Becker >| In article , Olaf Trygve Berglihn >| writes >| > >| >Has someone coded a collection of optimization routines, e.g. SQP, for >| >use with NumPy? >| > >| >Olaf >| > >| >| I've just been playing with Burke & Xu's non-interior point method for >| LCP's. I posted asking where this should be displayed/made available. >| Got no response. > -- Robin Becker From robin@jessikat.demon.co.uk Tue Nov 2 18:57:36 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 2 Nov 1999 18:57:36 +0000 Subject: [Matrix-SIG] Optimization algorithms, etc. In-Reply-To: References: Message-ID: In article , Travis Oliphant writes this particular algorithm is pure pyton+NumPy so I'll just post it to Travis. I have a C QP algorithm which I would like to package a bit more neatly before hacking that out. > >Robin, > >I remember your posting about Burke and Xu's LCP method and was >interested, but October was a busy paper-writing month for me and so I >spent all my time using Python and very little developing and >communicating and none packaging. > >My vision for multipack is that it would be a community effort and your >algorithm could find a very nice home there. Development of multipack >takes place on a CVS server graciously provided by Pearu Peterson who >has also contributed significantly to Multipack that I could get you >access to. Alternatively, you could just send a tarball to me. But I >have to admit that I'd prefer if authors took care of incorporating their >own packages, as it would be more likely to show up in future editions. >Multipack is very modular, so your wrapping could be dropped into the >overall umbrella quite easily. There is documentation about how to do it >in the release. > >I haven't checked this recently but you should be able to check out >multipack from CVS anonymously (it's pretty big right now as it includes >some alpha wrappings of all of the lapack and blas -- auto generated by >Pearu's f2py code) so you might just want to get the tarball from my site. > >I'm very willing to receive improvements to Multipack from individuals >anxious to see Numeric Python become a top-notch environment for >general-purpose number crunching and algorithm development. > >I have not worked on Multipack actively for several months, and >so my plan of incorporating all of my modules (signaltools, >cephes, etc. into the multipack structure has not been >realized...perhaps this is not such a good plan anyway >(thoughts?) ) > >Sorry I did not get contact you sooner, it can be frustrating when you >make this really neat algorithm available to Python and nobody seems to >care. My experience is that people care quite a bit, but are pretty busy >and don't have time to help so they are reluctant to comment. > > >--Travis Oliphant > >P.S. > >For those on matrix-sig interested in the sparse matrix development: > >Currently, I'm improving the sparse matrix package that I discussed on >this list several months ago so that it is actually useful to solve >partial differential equations using finite elements and finite >differences. I'm working on incorporating the package SuperLU for >directly solving a sparse linear system and implementing at least the >conjugate gradient algorithm (in Python) for iteratively solving the >system. > > > > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig -- Robin Becker From siegel@eico.com" Attached Python vecmath Version .20 November 2, 1999 Done by Arthur Siegel, ajs@ix.netcom.com Based on the following suppositions: 1- libraries are good for, among other things, helping people d oing similar things stay on the same page, and develop off one another 2-libraries without good documentation aren't very useful. 3-writing code is more fun than writing documentation 4-writing Python is more fun than writing Java. 5-I would like more company in writing 3d OpenGL stuff off of Python and there might be a population of folks who are interested in 3d but not particularly interested in wading into the Numeric library directly. the following arrangement was (wink) reached with the folks at Sun MicroSystems: I allowed them to port my vecmath library extension to Numeric as a Java3d extension in exchange for their services in writing documentation They have done a credible job. It is available as part of the Java3d documentation at I am looking for feedback, suggestions, help. My quaternion understanding sucks. I also have some PyOpenGL stuff ('dynamic geometry') written off of the vecmath library that I will be trying to talk David Ascher into including in the demos of the distribution, once I scale it down a bit to demo size. I would be happy to have anyone take a look but am without a site presence. Email me if interested. begin 600 pythonx.zip M4$L#!!0````(``:28B?PZ_\NNA4``"YS```*````=F5C;6%T:"YP>>4]_6_C MQK$_.X#_!^(.@4F9THFDV[XZ48!KFP(')$&;!$6;JR'0$N5C(%(R2?ET_NL[ MN[,?L\LE1F\_$(\UTV5EP_ZYZ>:=2[6:5U[\S^D=?:VJM)/MY=? M7"RSE3>?YV7>S.=^G:U78>-#S\XLLE\SHG.YT%X-;D*WH^C.S60$)J19]4O MB<_D`^O)5QZCS\E?7+#'&0?>E57ZE*U]SAQV`B@;R9O>3^^"&4=43]Z5S<_P MX&TJ=_^?UYN40P@B#!&PAJAGE%4)0.3!;A^!E?X$1Q?9NE98+[*J`CV!ZJ[R M]3I[2-=>N2ONL\K;K+QEVJ1,4)C_LJEOO7^6WI>U5V6/N[S*:O:L.LT?#_E3 M5EYY7_IJ;D);V:$21K)U4:5YG7D_?:J;K/BVJC95B,QA?[;N5F7=I.4BH]KB MY.JL^3-8JNRGTT)UL 6;:;3\BPW 5[M%`U.S@O\YTU<"ML4C:]?(@$4E\FQV M]7:?UV_+AW5VL[P2U-J3-)U,0_9_A'_M^2*>DT>YW)^H ?F-<19_7FW7?,I#=@:Z8+Z+J\;!<06/+<0! G M0EY]S1J\*YS$;UZA*- _0QA/BR:99/RQUBIK=E7IK8&":%.>BDVO\%0HBH#5 MKNC:8W]\K9'@/3/X5_SY57![1[#Q-NGX&N[?$"LS^%OD4!!(:S0:C3=L*+/M M?LKVBOD4%]^\PW<,QM&O/>ZI`3M(^+C+8!843I!*8?2DRD!2-PGFYS/8!RDAUR >^Y[UWYO!ZG2\R/3[T?NT>?OLK'5R[:(=/Z7H'ZFZ3A47# M^TP,;?*AYT(!I &!U"B'",U%2=6RS-;&M'"WTS3 HK?,*](!\&OHJ$20;'#R M+UXOQ>*B2-/[NC4SR$*U\*%SL]XUF3798FB9/70/';NG-ETNE5XVS8>L:J\, M-EH/OI;:06C$!6N+(P+E"914_[M[FT1KZDT:XQ:-"[V(AZ(S<72(7^S6@Y ! M7)-OU\82MIAD7+X&_CA*K@C^1.TE?QI$#.#R97: E-#&D3A-1"2\!U0KV\U' MB;0/)X!EU3 VC\(XC,GZL=)>T6U0`-%VBVQTL\&4T[58..Q$01#C:S8\JN 8 MFZ &_!N^3WX!EX=H.#,0V;74&.A]G[<@/I7[F!G'ZWY;D]\)8W^:9D66.]2-=I M!=D?)\3"($?2E]V]. DA^F,_A<9@@;LUIM1"5$=5)/4R;F*MH(Y,3#^._V^J M4R@38D(JX@7HTS*_R#:_2.>&J";B-C_#C L>[S\U6?TQW6ZS95?T(DN,0BL7 MD]8\@^1B>BI6]^)):Y:!^@H84'F>)_"I;-O!#PY7&8$8P9*4.G_N&:$@)--Y M#9N6)G_8;79USS *11R@D";T4C6A/(-C*;R?!H$WFWE3*P_E)L[6`TF@U38; M!LG5-7"2NV;9],0&?L$]I(0#_:@84(L!H4?.$'JV\&?:P)O;=\V@L8MM=/:,1^@$C;D;%-DL,7/_(\%ONC\GO^G^!'[;[=370NZ2R>GN31J0!7\_DCE4 M,"&1V/1^>AV:0_6OGL%'JYZ*\E:FX/N#27A+H&N92[Y(LNL!^CE51 @3&>RO MUB3-"_=1^$P,[-EM11?W69/.HO%SBW?]/&(PU\^C_3$3+/#NHQ9BUD/ULH^& MF,XI"X^ZX\3'OX8O3CJ<;X_#11XL9YNH$;9WE3-DL,?&D!N0/4DJ('"K=KI# M>4\N/IYI>WQG$N&M-@74/':A;O>8FWS"/\]!>+6\"FBF9>0&7,C!21:3TT&R*[(;X+HXZ5X#;VF^4`:_<`"MJ0 MU^7G,OUDZ5-UM.V]P\P3V\[!#%H&?F&26IV+U.H@J?MSD:I;I+BM4^>Q](F- M2N^Q[' ?+<((?KPV;U:4[.F$VKHTR=R?AXQ+CRH5^%O&S)\A>0TY`/YB^A,4 MEQMQPO 4(26Q"2S2ILKWK@N )YFY:,=4;JHB7BOL>3RM_R:K-G_(G\$&PY]8'EN@+7BW2DAU2*LZ\ MU&/7T![2\IZX'EZ=LL2ET(CI)]A*5^H$;Y "]6,+6QN-/LTWZ=%]++NT-R=Q M43A1%HMP)G&/@=&WIG-``IJSX*: M+PS,# /#`GV_L^@,]'R[B?M-*F#X% >6(?F^-%T(,Z.G6$48;^RIGICT1)"# M^J3%F:F"C8Z8&-CHF,K %@>O@K,(.V>E=UB;$(+.2M$5BI#>'S=K;B@B7>GR M#&V'( ;8I/KIB,B:W!]+Y_X0G0NM0DY*Y0K'BG1SG$@J63A6I)N#(JEJ^X)?>*[E"X#)?"$@W4)LY6^+,Y`$ 7 MEN\B)YYTN9S J!W;J3B.W273=.NH,.;ERHFS2/>'D2ECX?J$`,G_AOT9]*%] M\.#H*+!OJ\VOL,A-*5S7[9+U][?)W1OU(^%[W?ZTZQ7F73S'6HIN#_[;,G$E M`]#VRC:W&ZF27O_3K1&W(SJ30I@>>I5"80$T^BR*0M-9^OAWJ(=&Z"-B$ Y8 MG8=,7^C!(??G(>2(X@8=%L/Q82@A`7ZLYECP/@^A@[IC4?L\I'JWCM]SO^VX MU<..UK7>U,D+7QS.ZO@77^YQ+&U=\34I;IKE);->IW8/R[)1H",W@(?N#V$8 M\P&DGWA:K(G6G#KR_^,9(Y3?+:$U;SK.'G/:BPRP74C_7<11O&A.?MQ\1$.H M-A_IC"MW"TK+JL9UF,A8,"\&`TT1G2Y#>GLG3\(OM?M]R[&:OE>1E#1EE0,6 M#R38UXN]#[UCI'F(*D\W89.H.<6QX@CSG2A\0%W?+">H0%7Y<."H\L0I@@1S M5XA[Y<5F??Y9NF5H/]LLM;$/G24Q\C]YELB:_A:;]6IBFH%]S<'2K8B.Q5P$D1>N$L(AL(R*;C-&> M3PQ]DZ6-`:L!# S=9W(%.=3L*I[L'KTG@T\/)R>4S!+NR'#)!_:>LZZRLTB5 M\#BHM(-R?DP!*X%MF /UA:J@\%6H!); MD'.SB5B=;+KR4V,^3#28H%($/ZD2S/8P[2<\NG710T)>]4@R8=.S$!O4CR,^ MYD4&",ONQTV3LDV&X,5D@Q\ARH>7T1,4JTWS=Y08KWZ1U@*TA:M_VDX92]]1I-6>\3:IY-IJR-V=T2(R=7!42U:S1S1N+;:XRX\,>)I MP\<*_6.^7V1.EF/UN@O MGUFC+:$.V69;SWV6V:G,3M/LU*:8L)/-D[6SDC_U;0;4;"I>?BJ9;.R&S,H` MTE2P`2XGI#\P&V##HCVPB;Y:FK$X!?\;\9R1_)OQG+'ZJ202,[7FDC9MB M@=)[8\%A>22.P@$K6(1(2(4Y*8 MB"JYL*SLK[M4!.]'>-(F9ED7ZT0(8=NE]XTW%=8\BR&'YM9"TK^96"!/V2*: ML9$8"T53S#YO$8UX.]ZJP>^$-$YEXPUIQ,+;BH2R[4;"[-KR4P"8KF8 MB02E&QB.S$QM-+&B)$%:S,1"I!O%KP,+$"*\" 7IC$[E3V$AK:&>P5)_V*W3 M:L[/%>?+;+$I8!?)WP"VDWH8AK]:1V?LK%4=L/9Y1X:B^^P$V'V/GT6Q[JP2 M7SP$M\J5#KUA%ZQ8]T^_UT/\)$R"CHOEOGKS8CKMJ#@OIA&FB,P226LL6XDE M%1%BX?9&6B/92C%$L6RE&&*!(38PQ)%LI1CB6+;&QU:V^U+J4 HI'^(@]*4P MH>1?/NC.6';&LC..@\]>%"]-*&CM75$N`4?LO+,6GCE4H[S>\+3R2J,7A?XJ MDPN/S@M,9-+SZJL4'"9?2IZDN[W4F"B95%HQ+CSL&X\O:UU=#SSH&P_[E7_W M[8=6IKB%Y6OI\H 34");*9*QY&_TDK\DE]0GO&KB=@#1;XD'N EO6A[ )1V# M4SV\S3,^;V5^>>H8YQ$ZW <)9Z0O-ONH(Y@F9E_2=C,DN)&^R.QSN!P2S4A? M8O91>K%!S^F:2&PC?;'99SBZQ.RC]!*#7F+02R*SC])+8K./TDL2LP_I79[) M:%UZH6UY M\M:I$[VQ-C4%BN)G4.)N6RI,.7KO'?N$&+T@%V4LW9(X(F1-2DX"H]G!IQ0S M-[XSD1PKH&4L0L"V"D !K#9O,NT5JA5I%9&^2.M&AE6:2QN1I:%N*?AKH<%7 M"$6UQ#YO(K\!U*U^45-C;#W8T!ZTJP(>MEW].E6 MKXSC>HP^G^C/-EQ;#LV X[SP( /_>#D#A /'^=I!#GXY"P>8<8GEO_1-1]!. MLAQO]X@1@XHK+7JK<])SO9IGTKM1\MT<36]8\:A%;W5.>MVO'F(<,M^KQ+:! MWVDY5RVVMEJ#(+8VT0RQ^33?$'VQLX]9-)?CA$/6KK3[O^X=\0%%J?^Q"1+9 MOUD9TO=V@F1]0^\S;9^/W/R6:8$?M'+M?87^%YORUYW^.-VC=;?^:)/W&(6/5HW"(ZTY:B+*F5R2V.8L0Q(#N$FVAQ !V6\Z M#&9D)&!AT7C7GFQ/=/N4MD>ZG;_6*=MCW1[=A0:)Z#")B+;'!FE-8DI)FR3B MPR1BVCXU2(]=TDTM$HE!PLG5M -5U*$H]%X7+W*M8%/O2,$',RW/L*U2GH?, MF7'[DEC)/C\VG8A+!7)?]>^W18G:8&,DW6Q[T\?N?H[;W0^\15XJG09!28(S?6N82O[BJQB6*7'^6SO(0] MU64DU#/Y%0^D'$JC M`/7X[!+^:_:M2;^1WXFT!D,>LV#7^E)'>3EOQ*5^H_&(9E[LX, CRP`8O?$^ M!&SY"$F%]>[.56N-(_[AN1H\GKB/6U;K5[JB=T 3Q=(Q42;#NKM(*N=9# M^2!V,D+\Z>0W(U4)@2NK[2;4W3WSCEA288S[2ICVD3[..&F663.7N9#WM_P? M3VFJ=,&KLJ4O]:'Y&SJQM12^8?\X1"0J8@G+]0@85J#P_*;6$+R8@>''FH,Q MJQ_@%P'!B$!%"HK71R 4._8WH&(%Q2LQ$(I=< @HO6Z+=,]+%?8^_M_P.Y)0 M$&>?\A 48GWXZ/-!,T]"B_)BH@#9`Y1]B0E4HC!1]1#IM7XL!;5E5_@B(KLM M/*\0N?:DMDRPY)"^^>Z(RLKU<:OY`T/Y,%'R1HC%ET(JPE.7O-$`>>DLQEI_ MD27(=)A:$@+FM!SZ"@>=R!C!]:1>:VVT!8N58%]9DGWEY+EWCJ)A&D@(F,O< M7Q!3,25@,#CSLD3:C!SZ,= G1AB$?'*!T7LT)4ZFD,WA+U%S^-5YJ/2=[I$S M`<>KS:K3=1CFY*GG)KGS;6;]X4+G!XHO5.YBGHRQV=?<#P\,_ZY3+AZ^[),N MT4=JS0E'+SG[PF#Y__+\ZRP5)Y_QE,N=@?#@"ME.,_-U#L)>N@E&&#T8*'K4 M0F;1)*9).R17[NA7=9\."&JT-F?TZ!31U 26A1/,4\Z.2?Z8_GAL&+&ABA[W MYO+[:0PH9+E>HQ:XD16^D4.-17[\&N\JY&1Y=QK+<,C[MO0IY-_N\ZWSWR' M1!%">'C TH-6YR;JBE],07.V^-B_LS3SKN;S(H59F/-_K.]I)JZ6%)5 MS+Z7]W2\#8+.;\+?AK\+_R?\/?3_"U!+`P04````" "5F#XG'IGT>S\```!$ M````"P```%]?:6YI=%]?+G!Y4\[,+<@O*E$HKBS6R2_F4@;2>@6))1EZF7G% MJ44E&@8Z"O'Q(('X^&B#6.W\8KWBU )ML*JVP<``% E```.````5F5C;6%T:%1EMB2DMG^ZW='4A(IT8^D MKPU+XL0\W>/'N^.1/.>R+#)RRR997%^3))L594T.]_?DNWHY8U4[0IYV4"WA MP?X>FU5)6N3DA/BNQYPCI$W9)6'SFSBMK")GM*BO66D_V]\;)9=<(U+MDQ.N MW'V1%G']%MXB`W+$'[D8<8@0)#\1:81SC&9Q5>$;EE9,4LHDKTEK"FDEJV_* M?(,NQ DJP%Y2)7E5Q_F$XZ+/%TGU/+]*632U&TB6!X+PT%T<:$56"$H165+BV23.IUQPI$BL6J..!F*U5F+1PG(TF(NU M$C'.F HOB8%MZT[^=T_%&L[%42=#BI+T63!F'0LEP2$FN#M+D-OLH;Z(T\EP M?YD22J3YF21AIHODD Y%W3(G3Z4UM$";1!5J911V2.O12+QP$3Z_N#C]]:TU M*?)I4B=%3B=%EK&\/GF-*U"NR+RH2 :\_B))?:2:<>YU$793@EKNN. MN2RPN T5X5JVPE[\);CX<#1^%==EL@#IOQ- ]LM-7$=32I3Z1,F;`C@?M682 M=&,\P4#J)AM5G 31 M;7B$VEM?)04TI)&@!SK]B#I/[&/^)!PJ"=U)6525=>M38>PLX<4?"!" M< DE)X$Z1TH`SZQ0'NZ0_$DC\]J/5A'*:3:-0 MJ+L8U%_IZFU5OYBES'+#E#-?$MWL)K7.#4LK"R@YMU6N#-;RV1K.S#=5( `P M9; Q9$D>`TH;/?JXU9FSJ[AF"I1XV@+;A*4G%YKF%;K5S4>0:T:(WW./C!@! M?>.PT$WR6P9%4I?,3+4G"]$=_,$,,XSOB !!K".>4KT="==3) 7DDO.HUX2J M+.H_+'F0?/2XH=:0!16D1&;-3)Z9^;0UW*ZN3@D=B;H/!Q.%Z-GV)A2_M[SA MET 1@D'J#'#@+L15Q>@EY6QA>101Z1A,4)$0^]\"XAPABF.0988SU^&(^CDW MYC+F6] FLPJ;DGM")QO=VU9W*&>Z5YL#6CC%R;4Q:*:AB+:2=Y)S^<_=)4'H M_I)<^#YH\;N]RG6YK\35E(7;\ZZ)'<]KVS8*&C9131)D[R4IH-J&N6RKU.L* M.NPZ%Y,8W-?QR'3ODG_C0;*W`-9(_OQ&O2R0V%<&F38(^&"]C0K1POJ%8XPT MPBNMTP0Z:FQCI>?,)M!!WS^<\U#Y;?17H/E+X=OJI8%!_/9/VJP=6%0HFG@F5NQPQXZ"W MTW'J8'.9!WV"-I]8VUQ$,VCHF1CF$,L5@ IU`T*?Z50S![EY(]??8Q6[4H?Q MN*;J:+9"XPE*K02F.4KM#]9/32\@Z]5#D5^ 5_'/82 )2T%8MH25(*P$05/&1'?//U:,9L9VEG+3 MU\//G>!1T26BLEO$[?!S-S^UH]2Z_H!'-C>Q.]9W71,[:EL)5 L<'FN*"T"6 M7UFV*Z&/WX\A=U^_A%_C]X[O>J,`7AZ\X#C\`9^)A:!_J?SXPA;@"$S-;A4QM MF5V$!AV9'>!]SV;,YL14FS'#8K/-[O=HR-SU.KQ^)>3#>VZN:<\-'ZP(!BBV M4&/AI6+*??P4"-:UVW9A3&3](USA>7ZXP;#FHUI4DPS\```!$````"P`````````!`" `MH'B%0``7U]I;FET7U\N<'E0 M2P$"% `4````" "RD4PG,%^B'ML'``!0)0``#@`````````!`" `MH%*%@`` D5F5C;6%T:%1E Hey Numerical people! I wrote a python code for derivation in Fourrier space, and it gives very bad results. The idea is to multiply the transform of the data by -ik. Do you have any hint? Do you know about any code in any language which do that, and I could just translate into python? Are any books with detailled example of the use of the FFT to compute derivatives? Jean-Bernard def FFTderivative(a, order=1, axis=-1): from Numeric import arange from FFT import fft, inverse_fft a = Numeric.asarray(a) # works on arbitrary python sequence l = a.shape[axis]/2 m = a.shape[axis] - 2*l if axis != -1: a = Numeric.swapaxes(a, axis, -1) b = fft(concatenate((a, a[...,::-1]), -1)) # JD trick, could be made nicer c = (1j*concatenate((arange(a.shape[-1]),arange(-a.shape[-1],0))))**order #c = (1j*concatenate((arange(l+m),arange(-l,0))))**order # was before fourier space doubling # from the FT theory it should be -1j instead of 1j, why? d = b*c r = inverse_fft(d)[...,:a.shape[-1]] if a.typecode() != 'D' and a.typecode() != 'F': # not complex type r = r.real if axis != -1: r = Numeric.swapaxes(r, axis, -1) return r From warren@pfiesteria.gsfc.nasa.gov Thu Nov 4 22:37:47 1999 From: warren@pfiesteria.gsfc.nasa.gov (Warren B. Focke) Date: Thu, 4 Nov 1999 17:37:47 -0500 (EST) Subject: [Matrix-SIG] FFT derivative In-Reply-To: Message-ID: On Thu, 4 Nov 1999, Jean-Bernard ADDOR wrote: > Do you have any hint? Do you know about any code in any language which do > that, and I could just translate into python? Are any books with detailled > example of the use of the FFT to compute derivatives? Try this: -------------------------- import FFT, Numeric, umath def deriv(series, num=None, axis=-1): fspace = FFT.fft(series, num, axis) fspace = fderiv(fspace, num, axis) return(FFT.inverse_fft(fspace, num, axis)) def fderiv(fspace, num=None, axis=-1): if num == None: num = fspace.shape[axis] n2 = (num - 1) / 2 iomega = ((Numeric.arange(num) + n2) % num) - n2 iomega = iomega.astype('D') * 2.0 * Numeric.pi * 1.0j / num dims = len(fspace.shape) if dims > 1: newshape = [1] * dims newshape[axis] = num iomega.shape = newshape dspace = fspace * iomega # if the length is even, zero out the value at nyquist nyq = num / 2 if (nyq*2 == num): if dims > 1: sly = [slice(None)] * dims sly[axis] = nyq else: sly = nyq dspace[sly] = 0.0 return(dspace) ------------------------------ Note that the results will still look "bad" if the sequence you are taking the derivative of is not continuous at high order across its endpoints. > # from the FT theory it should be -1j instead of 1j, why? Probably because some people put the minus sign on the forward transform, and others on the reverse, and FFTPACK does the opposite of what you expected. Warren Focke From Oliphant.Travis@mayo.edu Fri Nov 5 08:53:01 1999 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Fri, 5 Nov 1999 02:53:01 -0600 (CST) Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python Message-ID: I've finally released Version 0.1 of a general purpose Sparse matrix package. It is available at http://oliphant.netpedia.net/packages/SparsePy.tgz RPMS for Linux may be available soon. The package requires a FORTRAN compiler, a C compiler, and a copy of the BLAS for your system. Currently the makefiles only work for a UNIX system using gcc and g77, they can be modified to work for any compiler. Features: * Initialization of Sparse Matrices using diagonal or coordinate convention. * Matrix-vector multiplies * Matrix-Matrix add, subtract, multiply, conjugate, transpose * Direct inversion of Sparse Linear Systems. The first three features are due Yousef Saad's SPARSEKIT2 package while the last feature is due to SuperLU by Demmel, Gilbert, and Li. The implementation is a Python class which has methods that call on wrapped versions of these libraries. There are other Sparse Matrix implementations available but this one is trying to be general purpose. Any suggestions and improvements are appreciated. Travis Oliphant Oliphant.Travis@altavista.net From parkw@better.net Fri Nov 5 12:05:00 1999 From: parkw@better.net (William Park) Date: Fri, 5 Nov 1999 07:05:00 -0500 Subject: [Matrix-SIG] FFT derivative In-Reply-To: References: Message-ID: <19991105070500.A6998@better.net> On Thu, Nov 04, 1999 at 05:00:43PM -0500, Jean-Bernard ADDOR wrote: > Hey Numerical people! > > I wrote a python code for derivation in Fourrier space, and it gives very > bad results. The idea is to multiply the transform of the data by -ik. > > Do you have any hint? Do you know about any code in any language which do > that, and I could just translate into python? Are any books with detailled > example of the use of the FFT to compute derivatives? Do you want h'(t) or H'(f)? For your reference, h'(t) <==> j2\pi f H(f) -j2\pi t h(t) <==> H('f) so the discrete version can be found by substituting f = n/(NT), t = kT where T is time sampling interval. > > > Jean-Bernard > > def FFTderivative(a, order=1, axis=-1): > from Numeric import arange > from FFT import fft, inverse_fft > a = Numeric.asarray(a) # works on arbitrary python sequence > l = a.shape[axis]/2 > m = a.shape[axis] - 2*l > if axis != -1: a = Numeric.swapaxes(a, axis, -1) > b = fft(concatenate((a, a[...,::-1]), -1)) # JD trick, could be made > nicer > c = > (1j*concatenate((arange(a.shape[-1]),arange(-a.shape[-1],0))))**order > #c = (1j*concatenate((arange(l+m),arange(-l,0))))**order # was before > fourier space doubling > # from the FT theory it should be -1j instead of 1j, why? The usual engineering convention is to use e^{-j2\pi ft} to go from time domain to frequency domain. But, there are people who still use e^{j2\pi ft} or, even worse, e^{j\omega t}. > d = b*c > r = inverse_fft(d)[...,:a.shape[-1]] > if a.typecode() != 'D' and a.typecode() != 'F': # not complex type > r = r.real > if axis != -1: r = Numeric.swapaxes(r, axis, -1) > return r > > > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig From robin@jessikat.demon.co.uk Fri Nov 5 14:11:09 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Fri, 5 Nov 1999 14:11:09 +0000 Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python In-Reply-To: References: Message-ID: In article , Travis Oliphant writes ... >There are other Sparse Matrix implementations available but this one is >trying to be general purpose. Any suggestions and improvements are >appreciated. > ... Of particular interest to optimisers and structural engineers are special solution methods for symmetric matrices. Ng & Peyton's method is widely used as part of the package PCx. It is originally coded in fortran, but is easy to move to C. I think it unlikely that the sparse matrix storage can easily be made fully dynamic as it uses parallel vectors representing super nodes etc. The strategy I have used in the past when converting fortran is to try and preserve the original assertions as elements are added/removed from the sparse matrix. I think for a Python module implementing various sparse matrix kinds there ought to be a standard API we can plug into. -- Robin Becker From robin@jessikat.demon.co.uk Fri Nov 5 14:48:25 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Fri, 5 Nov 1999 14:48:25 +0000 Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python In-Reply-To: References: Message-ID: <5LxzvBA54uI4Ew+A@jessikat.demon.co.uk> I downloaded SparesPy.tgz, but my winzip falls over with it. Should I try under Linux? -- Robin Becker From kern@its.caltech.edu Sun Nov 7 08:58:38 1999 From: kern@its.caltech.edu (Robert Kern) Date: Sun, 7 Nov 1999 00:58:38 -0800 (PST) Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python In-Reply-To: <5LxzvBA54uI4Ew+A@jessikat.demon.co.uk> Message-ID: On Fri, 5 Nov 1999, Robin Becker wrote: > I downloaded SparesPy.tgz, but my winzip falls over with it. Should I > try under Linux? Try downloading under Linux. I've had this problem with downloading any TGZ from Travis' site from a Windows browser. It may be a misconfiguration of the server. To Someone-In-The-Know: Could it be a problem with Travis' .htacces file? On a related note, I'm away from my Windows development environment for the nonce. Can someone else use mingw32 (or MSVC if you have it) to compile up Windows binaries? I'll put them up on the Starship. > -- > Robin Becker -- Robert Kern kern@caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From robin@jessikat.demon.co.uk Mon Nov 8 17:18:02 1999 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 8 Nov 1999 17:18:02 +0000 Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs In-Reply-To: References: <199911060602.BAA18489@python.org> Message-ID: In article , Travis Oliphant writes >> ... > ... > >I actually rather like using Fortran as a low-level language as it is much >easier to wrap (despite SWIG) --- arguments are always pointers to basic >data types in FORTRAN. > Is modern Fortran dynamic? I have heard so, but few of the old timers like me seem to believe. >> I downloaded SparesPy.tgz, but my winzip falls over with it. Should I >> try under Linux? > >I'm not sure what this problem is. I've heard this before off and on. I >think there may be a problem with WinZip understanding *.tgz files. I've >heard that simply renaming the file may help. But I don't know. > >If somebody knows what's up I'd appreciate hearing about it. > >Travis > > I tried to decode the .tgz with my rh 6.1 tar tzvf, but that also fails. I will have to try and download under Linux. Win32/Unix downloads don't seem to work sometimes. -- Robin Becker From Oliphant.Travis@mayo.edu Mon Nov 8 17:09:23 1999 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Mon, 8 Nov 1999 11:09:23 -0600 (CST) Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs In-Reply-To: <199911060602.BAA18489@python.org> Message-ID: > ... > Of particular interest to optimisers and structural engineers are > special solution methods for symmetric matrices. Ng & Peyton's method is > widely used as part of the package PCx. It is originally coded in > fortran, but is easy to move to C. I think it unlikely that the sparse > matrix storage can easily be made fully dynamic as it uses parallel > vectors representing super nodes etc. The strategy I have used in the > past when converting fortran is to try and preserve the original > assertions as elements are added/removed from the sparse matrix. I think > for a Python module implementing various sparse matrix kinds there ought > to be a standard API we can plug into. I actually rather like using Fortran as a low-level language as it is much easier to wrap (despite SWIG) --- arguments are always pointers to basic data types in FORTRAN. > I downloaded SparesPy.tgz, but my winzip falls over with it. Should I > try under Linux? I'm not sure what this problem is. I've heard this before off and on. I think there may be a problem with WinZip understanding *.tgz files. I've heard that simply renaming the file may help. But I don't know. If somebody knows what's up I'd appreciate hearing about it. Travis From olafb@pvv.org Tue Nov 9 14:48:31 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 09 Nov 1999 15:48:31 +0100 Subject: [Matrix-SIG] Wrapper for FSQP, anyone? Message-ID: I've obtained a licence for non-comercial, academic use of the SQP optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to use this with python, with help from Pyforth. Has anyone made the necessary modifications to the main sub-routine and written the .pyf file? Olaf -- * Olaf Trygve Berglihn From olafb@pvv.org Tue Nov 9 15:02:16 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 09 Nov 1999 16:02:16 +0100 Subject: [Matrix-SIG] Wrapper for FSQP, anyone? In-Reply-To: Olaf Trygve Berglihn's message of "09 Nov 1999 15:48:31 +0100" References: Message-ID: BTW: I'd also like to know if you successfully have used NAG E04UCF or equivalent SQP routine with pyforth. Olaf * Olaf Trygve Berglihn | I've obtained a licence for non-comercial, academic use of the SQP | optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of | Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to | use this with python, with help from Pyforth. Has anyone made the | necessary modifications to the main sub-routine and written the .pyf | file? -- * Olaf Trygve Berglihn From olafb@pvv.org Tue Nov 9 17:17:23 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 09 Nov 1999 18:17:23 +0100 Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs In-Reply-To: Robin Becker's message of "Mon, 8 Nov 1999 17:18:02 +0000" References: <199911060602.BAA18489@python.org> Message-ID: * Robin Becker | I tried to decode the .tgz with my rh 6.1 tar tzvf, but that also fails. | I will have to try and download under Linux. Win32/Unix downloads don't | seem to work sometimes. | -- | Robin Becker I also think there is a problem with the web-server configuration at oliphant.netpedia.net. tgz-files are downloaded as text. The following line in a .htaccess file on the server side (if Apache is used) will do it: AddType application/x-gzip .tgz -- * Olaf Trygve Berglihn From olafb@pvv.org Tue Nov 9 18:11:39 1999 From: olafb@pvv.org (Olaf Trygve Berglihn) Date: 09 Nov 1999 19:11:39 +0100 Subject: [Matrix-SIG] Wrapper for FSQP, anyone? In-Reply-To: Olaf Trygve Berglihn's message of "09 Nov 1999 15:48:31 +0100" References: Message-ID: Hmm... I guess it is not this simple (never worked with Pyfort before). The fortran code needs a function on which to iterate, and I want this to be a python function. * Olaf Trygve Berglihn | I've obtained a licence for non-comercial, academic use of the SQP | optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of | Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to | use this with python, with help from Pyforth. Has anyone made the | necessary modifications to the main sub-routine and written the .pyf | file? -- * Olaf Trygve Berglihn From Raphael.Guerois@EMBL-Heidelberg.de Tue Nov 9 18:13:11 1999 From: Raphael.Guerois@EMBL-Heidelberg.de (Raphael Guerois) Date: Tue, 9 Nov 1999 19:13:11 +0100 (MET) Subject: [Matrix-SIG] MMTK and Surface Calculation Message-ID: Hi Does anyone tried the method surfaceAndVolume() in mmtk module? I don't manage to to run it from this small script... Do you any idea ?... Thanks! Raphael from mmtk import * import PDB,Units seq=PDB.PDBFile('/data/pdb/1shg.brk').readSequence(1) seq.deleteHydrogens() prot = PeptideChain(seq[0],hydrogens=0) surface,volume = prot.surfaceAndVolume(probe_radius=1.4 * Units.Ang) resulted in : >>> ## working on region in file /usr/tmp/python-3... Process Python segmentation violation (core dumped) From kern@its.caltech.edu Tue Nov 9 19:49:01 1999 From: kern@its.caltech.edu (Robert Kern) Date: Tue, 9 Nov 1999 11:49:01 -0800 (PST) Subject: [Matrix-SIG] Wrapper for FSQP, anyone? In-Reply-To: Message-ID: On 9 Nov 1999, Olaf Trygve Berglihn wrote: > Hmm... I guess it is not this simple (never worked with Pyfort > before). The fortran code needs a function on which to iterate, and I > want this to be a python function. Travis Oliphant did this in his Multipack interface. Look at his code: http://oliphant.netpedia.net/multipack [snip] > -- > * Olaf Trygve Berglihn -- Robert Kern kern@caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From Oliphant.Travis@mayo.edu Tue Nov 9 22:34:00 1999 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Tue, 9 Nov 1999 16:34:00 -0600 (CST) Subject: [Matrix-SIG] New file names at http://oliphant.netpedia.net Message-ID: I've changed the filenames for the files on http://oliphant.netpedia.net to see if that helps the downloading problems for Windows users. All *.tgz files have been renamed to *.tar.gz I hope this helps the problem. If you get the chance, let me know if it does or doesn't help. Thanks, Travis From hinsen@dirac.cnrs-orleans.fr Fri Nov 12 16:35:44 1999 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Fri, 12 Nov 1999 17:35:44 +0100 Subject: [Matrix-SIG] MMTK and Surface Calculation In-Reply-To: (message from Raphael Guerois on Tue, 9 Nov 1999 19:13:11 +0100 (MET)) References: Message-ID: <199911121635.RAA08889@chinon.cnrs-orleans.fr> > Does anyone tried the method surfaceAndVolume() in mmtk module? I don't > manage to to run it from this small script... Do you any idea ?... Thanks! It works in the most recent MMTK version (2.0), but it didn't work in some earlier versions when used with newer releases of NumPy. I recommend upgrading to the most recent versions, but if you want to go on with what you have, replace the function init_surface in the file _surface.c by this one: init_surface() { PyObject *m; /* Create the module and add the functions */ m = Py_InitModule("_surface", surface_methods); /* Import the array module */ #ifdef import_array import_array(); #endif /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module _surface"); } I suppose that in your copy the line "import_array();" is missing, and that causes an immediate crash with sufficiently new NumPy versions. BTW, a better place for such questions is the MMTK mailing list! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From jbaddor@sca.uqam.ca Sat Nov 13 02:29:15 1999 From: jbaddor@sca.uqam.ca (Jean-Bernard ADDOR) Date: Fri, 12 Nov 1999 21:29:15 -0500 (EST) Subject: [Matrix-SIG] -1%2 = 1 and array([-1])%2 = array([-1]) Why? Message-ID: Hey Numerical people! I just tried the following: >>> -1%2 1 >>> array([-1])%2 array([-1]) I would have expected array([+1]). What is the philosophical reason Numerical should give another result than nude python? Jean-Bernard Python 1.5.1 (#1, Dec 17 1998, 20:58:15) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Debian python-numer 1.7-7.1 From hinsen@cnrs-orleans.fr Mon Nov 15 15:11:45 1999 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 15 Nov 1999 16:11:45 +0100 Subject: [Matrix-SIG] -1%2 = 1 and array([-1])%2 = array([-1]) Why? In-Reply-To: (message from Jean-Bernard ADDOR on Fri, 12 Nov 1999 21:29:15 -0500 (EST)) References: Message-ID: <199911151511.QAA11403@chinon.cnrs-orleans.fr> > I just tried the following: > > >>> -1%2 > 1 > >>> array([-1])%2 > array([-1]) > > I would have expected array([+1]). > > What is the philosophical reason Numerical should give another result than > nude python? Python has a well-defined rule for the modulo operator. NumPy just applies the C modulo operator, which if I remember correctly gives different results on different machines, guaranteeing only that b*(a/b) + (a%b) == a. I have pointed out the different outcome a while ago, but noone else seemed to see this as a problem. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------