goals for 3.1

[David Bateman]

John W. Eaton wrote:
> On  9-Mar-2008, David Bateman wrote:
>
> | John W. Eaton wrote:
> | >    7. Ensure that all operations which work on dimensions alone
> | >       (squeeze, numel, triu, etc.) work for all objects and preserve
> | >       type.  Should these functions all be built-in?  Possibly they
> | >       should all be provided by the octave_value class interface.
> | >   
> | 
> | Ok, I see this task as being in three parts, and maybe a zeroth part
> | 
> | 0) Identify which functions are concerned. I see the list at the moment
> | as being triu, tril, squeeze, permute, ipermute, shiftdim, circshift,
> | reshape,  and resize. I'm not sure I see why numel was in that original
> | list. Are there any others?
>
> That was a mistake.  It should have just been a list of functions that
> operate on dimensions or by indexing elements (like triu).
>
> What about diag, flipdim, fliplr, flipud?
>   
Ok, i'll add these and transpose, ctranspose, rot90, and a few others

> I'm not sure that all of these should be built in.  The ones that are
> .m files may already preserve type correctly, though it is worth
> checking, especially for any cases that can return empty values (they
> may convert to double then).  At least for now I would not bother to
> convert .m files to built-in functions unless there is a definite need
> for improved performance.
>   
Ok, I won't.. My first step is to propose the test code to prove that
the functions are currently implemented correctly or fix them if they
aren't.. I already sent one fix for circshift as the empty matrix case
caused issues, and the current test code doesn't identify any other issues.
> I have no objection to putting the tests in a separate file in the
> test directory if there is something to be gained by grouping the
> tests together.
>   
Ok, this is what I did in the attached patch, as it is much simpler.

> | 3) Convert these functions to be members of the octave_value class. What
> | are your thoughts now on this? Should they be members of the
> | octave_value class? Or can we forgo this?
>
> Let's look at each case individually.  If writing a function in the
> body of a DEFUN requires switching on type (for example) then I think
> we should use octave_value methods for that, possibly with the actual
> implementation in the Array/Sparse classes.
>   
The only function I see that is not already in the octave_value class
but is already a DEFUN is the Fdiag function. Yes this function has a
mess of if/else blocks for the types and so its probably worth moving it
into the octave_value class. I'll look at a patch for that in the near
future..

I attach a patch for Octave to add the test code and an equivalent 
function that can be used in Octave/Matlab to test compatible behavior.
Are there any other functions I missed? Are there any additional tests
that might be useful?

Regards
David


-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch7762
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080320/b6a7fe38/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testfunc.m
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080320/b6a7fe38/attachment-0001.ksh