more efficient tuple representation

[timholy]

Is there a correct syntax for doing this?

julia> immutable Iterator{1}
         ni::Int
       end
ERROR: syntax: malformed type parameter list

If so, one could create types Iterator{1}, Iterator{2}, etc, via metaprogramming. I suspect that the alternative,

immutable Iterator{N}
    n::NTuple{N,Int}
end

will not yield the kind of benefits we might want.

[timholy]

I should also say that it's not entirely obvious how one might use Iterator{N} in a generic way without metaprogramming, for anything but the simplest of usages. The only practical case I can think of is efficient linear indexing on SubArrays. This is nothing to sneeze at, of course. But anytime you want to start looking at A[iter.i+1, iter.j] it seems hard to imagine writing generic code without metaprogramming.

[pao]

Would immutable tuples accomplish this? It seems like a cleaner solution.

[StefanKarpinski]

Triples are always immutable. Not sure about the rest, or that I even understand the original request :-\

[pao]

@StefanKarpinski I think the idea was to insert N Int fields into the type. @timholy, based on what Stefan just said, your latter suspicion might be false.

[timholy]

Sorry, I didn't explain it very well.

It might be clearer with a more fleshed-out example. I'm looking to build iterators over all pixels in an image, or over pixels in 2D slices of 3D images, etc. To be able to support both arrays and subarrays, I'm envisioning a family like this:

immutable Iterator1D
    ni::Int   # the length along the 1st coordinate
    stridei::Int
    first_index::Int
end

immutable Iterator2D
    ni::Int   # the length along the 1st coordinate
    nj::Int   # the length along the 2nd coordinate
    stridei::Int
    stridej::Int
    first_index::Int
end

immutable Iterator3D
    ni::Int
    nj::Int
    nk::Int
    stridei::Int
    stridej::Int
    stridek::Int
    first_index::Int
end

This gets tiresome much above 3D. The good news that's probably all that really matters for image processing, but I was wondering whether there is a solution for the general case.

Triples are always immutable.

@timholy, based on what Stefan just said, your latter suspicion might be false.

Tuples won't work for what I want to do because they involve allocation. I first tried implementing Grid's Counter type with tuples. It was literally about a hundred-fold slower than what I finally came up with (which used Array{Int}).

[timholy]

Actually, in this example I should have focused here on the state of the iterator rather than the iterator itself; both can be immutable, but performance only matters for the state. But the point should be clearer now nonetheless, and you can see a complete implementation for 2D here:
https://github.com/timholy/Images.jl/blob/master/src/iterator.jl

[JeffBezanson]

There are actually two features here: the ability to specify different definitions for different parameter values, and structs with a variable number of fields (different since in that case the number of definitions is not finite).

Instead of adding both of those, I think the solution is to make tuples more efficient. Structs have now gotten a huge amount of work, and tuples have been largely neglected. NTuple{N,Int} ought to be exactly as efficient as a variable-size immutable struct of Ints. And, this conveniently corresponds to fixed-size array types ala C, as well as, oh I don't know, SIMD types.

[timholy]

Definitely, making NTuple{N,Int} behave efficiently sounds awesome.