Re: simple matrix problem/call by value

[Geraint Paul Bevan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden wrote:

|
| Not to knit-pick, but an in-place assignment is faster than
| re-allocating memory via the [...] operator:
|


Quite right, although I would be somewhat hesitant about quantifying the
improvement from a single data point.

This "A=[A,...]" expression looks like another place in which Paul's
A=f(A) idiom for optimization could usefully be applied.


Back on the question of references, there is clearly some reluctance to
introduce pointers (by whatever name) to Octave.


It does seem that there are three different concepts bound up in this:

1) Optimization by re-use of memory (the original motivation)

2) Additional labels/synonyms for data, within the interpreter, such as
my desire to reference substructures (a.k.a. syntactic sugar).

3) The ability to pass pointers to data between .oct files and  the
interpreter, without copying the actual data (real pointers).


As Paul has stated, the first item can be implemented without
introducing pointers at all and it seems that everyone who has commented
so far is (unsurprisingly) in favour of this optimization.


I think that it should also be possible to introduce the second item
without introducing the problems that are generally associated with
using pointers; there are two real problems that I am aware of:

Firstly, the syntax. The concept of pointers is straightforward but the
C/C++ syntax is seriously ugly and is, IMHO, the biggest source of
confusion for beginners.

The second, and more serious, problem is that the user must take
responsibility for ensuring that memory is freed correctly when it is no
longer required.

Within the Octave interpreter, there is no need for, nor indeed any
mechanism for, the user to explicitly allocate or deallocate memory.
This would not need to change. If P is assigned to be a reference to A,
by whatever syntax, P has no meaning independent of A. It is therefore
not necessary to ever dereference P, or take the address of A, so the
operators * and & do not have to be given any additional meanings. The
syntax is straightforward and there are no memory implications. If P is
assigned to [], A is also assigned to []. If P is cleared, its entry is
removed from the symbol table. If A is cleared, both A and P are removed
from the symbol table. No memory leaks, no confusing syntax. Nor would
any existing functions be affected.


The third item, passing pointers between .oct files and the interpreter
is perhaps the one with the most scope for introducing problems and the
most controversial. Perhaps the most minimal useful implementation of
this would be a new class oct_ptr, say, similar to std::auto_ptr which
could be passed between .oct files and the interpreter (wrapped within
an octave_value_list as usual). Such a pointer could be passed between
.oct files via the interpreter without the interpreter ever needing to
know what it was seeing. The creation of two additional Octave
functions, P=create_pointer(X)  and X=dereference_pointer(P), could
provide an interface for the interpreter to allow the user to tell
Octave when to act on these pointers without introducing any ugly syntax
or having any undesirable effects on existing functions.

- --
Geraint Bevan
http://homepage.ntlworld.com/geraint.bevan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj+pdLMACgkQcXV3N50QmNOAEQCfXMP5JOx6xNUbJo1HXuuQpx+L
EYcAn1TVqU4qEj7vfEnoW7UkfU1+4Ydt
=Z4/r
-----END PGP SIGNATURE-----



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------