Oskar's Multidim array code

[Bill Baxter]

Oskar Linde wrote:
> Bill Baxter wrote:
>> Oskar Linde wrote:
>>> Bill Baxter wrote:
>>>
>>>> Anyway, f[i][j][k] syntax is much more difficult to read than 
>>>> f[i,j,k].  So I think the latter is what we should be shooting for.
>>>
>>> I agree, and for what it is worth it is possible to implement 
>>> multidimensional indexing and slicing for UDTs today. The only thing 
>>> lacking is the ability to use the .. and $ tokens. For example:
>>>
>>> f[i, all, all, j, all, end-1, all, range(1, end)]
>>>
>>> gets translated into quite optimal code. The only variables that get 
>>> passed to the indexing function is (i,j,1,1) and no temporaries need 
>>> to be created. I guess that with some additional compiler supported 
>>> sugaring, the above could become something like:
>>>
>>> f[i, .. , .. , j, .. , $-1, .. , 1..$]
>>>
>>
>> Now if you would just put all that goodness on Dsource or somewhere 
>> where the rest of us can appreciate it... :-)
> 
> OK. I extracted it from my sources, stripping it from most external 
> dependencies. Operator overloading is also stripped and most 
> non-essentials:
> 
> http://www.csc.kth.se/~ol/multiarray.zip
> 
> The result is basically a simple demonstration of a strided 
> multidimensional array slice type.
> 
> Indexing/slicing is done in such a way that:
> 
> f[a,b,c] is identical to
> f[a][b][c]
> f[a,b][c]
> f[a][b,c]
> 
> Don's global __dollar idea is implemented, but not int[2] slices (can't 
> do them easily as things are now).
> 
> f[i, all, all, j, all, $-1, all, range(1, $)]
> 
> All indexing expressions are inlined by GDC at least. Since they are 
> inlined, there is probably no need to make "all" a distinct type rather 
> than range(0,$), but that is how it is now.
> 
> Iteration is very sub-optimal since it relies on opApply, that neither 
> GDC nor DMD can inline (as far as I know).
> 
> opIndex and opIndexAssign are implemented so they return the ElementType 
> rather than a 0-dimensional array when all dimensions are collapsed.
> 
> Since I just rewrote parts of it right now without keeping my unit 
> tests, the implementation is very unlikely to be bug free. :)
> 

Wonderful!

Would you mind if I checked that into my dsource multiarray project? 
I'd like to try to hook it up to lapack, and maybe try to unify it with 
my runtime N-dim array class.

I use the Zlib license for the rest of the stuff there, is that ok?

--bb