Mailman 3 December 2007 - NumPy-Discussion

matrix multipln takes too much time
by devnew＠gmail.com Dec. 26, 2007

Dec. 26, 2007

hi i am doing some maths calculations involving matrices of double values using numpy.matrix , java code for this is something like int items=25; int sample=5; int totalcols=8100; double[][]dblarrayone=new double[items][totalcols]; double[][]dblarraytwo=new double[items][totalcols]; //their elements are set elsewhere before calculation double[][] resultarray = new double[items][sample]; for(int i=0;i<items;i++){ for(int j=0;j<sample;j++){ double tval=0.0; for(int p=0;p<totalcols;p++) tval+=dblarrayone[j][p] * dblarraytwo[i][p]; resultarray[i][j]=Math.abs(tval); } } so I wanted to do the same in python..(may be this code is not in the recommended way..) i am storing the filled matrices and other values as instance variable of a class and access them by self.whatever... self.items=25 self.sample=5 self.totalcols=8100 #self.matrixone,self.matrixtwo are numply matix objects with already filled elements #but for testing i filled it with zeros self.matrixone=matrix(zeros((items,totalcols))) self.matrixtwo=matrix(zeros((items,totalcols))) resultmatrix=matrix(zeros((self.items,self.sample))) for i in range(self.items): for j in range(self.sample): tval=0.0 for p in range(self.totalcols): tval +=self.matrixone[ j , p ] * self.matrixtwo[ i , p ] resultmatrix[ i, j ]=abs(tval) here I found that while the java code takes barely 110 milliseconds to execute the code ,the python code takes something like 53 secs to execute !!..I am baffled by this ..can anyone advise me how i can improve this? (i want to code in python so I can't use c,c++ , java) dn

3 3

distutils_scons_command branch: 2nd step towards scons support in numpy
by David Cournapeau Dec. 26, 2007

Dec. 26, 2007

Hi, I have started publishing the distutils_scons_command branch in numpy svn repository. This implements all the distutils infrastructure necessary to call scons, by using the scons distutils command. In more details: - distutils setup files can ask for a different name for setup file: if the top setup file calls the Configuration __init__ function with setup_name argument = foo.py, it will recursively call foo.py instead of setup.py. This is useful to have several build configuration in parrallel (so that we can include setup.py files using the current build system, and setupscons.py files which use scons instead). - the scons distutils command is implemented. For every scons script file registered through the add_sconscript method, it will call scons. If at least one scons script is registered, it will need the numscons package. If no scons scripts files are registered, the command does nothing. Once those code changes are integrated in numpy trunk, the last step for a working scons solution will be the release of numscons, which implements all the functionalities to use scons script files easily within numpy code. The plan is to be able to optionally build numpy 1.0.5 using scons. cheers, David

1 0

gfortran/g77+f2py vs gcc+Cython speed comparison
by Ondrej Certik Dec. 24, 2007

Dec. 24, 2007

