Re: [Numpy-discussion] mercurial now has free hosting too
Ondrej Certik wrote: Hi, since there was so much discussion whether bzr or hg, Mercurial has now free hosting too: http://freehg.org/ also Mercurial 1.0 was finally released yesterday. That's really good news. Bzr has Launchpad, that's one of the (main) reasons ipython is investigating it, so I am still learning how to use bzr, but it's not really so much different. I thought ipython was going to use hg ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
On Wed, Mar 26, 2008 at 11:36:18AM +0200, Ville M. Vainio wrote: I think the killer issue here is Launchpad. We get pretty much everything for free, and it's something that we can expect to stay around in the long haul (and will continue to improve). The slight performance disadvantage of bzr is a minor concern, esp. for the project with the size of IPython. Both hg and bzr as-such (if we forget the hosting options etc) are good enough right now, and both are being improved. As it stands, I think we should stick with LP + bzr for now - we can re-evaluate the situation a year or so down the line, if need be. I have the very exact same gut fealing than you. I have watch developpers switch to DVCS lately, and I must say it requires a certain change in working habits. Let us wait for people to get used to these new tools before discussing which one to you. And don't get me wrong, I love DVCS, I just don't want to lose developper because of it. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
Gael Varoquaux wrote: I have watch developpers switch to DVCS lately, and I must say it requires a certain change in working habits. Let us wait for people to get used to these new tools before discussing which one to you. I personally think that the supposed difficulty of DVCS is greatly exaggerated. Basic things are as easy with bzr/hg as they are with svn/svn: cheking out, committing, blame and log are exactly the same. Branching/merging is different, but I don't think anybody would argue that it is easier/more natural with svn that it is with DVCS. Advanced concepts are maybe a bit difficult to grasp, but nobody need them if they do not need them. In particular, if you do not use branches, the only difference between hg/bzr and svn is that commit in svn is equivalent to commit + push in bzr/hg. All the basic commands even have the same name and the same abbreviation (ci for commit, up for update). Compare that to the immediate benefits (such as tracking patches, for example, which at least for me is a PITA right now with trac+svn), I think it worths 5 minutes spent on getting used to the new tool. The problem really is the change of infrastructure (I don't think anybody would be in favor of losing numpy/scipy history, for example, or losing trac tickets for launchpad if we use launchpad), and for windows users who want GUI (which do not exist today in any usable form). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
On Wed, Mar 26, 2008 at 07:08:31PM +0900, David Cournapeau wrote: Gael Varoquaux wrote: I have watch developpers switch to DVCS lately, and I must say it requires a certain change in working habits. Let us wait for people to get used to these new tools before discussing which one to you. I personally think that the supposed difficulty of DVCS is greatly exaggerated. Basic things are as easy with bzr/hg as they are with svn/svn: cheking out, committing, blame and log are exactly the same. Look, I am not talking about theory, I am talking about sitting with people and having to walk them through the conceptual difficulties, mainly due to the fact that you no longer have only one development tree. People are not used to that. I agree that DVCS is much better then centralised VCS, and I love working with it, I just feel that not everybody is ready for it yet, and that the tools are not as mature as for SVN yet. I think both will come in a year or two. My 2 centimes, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
Gael Varoquaux wrote: Look, I am not talking about theory, I was not talking about theory: - svn co url - bzr co url - svn commit -m bla bla - bzr ci -m bla bla - svn up - bzr up - svn log - bzr log - svn blame - bzr blame You cannot be more concrete than that :) I agree about everything else: tools maturity, GUI for windows, etc... and I am not saying that we should change now or to bzr for that matter. But the difficulty for developers, I don't think it is a valid argument. It is only different if you use branching, which nobody forces people to use, and works better than in svn. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
On Wed, Mar 26, 2008 at 07:26:13PM +0900, David Cournapeau wrote: Gael Varoquaux wrote: Look, I am not talking about theory, I was not talking about theory: - svn co url - bzr co url - svn commit -m bla bla - bzr ci -m bla bla - svn up - bzr up - svn log - bzr log - svn blame - bzr blame You cannot be more concrete than that :) Except that very often when you do a bzr up you have to do a merge because bzr makes obvious branching that is implicit with the svn model. In addition following the evolution of the trunk is harder because version numbers are harder to understand. Morever if you don't look at it with a tree view, you don't understand at all what is happening, and launchpad doesn't display a tree view, and under windows bzr viz (which rocks) requires a bit of work to get working. Thrust me, I have seen people quite often come up to me and ask me what do I do now?. Little details like the bzr merge;bzr conflicts; vim conflicting files; bzr resolv; bzr commit; bzr push confuse people. Once again, the tool is much more reliable than svn, and once you have understood it, its a breeze, with less bad surprises, but many people don't want to learn. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [IPython-dev] mercurial now has free hosting too
2008/3/26, David Cournapeau [EMAIL PROTECTED]: Gael Varoquaux wrote: Except that very often when you do a bzr up you have to do a merge because bzr makes obvious branching that is implicit with the svn model. bzr does not branch implicitly, as far as I know, so I am not sure to understand how this could happen if you only track one branch (which is what most people who just want to get the sources would do). At least, things could be set up such as people do see only one branch by default. That's how bzr itself is developed, for example: I track the development branch for a long time, I never had to use any merge command. Only pull (that's something I forgot in my former email: there is a difference for commit vs commit + push, as well as for up vs pull). In the lastest NiPy sprint, we intensively used bzr. Each of us had its own branch, and then we merged regularly with the trunk with push/pulls. In a usual week, this is not always needed, but for a coding sprint, it is a nice model :) Matthieu Once again, the tool is much more reliable than svn, and once you have understood it, its a breeze, with less bad surprises, but many people don't want to learn. I guess my argument is the following: there are several groups of people who may be interested in the sources. It is as simple as svn for occasional contributors (people who get source, people who do a trivial patch), and it would be different for people who significantly contribute to one of the project. But I don't think this later group includes people who do not want to learn :) cheers. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Quikest way to create a diagonal matrix ?
All, What's the quickest way to create a diagonal matrix ? I already have the elements above the main diagonal. Of course, I could use loops: m=5 z = numpy.arange(m*m).reshape(m,m) for k in range(m): for j in range(k+1,m): z[j,k] = z[k,j] But I was looking for something more efficient. Thanks a lot in advance ! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a diagonal matrix ?
Hi, Did you try diag() ? Or are you saying a symmetric matrix ? Matthieu 2008/3/26, Pierre GM [EMAIL PROTECTED]: All, What's the quickest way to create a diagonal matrix ? I already have the elements above the main diagonal. Of course, I could use loops: m=5 z = numpy.arange(m*m).reshape(m,m) for k in range(m): for j in range(k+1,m): z[j,k] = z[k,j] But I was looking for something more efficient. Thanks a lot in advance ! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a symetric (diagonal???) matrix ?
On Wed, Mar 26, 2008 at 09:48:02AM -0400, Pierre GM wrote: All, What's the quickest way to create a diagonal matrix ? I already have the elements above the main diagonal. Of course, I could use loops: m=5 z = numpy.arange(m*m).reshape(m,m) for k in range(m): for j in range(k+1,m): z[j,k] = z[k,j] But I was looking for something more efficient. From your code, you certainly meant symetric and not diagonal. Maybe you can speed up things a bit by assigning slices: for k in range(m): ... z[k:, k] = z[k, k:] -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a diagonal matrix ?
numpy.tri In [31]: T = numpy.tri(m) In [32]: z.T * T + z * T.T Out[32]: array([[ 0., 1., 2., 3., 4.], [ 1., 12., 7., 8., 9.], [ 2., 7., 24., 13., 14.], [ 3., 8., 13., 36., 19.], [ 4., 9., 14., 19., 48.]]) hth, L. On Wed, Mar 26, 2008 at 2:48 PM, Pierre GM [EMAIL PROTECTED] wrote: All, What's the quickest way to create a diagonal matrix ? I already have the elements above the main diagonal. Of course, I could use loops: m=5 z = numpy.arange(m*m).reshape(m,m) for k in range(m): for j in range(k+1,m): z[j,k] = z[k,j] But I was looking for something more efficient. Thanks a lot in advance ! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Lorenzo Bolla [EMAIL PROTECTED] http://lorenzobolla.emurse.com/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a diagonal matrix ?
On 26 Mar 2008, at 15:36, lorenzo bolla wrote: numpy.tri In [31]: T = numpy.tri(m) In [32]: z.T * T + z * T.T Out[32]: array([[ 0., 1., 2., 3., 4.], [ 1., 12., 7., 8., 9.], [ 2., 7., 24., 13., 14.], [ 3., 8., 13., 36., 19.], [ 4., 9., 14., 19., 48.]]) You still have to subtract the diagonal: def f(z): A = tri(z.shape[0], dtype = z.dtype) X = z.T * A + z * A.T X[range(A.shape[0]),range(A.shape[0])] -= z.diagonal() return X The suggestion of Alexandre seems to be about 4 times as fast, though. But I love the way you obfuscate things by having T for both the tri- matrix as the transpose method. :-) It get's even better with numpy matrices. Next year, my students will see something like I.H-T.H*T.I+I.I*H.I+T.T*H.H-H.I Refreshing! ;-) Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ANN: SfePy 00.41.03
Greetings, I'm pleased to announce the release 00.41.03 of SfePy (formerly SFE) SfePy is a finite element analysis software in Python, based primarily on Numpy and SciPy. Mailing lists, issue tracking, mercurial repository: http://code.google.com/p/sfepy/ Home page: http://sfepy.kme.zcu.cz Major improvements: - works on 64 bits - support for various mesh formats - Schroedinger equation solver - see http://code.google.com/p/sfepy/wiki/Examples - new solvers: - generic time-dependent problem solver - pysparse, symeig, scipy-based eigenproblem solvers - scipy-based iterative solvers - many new terms For information on this release, see http://sfepy.googlecode.com/svn/web/releases/004103_RELEASE_NOTES.txt Best regards, r. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a diagonal matrix ?
I like obfuscating things! Maybe I should switch to perl :-) you can use a one-liner like this: scipy.linalg.triu(z) + scipy.linalg.triu(z,k=1).T my %timeit gives roughly the same execution speed as your f(z): In [79]: %timeit f(z) 1 loops, best of 3: 79.3 us per loop In [80]: %timeit h(z) 1 loops, best of 3: 76.8 us per loop L. On Wed, Mar 26, 2008 at 4:21 PM, Joris De Ridder [EMAIL PROTECTED] wrote: On 26 Mar 2008, at 15:36, lorenzo bolla wrote: numpy.tri In [31]: T = numpy.tri(m) In [32]: z.T * T + z * T.T Out[32]: array([[ 0., 1., 2., 3., 4.], [ 1., 12., 7., 8., 9.], [ 2., 7., 24., 13., 14.], [ 3., 8., 13., 36., 19.], [ 4., 9., 14., 19., 48.]]) You still have to subtract the diagonal: def f(z): A = tri(z.shape[0], dtype = z.dtype) X = z.T * A + z * A.T X[range(A.shape[0]),range(A.shape[0])] -= z.diagonal() return X The suggestion of Alexandre seems to be about 4 times as fast, though. But I love the way you obfuscate things by having T for both the tri- matrix as the transpose method. :-) It get's even better with numpy matrices. Next year, my students will see something like I.H-T.H*T.I+I.I*H.I+T.T*H.H-H.I Refreshing! ;-) Cheers, Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Lorenzo Bolla [EMAIL PROTECTED] http://lorenzobolla.emurse.com/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: SfePy 00.41.03
Robert Cimrman wrote: I'm pleased to announce the release 00.41.03 of SfePy (formerly SFE) very cool! Totally off-topic, but how did you build that nifty pdf slide show? (introduction_slide.pdf) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a symetric (diagonal???) matrix ?
If the rest of the matrix is already zeros and memory wasn't a problem, you could just use A_sym = A + A.T - diag(diag(A)) If memory was an issue, I'd suggest weave.inline (if that's a viable option) or pyrex to do the loop, which would be about as fast as you could get. --Hoyt On Wed, Mar 26, 2008 at 7:22 AM, Alexandre Fayolle [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 09:48:02AM -0400, Pierre GM wrote: All, What's the quickest way to create a diagonal matrix ? I already have the elements above the main diagonal. Of course, I could use loops: m=5 z = numpy.arange(m*m).reshape(m,m) for k in range(m): for j in range(k+1,m): z[j,k] = z[k,j] But I was looking for something more efficient. From your code, you certainly meant symetric and not diagonal. Maybe you can speed up things a bit by assigning slices: for k in range(m): ... z[k:, k] = z[k, k:] -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR+pcDl6T+PKoJ87eAQI1zAf/W7wnB1a6sa4FuHDPTDjU61ZpvDgS41r7 B7EuSDncTluf3Y5ynQ8NroAihX0DvV4F5LTDcbFJbmqnQx8JApVoeQF3wnTnpf24 pUQ5oSB+w0+RtzU0Zu/TBkOh3hM8iPYyB2M7jq9/qakVxEsrlOiTH+j05ysJD9FG GezArMoQu5ycJ26Ir9P7jR0acH/WBA84U524aiDbenLMmpFIZX7mElU47z/Ue5m7 xKTT/lu3BWQAJPoQTiHG7nRLDaAqxKVO0WLXPuUJ7HyCc4qjURhXZMmJQ2FP2ajt H9AQQhNkO7eUAPmMLhK0x262bYIdq699UmjV7YOVmSvCrBM76okqew== =ha+1 -END PGP SIGNATURE- ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] missing function in numpy.ma?
Hello, I used to be able to inherit form nump.oldnumeric.ma.array, it looks like you can't any longer. I replaced it with: numpy.ma.MaskedArray i'm getting: result = result.reorder(order).regrid(grid) AttributeError: 'MaskedArray' object has no attribute 'reorder' Should I inherit from soemtihng else ? Aslo I used to import a some function from numpy.oldnumeric.ma, that are now missing can you point me to their new ma equivalent? common_fill_value, identity, indices and set_fill_value Thanks, C. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
Matt Knox wrote: data = [1., 2., 3., np.nan, 5., 6.] mask = [0, 0, 0, 1, 0, 0] I'm creating the ma with ma.masked_where... marr = ma.array(data, mask=mask) marr.set_fill_value(55) print marr[0] is ma.masked # False print marr[3] # ma.masked constant Yeah, and this is where I have the problem. The masked constant has a fill value of 9, rather than 55. That is annoying. filled_arr = marr.filled() print filled_arr # nan value is replaced with fill value of 55 Right, and this is how I currently work around the problem. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 9:32 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Not exactly. What do people think of the way I organized the numpy functions by category page? Apart from the sore-thumb other category, it does seem like the kind of grouping we might hope for. I can see categories 1 through 4 being one submodule, and the rest as they are. +1 -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
Pierre GM wrote: My bad, I neglected an overall doc for the functions and their docstring. But you know what ? As you're now at an intermediary level, That's pretty unkind to your userbase. I know a lot about python, but I'm a total novice with numpy and even the maths it's based on. help: just write down the problems you encountered, and the solutions you came up with, so that we could use your experience as the backbone for a proper MaskedArray documentation Blind leading the blind seems like a terrible idea to me... Try that: x = numpy.ma.array([0,1,2,3,]) x[-1] = numpy.nan print x [0 1 2 0] See? No NaNs with an int array. Right. Array types and whatever a dtype is are things that could be much better documented too :-( Well, no problem, they should stick around. Note that if a NaN/Inf should normally show up as the result of some operation (divide by zero for example), it'll probably won't: x = numpy.ma.array([0,1,2,numpy.nan],dtype=float) print 1./x [-- 1.0 0.5 nan] NaN/inf is still NaN in my books, so why would I be surprised by this? I'd argue that the masked singleton having a different fill value to the ma it comes from is a bug. It's not a bug, it's a featureTM One which sucks and is unintuitive. The fill_value for the mask singleton is meaningless, correct. However, having numpy.ma.masked as a constant is really helpful to test whether a particular value is masked, or to mask a particular value: x = numpy.ma.array([0,1,2,3]) x[-1] = masked x[-1] is masked True I may not know much about maths, but I know about these funny things in python we have called classes to solve exactly this problem ;-) x[-1] = Masked(fill_value=50) isinstance(x[-1],Masked) True ...which gives you what you want without forcing me to experience the resultant suck. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quikest way to create a symetri c (diagonal???) matrix ?
All, Yes, I was talking about symmetric matrices. Sorry for the confusion. Thanks a lot for your answers. The slices approach looks the best indeed. I was hoping that there was some way to use smart indexing, but it really looks like too complicated. Thx again P. P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] missing function in numpy.ma?
Charles, result = result.reorder(order).regrid(grid) AttributeError: 'MaskedArray' object has no attribute 'reorder' Should I inherit from soemtihng else ? Mmh, .reorder is not a regular ndarray method, so that won't work. What is it supposed to do ? And regrid ? Aslo I used to import a some function from numpy.oldnumeric.ma, that are now missing can you point me to their new ma equivalent? common_fill_value, identity, indices and set_fill_value For set_fill_value, just use m.fill_value = your_fill_value For identity, just use the regular numpy version, and view it as a MaskedArray: numpy.identity(...).view(MaskedArray) For common_fill_value: ah, tricky one, I'll have to check. If needed, I'll bring identity into numpy.ma. Please don't hesitate to send more feedback, it's always needed. Sincerely, P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] missing function in numpy.ma?
The reorder is a function we implement. By digging a bit into this my guess is that all the missing function in numpy.ma are causing to fail at some point in our init and returning the wrong object type. But the whole idea was to keep a backward compatible layer with Numeric and MA. It worked great for a while and now things are getting more and more broken. Correct me if I'm wrong but it seems as if the numpy.oldnumeric.am is now simply numpy.ma and it's pointing to the new MaskedArray interface. Loosing a LOT of backward compatibility at the same time. I'm thinking that such changes should definitely not happen from 1.0.4 to 1.0.5 but rather in some major upgrade of numpy (1.1 at least, may be even 2.0). It is absolutely necessary to have the oldnumeric.ma working as much as possible as MA, what's in now is incompatible with code that have been successfully upgraded to numpy using your recommended method (official numpy doc) Can you put back ALL the function from numpy.oldnumeric.ma ? It shouldn't be too much work. Now I'm actually worried about using ma at all? What version is in? Is it a completely new package or is it still the old one just a bit broken? If it's a new one, we'd have to be sure it is fully tested before we can redistribute it to other people via our package, or before we use it ourselves Can somebody bring some light on this issue? thanks a lot, C. Pierre GM wrote: Charles, result = result.reorder(order).regrid(grid) AttributeError: 'MaskedArray' object has no attribute 'reorder' Should I inherit from soemtihng else ? Mmh, .reorder is not a regular ndarray method, so that won't work. What is it supposed to do ? And regrid ? Aslo I used to import a some function from numpy.oldnumeric.ma, that are now missing can you point me to their new ma equivalent? common_fill_value, identity, indices and set_fill_value For set_fill_value, just use m.fill_value = your_fill_value For identity, just use the regular numpy version, and view it as a MaskedArray: numpy.identity(...).view(MaskedArray) For common_fill_value: ah, tricky one, I'll have to check. If needed, I'll bring identity into numpy.ma. Please don't hesitate to send more feedback, it's always needed. Sincerely, P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
On Wednesday 26 March 2008 15:42:41 Chris Withers wrote: Pierre GM wrote: My bad, I neglected an overall doc for the functions and their docstring. But you know what ? As you're now at an intermediary level, That's pretty unkind to your userbase. I know a lot about python, but I'm a total novice with numpy and even the maths it's based on. My bosses have different priorities and keep on recalling me that spending time writing Python code is not what I was hired to do, and that should be writing scientific papers by the dozen. Let's say that I'm just playing middle ground to the best of my capacities. And time. help: just write down the problems you encountered, and the solutions you came up with, so that we could use your experience as the backbone for a proper MaskedArray documentation Blind leading the blind seems like a terrible idea to me... You're no longer a complete neophyte, so you're not that blind, but are still experiencing the tough part of the learning curve. I took things for granted nowadays (for example, dtypes) that are not obvious for the absolute beginners, that's exactly where you can play your role: remind me what it is to be blind so that I can help you more, start some simple doc pages on the wiki that the community can edit/append. NaN/inf is still NaN in my books, so why would I be surprised by this? Because with a regular ndarray with no NaNs initially, you could end up with NaNs and Infs with some operations. With MaskedArray, you don't. I'd argue that the masked singleton having a different fill value to the ma it comes from is a bug. It's not a bug, it's a featureTM One which sucks and is unintuitive. I can understand the unintuitive part to a certain extent, I won't comment on the first aspect however, you know, tastes, colors, snails, oysters, that kind of thing. On top of that, I could kick into touch and say that it's needed for backwards compatibility. x[-1] = Masked(fill_value=50) isinstance(x[-1],Masked) True ...which gives you what you want without forcing me to experience the resultant suck. Yeah, that's a possibility. Feel free to implement it so that we can compare the two approaches. I still don understand why you really need to have a particular fill_value for the masked constant anyway: what are you trying to do exactly ? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] missing function in numpy.ma?
Charles Doutriaux wrote: The reorder is a function we implement. By digging a bit into this my guess is that all the missing function in numpy.ma are causing to fail at some point in our init and returning the wrong object type. But the whole idea was to keep a backward compatible layer with Numeric and MA. It worked great for a while and now things are getting more and more broken. There are costs as well as benefits in maintaining backward compatibility, so one should not rely on it indefinitely. Correct me if I'm wrong but it seems as if the numpy.oldnumeric.am is now simply numpy.ma and it's pointing to the new MaskedArray interface. Loosing a LOT of backward compatibility at the same time. numpy.oldnumeric.ma was a very small compatibility wrapper for numpy.core.ma; now it is the same, but pointing to numpy.ma, which is now Pierre's new maskedarray implementatin. Maybe more compatibility interfacing is needed, either there or in numpy.ma itself, but I would not agree with your characterization of the degree of incompatibility. Whether it would be possible (and desirable) to replace oldnumeric.ma with the old numpy/core/ma.py, I don't know, but maybe this, or some other way of keeping core/ma.py available, should be considered. Would this meet your needs? Were you happy with release 1.04? I'm thinking that such changes should definitely not happen from 1.0.4 to 1.0.5 but rather in some major upgrade of numpy (1.1 at least, may be even 2.0). No, this has been planned for quite a while, and I would strongly oppose any such drastic delay. It is absolutely necessary to have the oldnumeric.ma working as much as possible as MA, what's in now is incompatible with code that have been successfully upgraded to numpy using your recommended method (official numpy doc) Can you put back ALL the function from numpy.oldnumeric.ma ? It shouldn't be too much work. Now I'm actually worried about using ma at all? What version is in? Is it a completely new package or is it still the old one just a bit broken? If it's a new one, we'd have to be sure it is fully tested No, it is not broken, it has many improvements and bug fixes relative to the old ma.py. That is why it is replacing ma.py. before we can redistribute it to other people via our package, or before we use it ourselves Well, the only way to get something fully tested is to put it in use. It has been available for testing for a long time as a separate implementation, then as a numpy branch, and now for a while in the numpy svn trunk. It works well. It is time to release it--possibly after a few more tweaks, possibly leaving the old core/ma.py accessible, but definitely for 1.05. No one will force you to adopt 1.05, so if more compatibility tweaks are needed after 1.05 you can identify them and they can be incorporated for the next release. Eric Can somebody bring some light on this issue? thanks a lot, C. Pierre GM wrote: Charles, result = result.reorder(order).regrid(grid) AttributeError: 'MaskedArray' object has no attribute 'reorder' Should I inherit from soemtihng else ? Mmh, .reorder is not a regular ndarray method, so that won't work. What is it supposed to do ? And regrid ? Aslo I used to import a some function from numpy.oldnumeric.ma, that are now missing can you point me to their new ma equivalent? common_fill_value, identity, indices and set_fill_value For set_fill_value, just use m.fill_value = your_fill_value For identity, just use the regular numpy version, and view it as a MaskedArray: numpy.identity(...).view(MaskedArray) For common_fill_value: ah, tricky one, I'll have to check. If needed, I'll bring identity into numpy.ma. Please don't hesitate to send more feedback, it's always needed. Sincerely, P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] missing function in numpy.ma?
Charles, numpy.ma is supposed to replace numpy.core.ma only. I don't know what happened to numpy.oldnumeric.ma, more exactly when it was dropped. A quick search on the trac indicates it happens a while ago (before version 1.0.1)... In short, the major difference between the old (numpy.core.ma) and new (numpy.ma) implementation is that MaskedArray is nowadays a subclass of ndarray, when it was a complete different object in the old version. The new approach does simplify a lot of aspects (subclassing in particular). It introduces a lot of functions that were not available in the previous version, and it's supposed to be more transparent. But the whole idea was to keep a backward compatible layer with Numeric and MA. It worked great for a while and now things are getting more and more broken. As numpy is moving further and further away from Numeric ? It is absolutely necessary to have the oldnumeric.ma working as much as possible as MA, what's in now is incompatible with code that have been successfully upgraded to numpy using your recommended method (official numpy doc) I must admit I'm partially responsible: there are indeed a couple of incompatibilities between numpy.core.ma and numpy.ma, there are listed here: http://www.scipy.org/scipy/numpy/wiki/MaskedArrayApiChanges All in all, they look minor to me, but may have some naughty side effects: the _data as property is the trickiest as it will make tests on id fail. Can you put back ALL the function from numpy.oldnumeric.ma ? It shouldn't be too much work. I'm not sure I can assess properly the time it would need. I could try, but I never used numpy.oldnumeric.ma myself, and I have difficulties finding an old version. Now I'm actually worried about using ma at all? What version is in? Is it a completely new package or is it still the old one just a bit broken? If it's a new one, we'd have to be sure it is fully tested before we can redistribute it to other people via our package, or before we use it ourselves Well, as stated before, numpy.ma is a better numpy.core.ma, and therefore not totally compatible with Numeric.MA. Lots of functions are equivalent, but some functionalities have been added, some dropped. Once again, my objective was to ensure compatibility with numpy.core.ma (with which I started learning Python), not with Numeric.MA that I never used. Yes, numpy.ma has been regularly tested (I've been using it on a quasi daily basis for at least a year now); however, some issues/bugs still pop up from times to times. In any case, I'd be happy to help you figuring out how to modify/upgrade your code from Numeric.MA to numpy.ma, or to answer any specific questions you could have. Sincerely, P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] f2py functions, docstrings, and epydoc
Hi folks- Can anyone offer any tips on how I can get epydoc to produce API documentation for functions in an f2py-produced module? Currently they get listed in the generated docs as Variables: Variables psigc = fortran object at 0xa3e46b0 sigctp = fortran object at 0xa3e4698 smll_offset = fortran object at 0xa3e46c8 Yet each of these objects is callable, and has a docstring. The module itself has docs that give a 1-line signature for each function, but that's only part of the docstring. One reason I'd like to see the full docstrings documented by epydoc is that, for key functions, I'm loading the functions into a module and *changing* the docstrings, to have info beyond the limited f2py-generated docstrings. On a related question, is there a way to provide input to f2py for function docstrings? The manual hints that triple-quoted multiline blocks in the .pyf can be used to provide documentation, but when I add them, they don't appear to be used. Thanks, Tom - This mail sent through IMP: http://horde.org/imp/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] accumarray
Does numpy have something like Matlab's accumarray? http://www.mathworks.com/access/helpdesk/help/techdoc/ref/accumarray.html Best, Gabriel ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] accumarray
On Wed, Mar 26, 2008 at 5:20 PM, Gabriel J.L. Beckers [EMAIL PROTECTED] wrote: Does numpy have something like Matlab's accumarray? http://www.mathworks.com/access/helpdesk/help/techdoc/ref/accumarray.html No. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] vander() docstring
Hi all, The docstring for vander() seems to contradict what the function does. In particular, the columns in the vander() output seem reversed wrt its docstring. I feel like one of the two needs to be fixed, or is there something I'm not seeing? This here is fresh from the Numpy examples page: 8 docstring --- X = vander(x,N=None) The Vandermonde matrix of vector x. The i-th column of X is the the i-th power of x. N is the maximum power to compute; if N is None it defaults to len(x). 8 Example - from numpy import * x = array([1,2,3,5]) N=3 vander(x,N) # Vandermonde matrix of the vector x array([[ 1, 1, 1], [ 4, 2, 1], [ 9, 3, 1], [25, 5, 1]]) 8 - Andreas signature.asc Description: This is a digitally signed message part. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] vander() docstring
On Wed, Mar 26, 2008 at 5:22 PM, Andreas Klöckner [EMAIL PROTECTED] wrote: Hi all, The docstring for vander() seems to contradict what the function does. In particular, the columns in the vander() output seem reversed wrt its docstring. I feel like one of the two needs to be fixed, or is there something I'm not seeing? This here is fresh from the Numpy examples page: 8 docstring --- X = vander(x,N=None) The Vandermonde matrix of vector x. The i-th column of X is the the i-th power of x. N is the maximum power to compute; if N is None it defaults to len(x). 8 Example - from numpy import * x = array([1,2,3,5]) N=3 vander(x,N) # Vandermonde matrix of the vector x array([[ 1, 1, 1], [ 4, 2, 1], [ 9, 3, 1], [25, 5, 1]]) 8 - The docstring is incorrect. The Vandermonde matrix produced is compatible with numpy polynomials that also go from high to low powers. I would have done it the other way round, so index matched power, but that isn't how it is. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] accumarray
On Wed, Mar 26, 2008 at 5:20 PM, Gabriel J.L. Beckers [EMAIL PROTECTED] wrote: Does numpy have something like Matlab's accumarray? http://www.mathworks.com/access/helpdesk/help/techdoc/ref/accumarray.html On Wed, 26 Mar 2008, Robert Kern apparently wrote: No. But of course you can do things like (1d example) vals[subs==2].sum() Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
