NumPy-Discussion May 2006

numpy-discussion@python.org

115 participants
146 discussions

Re: your good crdit
by Chibuzo Twist 17 May '06

17 May '06

D p ea l r H r om p e O u wn m er, Your c d re d di e t doesn' f t m r atter to us! If you O w WN s r j ea q l e h st v at f e and wa i nt I s MME x DI g ATE c a as z h to s q pe f nd ANY wa f y you lik v e, or simp d ly wis t h to L e OW s ER your mo q nthly p d aym i ent h s by a thir e d or m m ore, h v ere a e re the d n ea q ls o we hav r e T q ODA x Y: $4 w 90 , 00 x 0 a b s l o ow a j s 3 , 6 b 4 % $ b 370 , 0 z 00 a d s l g ow a g s 3 , 8 u 9 % $ l 490 , 0 g 00 a p s lo p w a p s 3 , 1 k 9 % $2 t 50 , 00 k 0 a u s lo i w a l s 3 , 3 o 4 % $2 s 00 , 00 c 0 a p s lo z w a k s 3 , 5 v 4 % Your c e re f di h t does v n't mat k ter to u u s! g x et ma t tc y hed with l v en g der m s <http://geocities.com/ZaynaxaronLadd/> Chibuzo Twist , Ap h pr d ov k al M d ana r ge x r ----- Original Message ----- believe, after a long start. And so do burglars, he added as a parting shot, as he darted back and fled up the tunnel. It was an unfortunate remark, for the dragon spouted terrific flames after him, and fast though he sped up the slope, he had not gone nearly

1 0

Distutils/NAG compiler problems
by James Graham 17 May '06

17 May '06

I have been experiencing difficulty with the final linking step when using f2py and the NAG Fortran 95 compiler, using the latest release version of numpy (0.9.6). I believe this is caused by a typo in the options being passed to the compiler (at least, making this change fixes the problem): --- /usr/lib/python2.3/site-packages/numpy/distutils/fcompiler/nag.py 2006-01-06 21:29:40.000000000 +0000 +++ /scratch/jgraham/nag.py 2006-05-17 10:46:38.000000000 +0100 @@ -22,7 +22,7 @@ def get_flags_linker_so(self): if sys.platform=='darwin': return ['-unsharedf95','-Wl,-bundle,-flat_namespace,-undefined,suppress'] - return ["-Wl,shared"] + return ["-Wl,-shared"] def get_flags_opt(self): return ['-O4'] def get_flags_arch(self): (that may be incorrectly wrapped) -- "You see stars that clear have been dead for years But the idea just lives on..." -- Bright Eyes

2 1

Getting 0.9.8 out this week
by Travis Oliphant 17 May '06

17 May '06

I'd like to get 0.9.8 of NumPy released by the end of the week. There are a few Trac tickets that need to be resolved by then. In particular #83 suggests returning scalars instead of 1x1 matrices from certain reduce-like methods. Please chime in on your preference. I'm waiting to here more feedback before applying the patch. If you can help out on any other ticket that would be much appreciated. For my part, the scalar math module need to have a re-worked coercion model so that mixing in Python scalars is handled correctly (as well as the case of mixing unsigned and signed integers of the same type --- neither can be cast to each other). I'm open to any suggestions and help. This should eliminate many of the problems causing tests to fail currently with scalar math. The 0.9.8 release is past due now. I was out of town last week and did not have much time for NumPy. -Travis

8 13

Re: [Numpy-discussion] NumPy, Numeric or numarray or all of them?
by Mateusz Loskot 17 May '06

17 May '06

Christopher Barker wrote: > Mateusz Łoskot wrote: >> Christopher Barker wrote: >> >>> Speaking as a long time numpy (Numeric, etc.) user, and a new >>> user of GDAL, I had no idea GDAL worked with num* at all! at >>> least not directly. >> >> >> Yes, it is :-) >> >>> In fact, I thought I was going to have to write that code myself. >>> Where do I find docs for this? I'm sure I've just missed >>> something, but I'm finding the docs a bit sparse. >> >> >> Do you mean docs for Python bindings of GDAL? > > > I meant docs for the num* part. Yes, agreed. >> AFAIK the only docs for Python oriented users is the "GDAL API >> Tutorial" (http://www.gdal.org/gdal_tutorial.html). > > > That's all I've found. And there was no indication of what datatypes > were being returned (or accepted). So far, all I'm doing it reading > images, and it looks to me like ReadRaster() is returning a string, > for instance. I'd love to have it return a numpy array. Now, it's using Numeric package. NumPy will be used soon. >> In the meantime, I'd suggest to use epydoc tool to generate some >> manual - it won't be a complete reference but it can be usable. > > > Good idea. Someone should get around to doing that, and post it > somewhere. I if do it, I'll let you know. I'm going to include epydoc configuration file in GDAL source tree. Such file is similar to doxygen config and can be used to generate html/pdf documentations with single command. I think including generated docs is not necessary. >> There are two separate bindings to Python in GDAL: - native, called >> traditional - SWIG based, called New Generation Python > > > How do I know which ones I'm using? When you're building GDAL you can use appropriate options for ./configure script. > Were the "tradition" ones done my hand? Yes, traditional pymod. Cheers -- Mateusz Łoskot http://mateusz.loskot.net

