Tue, 27 Mar 2001 12:04:04 -0500
>> 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.
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: email@example.com