Proposal: Multidimensional opSlice solution

[Fawzi Mohamed]

On 2010-03-09 09:47:17 +0100, Norbert Nemec <Norbert at Nemec-online.de> said:

> Ellery Newcomer wrote:
>> On 03/08/2010 08:49 PM, bearophile wrote:
>>> 
>>>> Admitted, the last case does not work quite as nicely with ".." as it
>>>> does with Python's ":". Still, the point should be clear.
>>> 
>>> I have never understood why Walter has adopted .. for slices instead of 
>>> the better :
>>> I'd like to know why.
>>> 
>>> Bye,
>>> bearophile
>> 
>> Ternary ?:, I suppose.
> 
> Why not simply split up the ternary a?b:c into a nested expression
> 
> 	a?(b:c)
> 
> The binary ":" could simply be an expression that may only appear in 
> special contexts: on the right side of binary "?" expressions or within 
> indexing expressions.

I don't see why the obvious solution from..to..step would have 
problems, so that one needs the ":", but maybe I did not think enough 
about the implications. Anyway I find .. more self descriptive for 
slices than :.

Anyway at the moment there is no syntactic sugar for that.
You said that multidimensional arrays are a niche, well t might well 
be, but still there are some implementations in D.
In particular there is my NArray implementation in blip 
http://dsource.org/projects/blip .
Using it your example

	off = (y[:-1,:]*x[1:,:] - y[1:,:]*x[:-1,:]) / (x[1:,:]-x[:-1,:])

becomes

	auto 
off=(y[Range(0,-2)]*x[Range(1,-1)]-y[Range(1,-1)]*x[Range(0,-2)])/(x[Range(1,-1)]-x[Range(0,-1)]);

not 

ideal, but not so terrible either.
The Range structure negative indexes are from the end, and are 
inclusive (thus Range(0,-1) means up to the end, the whole range).
This removes problems with making $ work correctly.
NArrays basically never copy and have a reasonable performance. As they 
are based on a big flat storage, you can easily write very efficient 
code, and use already written libraries, for example blas and lapack 
are used by default for several operations.
You can use scope to guarantee collection (well not yet with all 
compilers it works as it should).
All operations can have the target array, so that you can avoid the 
allocation of temporary arrays.
Thus for example

	auto off=(y[Range(0,-2)]*x[Range(1,-1)]-y[Range(1,-1)]*x[Range(0,-2)]);
	off /= (x[Range(1,-1)]-x[Range(0,-1)]);

would already be a bit better (one temporary less).
Probably a pool for reusing temporaries would be good, but I did not do 
it. Also there are no expression templates (à la blitz++), these work 
well for small expressions, but when you have to follow several read 
contexts it becomes unclear if it is really a win, so optimizing them 
can be very complicated. There are optimized versions of commonly used 
operations.
Parallelization has been prepared, but not yet done (it is a rewrite of 
the ploop iteration away).
I think that the library is quite complete from the user point of view, 
and quite usable...

Fawzi