1 0

numpy docs
by joris＠ster.kuleuven.ac.be 16 May '06

16 May '06

On Tuesday 16 May 2006 16:32, you wrote: > That's great! > I think it would be nice if it could somehow become a gateway for > docstrings. Are you only interested in examples? I'm not sure what your > intentions are, but it would be nice if there were a Wiki page like yours > where people could contribute docstring fixes and then those fixes would > eventually find their way into the source with the help of someone with CVS > write access. Usage examples like the ones on your page are needed in the > docstrings too. My fear though is that with a wiki page, there's no real > incentive to be concise. People tend to just add more rather than erasing > something someone else wrote. I don't really want to read a flame war in my > docstrings about whether the sum() method is superior to the sum() function, > etc. > > --bill +1 on the docstrings. At the moment I will put my efforts in making the example list more complete, though. It's actually a great way to learn about the numpy features. I recommend numarray users to simply browse through the example list and pick up the new numpy features by reading some of the examples. But be aware that there are actually many more as the list is not yet complete. And don't hesitate to contribute! ;-) Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

1 0

Argument of complex number array?
by Sidney Cadot 16 May '06

16 May '06

Hi all, I am looking for a function to calculate the argument (i.e., the 'phase') from a numarray containing complex numbers. A bit to my surprise, I don't see this listed under the ufunc's. Now of course I can do something like arg = arctan2(z.real, z.imag) ... But I would have hoped for a direct function that does this. Any thoughts? (Perhaps I am missing something?) Cheerio, Sidney

2 2

Sourceforge delaying emails to list?
by Stephan Tolksdorf 16 May '06

16 May '06

Hi all, am I the only one who is sometimes (particularly today) receiving emails from the numpy-discussion list up to one day after they have been sent? Or is there a problem with sf.net? Stephan

3 2

Who uses matrix?
by Bill Baxter 16 May '06

16 May '06

On 5/10/06, Tim Hochberg <tim.hochberg(a)cox.net> wrote: > Of course I'm not a user of the matrix class, so take that for what it's worth. On 5/10/06, Sasha <ndarray(a)mac.com> wrote: > > > I don't use matrices, so I don't have a strong opinion on this issue. > > Hmm. And in addition to you two, I'm pretty sure I've seen Travis mention he doesn't use matrix, either. That plus the lack of response to my and others' previous posts on the topic kinda makes me wonder whether there are actually *any* hardcore numpy users out there using the matrix class. I've been using matrix, but I don't consider myself a numpy hardcore at this point. On the issue in quesiton about returning scalars vs matrices from things like sum(), my initial reaction is that any time you have a 1x1 matrix it should just be returned as a scalar. In linear algebra terms, a 1x1 matrix *is* a scalar for all intents and purposes, so it doesn't need to be all dressed up in this fancy 'maxtrix' garb, as in "matrix([[8]])". But I'm not sure it's worth getting all in a hurry to make the change before numpy 0.9.8, or ever for that matter. --bill

13 20

Returned mail: User unknown
by Mail Delivery Subsystem 16 May '06

16 May '06

The original message was received at Tue, 16 May 2006 03:10:27 +0900 (JST) from [83.244.18.119] ----- The following addresses had permanent delivery errors ----- <mdehoon(a)ims.u-tokyo.ac.jp>

1 0

Bug in ndarray.argmax
by Pierre Barbier de Reuille 15 May '06

15 May '06

Hello, I notices a bug in ndarray.argmax which prevent from getting the argmax from any axis but the last one. I join a patch to correct this. Also, here is a small python code to test the behaviour of argmax I implemented : ==8<====8<====8<====8<====8<====8<====8<====8<===8<=== from numpy import array, random, all a = random.normal( 0, 1, ( 4,5,6,7,8 ) ) for i in xrange( a.ndim ): amax = a.max( i ) aargmax = a.argmax( i ) axes = range( a.ndim ) axes.remove( i ) assert all( amax == aargmax.choose( *a.transpose( i, *axes ) ) ) ==8<====8<====8<====8<====8<====8<====8<====8<===8<=== Pierre diff numpy-0.9.6/numpy/core/src/multiarraymodule.c numpy-0.9.6.mod/numpy/core/src/multiarraymodule.c 1952a1953,1955 > If orign > ap->nd, then we cannot "swap it back" > as the dimension does not exist anymore. It means > the axis must be put back at the end of the array. 1956c1959,1979 < (op) = (PyAO *)PyArray_SwapAxes((ap), axis, orign); \ --- > int nb_dims = (ap)->nd; \ > if (orign > nb_dims-1 ) { \ > PyArray_Dims dims; \ > int i; \ > dims.ptr = ( intp* )malloc( sizeof( intp )*nb_dims );\ > dims.len = nb_dims; \ > for(i = 0 ; i < axis ; ++i) \ > { \ > dims.ptr[i] = i; \ > } \ > for(i = axis ; i < nb_dims-1 ; ++i) \ > { \ > dims.ptr[i] = i+1; \ > } \ > dims.ptr[nb_dims-1] = axis; \ > (op) = (PyAO *)PyArray_Transpose((ap), &dims ); \ > } \ > else \ > { \ > (op) = (PyAO *)PyArray_SwapAxes((ap), axis, orign); \ > } \

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion May 2006