Hi,
In general I agree with your comments, but it would be interesting to
hear from actual users (I don't really use this package, though I do
have it installed due to dependencies).
søn, 21 02 2010 kl. 11:29 +0100, skrev Jaroslav Hajek:
> I'm thinking about taking over the maintenance of the miscellaneous
> package.
Great! But please don't overburden yourself with maintenance tasks; we
need you for "real" development :-)
> Scanning through the functions, I found several of them that
> seem more or less redundant and I'm thinking of removing them.
Ahh, Spring Cleaning...
> A list
> follows. I also grepped for all usages of each function throughout
> OctaveForge.
>
> inz:
> Trivial wrapper over find(). Contrary to the name (indices of
> non-zeros), the indices are not actually returned as the first
> argument.
> used: nowhere.
>
> nze:
> Likewise trivial. Basically this is an equivalent of inz.
> used: vrml
>
> grep:
> Likewise. Exact equivalent to nze.
> used: nowhere
>
> I think we should either remove "grep" and "inz" and leave just nze,
> or remove all three.
I would say remove all of them and patch 'vrml'. However, you should
probably keep them a while and make them issue a warning telling users
that the functions are deprecated.
> slurp_file:
> Superseded by fileread in Octave core, combined with file_in_loadpath.
> slurp_file is also very inefficient, launching an external process for
> the operation.
> used: vrml
I'd say patch 'vrml'.
> apply:
> Can be replaced by cellfun or just cs-list call. Slightly more wordy,
> more efficient (sometimes much more).
>
> apply (@func, arglist) --> func (arglist{:})
> apply (func_list, arglist) --> cellfun (@feval, func_list,
> arglist{:})
Hmm, while I don't use this function, I do see the benefit of the syntax
in the last example. Would it be possible to patch 'cellfun' to support
similar syntax?
> map:
> Can be replaced by vectorized operations or arrayfun. Much more efficient.
>
> map (@vectorized_func, arg1, arg2, ...) --> vectorized_func (arg1, arg2,
> ...)
> map (@func, arg1, arg2, ...) --> arrayfun (@func, arg1, arg2, ...)
>
> map is also only working for 2D arguments.
>
> used: nowhere
I'd say remove it. The only benefit I see with this function is that the
name matches the corresponding names in functional programming languages
such as Standard ML. But I don't really consider that a big advantage...
> match:
> Usually replaceable by cellfun or simple logical indexing. More
> efficient, sometimes much more. More wordy only in the most general
> cases.
>
> match (@(x) x > 0, x) --> x(x > 0)
> match (@(x) strcmp (x, 'Octave'), strlist) --> strlist
> (strcmp (strlist, 'Octave')))
> match (@func, array) -->
> array(cellfun (@func, array))
>
> the difference is that match can convert nonscalar values to
> true/false (like if statement), but that doesn't seem to be much use
> to me.
I must admit I find the 'match' syntax more simple (and to me the simple
syntax is one of the major advantages of Octave). That being said, I've
never used the function, so I don't really care.
> csv2latex, xmlwrite:
> OK, but probably could be in io.
> used: nowhere
Makes sense to put these in 'io'.
> rotv, rotparams:
> OK, but probably should be in linear-algebra or elsewhere.
> used: vrml
I agree that these are more in the line of 'linear-algebra'.
Søren
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
