Re: comparison operators

[Lorenzo Fiorentini]

I don't think that's a bug. As far as I know, it's always been like that.

The point is, [1 1 1 1 1] is ambiguous, and Octave has a rule to decide, as 
suggested by Paul.

Given an L,1 vector, IX=ones(1,L) is the only ambiguous index vector. In fact 
it is the unique element belonging to both sets
A) vectors formed with naturals in the range 1 to L                             
    (index vectors)
B) L-long vectors formed by FALSE (0) and TRUE (1) values only            
(boolean selection vectors)

Would it be correct to try to remove the ambiguity? How?

In principle, a way to avoid this (beside marking the expression as "type 
boolean", see isbool() ), would be to replace the TRUE value with a different 
value, a 
negative one => most natural choice ---> -1. I think that a switch like: set 
"boolean_negated_true = 1", could be proposed. So the two case would be:
a([1 1 1 1 1]) returns [ a(1) a(1) a(1) a(1) a(1) ]
a(a==a) gives a([-1 -1 -1 -1 -1) which returns a

This will produce compatibility problems in all hacks in which the arithmetical 
value of TRUE is used as in the example: 
abs_a = ( (a>0) - (a<0) ) .*a;
abs_a =  ( 2* (a>0) - 1 ).*a 
But will always work well in all other cases, since -1, as a nonzero value, is 
already treated like a TRUE.

Regards.
Lorenzo






-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------