[Rd] DUP=FALSE

[Paul Gilbert]

>> 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.

Thanks,
Paul Gilbert

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._