Hi, I needed to write 2D Ising model simulation into my school and I decided to compare the two possible solutions how to do it, so I of course wrote it in Python, then rewrote it in Fortran + f2py, and also Cython. What is better? Read below. :) But for the impatient, I am going to use Cython, reasons below. CCing to Cython, numpy (f2py is discussed there), and sage-devel (there are people there who could be interested in these kinds of comparisons). The code is available at: http://hg.sharesource.org/isingmodel/ How to play with that - just do this (after installing Mercurial): $ hg clone http://hg.sharesource.org/isingmodel/ [...] $ cd isingmodel $ hg up db7dd01cdc26 # just to be sure that we are talking about the same revision / code $ make [...] $ time python simulate.py [...] real 0m2.026s user 0m1.988s sys 0m0.020s This runs Cython code. Then apply this patch to run fortran code instead: $ hg di diff -r db7dd01cdc26 simulate.py --- a/simulate.py Sun Dec 23 02:23:30 2007 +0100 +++ b/simulate.py Sun Dec 23 02:24:33 2007 +0100 @@ -31,8 +31,8 @@ def MC(mu = 1, temp = 2, dim = 20, steps J=1 #coupling constant k=1 #Boltzman constant - #from mcising import mc - from pyising import mc + from mcising import mc + #from pyising import mc B = D1(A) mc(B, dim, steps, temp, H, mu, J, k) return D2(B) And then again (and apply the patch below, otherwise it might not work for you): $ time python simulate.py [...] real 0m3.600s user 0m3.528s sys 0m0.052s So it's a lot slower. We are comparing many things here - wrappers, my fortran coding skills vs Cython C code generation and gcc vs gfortran. So I wrote to numpy mailinglist. First Travis (the author of numpy) suggested: " My experience with similar kinds of comparisons is that gnu fortran compilers are not very good, especially on 2-d problems. Try using a different fortran compiler to see if speeds improve. " Then Pearu (the author of f2py) suggested: " Though the problem is 2D, your implementations are essentially 1D. If you would treat the array A as 2D array (and avoid calling subroutine p) then you would gain some 7% speed up in Fortran. When using -DF2PY_REPORT_ATEXIT for f2py then a summary of timings will be printed out about how much time was spent in Fortran code and how much in the interface. In the given case I get (nsteps=50000): Overall time spent in ... (a) wrapped (Fortran/C) functions : 1962 msec (b) f2py interface, 60 calls : 0 msec (c) call-back (Python) functions : 0 msec (d) f2py call-back interface, 0 calls : 0 msec (e) wrapped (Fortran/C) functions (acctual) : 1962 msec that is, most of the time is spent in Fortran function and no time in wrapper. The conclusion is that the cause of the difference in timings is not in f2py or cpython generated interfaces but in Fortran and C codes and/or compilers. Some idiom used in Fortran code is just slower than in C.. For example, in C code you are doing calculations using float precision but in Fortran you are forcing double precision. HTH, Pearu PS: Here follows a setup.py file that I used to build the extension modules instead of the Makefile: #file: setup.py def configuration(parent_package='',top_path=None): from numpy.distutils.misc_util import Configuration config = Configuration('',parent_package,top_path) config.add_extension('mcising', sources=['mcising.f'], define_macros = [('F2PY_REPORT_ATEXIT',1)] ) #config.add_extension('pyising', sources=['pyising.pyx']) return config from numpy.distutils.core import setup setup(configuration = configuration) " and then quickly added " When using g77 compiler instead of gfortran, I get a speed up 4.8 times. Btw, a line in a if statement of the fortran code should read `A(p(i,j,N)) = - A(p(i,j,N))`. " (btw I have no idea how it could work for me without the A(p(i,j,N)) = - A(p(i,j,N)) fix, quite embarassing) So then we discussed it on #sympy IRC: * Now talking on #sympy <ondrej> hi pearu, thanks a lot for testing it! <ondrej> 4.8 speedup, jesus christ. so the gfortran sucks a lot <pearu> hey ondrej * ondrej is trying g77 <pearu> gortran has advantage of being Fortran 90 compiler <ondrej> g77 is depricated in Debian and dead upstram (imho) <pearu> yes but I guess those guys who are maintaing g77/gfortran, those do not crunch numbers much;) <pearu> g77 has a long development history and is well optimized <ondrej> I fear the fortran is a bad investment for new projects <ondrej> I know g77 is well optimized, but it's dead <pearu> gfortran is a write from scratch and is too young <ondrej> do you think many people still write fortran? I use it just because g77 was faster than gcc <pearu> g77 is certainly not dead, scientist use it a lot because of its speed <ondrej> btw`A(p(i,j,N)) = - A(p(i,j,N))`. <ondrej> means my fortran code was broken <ondrej> doesn't it? <pearu> some think that fortran is a dead language, some use it a lot because lots of code is written in fortran over several decades <ondrej> yes <pearu> yes, it was, I got segfaults because of that <ondrej> I don't know what to think myself <pearu> it depends on application <pearu> if it is a research app then use fortran because of speed <ondrej> but as you can see, you need to use g77 <ondrej> and not gfortran <ondrej> (but all Debian is moving to use gfortran) <pearu> I use gfortran only for f90 code <ondrej> hm <pearu> I think Debian is wrong in short term, may be in future gfortran will be faster, but not at the moment <ondrej> hm, that's bad <ondrej> but is someone developing g77? <pearu> no, I don't think so <ondrej> debian moved to gfortran, because there are problems with g77 being umaintained <pearu> but it is a complete Fortran 77 compiler and a very good one <ondrej> hm. I think when one wants speed, one should use some comercial compilers <pearu> probably because new architectures are developed and g77 is not updated to use their features <ondrej> and when one wants robustness, it should use a free compiler that is maintinaed (gfortran) <pearu> commercial compilers does not mean fast compliers, in general <ondrej> I didn't try intel, so I don't know how it compares to g77 <pearu> using intel restricts one to be on Intel platform <ondrej> the g77 doesn't support -fdefault-real-8 for example <pearu> AMD is daster in floating point that most scientist use <pearu> why is this flag important, one can always write real*8 <ondrej> indeed, g77 is 1.8s and gcc 2.0s on my comp <ondrej> as to real*8 - I thought a good strategy is to write real and let the compiler choose the precision <pearu> try to use float in fortran as you do in C <ondrej> ok <pearu> this will mess up f2py-ing as f2py assumes that real is real*4 <ondrej> yes - <ondrej> real*4 is float, isn't it? <pearu> yes <ondrej> so I'll just use real*4 everywhere <pearu> yep <ondrej> ok <ondrej> btw, I was writing a python script for automatically converting real*4 to real*8 and back <ondrej> but it's freaking hard to parse fortran <ondrej> (I needed to also work with "real", etc) <ondrej> I only managed it to work in simple cases <pearu> just do re.sub <ondrej> it's not that easy <ondrej> there are constructs like real(something) <ondrej> that shouldn't be converted <ondrej> but real T should be converted <ondrej> etc. <ondrej> so using real*4 with g77 slowed the code done from 1.8s to 1.9s <pearu> re.sub should be able to handle these, use cb argument, fo instance <ondrej> ok <pearu> you are using random numbers, could this make also a difference <ondrej> I think it does <ondrej> (I had to use glibc fast random to speed C up) <pearu> a, ok, that also explains things <ondrej> shit, the gfortran is really slow <ondrej> 3.5s on my comp <ondrej> no matter which precision <pearu> try to disable random to see if loops are faster in C or fortran <ondrej> ok <ondrej> so gfortran is now 1.3s <ondrej> and g77 1.04s * ondrej is trying C <ondrej> C is 1.05s <pearu> so gfortran random is slow <ondrej> yes <ondrej> g77 random is fast <ondrej> C random is slower than g77 <ondrej> it depends on the quality of the random generator as well <ondrej> there are huge differences in that <pearu> and so gfortran itsel is not too bad <pearu> :) <ondrej> but as you can see - there is no point for me to use g77 if I can achieve the same speed with C <ondrej> and gfortran is slower than both <pearu> yep <ondrej> ok, going to write this to the list <pearu> can you try ifc <ondrej> I'll also send it to the Cython guys, they'll like the result. :) <ondrej> ifc = intel fortran compiler? <pearu> yes <ondrej> I like opensource and Debian <ondrej> I think this clearly shows, that fortran is dead for me. I think gcc is pretty good too. <pearu> note that these results are not thanks to pyrex /cpython but thanks to compilers:) <pearu> i like to be fair;) <ondrej> (yes, it's just compilers comparison, not f2py vs Cython/pyrex) <pearu> yep <ondrej> but there are two ways a user can choose - either cython+gcc, or f2py+fortran <pearu> next time we shoul probably have this discussion inscipy irc <ondrej> and if he wants to use the most recent default free compilers, at least I will choose cython+gcc <pearu> there are more ways, weave, etc etc <ondrej> I am going to paste this to my email about that <pearu> ok <ondrej> (if you are ok with that) <pearu> ok with me So, what do you think of that? Ondrej

