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 !
Hi, Did you try diag() ? Or are you saying a symmetric matrix ? Matthieu 2008/3/26, Pierre GM <pgmdevlist@gmail.com>:
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
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
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 <alexandre.fayolle@logilab.fr> 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
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.
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.
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
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.
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
Eric, Pierre, I agree the new ma is probably much better and we should use it. all i was saying is that 1.0.4 was working great with the small compatibility layer. I even have a frozen version of 1.0.5 devel that works great. Then suddenly everything broke. I was really happy was the layer of 1.0.4. It is not only a matter of converting our software, I can do that. It also a matter of have our user base go smoothly thru the transition. So far they were happy with the 1st order conversion script. And a little bit of editing. But we can't ask them to go thru thousands of lines of old code and sort of rewrite it all. When I said it shouldn't be hard to do as much of MA as possible. I simply meant put back the compatibility layer that was there in 1.0.4. and early 1.0.5dev. I'm not advocating to rewrite the old MA at all, simply to keep what was already there as far as transition, why undoing it? I really don't mind help you i the process if you want. C. Eric Firing wrote:
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
Charles,
all i was saying is that 1.0.4 was working great with the small compatibility layer. I even have a frozen version of 1.0.5 devel that works great. Then suddenly everything broke.
Could you be more specific ? Would you mind sending me bug reports so that I can check what's going on and how to improve backwards compatibility ?
I was really happy was the layer of 1.0.4.
We're talking about the 15-line long numpy.oldnumeric.ma, right ? The ones that redefines "take" as to take the averages along some indices ? The only difference between versions is that 1.0.5 uses numpy.ma instead of the old numpy.core.ma. [...] OK, now I see: there were some functions in numpy.core.ma that are not in numpy.ma (identity, indices). So, the pb is not in the conversion layer, but on numpy.ma itself. OK, that should be relatively easy to fix. Can you gimme a day or two ? Sorry for the delayed comprehension. P.
Hi Pierre, No problem, let me know when you have something in. I can't be sure all I mentioned is all that's missing. It's all I got so far. But since I can't get our end going. I can't really give you a comprehensive list of what's exactly missing. Hopefully this is all and it will work fine after your changes. Thanks for doing this, C. Pierre GM wrote:
Charles,
all i was saying is that 1.0.4 was working great with the small compatibility layer. I even have a frozen version of 1.0.5 devel that works great. Then suddenly everything broke.
Could you be more specific ? Would you mind sending me bug reports so that I can check what's going on and how to improve backwards compatibility ?
I was really happy was the layer of 1.0.4.
We're talking about the 15-line long numpy.oldnumeric.ma, right ? The ones that redefines "take" as to take the averages along some indices ? The only difference between versions is that 1.0.5 uses numpy.ma instead of the old numpy.core.ma. [...] OK, now I see: there were some functions in numpy.core.ma that are not in numpy.ma (identity, indices). So, the pb is not in the conversion layer, but on numpy.ma itself. OK, that should be relatively easy to fix. Can you gimme a day or two ?
Sorry for the delayed comprehension. P. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Charles Doutriaux wrote:
Eric, Pierre,
I agree the new ma is probably much better and we should use it.
all i was saying is that 1.0.4 was working great with the small compatibility layer. I even have a frozen version of 1.0.5 devel that works great. Then suddenly everything broke.
Hey Charles, I think it would be a good idea to do as you suggest and look into making the oldnumeric.ma compatibility layer work as well as possible. The problem is that the old compatibility layer was a pretty light wrapper around the old numpy.core.ma. I guess what could be done is to take the old numpy.core.ma file and move it into oldnumeric.ma (along with the few re-namings that are there now)? Could you test that option out and see if it works for you? Thanks, -Travis O.
On Thursday 27 March 2008 16:11:22 Travis E. Oliphant wrote:
I guess what could be done is to take the old numpy.core.ma file and move it into oldnumeric.ma (along with the few re-namings that are there now)? Could you test that option out and see if it works for you?
I'm currently re-introducing some functions of numpy.core.ma in numpy.ma.core, fixing a couple of bugs along the way (for example, round: the current behavior of numpy.round is inconsistent: it'll return a MaskedArray if the nb of decimals is 0, but a regular ndarray otherwise, so I just coded a numpy.ma.round and the corresponding method). 2-3 functions from numpy.core.ma (average, dot, and another one I can't remmbr) are already in numpy.ma.extras. I should update the SVN by later this afternoon.
On Thu, Mar 27, 2008 at 1:31 PM, Pierre GM <pgmdevlist@gmail.com> wrote:
On Thursday 27 March 2008 16:11:22 Travis E. Oliphant wrote:
I guess what could be done is to take the old numpy.core.ma file and move it into oldnumeric.ma (along with the few re-namings that are there now)? Could you test that option out and see if it works for you?
I'm currently re-introducing some functions of numpy.core.ma in numpy.ma.core, fixing a couple of bugs along the way (for example, round: the current behavior of numpy.round is inconsistent: it'll return a MaskedArray if the nb of decimals is 0, but a regular ndarray otherwise, so I just coded a numpy.ma.round and the corresponding method). 2-3 functions from numpy.core.ma (average, dot, and another one I can't remmbr) are already in numpy.ma.extras. I should update the SVN by later this afternoon.
Excellent, I prefer this approach. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
Jarrod Millman wrote:
On Thu, Mar 27, 2008 at 1:31 PM, Pierre GM <pgmdevlist@gmail.com> wrote:
On Thursday 27 March 2008 16:11:22 Travis E. Oliphant wrote:
I guess what could be done is to take the old numpy.core.ma file and move it into oldnumeric.ma (along with the few re-namings that are there now)? Could you test that option out and see if it works for you?
I'm currently re-introducing some functions of numpy.core.ma in numpy.ma.core, fixing a couple of bugs along the way (for example, round: the current behavior of numpy.round is inconsistent: it'll return a MaskedArray if the nb of decimals is 0, but a regular ndarray otherwise, so I just coded a numpy.ma.round and the corresponding method). 2-3 functions from numpy.core.ma (average, dot, and another one I can't remmbr) are already in numpy.ma.extras. I should update the SVN by later this afternoon.
Excellent, I prefer this approach.
If this works then it should be fine. If it doesn't, however, then it would not be too big a deal to just move the old implementation over. In fact, I rather think it ought to be done anyway. The oldnumeric directory will be disappearing in 1.1, so it doesn't introduce any long-term burden and just makes 1.0.5 a bit more robust. -Travis
Hello, Ok, I'll wait for Pierre's changes and see what it does for us. If it still breaks here or there then i'll do as Travis suggested (while still reporting to Pierre what went wrong). Thank you all, C. Travis E. Oliphant wrote:
Jarrod Millman wrote:
On Thu, Mar 27, 2008 at 1:31 PM, Pierre GM <pgmdevlist@gmail.com> wrote:
On Thursday 27 March 2008 16:11:22 Travis E. Oliphant wrote:
I guess what could be done is to take the old numpy.core.ma file and move it into oldnumeric.ma (along with the few re-namings that are there now)? Could you test that option out and see if it works for you?
I'm currently re-introducing some functions of numpy.core.ma in numpy.ma.core, fixing a couple of bugs along the way (for example, round: the current behavior of numpy.round is inconsistent: it'll return a MaskedArray if the nb of decimals is 0, but a regular ndarray otherwise, so I just coded a numpy.ma.round and the corresponding method). 2-3 functions from numpy.core.ma (average, dot, and another one I can't remmbr) are already in numpy.ma.extras. I should update the SVN by later this afternoon.
Excellent, I prefer this approach.
If this works then it should be fine. If it doesn't, however, then it would not be too big a deal to just move the old implementation over. In fact, I rather think it ought to be done anyway.
The oldnumeric directory will be disappearing in 1.1, so it doesn't introduce any long-term burden and just makes 1.0.5 a bit more robust.
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
All, Would you mind trying the SVN (ver > 4946) and let me know what I'm still missing ? Thanks a lot in advance P.
Hi Pierre, I just tested it out, I'm still missing from numpy.oldnumeric.ma import common_fill_value , set_fill_value which breaks the code later C. Pierre GM wrote:
All, Would you mind trying the SVN (ver > 4946) and let me know what I'm still missing ? Thanks a lot in advance P. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Charles,
I just tested it out, I'm still missing from numpy.oldnumeric.ma import common_fill_value , set_fill_value which breaks the code later
Turns out I had forgotten to put the functions in numpy.ma.core.__all__: they had been already coded all along... That's fixed in SVN4950
Hi Pierre, Hum... something is still broken. But maybe you can help me figuring out if something dramtically changed We're defining a new class object MaskedVariable which inherit from our other class: AbstractVariable (in which we define a reorder function for the obects) and from MaskedArray (used to be from numpy.oldnumeric.ma.array) Now when reading data from a file it complains that "MaskedArray" has no attribute "reorder", so that probably means that somewhere something failed in the initialisation of our object and it retuned a simple MaskedArray instead of an MaskedVariable... But since the only changes are from numpy, i wonder if the inheritance form MaskedArray is somehow different from the one from MA.array ? Any clue on where to start looking would be great, Thanks, C> Pierre GM wrote:
Charles,
I just tested it out, I'm still missing from numpy.oldnumeric.ma import common_fill_value , set_fill_value which breaks the code later
Turns out I had forgotten to put the functions in numpy.ma.core.__all__: they had been already coded all along... That's fixed in SVN4950 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Friday 28 March 2008 14:29:29 Charles Doutriaux wrote:
Hi Pierre,
Hum... something is still broken. But maybe you can help me figuring out if something dramtically changed
Something did indeed: numpy.ma.MaskedArray is now a subclass of ndarray, and inheriting from MaskedArray should follow the rules of ndarray subclassing. You'll find a brief overview of subclassing at this link: http://www.scipy.org/Subclasses In short, you can't initialize it with a __init__, you need a combination of __new__ and __array_finalize__. Don't hesitate to send me your class (at least the __init__ and a couple of specific methods) and I'll see how what I can do.
On Thu, Mar 27, 2008 at 1:57 PM, Travis E. Oliphant <oliphant@enthought.com> wrote:
If this works then it should be fine. If it doesn't, however, then it would not be too big a deal to just move the old implementation over. In fact, I rather think it ought to be done anyway.
My main concern is that we shouldn't release 1.0.5 with known missing functionality in the new implementation of MaskedArrays.
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.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 <pgmdevlist@gmail.com> 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 lbolla@gmail.com http://lorenzobolla.emurse.com/
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
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) 10000 loops, best of 3: 79.3 us per loop In [80]: %timeit h(z) 10000 loops, best of 3: 76.8 us per loop L. On Wed, Mar 26, 2008 at 4:21 PM, Joris De Ridder < Joris.DeRidder@ster.kuleuven.be> 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 lbolla@gmail.com http://lorenzobolla.emurse.com/
participants (10)
-
Alexandre Fayolle -
Charles Doutriaux -
Eric Firing -
Hoyt Koepke -
Jarrod Millman -
Joris De Ridder -
lorenzo bolla -
Matthieu Brucher -
Pierre GM -
Travis E. Oliphant