Implementing nd-arrays

[Heine Kolltveit]

We're a couple of guys that are currently working together on implementing
nd-arrays. In relations to that we have a few questions and statements to
make:

Earlier today, a patch was sent as an attachment that was BASE64-encoded.
I see that on the web-site archives it still is BASE64-encoded and
therefore not directly readable. Is this a problem?

Do we send new code as soon as we have written it and made a quick
bug-check, or do we wait a week or two to see if any new bugs turn up?
The former alternative will increase the number of patches and bug-fixes
sent in, and could make the use of nd-arrays unstable and buggy, whereas
the latter may delay new code unnecessary.

A design issue we would like to address is how creation of nd-arrays
should be done. Right now, an assigment where both the left hand
side and the right hand side are scalars, the resulting value will
be a ndarray (redefined in /src/OPERATORS/op-s-s.cc), on which we
call maybe_mutate. If the ndarray has one dimension, it will mutate to
a scalar, and similarly if it has two dimensions, the result will be a
matrix.
The same approach is done for matrices: matrix = matrix -> nd-array.
This design is an extension of the existing design where a scalar = scalar
results in a matrix which is mutated to a scalar if is needed.

Does anyone have any comments/concerns on this design?



Some of our implementations and work in progress are:

The zeros() and ones() functions for nd-arrays.
Formatted printout of nd-arrays.
Nd-array assignments
The rand() and randn() functions for nd-arrays
Nd-array indexing (ArrayN::index() functions)



Regards,
Heine Kolltveit and Petter Risholm