The Matrix to end all Matrix classes (Let's dream!)

[Bill Baxter]

Dan wrote:
> Neal Becker Wrote:
> 
>> I'm fond of blitz++ approach:
>>
>> 1.  An array is a view of memory, with dimension, strides, and (possibly)
>> non-zero bases.  This design allows multiple, independent views of the same
>> memory.
> 
> An array already has a clear definition.  Anyone attempting to redefine terms doesn't have enough familiarity with them.  Arrays are 1 dimensional segments of discrete information.
> 
>> 2. Memory allocation itself is ref counted.
>>
>> Benefits: 
>>
>> * This design allows a slice, or view to be an lvalue.
>> * Plays nicely with python - semantics are similar to numpy/numeric.
>>   specifically, I can return a view as a python object.  Python can hold it,
>> and ref counting keeps the underlying memory alive.
>> * Generalized views.  For example real(complex_array) is a view, and is an
>> lvalue.
> 
> Recreating the Python square wheel in D won't serve the needs of very many people.

Maybe not, but if you'd like to take it for a test drive, go visit 
www.dsource.org/projects/multiarray .  :-)

> Especially if there's no value added.

The value added is that it's no longer interpreted python code where the 
use of a for loop kills your performance.  And being similar to numpy 
under the hood opens the door for using D and pyD to easily create 
extension modules for Numpy.  Though multiarray doesn't do that currently.

> D's slices already perform 90% of the stuff we want in order to achieve a Matrix.  You more or less just want a standard library that lets you do it, right?

I'd say it lets you do about 50% of the stuff you want for a Matrix, but 
putting a single percentage figure on it is not really possible, because 
different features have different importance to different users.

In particular:
1) $ can't be used for opIndex or opSlice in user-classes.
2) D lacks a clean syntax for slices of multiple dimensions.  opSlice 
calls must have one and only one ".."
3) D lacks a way to return a reference.  opIndexAssign only takes you so 
far.
4) D lacks a way to transparently reference count memory.  (No 
equivalent of struct copy constructors or destructors)
5) D lacks a way to pass by const-reference (even in D2 -- but 
presumably this is just a bug in the D2.x compiler)

> D let's us use the sugar coated format:
> 
> myArray.method() if the method is written to take a myArray as the first argument.

I have no idea what problem this is suggesting a solution to.

--bb