From ripley@stats.ox.ac.uk  Tue Mar 27 18:27:21 2001
From: ripley@stats.ox.ac.uk (Prof Brian D Ripley)
Date: Tue, 27 Mar 2001 18:27:21 +0100 (BST)
Subject: [Rd] DUP=FALSE
In-Reply-To: <3AC0C803.F296CECE@bank-banque-canada.ca>
Message-ID: <Pine.GSO.4.31.0103271824250.10215-100000@auk.stats>

On Tue, 27 Mar 2001, Paul Gilbert wrote:

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

You can write a C wrapper and .Call that, of course.

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

It's not a Solaris issue, but 2.8.1 is rather old: I use 2.95.2 on Solaris.
There may be order-of-evaluation issue though.  Does the difference persist
with optimization turned off?

Brian

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

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


[Rd] DUP=FALSE
Prof Brian D Ripley