From: Pietro B. <be...@ga...> - 2006-07-13 13:11:12
|
Dear numpys, a couple of weeks ago Tiziano and I completed the conversion of our data processing library MDP to numpy. We collected a few ideas and questions: - we found the convertcode.py module quite useful to perform a first, low-level conversion. We had some problem when 'typecode' was used as a keyword argument because the parser only converts 'typecode=' to 'dtype=' and skips the cases where there is an additional space character before the equal sign ('typecode ='). Other names that might be easily converted are 'ArrayType' and 'NewAxis'. - some functions changed the columns/rows conventions ('cov', for example). It would be really helpful to explicitly write this in the list of necessary changes in the documentation. It could be nice to have the file 'convertcode.py' to print a warning every time one of this functions is used in the code. - the linalg functions svd, eig, inv, pinv, diag, and possibly others perform an upcast, e.g. from 'f' to 'd'. This is apparently because the litelapack module only wraps double precision routines. Wouldn't it be more consistent to cast the results back to the numerical type of the input? Otherwise, the user always has to take care of the casting, which makes the use of single precision arrays quite cumbersome. - we found a bug in the 'eig' function in the case the solution is complex: in (linalg.py, line 269) 'Complex' should be 'w.dtype' We wondered whether it would be possible to obtain SVN write access in orderto be able to fix this kind of issues by ourselves in the future. We could also contribute docstrings for some of the functions. In general, we found the conversion to numpy quite straightforward and would like to thank you all for the great work! Cheers, Pietro Berkes and Tiziano Zito http://mdp-toolkit.sourceforge.net/ |
From: David M. C. <co...@ph...> - 2006-07-13 21:11:56
|
On Jul 13, 2006, at 09:11 , Pietro Berkes wrote: > Dear numpys, > > a couple of weeks ago Tiziano and I completed the conversion of our > data > processing library MDP to numpy. We collected a few ideas and > questions: > > - we found the convertcode.py module quite useful to perform a first, > low-level conversion. We had some problem when 'typecode' was > used as a keyword argument because the parser only converts > 'typecode=' to 'dtype=' and skips the cases where there is an > additional space character before the equal sign ('typecode ='). > Other names that might be easily converted are 'ArrayType' and > 'NewAxis'. fixed in svn. > - some functions changed the columns/rows conventions ('cov', for > example). It would be really helpful to explicitly write this in the > list of necessary changes in the documentation. It could be nice > to have the file 'convertcode.py' to print a warning every time one > of this functions is used in the code. Do you have a list of these? > - the linalg functions svd, eig, inv, pinv, diag, and possibly > others perform an upcast, e.g. from 'f' to 'd'. This is apparently > because the litelapack module only wraps double precision routines. > Wouldn't it be more consistent to cast the results back to the > numerical type of the input? Otherwise, the user always has to take > care of the casting, which makes the use of single precision > arrays quite cumbersome. That makes sense. I'll have a look at it. > - we found a bug in the 'eig' function in the case the solution > is complex: in (linalg.py, line 269) 'Complex' should be 'w.dtype' fixed in svn. > We wondered whether it would be possible to obtain SVN write access in > orderto be able to fix this kind of issues by ourselves in the future. > We could also contribute docstrings for some of the functions. I don't know about svn write access (that's not up to me), but we're perfectly willing to take patches made with 'svn diff', and uploaded to our bug tracker. > In general, we found the conversion to numpy quite straightforward > and would like to thank you all for the great work! > > Cheers, > Pietro Berkes and Tiziano Zito > http://mdp-toolkit.sourceforge.net/ -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
From: Robert K. <rob...@gm...> - 2006-07-14 06:35:48
|
Pietro Berkes wrote: > We wondered whether it would be possible to obtain SVN write access in > orderto be able to fix this kind of issues by ourselves in the future. > We could also contribute docstrings for some of the functions. The best way to get SVN privileges in any open source project is by posting a constant stream of good patches to the bug tracker such that it becomes less work for us to give you access than manually applying the patches ourselves. ;-) http://projects.scipy.org/scipy/numpy Note that you will need to register a username/password in order to create new tickets. We have had to institute this policy due to egregious amounts of ticket spam. I have no doubt that you will provide such patches and be given SVN access in short order. -- 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 |