2 3

matlab to numpy help
by Gabriel J.L. Beckers Dec. 23, 2007

Dec. 23, 2007

I found a matlab script that I want to translate into numpy, but have difficulties with understanding indexing in matlab. I haven't used matlab very much and I was hoping that someone could help with the following: It says: Uns = ones(1,m); ... and then later Xijm(:,Uns); m is a positive integer. The problem is that Xijm should be a 1-dimensional array (I think), so what is Uns doing in the second statement? Is this some way to expand Xijm into a second dimension? What would be a numpy equivalent? Gabriel

3 2

setting items in a matrix
by devnew＠gmail.com Dec. 23, 2007

Dec. 23, 2007

hi i am a beginner with numpy and python,so pardon me if this doubt seems silly i want to create a matrix with say 3 rows and 5 columns..and then set the values of each item in it .for this i did something like below myarray=zeros((3,5)) #then set the items for row in range(3): for col in range(5): myarray[row][col]=999999.9999 mymatrix=matrix(myarray) is this the way to do the matrix creation and value setting? is the use of zeros() unnecessary? i am in the early learning stage so your reply wd help me much dn

4 3

ising model: f2py vs cython comparison
by Ondrej Certik Dec. 23, 2007

Dec. 23, 2007

Hi, I need to write 2D Ising model simulation into my school, so I wrote it in Python, then rewrote it in Fortran + f2py, and also Cython: http://hg.sharesource.org/isingmodel/ And Cython solution is 2x faster than f2py. I understand, that I am comparing many things - wrappers, my fortran coding skills vs Cython C code generation and gcc vs gfortran. But still any ideas how to speed up fortran+f2py solution is very welcomed. How to play with that - just do this (after installing Mercurial): $ hg clone http://hg.sharesource.org/isingmodel/ [...] $ hg up db7dd01cdc26 # just to be sure that we are talking about the same revision / code $ cd isingmodel $ make [...] $ time python simulate.py [...] real 0m2.026s user 0m1.988s sys 0m0.020s This runs Cython code. Then apply this patch to run fortran code instead: $ hg di diff -r db7dd01cdc26 simulate.py --- a/simulate.py Sun Dec 23 02:23:30 2007 +0100 +++ b/simulate.py Sun Dec 23 02:24:33 2007 +0100 @@ -31,8 +31,8 @@ def MC(mu = 1, temp = 2, dim = 20, steps J=1 #coupling constant k=1 #Boltzman constant - #from mcising import mc - from pyising import mc + from mcising import mc + #from pyising import mc B = D1(A) mc(B, dim, steps, temp, H, mu, J, k) return D2(B) And then again: $ time python simulate.py [...] real 0m3.600s user 0m3.528s sys 0m0.052s So it's a lot slower. Maybe I did some stupid mistake, like doing different amount of steps in Cython and Fortran, but I tried to check that and if I did everything all right, it's interesting to find why is fortran+f2py slower. Ondrej

