On Mon, Feb 22, 2010 at 7:09 AM, Søren Hauberg <[email protected]> wrote:
> 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.
>

I removed inz and grep and rewritten nze. In case someone really
needed those, old versions of the package are still available.


>> 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'.
>

OK.

>> 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?
>

I think cellfun already has a lot of bells and whistles. I'll simply
rewrite apply in terms of cellfun.

>> 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...
>

OK.

>> 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.
>

Only in the last example, I suppose. What I don't find intuitive is
the name of the function.
I'll just rewrite this.

>> csv2latex, xmlwrite:
>> OK, but probably could be in io.
>> used: nowhere
>
> Makes sense to put these in 'io'.

I see there's also xmlread, so I'll keep these for the time being.

>
>> 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'.
>

I moved these two to linear-algebra.

I think I could move some of the functions to general.

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

------------------------------------------------------------------------------
Download Intel&#174; 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

Reply via email to