Proposal: Multidimensional opSlice solution

[Norbert Nemec]

Fawzi Mohamed wrote:
> 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 :.

The ".." vs. ":" issue is really more cosmetics. It makes a bit of 
difference in readability when full slices are used in multiple 
dimensions. Simply imagine
	A[..,..,..,..]
vs.
	A[:,:,:,:]


> 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 .

Indeed, there is a number of implementations. Will be interesting to do 
a systematic comparison. Ultimately, I would like to combine the 
strengths of all these different implementations into one library that 
has the potential to become standard. Multidimensional arrays are the 
essence of the interfaces of most numerical libraries. Having several 
incompatible standards is a major roadblock for acceptance in the 
numerical community.


> 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 full slicing indices for the second dimension are missing. You could 
of course make those implicit, but then what happens if you need that 
expression to work on swapped dimensions?


> 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.

The negative sign solution is nice for scripting languages like Matlab 
or Python. In a compiled language it leads to unnecessary runtime 
overhead because every indexing operation needs to be checked for the sign.


> I think that the library is quite complete from the user point of view, 
> and quite usable...

Good to know. I will have a closer look at it.