From huber at ebi.ac.uk  Thu Mar 10 23:36:37 2005
From: huber at ebi.ac.uk (Wolfgang Huber)
Date: Thu Mar 10 23:37:10 2005
Subject: [Rd] R_alloc with more than 2GB (PR#7721)
In-Reply-To: <Pine.LNX.4.61.0503102137330.5792@gannet.stats>
References: <20050310210708.309A0C00D@slim.kubism.ku.dk>
	<Pine.LNX.4.61.0503102137330.5792@gannet.stats>
Message-ID: <4230CBF5.2030903@ebi.ac.uk>

Dear Prof Ripley,

> It is a feature.  Other parts of R expect a CHARSXP to have length less 
> than or equal to 2^31 - 1.

OK, after looking closer at the code and comments in memory.c and 
Rinternals.h (typedef int R_len_t;) I realized that.

> 
> Could you not use x = allocVector(REALSXP, vs) and REAL(x)[i]?  That 
> will get you up to 2^31 - 1 elements, which is the R limit AFAIK.

Thanks, that is an excellent idea. It should be fine for my immediate 
needs, and better what I've just been doing with Calloc!

 > Because of the use of Fortran, it is hard to see how to allow internal
 > lengths (in elements, not necessarily bytes) to exceed that value.  We
 > need to return to that, but it is not straightforward and last time we
 > discussed it we agreed to defer it.

 > We can manage a better error message, but I am afraid nothing else in
 > the near future.

In the application that triggered this posting, the memory is for a C 
array of doubles within a user-defined C function, not for anything that 
needs to become an R object, so maybe a suggestion would be to make 
R_alloc go directly to malloc without the detour over allocString or 
allocVector; or something along that line?

  Best regards
   Wolfgang

-------------------------------------
Wolfgang Huber
European Bioinformatics Institute
European Molecular Biology Laboratory
Cambridge CB10 1SD
England
Phone: +44 1223 494642
Fax:   +44 1223 494486
Http:  www.ebi.ac.uk/huber


[Rd] R_alloc with more than 2GB (PR#7721)
Wolfgang Huber