Proposal: Multidimensional opSlice solution

[Fawzi Mohamed]

On 2010-03-09 12:06:05 +0100, Norbert Nemec <Norbert at Nemec-online.de> said:

> 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[:,:,:,:]

I agree that for the full slice it looks uglier

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

As far as I know for D1.0 and large multidimensional arrays, really 
usable libraries are just multiarray by braxissimo (that is a kind of 
abandoned experiment, as he focused on matrixes and vectors), and then 
my library.
Matrix libraries are more (and my library supports dense 
matrixes/vectors), but really multidimensional libraries, I am not 
aware of other serious contenders, please share the others...

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

Indeed missing= implicit, to swap dimensions you have to use Range(-1) 
(the full range from 0 to the last).

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

Indeed I don't accept negative indexes for indexing, just for Ranges 
(where the overhead should be acceptable).

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

let me know if you have problems/comment about it (also in the IRC if 
you want).

ciao
Fawzi