[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: comparison operators

**From**: |
Lorenzo Fiorentini |

**Subject**: |
Re: comparison operators |

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