Skip to content
Prev 4125 / 63424 Next

binary file access [was "RFC: System and time support"...]

On Tue, 25 Jul 2000, Martin Maechler wrote:

            
I don't think that translating/re-writing it is a problem, but I thought
Duncan was planning to do this.  If not I will have a go.
[Doesn't look like it to me!]
Probably, but I find byte-wise reading not at all useful (and none of
our image-analysis files are that shallow).
Introducing a new type in R looks to me like a fairly major undertaking.
Duncan's package does a different task at a higher level than `raw' (which
is just an unstructured stream of bytes). As ?readint says

  Signed integers of sizes 1, 2, 4, and 8 bytes can be read.  Unsigned
  integers of any size up to 8 bytes can be read. (Integers larger than are
  supported in R will be returned in a vector of doubles.)  Floats of sizes
  4, 8, and 10 bytes can be read.  Complex values using any of the float
  sizes for the real and complex parts can be read.  Any size of character
  string that you can create can be read.

although some of that is Windows-specific (10 bytes = 80 bits = extended
format, I presume).

I suspect the best way forward is a get a general (non-Delphi, both Unix
and Windows) contributed package working and on CRAN, and then think about
merging it into base if it looks worthwhile.  (There is a lot of very
useful stuff not in base, and the point of my original posting was that
those are things which need to be internal and OS-specific.)

BTW, I think something like inttostr (but not that name) and its converse
would be useful in base.  
\description{
  Converts an integer to a string representation in base 2 to 36.
}
My memory says S had a function called something like oddometer, but
I can't find it.

Another comment: The R code uses _, F and T and is seriously lacking in
spaces. One way to get standard formating is to set
options(keep.source=FALSE) and then read in and dump the code.


How much support is there for adding a `raw' (byte-stream) type?

Brian