TSa wrote: > 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.
I'm not certain about the exact mechanism to use; all I know for certain is that I want a kind of dwimmery with postfix:<%> that returns a percentage of some other value when it's reasonably easy to decide what that other value should be, and a percentage of the number one otherwise. Perhaps that _is_ best handled by means of a "Ratio" type (or whatever), perhaps not. If so, I think that Rat (as in "a Rational Number") should be kept distinct from "Ratio" (as in "a portion of something else"). Perhaps the latter should be called a "Portion" rather than a "Ratio". > 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. I'm not sold on the notion that Num should represent a range of values (and I use "range" here in its mathematical sense of "any number that's between the given lower and upper bounds", as opposed to its Perlish sense of "a discrete list of numbers"). However, I _do_ like the idea of distinguishing between "is exactly equal to" and "is approximately equal to"; and tracking the margin of error would be essential to getting the latter option to work. > Another question is if we define some arithmetic on these closures > so that asin(sin(2)) == 2 exactly. I don't know how relevant this is; but this sounds like the sort of optimization that pure functional programming allows for - that is, if the compiler ever sees a call like asin(sin($x)), it might optimize the code by just putting $x in there directly, and bypassing both the sin and asin calls - but only because both sin and asin are pure functions (i.e., they don't produce any side effects). As well, I have a certain fondness for the idea of lazy evaluation of mathematical functions (and pure functions in general), on the premise that whenever you actually carry out an operation such as sqrt or sin, you potentially introduce some error into the value with which you're working; and if you postpone the calculation long enough, you may find that you don't need to perform it at all (such as in the aforementioned "asin(sin(2))" example). -- Jonathan "Dataweaver" Lang
