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

Prof Brian D Ripley ripley@stats.ox.ac.uk
Tue, 25 Jul 2000 13:48:15 +0100 (BST)

On Tue, 25 Jul 2000, Duncan Murdoch wrote:

> On Tue, 25 Jul 2000 10:33:17 +0100 (BST), you wrote:
> >>     Duncan> I think it would be really useful, and have put together a
> >>     Duncan> prototype (still for Windows only) that's on my web site at
> >> 	                        ==============
> >>     Duncan> <http://www.stats.uwo.ca/faculty/murdoch/software/Rstreams.zip>
> >> 
> >> I first thought "great! .." when you announced this a while ago, but
> >> "Windows only" & relying on Delphi, i.e. proprietary software,
> >> stopped me to even have a look, sorry.
> >> We are committed primarily to the POSIX "clarification" of ANSI C and freely
> >> available tools.
> >
> >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.
> I am, but it won't be quick.  I now have a C compiler installed, but I
> have very little experience writing in C.  I'll probably ask for help
> later in cleaning up whatever I write.  

I will take a quick look. It might be faster to do it that try to help you.
Delphi is an extended Pascal, and I used to be fluent in Pascal.

> >although some of that is Windows-specific (10 bytes = 80 bits = extended
> >format, I presume).
> Yes, but that's Intel-specific, not Windows-specific.  I think it
> would be useful to have on any platform: the idea is that this code
> will allow you to read binary files produced by someone else. For
> example, I do include code to handle byte-order switching, and use it
> in the demo routine (readsfile) to be able to read binary S objects,
> whether produced on big or little endian machines.

Correctt: I just don't know how to get them in a binary file on
any other Intel-based OS (which may be my ignorance).

> If the data you're reading were produced on an Intel platform, they
> might include the extended types. Are there conversion routines
> available in the libraries that R already uses for machines that don't
> support extended as a native type?

Yes, there are. Both in src/main/arithmetic.c and I think in packages 
stataread and foreign.

> >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.)
> Sounds good to me.
> >
> >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.
> I don't object to a name change, but I think "odometer" is a pretty
> bad choice.

It's not the function I wanted, anyway, and not being a word in UK usage I
was unfamiliar with its meaning.  (The UK says `trip counter'.)  What we
really want is a radix argument to as.character applied to integers, I

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