[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Implementing nd-arrays
From: |
Heine Kolltveit |
Subject: |
Implementing nd-arrays |
Date: |
Wed, 30 Jul 2003 15:29:52 +0200 (MEST) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Implementing nd-arrays,
Heine Kolltveit <=