On 2010-03-09 12:06:05 +0100, Norbert Nemec <[email protected]> said:
Fawzi Mohamed wrote:
On 2010-03-09 09:47:17 +0100, Norbert Nemec <[email protected]> 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
