Re: complex arrays in octfiles

[John W. Eaton]

On 29-Jun-2011, c. wrote:

| Can you explain this a bit better? 
| By saying the slowness is due to copy-on-write semantics, 
| do you mean that using the indexing operator is making a copy of
| a each time I access it?

No, it is checking to see if it needs to make a copy.  If it does,
then it copies the contents of the array.  The copy will only happen
once, but the check will happen every time through the loop.

In your case, no copy is needed, because you just created the array.

A copy would be needed if there were multiple "handles" for the same
data.  For example

  NDArray x (...);   // Create an array; initial reference count for
                     // underlying data is 1.

  NDArray y = x;     // No data is actually copied here, just a
                     // pointer; the reference count for the
                     // underlying data is also incremented.

  x(...) = val;      // Here, the reference count is checked, and
                     // since it is greater than 1, a copy is made,
                     // reference counts are adjusted, then the
                     // assignment is performed.  This way, x changes
                     // but y does not (copy on write).

Does that help?

| Sorry if the question sounds stupid, I do things this way sometimes in order 
to have
| bounds checking, but if I am doing it wrong I have quite a bit of code to fix 
;)

Even if you use the indexing operators, you don't get bounds checking
unless you enable it with

  #define BOUNDS_CHECKING

before including Array.h.  Because bounds checking slows things down
considerably, this macro is not defined by default unless Octave is
configured with --enable-bounds-checking.

jwe