octave-maintainers
[Top][All Lists]
Advanced

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

Re: indexing improvements - advice wanted


From: David Bateman
Subject: Re: indexing improvements - advice wanted
Date: Mon, 27 Oct 2008 16:13:13 +0000
User-agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)

Jaroslav Hajek wrote:
So, my questions (or opinion inquiries) are:

1. how much is backward compatibility of error messages desirable? In
the current patch, I let Array<T>::resize () gripe when invalid
resizing is requested (e.g. A(10) = 1 with A = ones(3)). However, the
error message changes in such case; otherwise, an argument to resize
would be needed to distinguish whether it's called from
Array<T>::assign or from elsewhere. This is certainly possible, but is
it worth cluttering interfaces by optional arguments just to keep
error messages backward compatible? (note that they're by no means
Matlab compatible, but that's not even reasonable to want)

I don't think back compatiblity of error messages is that important. If there is a good reason to change them, I'd say do it.


2. what about the failing tests relying on Matlab incompatible (and
slightly illogical) behaviour? Should the tests be fixed, or should I
try to adapt the code so that it behaves backward in a
backward-compatible manner? Note that these are rather corner cases,
quite unlikely to occur in real code.

Less sure about this point. If the corner cases were added as test cases, wwho were they added by? Maybe the person who added them should comment on their need for these cases?

and, of course, if anyone discovers the source of the concatenation
bug, I'll be grateful :)

Haven't looked at the patch so can't help out there (at least yet). In any case I've always thought the indexing was needlessly slow and so this is a big improvement and so I'm all for this patch. Also it seems to me that a case like

A = speye(1e6,1e6)
A (A != 0) = randn(1e6,1);

that uses sparse logicall indexing would be easy to implement in your new scheme as described, and this is one point that has always annoyed me.

One point though, given that 3.2 is relatively close, perhaps this is another patch to consider for 3.3 rather than 3.2 as with Michael's object properties patch as the risk of obscure bugs is fairly high.

Cheers
David

--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)


reply via email to

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