octave-maintainers
[Top][All Lists]
Advanced

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

Re: fix null assignment


From: David Bateman
Subject: Re: fix null assignment
Date: Wed, 24 Sep 2008 15:22:53 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080725)

Jaroslav Hajek wrote:
On Mon, Sep 22, 2008 at 8:39 PM, John W. Eaton <address@hidden> wrote:
On 22-Sep-2008, Jaroslav Hajek wrote:

| On Sat, Sep 20, 2008 at 6:09 AM, John W. Eaton <address@hidden> 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                                address@hidden
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



reply via email to

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