From help-octave-request at bevo dot che dot wisc dot edu Wed Mar 20 11:06:48 2002 Subject: Re: comparison operators From: Lorenzo Fiorentini To: Ted dot Harding at nessie dot mcc dot ac dot uk, Douglas Eck Cc: Fabian Alvarez , help-octave@bevo.che.wisc.edu Date: Wed, 20 Mar 2002 18:07:07 +0100 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 -------------------------------------------------------------