purpose of 10486:4e64fbbd5c58

[John W. Eaton]

On  6-Apr-2010, Jaroslav Hajek wrote:

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

I agree that it would be better to require indices to be integers.
The change was made after I received a bug report from someone who is
paying me for support and who noticed the incompatibility with
Matlab.  It seemed to me that it would be a relatively safe change
since it only relaxed the rules for indexing slightly.  It also seemed
best to me to make the change at a low level so that any code that
created an idx_vector object from a Range would work the same way.  I
didn't discuss the change because it seemed pretty straightforward and
I didn't see it causing any trouble with existing code.

| IMHO this is simply a defect in Matlab that persists for compatibility
| and will likely be removed in the future.

Since the warning message from Matlab says that integer indexing is
required, but then it allows non-integer indexing in this particular
case, it could also be that at some point a change was made to make
non-integer indexing with ranges an error, then someone complained
that the change broke a lot of their code (I know, why would they be
doing this in the first place, but they are, so they don't want to
be forced to modify all their code) then the "fix" was to just make
the error a warning.  But that's of course just a guess.

| Besides breaking isindex(),

How does it break isindex?

| this breaks the general consistency; an
| invalid index is accepted in some contexts but rejected in others.

Will you please give an example of the inconsistent behavior?  If I
had recognized an inconsistency (other than the different treatment of
matrices and ranges) I would have probably thought about whether there
was a better way to make the change.

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

I don't understand.  You seem to be thinking about examples that I am
unable to guess, so it would help if you could show the examples where
this change will cause trouble.

| Are there any positives that I'm missing?

The positive is that it makes Octave compatible with Matlab in this
one small way, so that people who happen to use this feature (and yes,
I agree that it is not a good feature) won't trip over the difference
when they try to use their code in Octave, and then subsequently
conclude that Octave sucks.

jwe