Hi all,
I think D has a lot to offer technical computing:
- the speed and modeling power of C++
- GC for clean API design
- reflection for automatic bindings
And technical computing has a lot to offer D:
- users
- API writers
- time in the minds of people who teach
Multidimensional array support is important for this exchange to
happen, so as a D user and a computer vision researcher I'm glad
to see it's being addressed! However, I'm interested in hearing
more about the rationale for the design decisions made concerning
pull request #443. My concern is that this design may be
ignoring some of the lessons the SciPy community has learned over
the past 10+ years. A bit of elaboration:
In Python, slicing and indexing were originally separate
operations. Custom containers would have to define both
`__getitem__(self, key)` and `__getslice__(self, start, end)`.
This is where D is now. Python then deprecated `__getslice__`
and decided `container[start:end]` should translate to
`container[slice(start, end)]`: the slicing syntax just became
sugar for creating a lightweight slice object (i.e. a "range
literal"), but it only worked inside an index expression. If I
understand correctly, this is similar in spirit to the solution
the D community seems to be converging upon. This solution
enables multidimensional slicing, but needlessly prohibits the
construction of range literals outside of an index expression.
So, why is this important? One point of view is that
multidimensional slicing is just one of many use cases for a
concise representation of a range of numbers. In more
"specialized" scientific languages, like MATLAB/Octave and Julia,
range literals are a critical component to readable, idiomatic
code. In order to partially make up for this, SciPy is forced to
subvert Python's indexing syntax for calling functions that may
operate on numeric ranges, obfuscating code (e.g.
http://docs.scipy.org/doc/numpy/reference/generated/numpy.r_.html).
I point this out because it (fortunately) seems like D is in a
position to have range literals while maintaining backwards
compatibility and reducing language complexity (details are
below). I'd like to hear your thoughts about range literals as a
solution for multidimensional indexing: whether it's been
proposed, if so, why is was decided against, what its
disadvantages might be, whether they're compatible with the work
already done on this front, etc.
===================
Range Literals in D
===================
// Right now this works:
foreach (i; 0..10) doScience(i);
// And this works:
auto range = iota(0, 10);
foreach (i; range) doScience(i);
// So why shouldn't this work?
auto range = 0..10;
foreach (i; range) doScience(i);
// Or this?
auto range = 0..10;
myFavoriteArray[range] = fascinatingFindings();
// Or this?
auto range = 0..10;
myFavoriteMatrix[0..$, range] = fascinating2DFindings();
// `opSlice` would no longer be necessary...
myMap["key"]; // calls `opIndex(string);`
myVector[5]; // calls `opIndex(int);`
myMatrix[5, 0..10]; // calls `opIndex(int, NumericRange);`
// But old code that defines `opSlice` could still work (like in
Python).
myVector[0..10]; // If `opIndex(NumericRange)` isn't defined,
// fall back to`opSlice`.
// `ForeachRangeStatement` would no longer need to exist as an
odd special case.
// The following two statements are semantically equivalent, and
with range
// literals, they'd be instances of the same looping syntax.
foreach (i; 0..10) doScience();
foreach (i; iota(0, 10)) doScience();
// Compilers would, of course, be free to special-case `foreach`
loops
// over range literals, if it's helpful for performance.
On Wednesday, 12 March 2014 at 13:55:05 UTC, Kenji Hara wrote:
2014-03-08 10:24 GMT+09:00 Andrei Alexandrescu <
seewebsiteforem...@erdani.org>:
I agree and sympathize.
I finished to update my pull request #443. Now it is active.
Kenji Hara
