On 31 October 2011 21:38, Søren Hauberg <so...@hauberg.org> wrote: > man, 31 10 2011 kl. 21:25 +0000, skrev Carnë Draug: >> On 31 October 2011 21:00, Søren Hauberg <so...@hauberg.org> wrote: >> > man, 31 10 2011 kl. 20:52 +0000, skrev Carnë Draug: >> >> Hi >> >> >> >> while trying to port the perl Lingua::EN::Numbers module, I found that >> >> matlab's image processing toolbox had the iptnum2ordinal function so I >> >> wrote a clone of it too. However, this function has nothing to do with >> >> image processing (it takes a number and returns the ordinal such as 1 >> >> = first, 23 = 23rd). Should it still go in the image package? >> >> >> >> Here's the code anyway >> >> https://gitorious.org/octave-devel/inputparser/blobs/master/iptnum2ordinal.m >> > >> > Hmm, that's a weird place to put a function like that. Perhaps it's more >> > suited for the 'general' package or the 'strings' package? Given that >> > Matlab has it in their implementation as part of their image processing >> > tools I guess we can do the same if you think that's better. >> >> I guess it depends if we want the image package to also be a clone of >> the image processing toolbox. My opinion would be to add it to the >> image package as a wrapper to a function in the general package >> (because in core, num2str is in general) named num2ordinal (without >> the "ipt" prefix). >> >> From their online documentation, it appears they added this function >> to help people write their own tools with nicely formatted error >> messages such as "the second argument is incorrect". Unlike us, matlab >> toolboxes can't have an extra toolbox as dependency. I'm guessing >> every package will have its set of functions designed to help checking >> input. > > Sounds a bit ugly, but I follow the logic behind your suggestion. > Perhaps we should create a "compatibility" and put functions like > "iptnum2ordinal" there? This, of course, only makes sense if plenty of > functions like this exist.
There's a couple of them on the image package (I see iptcheckconn, iptcheckinput, iptcheckmap, iptchecknargin, iptcheckstrs, iptnum2ordinal (they seem easy enough to write, I might do most of them tonight). I see how some of them would only make sense to check input of image functions but still...), I don't know about the others. I don't think there's a need to create an extra package for them just yet. There's an extension to pkg that I thought some time ago but never tried to implement. The idea was that each package could have sets of functions that could be loaded independently so that one could use 'pkg load image::morphological' and 'pkg load image::io' to load different sets of functions. A package could have different sets to be loaded as automatic so that in this case 'pkg load image' would not load this images but 'pkg load image::compatibility' would. Just an idea, haven't thought much how that could be done but I'm guessing symbolic links and subdirectories. Carnë ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
