• Dan <murpsoft hotmail.com> Nov 20 2007
• Bill Baxter <dnewsgroup billbaxter.com> Nov 20 2007
• Robert DaSilva <sp.unit.262+digitalmars gmail.com> Nov 20 2007
• Ary Borenszweig <ary esperanto.org.ar> Nov 20 2007
• Bill Baxter <dnewsgroup billbaxter.com> Nov 20 2007
• Dan <murpsoft hotmail.com> Nov 20 2007
• Bill Baxter <dnewsgroup billbaxter.com> Nov 20 2007
• Don Clugston <dac nospam.com.au> Nov 20 2007

Dan <murpsoft hotmail.com> writes:

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.

Especially if there's no value added.

Can we please get over the cryptolect bullshit and talk straight?  

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?

D let's us use the sugar coated format:

myArray.method() if the method is written to take a myArray as the first
argument.

Regards,
Dan

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Robert DaSilva <sp.unit.262+digitalmars gmail.com> writes:

Bill Baxter wrote:
 Dan wrote: 
 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.


I think there's a proposal for that already.

 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
 calls must have one and only one ".."


Can you propose a syntax for that?

 3) D lacks a way to return a reference.  opIndexAssign only takes you so
 far.


Isn't that in the works?

 4) D lacks a way to transparently reference count memory.  (No
 equivalent of struct copy constructors or destructors)


Can you think of a something that really need reference counting when
you have GC?

 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)


The ref parameter storage type combined with const doesn't make sense,
use in and let the complier decide how to pass it.

Ary Borenszweig <ary esperanto.org.ar> writes:

Robert DaSilva escribió:
 Bill Baxter wrote:
 Dan wrote: 
 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?


 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.


 I think there's a proposal for that already.
 
 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
 calls must have one and only one ".."


 Can you propose a syntax for that?


[1 .. 2, 3 .. 4]

Bill Baxter <dnewsgroup billbaxter.com> writes:

Ary Borenszweig wrote:
 Robert DaSilva escribió:
 Bill Baxter wrote:
 Dan wrote:
 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?


 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.


 I think there's a proposal for that already.

 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
 calls must have one and only one ".."


 Can you propose a syntax for that?


 [1 .. 2, 3 .. 4]


:-) What about the other end?  How do you define the opSlice that gets 
called by every possible combination of N-dimensional slices and indices 
like
    [1..2, N, 4..7]

One way to extend the current syntax would be if there's any .., in an 
argument then all arguments are treated as slices, and a single number 
argument would be treated as N..N+1.  So the above would call 
opSlice(1,2, N,N+1, 4,7)

Another more general solution would be to have 1..2 result in a slice 
object.  So the above would be like calling 
opSlice(slice(1,2),slice(N,N+1),slice(4,7))

--bb

Dan <murpsoft hotmail.com> writes:

Bill Baxter Wrote:
 
 :-) What about the other end?  How do you define the opSlice that gets 
 called by every possible combination of N-dimensional slices and indices 
 like
     [1..2, N, 4..7]
 One way to extend the current syntax would be if there's any .., in an 
 argument then all arguments are treated as slices, and a single number 
 argument would be treated as N..N+1.  So the above would call 
 opSlice(1,2, N,N+1, 4,7)
 
 Another more general solution would be to have 1..2 result in a slice 
 object.  So the above would be like calling 
 opSlice(slice(1,2),slice(N,N+1),slice(4,7))


I would certainly agree that the [n,n] notation seems to have some major
limitations with regards to the other features of D.  If they're fixing them,
awesome.

The way I had thought to achieve this is to use [1..2][0..$][4..7].  This is
arrays of arrays, which I suppose isn't quite as efficient but would allow
slicing multiple ways and you could accomplish alot of cool stuff with that.

Heck, if you use [0..i][($-i)..($-i+1)][3] you can even get diagonal profiles
on a matrix any way you wanna cut it.

You don't have to worry about opSlice weirdness or much else.  You also don't
need templates or classes or any wizardry to get 90% of the stuff you want out
of it.

Instead of boxes or templates to handle the type nastiness, I recommend using
some parts of my Value struct from Walnut - it's BSD licensed and will let you
do different stuff to different types at runtime.  That will matter because
values in a matrix can be non-numerical.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Robert DaSilva wrote:

Hey there Robert, I took Don's original message to be asking about what 
we could do *today*.  There are certainly some features in the works 
that will address a number of my points, and some potential additions 
that with a reasonable proposal, and enough lobbying and support might 
be added sometime in the future.  But that's not what I was writing about.

--bb

 Bill Baxter wrote:
 Dan wrote: 
 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?


 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.


 I think there's a proposal for that already.
 
 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
 calls must have one and only one ".."


 Can you propose a syntax for that?
 
 3) D lacks a way to return a reference.  opIndexAssign only takes you so
 far.


 Isn't that in the works?
 
 4) D lacks a way to transparently reference count memory.  (No
 equivalent of struct copy constructors or destructors)


 Can you think of a something that really need reference counting when
 you have GC?
 
 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)


 The ref parameter storage type combined with const doesn't make sense,
 use in and let the complier decide how to pass it.

Don Clugston <dac nospam.com.au> writes:

Bill Baxter wrote:
 Robert DaSilva wrote:
 
 Hey there Robert, I took Don's original message to be asking about what 
 we could do *today*.


Not really. I was saying, * what does the ultimate goal look like?
And the follow-up question is, * how far are we from the goal?

   There are certainly some features in the works
 that will address a number of my points, and some potential additions 
 that with a reasonable proposal, and enough lobbying and support might 
 be added sometime in the future.  But that's not what I was writing about.
 
 --bb
 
 Bill Baxter wrote:
 Dan wrote:
 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?


 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.


 I think there's a proposal for that already.

 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
 calls must have one and only one ".."


 Can you propose a syntax for that?

 3) D lacks a way to return a reference.  opIndexAssign only takes you so
 far.


 Isn't that in the works?

 4) D lacks a way to transparently reference count memory.  (No
 equivalent of struct copy constructors or destructors)


 Can you think of a something that really need reference counting when
 you have GC?

 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)


 The ref parameter storage type combined with const doesn't make sense,
 use in and let the complier decide how to pass it.