3 4

Re: [Numpy-discussion] [SciPy-dev] SciPy Sprint results
by Travis E. Oliphant Dec. 22, 2007

Dec. 22, 2007

Stefan van der Walt wrote: > Hi Travis, > > During the sprint I also merged Pierre's MaskedArray code into the > maskedarray branch. That is nearly done, with only a few unit tests > still failing -- ones brought over from the old numpy.ma. > > This is mainly due to some changes in the API, for example put and > putmask now behave like their ndarray counterparts. Pierre, would you > remind us of any other such changes, and why they were made? > > What is the road forward with this code? We will probably only merge > API changes into 1.4. Do we use svnmerge to keep the branch up to > date until then? > I'd like to move forward with it sooner (for 1.0.5) if the API changes are not drastic. Although ideally 0 API changes would be desireable, I'm not sure if that is feasible. Are put and putmask the only changes in the API. What are the rest of them? -Travis

4 8

new P3 binaries for NumPy 1.0.4 and SciPy 0.6.0
by Jarrod Millman Dec. 21, 2007

Dec. 21, 2007

Hey, If you are having problems with NumPy and SciPy on Pentium III machines running Windows, please try the newly released binaries: numpy-1.0.4.win32-p3-py2.3.exe numpy-1.0.4.win32-p3-py2.4.exe numpy-1.0.4.win32-p3-py2.5.exe numpy-1.0.4.win32-p3-py2.5.msi scipy-0.6.0.win32-p3-py2.3.exe scipy-0.6.0.win32-p3-py2.4.exe scipy-0.6.0.win32-p3-py2.5.exe scipy-0.6.0.win32-p3-py2.5.msi Enjoy, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

