Jon Lang wrote:
> TSa wrote:
>> 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".
Another possible approach would be to define postfix:<%> as returning
a code block:
sub postfix:<%>(Num $x) generates { $x / 100 * ($_ \\ 1.0) }
This would allow it to partake of nearly all of the same dwimmery of
which Whatever can partake, save for the purely Whatever stuff.
Brandon S. Allbery wrote:
> Jon Lang wrote:
>> I'm not sold on the notion that Num should represent a range of values
>
> Arguably a range is the only sane meaning of a floating point number.
Perhaps; but a Num is not necessarily a floating point number - at
least, it shouldn't always be.
Doug McNutt wrote:
> Jon Lang wrote:
>> 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).
>
> Don't get too hung up on that example.
>
> If $x is 2*pi, asin(sin($x)) would return 0.0 and not 2*pi.
True enough: asin is not the inverse function of sin, although it's
probably as close as you can get. And even there, some sort of
compiler optimization could potentially be done, replacing the
composition of asin and sin (both of which have the potential to
intensify error) with a normalization of the value into the -pi ..^ pi
range (which might also introduce error).
--
Jonathan "Dataweaver" Lang
