Re: Comparing inexact values (was "Re: Temporal changes")

```HaloO,

Larry Wall wrote:
```
```That seems a bit ugly though.  Another way would be to define ± as
simple half-open Range and then overload comparison:```
```
multi sub infix:<==>(Num \$x,Range \$r) {
\$x == any(\$r.minmax);
}
```
```
This is strange. Having 1 == 1..3 and 3 == 1..3 as true is
not what I expect. I think for consistency with lists and
arrays a range should numify to the length of the list it
represents. That is, we have 'a'..'z' == 26 and 4..6 == 3.

Thinking of string ranges, how would infix ± treat these?
'm' ± 3 === 'j'..'p' seems reasonable albeit not overly
useful. The overload infix:<±>:(Str,Ratio) will hardly work.

BTW, here is a correct implementation of relative error
range creation:

multi infix:<±> (Num \$x, Ratio \$r --> Range of Num)
{
if \$x == 0
{
# range instead of plain 0 to comply with sig
return 0..0;
}
elsif \$x < 0
{
return \$x * (1 + \$r) ..^ \$x * (1 - \$r);
}
else
{
return \$x * (1 - \$r) ..^ \$x * (1 + \$r);
}
}

The interesting thing is that 0 comes out as a special number
that is exact as far as relative error goes. Note that it can't
be subsumed by the other cases because that would produce 0..^0
which fails for 0 ~~ 0..^0 since that means 0 <= 0 < 0 which
is false.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan
```