3 2

setting items in a matrix
by devnew＠gmail.com Dec. 21, 2007

Dec. 21, 2007

hi i am a beginner with numpy and python,so pardon me if this doubt seems silly i want to create a matrix with say 3 rows and 5 columns..and then set the values of each item in it .for this i did something like below myarray=zeros((3,5)) #then set the items for row in range(3): for col in range(5): myarray[row][col]=999999.9999 mymatrix=matrix(myarray) is this the way to do the matrix creation and value setting? is the use of zeros() unnecessary? i am in the early learning stage so your reply wd help me much dn

3 2

Loading a > GB file into array
by Martin Spacek Dec. 21, 2007

Dec. 21, 2007

I need to load a 1.3GB binary file entirely into a single numpy.uint8 array. I've been using numpy.fromfile(), but for files > 1.2GB on my win32 machine, I get a memory error. Actually, since I have several other python modules imported at the same time, including pygame, I get a "pygame parachute" and a segfault that dumps me out of python: data = numpy.fromfile(f, numpy.uint8) # where f is the open file 1382400000 items requested but only 0 read Fatal Python error: (pygame parachute) Segmentation Fault If I stick to just doing it at the interpreter with only numpy imported, I can open up files that are roughly 100MB bigger, but any more than that and I get a clean MemoryError. This machine has 2GB of RAM. I've tried setting the /3GB switch on winxp bootup, as well as all the registry suggestions at http://www.msfn.org/board/storage-process-command-t62001.html. No luck. I get the same error in (32bit) ubuntu for a sufficiently big file. I find that if I load the file in two pieces into two arrays, say 1GB and 0.3GB respectively, I can avoid the memory error. So it seems that it's not that windows can't allocate the memory, just that it can't allocate enough contiguous memory. I'm OK with this, but for indexing convenience, I'd like to be able to treat the two arrays as if they were one. Specifically, this file is movie data, and the array I'd like to get out of this is of shape (nframes, height, width). Right now I'm getting two arrays that are something like (0.8*nframes, height, width) and (0.2*nframes, height, width). Later in the code, I only need to index over the 0th dimension, i.e. the frame index. I'd like to access all the data using a single range of frame indices. Is there any way to combine these two arrays into what looks like a single array, without having to do any copying within memory? I've tried using numpy.concatenate(), but that gives me a MemoryError because, I presume, it's doing a copy. Would it be better to load the file one frame at a time, generating nframes arrays of shape (height, width), and sticking them consecutively in a python list? I'm using numpy 1.0.4 (compiled from source tarball with Intel's MKL library) on python 2.5.1 in winxp. Thanks for any advice, Martin

13 29

segfault with atlas3-sse2, works with atlas3-sse
by Ondrej Certik Dec. 21, 2007

Dec. 21, 2007

Hi, when compiled on Debian, numpy segfaults when used with ATLAS sse2, but works when used against ATLAS sse. More information here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448530 I have no idea, where the problem is. Do you have any ideas, what we should try? Thanks a lot, Ondrej

4 5

Fwd: SSE2 segfault
by Ondrej Certik Dec. 21, 2007

Dec. 21, 2007

