for the record, this almost works, once types are specified. what seems to
limit things is the lack (afaict) of a way to specify that the type
parameters are themselves Ints. for example
start{S::Int,I::Int,E::Int}(r::TypedRange{S,I,E}) = S - I
is invalid syntax.
andrew
On Wednesday, 19 March 2014 18:44:05 UTC-3, andrew cooke wrote:
>
>
> ok, after thinking some, i guess it's because the type of the iterator
> isn't fixed by the function arguments. i'll see if i can make that
> happen. andrew
>
> On Wednesday, 19 March 2014 18:03:09 UTC-3, andrew cooke wrote:
>>
>>
>> various people (mainly vtjnash, i guess) have repeatedly warned me off
>> using the type system as much as i would like. despite this, i had the
>> idea of sticking iterator parameters into the type system. my reasoning
>> was that specialised code would be inlined for each iterator. it failed
>> miserably (gave a 300x slowdown), but i don't understand why.
>>
>> so can anyone give me a rough sketch of why the code at
>> https://github.com/andrewcooke/IntModN.jl/blob/master/src/Range.jl is
>> such a bad idea?
>>
>> here's the meat:
>>
>> immutable TypedRange{S,I,E} <: Ranges{Int}
>> end
>>
>> # MyInt is used just to isolate this code; if I re-implement the generic
>> # count I cause chaos, changing code deep within the implementation...
>>
>> function colon(start::MyInt, inc::MyInt, end_::MyInt)
>> TypedRange{start.i, inc.i, end_.i}()
>> end
>>
>>
>> start{S,I,E}(r::TypedRange{S,I,E}) = S - I
>> next{S,I,E}(r::TypedRange{S,I,E}, i::Int) = (i + I, i + I)
>> done{S,I,E}(r::TypedRange{S,I,E}, i::Int) = I > 0 ? i >= E : i <= E
>>
>> thanks,
>> andrew
>>
>>
