Re: purpose of 10486:4e64fbbd5c58

[Jaroslav Hajek]

On Tue, Apr 6, 2010 at 8:02 AM, Jaroslav Hajek <address@hidden> wrote:
> hi John,
>
> maybe we should discuss this change. What's the point of this?
> OK, now it's Matlab-compatible, but I think Octave's behavior was
> better. I really hate it that x([a:b]) now behaves differently from
> x(a:b).
> IMHO this is simply a defect in Matlab that persists for compatibility
> and will likely be removed in the future.
>
> Besides breaking isindex(), this breaks the general consistency; an
> invalid index is accepted in some contexts but rejected in others.
> Since it is nearly impossible to distinguish a range from a matrix in
> an m-function, this will be difficult to honor in user-defined
> classes, breaking consistency even more.
>
> Are there any positives that I'm missing? Otherwise, I think the
> change should be reverted.
>
> regards
>

I figured out a slightly better solution, that doesn't pollute the
other functions using index_vector, so I reverted the previous change
and suggest the attached one as a replacement. This time the change is
done in the interpreter so does not leak to other contexts and is
controlled by a variable, which is on in the maximum braindamage mode.
Note that this still is not quite Matlab compatible (neither is your
previous change), because Matlab (2007a) allows this:
a(1.1:4)
with a warning, yet disallows this:
i = 1.1:4;
a(i)

Apparently Matlab treats the ranges differently than we do, hence the
difference. The behavior seems undocumented and IMHO likely to be
removed (the warning even says that integers are *required*) in the
future. I suggest you rethink whether you really want Octave to
support this nonsense at all.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

nintranges.diff
Description: Text Data