Hi, forwarding more information about the problem + backtrace. Ondrej ---------- Forwarded message ---------- From: Jan Medlock <medlock(a)turboshower.net> Date: Dec 21, 2007 4:17 AM Subject: Re: Bug#448530: bug reproduced To: Ondrej Certik <ondrej(a)certik.cz> Cc: 448530(a)bugs.debian.org, Kumar Appaiah <akumar(a)ee.iitm.ac.in> On Thu, Dec 20, 2007 at 08:01:01PM +0100, Ondrej Certik wrote: > Paul Metcalfe has sent me this explanation: > > I think it's a packaging problem with linear algebra. > > ... Hi Ondrej, I'm still here. I saw the bug in the NumPy bug tracker that suggests the problem is specific to Debian & Ubuntu and Paul Metcalfe's details about linking. Linking against ATLAS instead of BLAS & LAPACK may indeed ultimately be the problem and I'm afraid I don't understand the details. That said, I believe the problem is SSE2 specific. The machine that I'm having the problem with is an Intel Pentium4 with SSE2, but I also have an AMD K7 machine that has 3DNow but not SSE2. The AMD machine does not exhibit the bug with the 3DNow version of ATLAS. (Of course neither do with the SSE or base versions of ATLAS.) I haven't participated in the thread on the NumPy mailing list because I don't see a way to reply to the thread since I wasn't subscribed at the time... Attached is a gdb backtrace. Please let me know how I can make it more informative, if necessary. Thanks again for tracking down this bug, Jan

1 0

Propose modification to binary_repr
by David Huard Dec. 20, 2007

Dec. 20, 2007

Hi, The current behavior of numpy's binary_repr is the following: >>> binary_repr(1,width=2) '01' >>> binary_repr(0,width=2) '0' This seems inconsistent and I'd suggest always padding with zeros to make sure that the return string always has length=width. Objections ? David

8 9

Indexing into a matrix
by Keith Goodman Dec. 20, 2007

Dec. 20, 2007

>> x = M.rand(3,1) <-------- 3x1 >> x[M.isfinite(x)] matrix([[ 0.36541551, 0.6305087 , 0.66054899]]) <---------- Should this be 3x1? My workaround is awkward: >> x[M.where(M.isfinite(x).A)[0]] matrix([[ 0.36541551], [ 0.6305087 ], [ 0.66054899]])

1 0

Compiler change for Windows version between 1.0.3.1 and 1.0.4?
by Stuart Brorson Dec. 20, 2007

Dec. 20, 2007

Hi -- I have found a bug in numpy-1.0.4. The bug is a crash when doing linalg.inv() on a Windows machine. The machine is an old Pentium 3 machine. The error report indicates an invalid op code. Details about this bug are in the numpy tracker under ticket 635. Numpy-1.0.3.1 doesn't crash when running the same code. I installed the pre-built binaries available from numpy's SF site. Since the binaries were built by you, I can only suspect that the problem involves using a different compiler to build 1.0.4. I suspect the new version was built with a compiler which emitted op codes the old P3 chip couldn't handle. Can the developers confirm or deny my hypothesis? Thanks, Stuart Brorson Interactive Supercomputing, inc. 135 Beaver Street | Waltham | MA | 02452 | USA http://www.interactivesupercomputing.com/

3 2

Mailing list was not sending out new mails for awhile.
by Travis E. Oliphant Dec. 20, 2007

Dec. 20, 2007

Hi all, The postfix service on the server hosting several of the mailing lists was down since Monday. Mails to the list were preserved and archived but were not being distributed to subscribers. We restarted the postfix service and messages should now be going out. Apologies for the problem. -Travis O.

1 0

Changing the distributed binary for numpy 1.0.4 for windows ?
by David Cournapeau Dec. 18, 2007

Dec. 18, 2007

