fix null assignment

[David Bateman]

Jaroslav Hajek wrote:
> On Mon, Sep 22, 2008 at 8:39 PM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
>   
>> On 22-Sep-2008, Jaroslav Hajek wrote:
>>
>> | On Sat, Sep 20, 2008 at 6:09 AM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
>> |
>> | > I'd prefer to avoid adding a new assign_op.  I think we would have to
>> | > be careful to also check for op_nul_asn_eq in each place where
>> | > op_asn_eq is used and that is likely to cause confusion.
>> |
>> | Why? I think it would only require to register the handlers.
>>
>> I was just looking at the places where we check for op_asn_eq and
>> thinking that it might be necessary to also check for op_nul_asn_eq,
>> and that this could lead to a maintenance problem in the future.
>>
>> | Btw. I don't much like the fact that A(I,:) =[[;[];];] is also a null
>> | assignment in Matlab; do we really want to copy this behaviour?
>>
>> No, I don't think it is necessary to have [] and [;] or [,] be exactly
>> equivalent.  We could have [] (and, for strings, '' and "") be the
>> only ways of specifying a special nul matrix.  But for compatibility,
>> we should probably accept the [;] and [,] syntax.
>>
>> In any case, I don't think my patch is good enough to include at this
>> point.  I'd be happy to consider your approach instead, if you are
>> willing to write enough of a patch to show how it would be done.
>>
>> Thanks,
>>
>> jwe
>>
>>     
>
> Hmm, at a second glance, the new op type does not seem such a great
> idea. Passing it to subsasgn breaks the consistency of subsasgn
> methods with Matlab's subsasgn, and requires modifying at a lot of
> places.
>
> So attached is what I finally got starting where I left off your patch
> last time. I avoided cluttering the OPERATORS/op-*.cc files with the
> if-is_null_matrix-mark_as_null_matrix stuff by handling null matrices
> in Array<U>->Array<T> type conversion. Unfortunately, it proved
> insufficient - sometimes, conversions are bypassing this method and
> done element by element (e.g. Matrix->ComplexMatrix) so I needed to
> track these cases down.
>
> Btw. I found out that Matlab is also not quite consistent and seems to
> do some magic:
>
> 1. a = ones (3); a(1:2,:) = [] # works
> 2. a = ones(3); subsasgn (a, substruct('()',{1:2, ':'}), []) # works
> 3. a = ones(3); b = []; subsasgn (a, substruct('()',{1:2, ':'}), b) #
> works (i.e. deletes!)
> 4. a = 1:3; a(1:2) = '' # works, i.e. deletes, but isn't this a nonsense?
> 5. a = gf(1:4, 4); a(1:2) = []  # doesn't work (i.e. you cannot delete
> elements from class arrays)
>
> what do you think about these cases? Should we follow all of them?
> In particular 5. is serious, but I'm sure that if we come up with a
> solution, Matlab will likely solve it differently.
>   
With teh galois field code in octave-forge is based on the Array<T> 
class and the assignment of the empty matrix works as expected.

octave:1>  a = gf(1:4, 4), a(1:2) = []
a =
GF(2^4) array. Primitive Polynomial = D^4+D+1 (decimal 19)

Array elements =

   1   2   3   4

a =
GF(2^4) array. Primitive Polynomial = D^4+D+1 (decimal 19)

Array elements =

   3   4

I think we should try and keep this behavior. However in the toy galois 
field class I sent using Octave 3.1.51+ OOP and the subsasgn function

function s = subsasgn (s, index, val)
  switch (index.type)
    case "()"
      if (! isnumeric (val) || iscomplex(val) ||any (val(:)) >= 2.^ s.m ||
      any (val(:)) < 0 || any (val(:) != fix(val(:))))
    error ("subsasgn: value must be an array of real integers between 0 
and 2.^m - 1");
      endif
      s.x = subsasgn (s.x, index, double (val));
    case "."
      error ("subsagn: can not set properties of a galois field directly");
  endswitch
endfunction

I get pretty much the same behavior. If this doesn't work for Matlab 
that is their bug in my opinion as it should.

D.

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