Re: goals for 3.1

[John W. Eaton]

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?

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.

| 1) Write test code that compares the output of Octave against matlab for
| the desired functions and confirm their consistency. Address any issues
| in the Octave code. The resize function doesn't exist in matlab so its
| not obvious to test this function. The attached code I believe tests all
| of the others and compares the behavior with matlab's as thecode is
| matlab compatible. The 3.0.0 behavior of all of these functions seems to
| be correct.

OK.

| 2) Convert that test code to test/assert framework of Octave for
| regression testing. It would be easy to add the attached test code into
| the test/ directory. However, the trend is to have the tests embedded in
| the code, and that will be an issue, in that all of the tests are much
| the same, and distributing the tests into each function will result in
| code duplication.

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.

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

jwe