Hi, Several people reported problems with numpy 1.0.4 (See #627 and #628, but also other problems mentionned on the ML, which I cannot find). They were all solved, as far as I know, by a binary I produced (simply using mingw + netlib BLAS/LAPACK, no ATLAS). Maybe it would be good to use those instead ? (I can recompile them if there is a special thing to do to build them) cheers, David

15 33

Float and math module enhancements for Python 2.6 and 3.0
by Christian Heimes Dec. 18, 2007

Dec. 18, 2007

Hello! The Python core developers are currently working on several improvements for floats and the math module. Since you are "power users" I like to get your opinion and suggestions on several patches: http://bugs.python.org/issue1534 -- sys.float_info [done] http://bugs.python.org/issue1580 -- shorter repr of floats http://bugs.python.org/issue1635 -- platform independent representation and creation of +/-inf and nan http://bugs.python.org/issue1640 -- additional functions for the math module new: sys.maxsize, gone in 3.0: sys.maxint Christian

1 0

Changes to the NumPy's developer trac site
by Jarrod Millman Dec. 17, 2007

Dec. 17, 2007

Hello, It looks like the spammers have figured out how to use our trac site again. I locked down the trac site a bit to make it more difficult for them. Basically, I removed some of the default permissions that all users get. I don't think this will effect many people; but if you have a trac acount and aren't able to do something because you don't have permission just send me an email. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

assign a variable to each column of an array
by elfnor Dec. 17, 2007

Dec. 17, 2007

Is there a more concise way of assigning a variable to each column of an array? This works x,y,z = X[:,0],X[:,1],X[:,2] but seems clumsy.

2 1

Re: [Numpy-discussion] RAdian <--> degres conversion
by Neil Crighton Dec. 16, 2007

Dec. 16, 2007

Do we really need these functions in numpy? I mean it's just multiplying/dividing the value by pi/180 (who knows why they're in the math module..). Numpy doesn't have asin, acos, or atan either (they're arcsin, arcos and arctan) so it isn't a superset of the math module. I would like there to be fewer functions in numpy, not more. > > Someone on the wxPython list just pointed out that the math module now > > includes includes angle-conversion utilities: > > > >>>> degrees.__doc__ > > degrees(x) -> converts angle x from radians to degrees > >>>> radians.__doc__ > > radians(x) -> converts angle x from degrees to radians > > > > Not a big deal, but handy. As I generally like to think if numpy as a > > superset of the math module, perhaps is should include these too. > > > Done. >

3 2

matrix multiplication A x, x has some zeros
by dmitrey Dec. 14, 2007

Dec. 14, 2007

Hi all, I have to get Ax, A is n x n matrix, x is vector of length n. Some coords of x are zeros, so I want to economy time/cputime somehow w/o connecting sparse module from scipy. What's the easiest way to do so? Thx, D.

4 6

RAdian <--> degres conversion
by Christopher Barker Dec. 14, 2007

Dec. 14, 2007

HI all, Someone on the wxPython list just pointed out that the math module now includes includes angle-conversion utilities: >>> degrees.__doc__ degrees(x) -> converts angle x from radians to degrees >>> radians.__doc__ radians(x) -> converts angle x from degrees to radians Not a big deal, but handy. As I generally like to think if numpy as a superset of the math module, perhaps is should include these too. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 1

ANN: SFE-00.35.01
by Robert Cimrman Dec. 14, 2007

Dec. 14, 2007

Let me announce SFE-00.35.01, bringing per term integration - now each term can use its own quadrature points. This is a major change at the heart of the code - some parts may not work as all terms were not migrated yet to the new framework. All test examples work, though, as well as acoustic band gaps. See http://ui505p06-mbs.ntc.zcu.cz/sfe . SFE is a finite element analysis software written almost entirely in Python. The code is released under BSD license. best regards, r.

1 0

Traceback on divide by zero error
by Tony S Yu Dec. 13, 2007

Dec. 13, 2007

Hello, This is something that's been bothering for awhile. When numpy raises the following divide by zero error: >>> Warning: divide by zero encountered in double_scalars is there a way to get a Traceback on where that warning occurred. Thanks, Tony

2 2