DLD vs. M-File

[Al Niessner]

I recently posted a potential bug because of a change in the class Cell
behavior (http://www.octave.org/mailing-lists/help-octave/2004/1016) and
John Eaton replied 
(http://www.octave.org/mailing-lists/help-octave/2004/1017) stating that
I should potentially start a new thread on the topic here.

The thread I would like to start is an attempt to figure out why
programming a DLD has to be so different from an m-file and this change
is Cell is simply my breaking point to venture off onto this topic. What
would be nice, if possible, is to maintain a set of helper macros,
functions, and/or whatever, that allow the DLD writer to nearly as
possible express an m-file directly. I have been writing a lot of DLDs
lately and I feel as though I have to learn yet another language.

When I first started using Cell in 2.1.52, I liked the way it worked
because all I had to do was some syntactic sugar and change '{}' to
'()'. Sure, John pointed out that the resizing operation was not being
performed correctly, but it is the fact that it operated just as the
command line did that made it simple and easy to use. If I need to
improve performance I know that one of the first things to do is
preallocate the space rather than dynamically resizing. Fortunately I
know all the sizes posteriori at allocation time, but in many instances
this is not possible or not desirable in which case the dynamic resizing
should be done transparently like in an m-file.

Another example is the 'if (any(M))' will reduce to a boolean. Why is
there no such thing available to the DLD writer? Or 'all'?

I understand that some things are syntactically are not allowed like
'M(:,1)' and I have to get the ColumnVector from the Matrix instead, but
all users of C++ should recognize that quite quickly. There is no reason
I cannot have 'bool all (Matrix bm)' and 'bool all (ColumnVector cv)'
etc. The other problem with the current all() and any() is the loss of
type information. I have a statement something like '(Matrix(chg).abs()
< someValue).bool_matrix_value().all()(0,0))' and it strikes me as bad.
First, I have to convert chg, a ColumnVector, to a matrix just for the
'<' operator. Then I get back something other than a BooleanMatrix???
How could that possibly be? Why should it be allowed? After extracting
the BooleanMatrix from the octave_value, I do an all() on it and get
another matrix back. What happened to reducing the number of dimensions
by one? I would have preferred doing an '....all().all()' to get to a
boolean than magically know that element (0,0) of some matrix contains
the result I want.

So, I have been venting here a bit, but, in the end, I prefer and very
much like Octave. I would just like to see some consistency between the
m-file stuff and the DLD stuff so that people like me can quickly port
the leasqr.m from octave-forge to __leastsq__.cc very quickly and then
dig deeper into octave specifics as I need more and more improvement.

-- 
Al Niessner <address@hidden>
Jet Propulsion Laboratory

All opinions stated above are mine and do not necessarily reflect 
those of JPL or NASA.

 ----
| dS | >= 0
 ----