R-alpha: Re: R

Paul Gilbert (pgilbert@bank-banque-canada.ca)
Thu, 28 Mar 1996 14:10:00 -0500

Date: Thu, 28 Mar 1996 14:10:00 -0500
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
To: R-testers@stat.math.ethz.ch
Subject: R-alpha: Re: R
Message-Id: <96Mar28.140437est.29445@mailgate.bank-banque-canada.ca>

Thanks to Martin for pointing out that I didn't do something crazy to
make R -n200000 -v20 not work under Solaris.

In response to my previous problem with UseMethod
>You have to be
>a little more precise in your generic function definition -- arguments
>have to be passed explicitly.  E.g.
>	zot <- function(...) UseMethod("zot", ...)

I'm not sure if you meant this exactly, but if so, it doesn't work
> zot <- function(...) UseMethod("zot", ...)
> zot.zzz <- function(x) x*2
> z <- 2
> class(z) <- "zzz"
> zot(z)
Error: ... used in an incorrect context
(but it does work in Splus)

> zot <- function(x, ...) UseMethod("zot", x, ...)
> zot(z)
[1] 4
works, as it does in Splus (except that in Splus the default print
method seems to print the attr's too).

I don;t use NextMethod a lot and should be able to work around that.
Thanks for the warning.

sys.call() does not seem to be implemented. The only place I use this
is in a function %$% which enforces exact $ argument matching, which is
already the rule in R, so I tried  %$% <- get("$"), but this does not
work for some reason, as illustrated next, so I've recoded %$% to $

> dim(output.data(example.BOC.93.4.data.all.raw))
> dim(example.BOC.93.4.data.all.raw$output)
[1] 364   3
> class(example.BOC.93.4.data.all.raw)
[1] "TSdata"
> output.data
function (x) 
UseMethod("output.data", x)
> output.data.TSdata
function (x) 
x %$% output
> get("%$%")
<primitive: $>
> output.data.TSdata <- function(x) x$output
> dim(output.data(example.BOC.93.4.data.all.raw))
[1] 364   3

Is there a good way to distinguish when I'm in R or in S? There seem to
be a few things I would like to do slightly differently in the files I
source. eg
if (inR) %$% <- get("$")

It would be nice to have a  summary.default() which , for a list gives
the elements, their mode, and length. I use  summary.default a lot for
debugging ( because I have summary methods which give user information,
not debugging information, for my objects).

It would also be nice to have something like traceback() to see where
things break when there is a problem.

I put a bunch of files into dseR.tar and tried to ftp it to
stat.auckland.ac.nz in pub/incoming but the server kept dropping the
connection so I've put it on ftp.bank-banque-canada.ca in

The tar file includes a fortran file dsefor.f which will have to be
linked (or dynamically loaded?) into R.

The files are slightly modified from my S version (Most notably, $F is
changed to $FF, and %$% is changed to $).

I put the files in $RHOME/scr/dse.test and ran R in $RHOME so to load
the files:

> source("src/dse.test/dse1a.s")
> source("src/dse.test/dse1b.s")
> source("src/dse.test/dse1c.s")
> source("src/dse.test/dse1d.s")
> DSE.HOME <- "src/dse.test"
> source("src/dse.test/eg1.s")
> source("src/dse.test/eg2.s")

When you get this far you should be able to run the first test program.
> dse1.function.tests()
dse1 test 0 ... Error in ts.eps/4 : Non-numeric argument to binary operator

When this works it may indicate that some tests have failed and give an
error magnitude. The default comparison tolerance is too tight, so
don't worry as long as the magnitude is small. I haven't yet fixed a
couple of calls too NextMethod in these files, but I don't think the
tests will use them.

If you get this far and you're still having fun, then source dse2.s and
run dse2.function.tests(), then source dse3a.s and dse3b.s and run
dse3.function.tests(), then dse4.s and run dse4.function.tests(), then
source guidetst.s and run guide.example.tests.part1() and
guide.example.tests.part2(). Typically I source everything first and
then run the tests, so I can't 100% guarantee that it will work
piecemeal like this, but it is suppose to. If not, try sourcing
everything first, then running the tests.

r-testers mailing list -- To (un)subscribe, send
subscribe	or	unsubscribe
(in the "body", not the subject !)  To: r-testers-request@stat.math.ethz.ch