HaloO,
Jon Lang wrote:
@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.
I don't understand what you mean with setting Whatever. Whatever is
a type that mostly behaves like Num and is used for overloaded
postcircumfix:<[ ]>:(Array @self: Whatever $i). So *-1 just casts
the -1. Postfix % would do the same for Ratio. Then one can overload
postcircumfix<[ ]>:(Array @self: Ratio $r) and multiply $r with the
size of the array to calculate the index. BTW, this indexing reminds
me of the way how textures are indexd in OpenGL. With that in mind
the index ratio could also interpolate between entries of a texture
array.
Concerning "-> $val, $err { [..^] $val - $err, $val + $err }" vs "->
$val, $err { any $val - $err, $val + $err }": I'm not sold on the
notion that Huffman coding might imply that ± should go with the
former. Perhaps an argument can be made for it; but I suspect that
the relative commonness of the two uses is extremely similar (which,
per Huffman coding, would imply that their names should have similar
lengths). Whichever one we go with, we have a conundrum: if we use ±
as the name of the latter, the conundrum is that the only other
intuitive name for the former that has thus far been proposed (i.e.,
"within") is too long; if we use ± as the name for the former, the
conundrum is that no other intuitive name has been proposed for the
latter.
So: what we need are proposals for short, understandable names for
each operator. Suggestions?
I think the junctive alternative is of little use. A numeric Range has
its primary purpose as the rhs of a smartmatch that checks numbers. We
have no proper range arithmetic that renders the semantics of
approximated exact numbers.
So here comes some rant about Num as the type that in contrast to Rat
carries an approximation error and an approximation closure that can be
called to decrease the error. That is e.g. sqrt(2) returns such a thing
that can be called again to continue the iteration. Numeric equality
checks would then not only compare the approximate values but also the
identity of the iteration closure. Whereas ~~ would check if the lhs
number's interval falls into the range of the rhs which is build from
the current approximation and the error. The approximation closure is
never invoked by ~~. Infix ± would then not create a range but a Num
with explicit error. That is, it is syntactic sugar for
$y.error = 0.001;
$x ~~ $y;
where I think the error should always be the relative error. Hmm, or the
relative error is indicated by the Ratio type. This gives the following
ways to write literal Nums:
my $x = 10 ± 0.01; # absolute error, no approximation closure
my $y = 10 ± 0.1%; # same with relative error
10.001 == $x; # false because undecidable
10.001 ~~ $x; # true
The falsity of == is due to the fact that 10.001 is exact and therefore
the errors aren't the same. That is 10 ± 0.1 == 10 ± 0.01 is false
because their is no approximation closure to decrease the error on the
lhs. Num equality is a rare event! 9 ± 0.1 < 10 ± 0.1 is easily true
because 9.1 < 9.9. Even 10 ± 0.1 == 10 ± 0.1 could be false, so that
only exact values and values with the identical approximation closure
can be equal. Assuming that the basic arithmetic operations are exact
because they use the Rat type the approximation system should manage to
have sqrt(2) / 2 == 1 / sqrt(2). I think that succeeds because the Rat
returned by sqrt(2) is the same, division preserves the relative error
and the approximation closure is the same.
The problem with the approximation closure is that it becomes more and
more complex during calculations. So we need to cut it off e.g. so that
it is at most one level deep. Also the error is than fixed at the level
of the input.
Another question is if we define some arithmetic on these closures
so that asin(sin(2)) == 2 exactly. I think this is doable by e.g. an
'is inverse' trait on code objects. This would allow asin to extract
the integer 2 from the sin approximation closure and return it. Pi
would be the identity of an approximation closure and it is not required
from an implementation to render sin($x) == sin($x + 2*pi) even though
it is imaginable if $x contains a Num that has pi as approximation
closure so that an exact modulo can be put into the approximation
closure of sin's return value.
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
