DUP=FALSE

Thomas

Thanks for verifying that this actually does work the way you thought it
did. In the example I asked about  (qr.qty ) I am fairly sure that it
does not modify the y argument. Unfortunately this seems relatively
difficult to trace for certain, and experimenting works but may not hit
all cases.

Another thing I find I do not understand is how many copies of an
argument are made. For example, in a call to a function like

f <- function(x){ .C("goodidea", y=double(1),  x, DUP=TRUE)[[y]] }

there is the original x and the duplicated x in the argument to .C, but
is there a third in the list returned by .C, or is that somehow the same
one as in the argument to .C.  My problem is that my x is very big.

Another thing I find I do not understand is how many copies of an
argument are made. For example, in a call to a function like

f <- function(x){ .C("goodidea", y=double(1),  x, DUP=TRUE)[[y]] }

there is the original x and the duplicated x in the argument to .C,

is there a third in the list returned by .C, or is that somehow the

one as in the argument to .C.  My problem is that my x is very big.

There's a third one. In dotcode.c the following happens

a) x is copied to a C array at the top of the R heap
b) the C function is called
c) the C array is copied into a newly created R object
d) this new R object is returned.

I don't know why you are getting slightly different results with
DUP=FALSE. I can't think of any good explanation.

Thomas

Another thing I find I do not understand is how many copies of an
argument are made. For example, in a call to a function like

f <- function(x){ .C("goodidea", y=double(1),  x, DUP=TRUE)[[y]] }

there is the original x and the duplicated x in the argument to .C,

but

is there a third in the list returned by .C, or is that somehow the

same

one as in the argument to .C.  My problem is that my x is very big.

There's a third one. In dotcode.c the following happens

a) x is copied to a C array at the top of the R heap
b) the C function is called
c) the C array is copied into a newly created R object
d) this new R object is returned.

It seems like there is an unnecessary extra copy here, unless of course
the array in the R object cannot be the C array (but your example of
messing up things in the parent environment suggests it can be). If

DUP=TRUE then there should be no harm in the result being just a pointer
to the copy which is the argument, and if DUP=FALSE then the result is
already in the copy as illustrated in the example circulated by Martin
Schlather on Martin Maechler suggestion a few days ago, so again there
is no harm. I won't pretend to understand the internals of R but I know
I am getting clobbered by a big array in an argument.

I don't know why you are getting slightly different results with
DUP=FALSE. I can't think of any good explanation.

I'll try to track this down sometime. If you think of anything please
let me know.

It seems like there is an unnecessary extra copy here, unless of course
the array in the R object cannot be the C array (but your example of
messing up things in the parent environment suggests it can be). If

Well, in current R internals there is no simple way to create an R array
out of data held in a C array.  (It can be done, but is messy AFAIK.)
Also, with DUP=TRUE, you need protection.  The C routine might have cached
that address and use it next time it was called, thereby working with part
of the `newly created R object'.

Why are you using .C not .Call anyway?  These things are much easier to
control with .Call.

I don't know why you are getting slightly different results with
DUP=FALSE. I can't think of any good explanation.

I'll try to track this down sometime. If you think of anything please
let me know.

Linux? If so I think this is probably due to forced stores or not.  gcc on
Linux is getting notorious with me for not doing IEEE-compatible
arithmetic, and so getting inconsistent results. Compiling with
-fforce-store seems to solve this (at some performance expense).

It seems like there is an unnecessary extra copy here, unless of course
the array in the R object cannot be the C array (but your example of
messing up things in the parent environment suggests it can be). If

Well, in current R internals there is no simple way to create an R array
out of data held in a C array.  (It can be done, but is messy AFAIK.)
Also, with DUP=TRUE, you need protection.  The C routine might have cached
that address and use it next time it was called, thereby working with part
of the `newly created R object'.

ok, I think I'll avoid this for now. On the wish list:  it would be nice to have a
call which distinguished items to return and only built an R object of those rather
than the complete list of arguments in the call  (for me with .Fortran especially).

Why are you using .C not .Call anyway?  These things are much easier to
control with .Call.

Actually, I am using .Fortran, I just happened to grab Thomas example. I understand
the documentation to mean that .Call and .External are only alternatives to .C and
not to .Fortran. If I'm wrong on that please let me know.

I don't know why you are getting slightly different results with
DUP=FALSE. I can't think of any good explanation.

I'll try to track this down sometime. If you think of anything please
let me know.

Linux? If so I think this is probably due to forced stores or not.  gcc on
Linux is getting notorious with me for not doing IEEE-compatible
arithmetic, and so getting inconsistent results. Compiling with
-fforce-store seems to solve this (at some performance expense).

Solaris.  fforce-store does not seem to be an option in my version of gcc (2.8.1) but
my man pages may be older.