octave-maintainers
[Top][All Lists]
Advanced

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

Re: fix null assignment


From: John W. Eaton
Subject: Re: fix null assignment
Date: Fri, 19 Sep 2008 11:50:51 -0400

On 19-Sep-2008, Jaroslav Hajek wrote:

| It seems that there is a need to propagate the information (whether
| this is a deletion statement) fairly deeply - thinking of things like
| a(3).x.y(1:2,:) = []
| that should work... this stuff is resolved by subsasgn, and creating
| methods like subsnulasgn would probably mean a lot of duplication. It
| seems better to make a special kind of object for the "genuine" empty
| matrix that was not touched by expressions. I'm just not sure where to
| put it.

I think there are a few things to consider.  First, for an expression
like "X(I) = []", if X is a class object, the subsasgn method for the
class is still called.  So in that case, if we have the parser
recognize "= []" as a special case and convert it to a call to a
function that deletes elements, then that function will need to
dispatch to the subsasgn method for the given class.

Another possibility is to tag matrices that are created with [], then
use that information in the assign2 and assignN functions to decide
when to call maybe_delete_elements.  So instead of

  if (rhs_nr == 0 && rhs_nc == 0)
    {
      lhs.maybe_delete_elements (idx_i, idx_j);
    }

in the assign2 function in Array.cc, we would have something like

  if (rhs.is_null_array ())
    {
      lhs.maybe_delete_elements (idx_i, idx_j);
    }

But is this the right place for the check?  Maybe not, since it only
happens when the RHS is [] (i.e., double) and the LHS can be anything
(even a struct array).  So it should probably be handled a little
higher up, and the detection and call to maybe_delete_elements should be
removed from the assign2 and assignN functions.  In that case, I think
the proper places for this are the various octave_value subsasgn
methods.  Then the special tag for the [] value could go in the
octave_value object itself.  Perhaps there could even be a special
octave_value type for this object, similar to the octave_magic_colon
type.  In any case, the special nature of this value/type should not
be propagated by assignment or copying since

  x(idx) = []

deletes, but

  y = []; x(idx) = y

does not.

Unless someone else is interested, I'll take a look at making these
changes.

jwe


reply via email to

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