Skip to content

.C

3 messages · Steve Oncley, Brian Ripley, Thomas Lumley

#
Happy 1999!

I've been celebrating the holidays by (finally) getting to the port of our 
S+ NetCDF routines to R, which I'm trying to make into a library.  At the 
moment, there are two issues I'd appreciate advice on:

1. Is support for mode "single" data planned anytime soon in R?  A lot of
our NetCDF files contain "single" data and having to coerce into "double"
will increase the use of R memory drastically (and slow things down).

2. Is there support for "pointer to pointer" arguments to .C?  NetCDF files
contain the data attributes, which aren't known until the files are read.
Our S+ code defines a dummy variable for the data dimensions, which are 
redefined (calling "S_alloc") and set within the C code once they are known.
The appended example works in S+ using the pointers= argument in .C.  
Is there a way to do this in R?

Thanks...Steve Oncley
oncley@ucar.edu

C-code:

void inquire_varid(
  int *ncid_p,          /* NetCDF file id. File is left open  */
  int *var_id_p,        /* variable id */
  long **varlen,        /* Length of variable, along each dimension */
  long *ndims_r,        /* number of dimensions in variable */
			/* This argument is created automatically by S+'s
			   .C for pointers=T variables */
  char **vartype)       /* character string describing S object type */
{
...
  *varlen = dimval = (long *)S_alloc(ndims,sizeof(long));
...
}

S+ call:
	...
      vardims <- integer(0)             # Length of each dimension
      vartype <- ""                     # "integer","single","double" etc
      # get info about variable
      cdf <- .C("inquire_varid",
        cdfid = cdfid,
        varid = varid,
        vardims = vardims,
        vartype = vartype,pointers=c(F,F,T,F))
	...

P.S. I'm using R 0.64 under Redhat Linux 5.2.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
#
On Fri, 1 Jan 1999, Steve Oncley wrote:

            
As people kept telling me, a `package' in R.
Not `soon' from the responses to my requests.  I think you exaggerate
though: this can at most double the memory usage, and depending on the
machine and if you actually compute with the data (rather than move it
around) may have negliglible speed penalty. Remember too that anything done
with the data inside S-PLUS 3.x (and R, AFAIK) will make several
double-precision copies.
Actually, there is no longer a way to do this in S-PLUS: the pointers=
argument is not available in S-PLUS 5.x.  I think you need to re-think your
strategy: an alternative can be seen in the rpart code.
1 day later
#
On Fri, 1 Jan 1999, Steve Oncley wrote:

            
I don't think there's any immediate plan for genuine single precision
support.  I have written some code based on an idea of Peter Dalgaard's
to simplify porting of code that uses single precision. It uses a vector
of integers of class "single" to hold the data and defines various group
methods based on coercing back to double precision at the slightest
provocation. It's very preliminary at the moment, but you can get it at 
http://www.biostat.washington.edu/~thomas/single.tgz

This obviously wouldn't solve the time or memory problems, but only a few
people have time/memory problems that would be solved by single precision
support and it appears that none of them has the substantial amount of
spare time needed to implement it.


Thomas Lumley
Assistant Professor, Biostatistics
University of Washington, Seattle

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