octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DLD vs. M-File


From: John W. Eaton
Subject: DLD vs. M-File
Date: Fri, 16 Apr 2004 12:50:30 -0500

On 12-Apr-2004, Al Niessner <address@hidden> wrote:

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

To make automatic resizing work correctly in C++ requires knowing
whether the indexing operation appears on the left or right side of an
assignment operation.  Not impossible, but does add to the
complexity, and I believe this is not something that can be done in
one base class.  The extra complexity must appear in every class that
needs this functionality.  So it could be a lot of work for relatively
small (for me, at least) payoff.

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

I don't think we can overload on return type in C++.  We need any()
and all() to return N-d arrays so they can work along some specified
dimension.  If you'd like to write a function that does the equivalent
of all() or any() over all dimensions and returns bool please do so
and submit a patch.  But I think you will have to call them something
other than just all and any.

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

There is no operator < defined for Matrix objects either.  What is
actually happening is that the Matrix operands are being converted to
octave_value objects, which do have an operator <.  It returns an
octave_value, object, not a boolMatrix, because there is no reason to
assume that all possible octave_value types will want to return
boolMatrix (or boolNDArray).

I don't think anyone ever claimed that every operator that anyone
would ever want was implemented in the C++ classes.  I implemented the
ones I needed to support writing Octave.  If you find that others are
needed, then please submit patches to provide them.  Or consider
funding someone to do it.

You could argue that the conversions should not happen implicitly, but
I think it is very convenient to have some default conversions.
Otherwise, there would have to be a lot more explicit "octave_value
(xxx)" conversions in Octave's internals, and I think I would find
that quite distracting.

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

The all function accepts an optional dim argument, so the result could
be either a row or a column.  Again, overloading on return type is not
allowed.  We could have two functions (but only for the 2-d case, for
N-d, what would you do?) but I found it sufficient to have just one,
since originally, Octave (not liboctave) only had Matrix objects
internally, not ColumnVector and RowVector as well.

| 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

That would probably be good, but there are many many many projects
that people have suggested and very little contributed funding, code,
or time to go along with those requests.

| so that people like me can quickly port
| the leasqr.m from octave-forge to __leastsq__.cc

But why should people always be converting everything to .cc files?
It is generally much simpler to maintain the .m versions.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]