From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 09:34:04 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 10:34:04 +0100
Subject: R-alpha: Re^2: data file names
In-Reply-To: <199712020706.IAA10187@pc25.none> (message from Kurt Hornik on
 Tue, 2 Dec 1997 08:06:13 +0100)
Message-ID: <199712020934.KAA01688@sophie.ethz.ch>

	[R-devel'ers:  spill over from R-core .. -- MM]

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >> In preparing the next Windows release I want to make opening up
    >> system data files (and their documentation) more transparent. I
    >> would really like to adopt the convention that data files use the
    >> suffix .rdf (.dat seems like it's taken). This will make it easier
    >> to get the builtin Windows file browsers to work on it and save me
    >> some considerable work trying to figure out what is and isn't a data
    >> file.

    KH> What does `rdf' stand for?

R Data File ?

But why can't it just be `.R'  (-> `.r' in the ...OS)?

At least currently, these are simply files with valid  R code.
If they would end in `.R', ESS (Emacs Speaks Statistics) would
automatically be put in the proper mode.
Of course, we could also use a new ending,
but I think this would only make sense if the data files would internally
use a different format,
e.g.,  data.dump / data.restore, or one which works with  read.table.

We have discussed earlier that it would be nice to allow different formats
for data files, and maybe the file extension would tell the  data(.)
function in which way it has to read the data
(Of course, UNIX `file' would be much nicer than file extensions,
 but portability ...)

 


    >> It would also be nice if one of you great documentation folks
    >> thought of a html-like format for the .doc files so that I could
    >> simply pop them up. This would also ideally let index.doc be built
    >> on the fly....
yes

    >> I find it quite frustrating that I can't peek at the doc file while
    >> trying to decide which data file I want.
Hmm; in 0.60 we at least have
	data()
for the list
and
	?foodata
for the doc in foodata.doc.  This does already help me quite a bit..


    >> I'm hoping to get a browser
    >> that will let you peruse the documentation while selecting the file.

    >> Comments/opinions appreciated.

    KH> You are obviously right.  I think what we want is to have a unified
    KH> documentation format for both functions (which is what we have
    KH> until now been focussing on) and variables (``data files'').  In
    KH> the not too long run, will we be able to attach data directories so
    KH> that we can really treat the data files as variable objects?
Do you mean binary data files?  Or would they be `compiled' 
	from src/library/<pkg>/data/
	to   library/<pkg>/data/  ?


    KH> Anyway, I just realized that all .doc files now have the structure

    KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES

    KH> so it seems that we only need to add \format{} and \source{} to the
    KH> Rd standard.
yes; this would be one thing; the other being a script (or a person ..)
for translating all current the foodata.doc to foodata.Rd ...
But __YES__ , the earlier, the better  (but ``post release'');
I'd like to have this BEFORE the following is completely solved ..

    KH> And, well, to document the format we really need
    KH> tables.  FL, MM, what is the right way to do these?

As with \itemize , \enumerate and \describe
	(do they work now in HTML,  Fritz? -- would be nice for release ...).
HTML and LaTeX are `obvious'
(we  shouldn't be too fancy, I think, just use a common denominator of
	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
        Fritz will have to look at (a newer version of) latex2html once more)
and the real problem is  nroff.
 (yes, I do want to have simple fast online help using C-c C-v in ESS ...)



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

From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 11:26:32 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 12:26:32 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: <x2oh30m4h2.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 02 Dec 1997 11:20:09 +0100)
Message-ID: <199712021126.MAA01905@sophie.ethz.ch>

	[R-devel instead of  R-help]

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> 
    >> >>>>> Albrecht Gebhardt <agebhard@zidsrv.sci.uni-klu.ac.at> writes:
    >> 
    Albrecht> would it be possible to change the hist() function in future
    Albrecht> R Versions to accept a "plot=F" parameter (like hist() in S
    Albrecht> it should return a list with "breaks" and "counts" in this
    Albrecht> case). This change should be very simple.
    >> 
    >> it _was_ simple, and has been in the current sources for a while now.
    >> You'll see it in version 0.60 which should be released `real soon now'.
    >> 
    >> > hist(rnorm(50), plot=F)
    >> $breaks
    >> [1] -3 -2 -1  0  1  2  3
    >> 
    >> $counts
    >> [1]  1 11 12 20  5  1

    PD> Martin: Wouldn't it be better to return

    PD> invisible(list(breaks = breaks, counts = counts))

    PD> in the plot=T case? (currently it's  invisible(NULL) )

Yes, it would be better;
I even remember having thought about it....
ahh, the reason I did not implement it, is that S-plus is different:
It returns something else for  plot=TRUE:

S> x_ rnorm(50)
S> hi_ hist(x)
S> h2_ hist(x,plot=F)
S> hi
[1] -2.5 -1.5 -0.5  0.5  1.5  2.5
S> h2
$breaks:
[1] -3 -2 -1  0  1  2  3

$counts:
[1]  1  6 14 22  6  1

---
Do we want  S-compatibility here?
(At that time, I hated the idea that the return value is so different, just
 depending on the  plot=.. value).

At the moment, I have (only here, not yet commited)

In the case of  plot=FALSE, one wants (almost) always to
work with the result (and not just see it),i.e. one can have invisible
in both cases.
Therefore, I'd propose the following ``end of hist''
 ((Shall I commit this change later today, about GMT 15.00 ?)


	......

	if(plot) {
		plot.new()
		plot.window(xlim, ylim, "")
		title(main = main, xlab = xlab, ylab = ylab, ...)
		if(axes) {
			axis(1, ...)
			axis(2, ...)
		}
		rect(breaks[-nB], 0, breaks[-1], counts,
		     col = col, border = border)
	}
	invisible(list(breaks = breaks, counts = counts))
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 12:21:39 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 13:21:39 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: Martin Maechler's message of Tue, 2 Dec 1997 12:26:32 +0100
References: <199712021126.MAA01905@sophie.ethz.ch>
Message-ID: <x2lny4lyuk.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

>     PD> Martin: Wouldn't it be better to return
> 
>     PD> invisible(list(breaks = breaks, counts = counts))
> 
>     PD> in the plot=T case? (currently it's  invisible(NULL) )
> 
> Yes, it would be better;
> I even remember having thought about it....
> ahh, the reason I did not implement it, is that S-plus is different:
> It returns something else for  plot=TRUE:
> 
> S> x_ rnorm(50)
> S> hi_ hist(x)
> S> h2_ hist(x,plot=F)
> S> hi
> [1] -2.5 -1.5 -0.5  0.5  1.5  2.5
> S> h2
> $breaks:
> [1] -3 -2 -1  0  1  2  3
> 
> $counts:
> [1]  1  6 14 22  6  1
> 
> ---
> Do we want  S-compatibility here?
> (At that time, I hated the idea that the return value is so different, just
>  depending on the  plot=.. value).

Hmmm. In S, hist() calls barplot() with

VALUE:
       a non-printing vector which contains the x-coordinates  of
       the  centers  of  the  bars (y-coordinates if the bars are
       horizontal).  The returned value can be used if  you  want
       to add to the plot.

This is actually quite useful for placing labels, etc. However,
presumably you'd want the counts too, so a list containing the union
of the two might be ideal? How about relative frequencies, BTW?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 16:56:15 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 10:56:15 -0600 (CST)
Subject: R-alpha: NextMethod in 0.50-a4
Message-ID: <m0xcvcN-000hhXC@franz.stat.wisc.edu>

I am encountering difficulty with NextMethod in 0.50-a4.  We created a
class of groupedData objects which are data.frames with additional
attributes.  The most important attribute is a formula describing
roles of some of the variables in the experimental design.

The class of such objects ends in "groupedData", "data.frame".  The
print method for the groupedData class simply cat's the formula then
calls NextMethod.  In R this produces a peculiar message about not
being able to find the function print.groupedData which happens to be
the function that is currently being evaluated.  I tried different
forms of the call to NextMethod but to no avail.

The purpose and design of the groupedData class is described in

@InProceedings{	  bate:pinh:1997,
  author	= {Douglas M. Bates and Jos\'{e} C. Pinheiro},
  title		= {Software Design for Longitudinal Data},
  editor	= {Timothy G. Gregoire},
  booktitle	= {Modelling Longitudinal and Spatially Correlated Data:
		  Methods, Applications and Future Directions},
  year		= 1997,
  address	= {New York},
  publisher	= {Springer-Verlag},
  pages		= {37--48}
}

I created an artificial example using the "acid" data so it can be
reproduced by others.  (BTW, the acid.doc file has a misprint.  The
name of the second column is "optden", not "opt".)

 R> data(acid)
 R> acid
   carb optden
 1  0.1  0.086
 2  0.3  0.269
 3  0.5  0.446
 4  0.6  0.538
 5  0.7  0.626
 6  0.9  0.782
 R> class(acid)
 [1] "data.frame"
 R> attr(acid, "formula") <- optden ~ carb
 R> class(acid) <- c("groupedData", "data.frame")
 R> print.groupedData
 function (x, ...) 
 {
	 cat("Grouped Data: ")
	 print(attr(x, "formula"))
	 NextMethod()
 }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod(print, x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod("print", x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 17:49:55 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 18:49:55 +0100
Subject: R-alpha: NextMethod in 0.50-a4
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 10:56:15 -0600 (CST)
References: <m0xcvcN-000hhXC@franz.stat.wisc.edu>
Message-ID: <x27m9nmy7w.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

>  R> acid
>  Grouped Data: optden ~ carb
>  Error: couldn't find function "print.groupedData"

Same thing in my snapshot of 0.60.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 17:55:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 11:55:49 -0600 (CST)
Subject: R-alpha: two-sided to one-sided formula
Message-ID: <m0xcwY1-000hhXC@franz.stat.wisc.edu>

At times we want to convert a two-sided formula to a one-sided
formula.  In S we can do this by dropping the second entry in the
formula.  In R that object no longer has a formula class.
 R> ttt <- score ~ age | Infant
 R> class(ttt)
 [1] "formula"
 R> length(ttt)
 [1] 3
 R> ttt[-2]
 [[1]]
 ~

 [[2]]
 age | Infant

 R> class(ttt[-2])
 NULL
 R> do.call("~", ttt[-(1:2)])
 ~age | Infant

In general it would not be a good idea to propagate the formula class
to subsets but it does make sense in this case.  We can get around it
by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
opinions on whether ttt[-2] should still be a formula?
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 18:21:47 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 19:21:47 +0100
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 11:55:49 -0600 (CST)
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu>
Message-ID: <x267p7mwqs.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> In general it would not be a good idea to propagate the formula class
> to subsets but it does make sense in this case.  We can get around it
> by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> opinions on whether ttt[-2] should still be a formula?

Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
the idea of properties depending on the value of a parameter, so I'm
inclined to say no. BTW,

eval(as.call(ttt[-2]))

also works. And one would *think* that formula(as.call(ttt[-2])) did
too, but typeof(as.call(...))==language and !=call (is this weird or
not?), so formula.default protests.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 18:34:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 02 Dec 1997 12:34:49 -0600
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Peter Dalgaard BSA's message of 02 Dec 1997 19:21:47 +0100
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu> <x267p7mwqs.fsf@blueberry.kubism.ku.dk>
Message-ID: <6rafejiofq.fsf@franz.stat.wisc.edu>

Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

> Douglas Bates <bates@stat.wisc.edu> writes:
> 
> > In general it would not be a good idea to propagate the formula class
> > to subsets but it does make sense in this case.  We can get around it
> > by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> > opinions on whether ttt[-2] should still be a formula?
> 
> Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
> the idea of properties depending on the value of a parameter, so I'm
> inclined to say no. BTW,
> 
> eval(as.call(ttt[-2]))
> 
> also works.

I agree with Peter.  We will change our code.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec  2 19:21:08 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 14:21:08 -0500
Subject: R-alpha: compatability functions
Message-ID: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>

With some input from Martin Maechler and Martyn Plummer I think I now have a
fairly good set of functions for handling R/S and OS differences, however, I
still have two areas where I would appreciate input. These are largely S
problems, not R problems, but I am doing this so I can write code to work on
both.

1/ In Windows I have been trying to identify NT, 95, or 3.1, but Martyn (who
claims to have little experience but has lots more than I do) suggested that
Win16 vs Win32 might be a more important distinction.  Does anyone know about
this? The eventual purpose is to do things like opening a graphics window,
copying a file, deleting a file, getting date info on a file, starting another
process, getting host name info, or sending mail (from an R/S program).  I can
use machine() to define is.Win32 and is.Win16 in R, but does anyone know how to
do this in Splus?

2/ In S it is fairly easy to get information to define functions like
is.Linux(), is.Sun5(), but most of the time I just want to be able to use
is.unix().  I have two approaches, neither of which I like. One is to default to
unix if I don't identify Windows, and the other is to identify all the different
types of unix and then "or" them. Can anyone suggest a better way to define
is.unix() in S.

Paul Gilbert

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

From thomas@biostat.washington.edu  Tue Dec  2 19:31:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Tue, 2 Dec 1997 11:31:39 -0800 (PST)
Subject: R-alpha: compatability functions
In-Reply-To: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>

On Tue, 2 Dec 1997, Paul Gilbert wrote:
> 
> 2/ In S it is fairly easy to get information to define functions like
> is.Linux(), is.Sun5(), but most of the time I just want to be able to use
> is.unix().  I have two approaches, neither of which I like. One is to default to
> unix if I don't identify Windows, and the other is to identify all the different
> types of unix and then "or" them. Can anyone suggest a better way to define
> is.unix() in S.
> 

Doesn't  
	exists("unix") 
work?
	-thomas

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

From pgilbert@bank-banque-canada.ca  Tue Dec  2 20:02:06 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 15:02:06 -0500
Subject: R-alpha: compatability functions
References: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>
Message-ID: <97Dec2.150325est.26691@mailgate.bank-banque-canada.ca>

>Doesn't
>        exists("unix")
>work?

Yes. (At least it is true in unix, I can't verify that it is false otherwise.)
Thanks,
Paul

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

From rgentlem@stat.auckland.ac.nz  Tue Dec  2 21:00:30 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Wed, 3 Dec 1997 10:00:30 +1300 (NZDT)
Subject: R-alpha: Re^2: data file names
Message-ID: <199712022100.KAA25304@stat1.stat.auckland.ac.nz>


> 	[R-devel'ers:  spill over from R-core .. -- MM]
> 
> >>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
> 
> >>>>> Robert Gentleman writes:
>     >> In preparing the next Windows release I want to make opening up
>     >> system data files (and their documentation) more transparent. I
>     >> would really like to adopt the convention that data files use the
>     >> suffix .rdf (.dat seems like it's taken). This will make it easier
>     >> to get the builtin Windows file browsers to work on it and save me
>     >> some considerable work trying to figure out what is and isn't a data
>     >> file.
> 
>     KH> What does `rdf' stand for?
> 
> R Data File ?
> 
> But why can't it just be `.R'  (-> `.r' in the ...OS)?
> 
> At least currently, these are simply files with valid  R code.
> If they would end in `.R', ESS (Emacs Speaks Statistics) would
> automatically be put in the proper mode.
> Of course, we could also use a new ending,
> but I think this would only make sense if the data files would internally
> use a different format,
> e.g.,  data.dump / data.restore, or one which works with  read.table.

I agree with Martin. I would be happy with .R initially and later we could
add other suffixes if we have different data formats. I was just going to
slurp them in through source.
>  
> 
> 
>     >> It would also be nice if one of you great documentation folks
>     >> thought of a html-like format for the .doc files so that I could
>     >> simply pop them up. This would also ideally let index.doc be built
>     >> on the fly....
> yes
> 
>     >> I find it quite frustrating that I can't peek at the doc file while
>     >> trying to decide which data file I want.
> Hmm; in 0.60 we at least have
> 	data()
> for the list
> and
> 	?foodata
> for the doc in foodata.doc.  This does already help me quite a bit..
> 
> 
>     >> I'm hoping to get a browser
>     >> that will let you peruse the documentation while selecting the file.
> 
>     >> Comments/opinions appreciated.
> 
>     KH> You are obviously right.  I think what we want is to have a unified
>     KH> documentation format for both functions (which is what we have
>     KH> until now been focussing on) and variables (``data files'').  In
>     KH> the not too long run, will we be able to attach data directories so
>     KH> that we can really treat the data files as variable objects?
> Do you mean binary data files?  Or would they be `compiled' 
> 	from src/library/<pkg>/data/
> 	to   library/<pkg>/data/  ?
> 
> 
>     KH> Anyway, I just realized that all .doc files now have the structure
> 
>     KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES
> 
>     KH> so it seems that we only need to add \format{} and \source{} to the
>     KH> Rd standard.
> yes; this would be one thing; the other being a script (or a person ..)
> for translating all current the foodata.doc to foodata.Rd ...
> But __YES__ , the earlier, the better  (but ``post release'');
> I'd like to have this BEFORE the following is completely solved ..


I agree post 0.60 release (but somethings will have to slip in to the Windows
release of 0.60. I can't believe how hard it is to keep the two in sync. It 
would be handy if we could put the .R's on the data files before the release.
I could live with messy documentation but I really don't want to drop down
into the nuts and bolts of some of the windows dialog code.

>     KH> And, well, to document the format we really need
>     KH> tables.  FL, MM, what is the right way to do these?
> 
> As with \itemize , \enumerate and \describe
> 	(do they work now in HTML,  Fritz? -- would be nice for release ...).
> HTML and LaTeX are `obvious'
> (we  shouldn't be too fancy, I think, just use a common denominator of
> 	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
>         Fritz will have to look at (a newer version of) latex2html once more)
> and the real problem is  nroff.
>  (yes, I do want to have simple fast online help using C-c C-v in ESS .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 08:00:11 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 09:00:11 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <199712030723.IAA16264@pc25.none> (message from Kurt Hornik on
 Wed, 3 Dec 1997 08:23:24 +0100)
Message-ID: <199712030800.JAA03331@sophie.ethz.ch>

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >>> In preparing the next Windows
    >>> release I want to make opening up system data files (and their
    >>> documentation) more transparent. I would really like to adopt
    >>> the convention that data files use the suffix .rdf (.dat seems
    >>> like it's taken). This will make it easier to get the builtin
    >>> Windows file browsers to work on it and save me some
    >>> considerable work trying to figure out what is and isn't a data
    >>> file.

    MM> But why can't it just be `.R' (-> `.r' in the ...OS)?
    MM> 
    MM> At least currently, these are simply files with valid R code.  If
    MM> they would end in `.R', ESS (Emacs Speaks Statistics) would
    MM> automatically be put in the proper mode.  Of course, we could also
    MM> use a new ending, but I think this would only make sense if the
    MM> data files would internally use a different format, e.g., data.dump
    MM> / data.restore, or one which works with read.table.

    >> I agree with Martin. I would be happy with .R initially and later we
    >> could add other suffixes if we have different data formats. I was
    >> just going to slurp them in through source.

    KH> Shall we try to be consistent about other endings, too?  E.g.,

Yes, why not agree on this, now, even before implementation!
 
    KH> rdf	for R data file/format (data.dump/data.restore)

data.dump/data.restore  is hopefully going to be  S-plus compatible as much
as possible (that's why most of us would want it).
Hence, I think the `R' is really too much there.

Would just

	dmp	still be `free' (in Windoze I mean) ?


    KH> table	for tables

For portability, we'd probably rather need 3 letter expansions...
i.e.
	tab	for tables (to be readable by read.table ?!)
		Note, we have to agree if read.table will be called
		with  (...., header = TRUE)  or not.

		Here, mostly for teaching purposes, we have (almost) all
		our data files in the format

			nam.1  col.2  var.3 ...  var.<p>
			<x11>   <x12>  <x13> ...  <x1p>
			<x21>   <x22>  <x23> ...  <x2p>
			  ..      ..    ..         ..
			  ..      ..    ..         ..
			  ..      ..    ..         ..

		I.e. we don't have `rownames' most of the time and don't
		want to type '1' '2' ... 'n' in front of the variables.

	

	Maybe we should even have

	tab	for the above		 ->  read.table(<file>, header = T)
	tbr	for tables with rownames ->  read.table(<file>)


			col.1  col.2  var.3 ...  var.<p>
		r1	<x11>   <x12>  <x13> ...  <x1p>
		r2	<x21>   <x22>  <x23> ...  <x2p>
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..

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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 11:30:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 12:30:13 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 09:00:11 +0100
References: <199712030800.JAA03331@sophie.ethz.ch>
Message-ID: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Yes, why not agree on this, now, even before implementation!
>  
>     KH> rdf	for R data file/format (data.dump/data.restore)
> 
> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
> as possible (that's why most of us would want it).
> Hence, I think the `R' is really too much there.

I don't think so. The data.dump format is really just an efficient
encoding of the output of dput/dump. It won't be more compatible than
the data structures themselves. That is, unless someone wants to sit
down and catalog all the differences in internal data structures and
do the relevant transformation code....


-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From colin@geology.gla.ac.uk  Wed Dec  3 12:13:24 1997
From: colin@geology.gla.ac.uk (Colin Farrow)
Date: Wed, 3 Dec 1997 12:13:24 GMT
Subject: R-alpha: Two buglets and a difference
Message-ID: <199712031213.MAA24476@alligin.gla.ac.uk>


I have come across three problems in the past few days, in spell of
heavy R ( version  R0.50-a4/Sun Solaris2.5.1 ) use.

1.
I was using lwd=2 to get thicker lines on plots for printing, but
although the 'lwd' parameter works fine with x11(), the thickened lines
do not print with print.plot, or by using postscript() directly.


2.
Try the following,

	plot(1:10, -(1:10))
	mtext("distance", side=3, line=1)

where does the text disappear to, nothing appears on the plot.
The problem relates to the -y in the plot() call, as it works with
plot(1:10, 1:10). This occurs in a function to plot a variable with
 depth (-y), with depth increasing down the y axis.


3.
Less of a bug, more of a difference between implementations

foo <- function(x) {
	paste(substitute(x) )
}


In S
foo(lamp)
	"lamp"
foo(lamp$v)
	"lamp$v"
In R
foo(lamp)
	"lamp"
foo(lamp$v)
	"$" "lamp" "v"


which broke a number of functions I was porting to R

The fix which works in both is
	paste(deparse(substitute(x)))
which is an awful mouthful to get the name of the argument

Colin

--------------------
                     \
Colin Farrow          \
                       \---------------------------------------
                        \                                       \
Department of Geology,   \ E-mail: colin@geology.gla.ac.uk       \
University of Glasgow,    \                                       \
Glasgow, G12 8QQ. Scotland \ Tel: +44 (0)41 339 8855 x5466         \
                            \ Fax: +44 (0)41 330 4817               \
`````````````````````````````````````````````````````````````````````````
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 12:51:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 13:51:03 +0100
Subject: R-alpha: Two buglets and a difference
In-Reply-To: <199712031213.MAA24476@alligin.gla.ac.uk>
 (colin@geology.gla.ac.uk)
Message-ID: <199712031251.NAA03649@sophie.ethz.ch>

>>>>> "Colin" == Colin Farrow <colin@geology.gla.ac.uk> writes:

    Colin> I have come across three problems in the past few days, in spell
    Colin> of heavy R ( version R0.50-a4/Sun Solaris2.5.1 ) use.

thank you for reporting these.

    Colin> 1.  I was using lwd=2 to get thicker lines on plots for
    Colin> printing, but although the 'lwd' parameter works fine with
    Colin> x11(), the thickened lines do not print with print.plot, or by
    Colin> using postscript() directly.

Unfortunately, this is still true for the current source code version
(0.60). 

    Colin> 2.  Try the following,

    Colin> 	plot(1:10, -(1:10)) mtext("distance", side=3, line=1)

    Colin> where does the text disappear to, nothing appears on the plot.
    Colin> The problem relates to the -y in the plot() call, as it works
    Colin> with plot(1:10, 1:10). This occurs in a function to plot a
    Colin> variable with depth (-y), with depth increasing down the y axis.

this is a known bug which is fixed in the upcoming release

    Colin> 3.  Less of a bug, more of a difference between implementations

    Colin> foo <- function(x) { paste(substitute(x) ) }

    Colin> In S
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "lamp$v"

This is not true for my version of S-plus :

> version
Version 3.4 Release 1 for Sun SPARC, SunOS 5.3 : 1996 
> tst3 <- function(x) paste(substitute(x))
> tst3(lamp)
[1] "lamp"
> tst3(lamp$v)
[1] "$"     "lamp"  "\"v\""

    Colin> In R
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "$" "lamp" "v"

    Colin> which broke a number of functions I was porting to R

    Colin> The fix which works in both is paste(deparse(substitute(x)))
    Colin> which is an awful mouthful to get the name of the argument

You can omit the paste(.)  and use

	deparse(substitute(x))

in both cases  which is  THE  recommended way in both R and S, anyway.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 15:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 16:56:31 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 03 Dec 1997 12:30:13 +0100)
Message-ID: <199712031556.QAA03899@sophie.ethz.ch>

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> Yes, why not agree on this, now, even before implementation!
    >> 
    KH> rdf	for R data file/format (data.dump/data.restore)
    >> 
    >> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
    >> as possible (that's why most of us would want it).
    >> Hence, I think the `R' is really too much there.

    PD> I don't think so. The data.dump format is really just an efficient
    PD> encoding of the output of dput/dump.
right!  Actually I never looked at it this way.

    PD> It won't be more compatible than the data structures themselves.

but this will lead to really portable (between S and R) data.dump output
for many cases we want.

    PD> That is, unless someone wants to sit
    PD> down and catalog all the differences in internal data structures and
    PD> do the relevant transformation code....

not really; 
Actually  however, one case we may want to be `compatible' are
factors, since they are part of data.frames.
Factors are somewhat different in R and S
(internally: clear;  in 'dput(.)' -- maybe not necessary).



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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 20:58:07 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 21:58:07 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 16:56:31 +0100
References: <199712031556.QAA03899@sophie.ethz.ch>
Message-ID: <x2ra7ukuu8.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Factors are somewhat different in R and S
> (internally: clear;  in 'dput(.)' -- maybe not necessary).

Hmm:

R:

> dput(gl(4,1,8))
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))
> ff<-structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1",
"2", "3", "4"), 
+         class = "factor")
> dput(ff)
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))

Splus:

> dput(gl(4,1,8))
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")
> ff<-structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4),
+ class = "factor", .Label = c("1", 
"2", "3", "4"))
> dput(ff)
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")

I.e. when R creates a structure based on the output of Splus's dput(factor),
you get the same structure as if you had created the factor directly,
and vice versa. 

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From rgentlem@stat.auckland.ac.nz  Wed Dec  3 20:59:18 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Thu, 4 Dec 1997 09:59:18 +1300 (NZDT)
Subject: R-alpha: Re^3: data file names
Message-ID: <199712032059.JAA02106@stat1.stat.auckland.ac.nz>

I will make the changes needed for .R extensions to the library files
(and the code change given by Martin for 0.60; Ross will roll it out as
soon as we stop making last minute changes).

Currently I use .rmg as an extension for R images. I wasn't planning on
using anything else (but rdf for binary dumps is probably good). I don't
know if we really want to use extensions for tables. I was simply going to
make this a standard file dialog (under windows) followed by a pop-up
that would let you select the defaults for read.table.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec  4 17:23:23 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 4 Dec 1997 18:23:23 +0100
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
Message-ID: <199712041723.SAA05244@sophie.ethz.ch>

and this breaks  multinom from the nnet library
	[yes, Kurt, I'm working on that and I'll send you patches..]	

Is this a bug or an (half-)intentional difference to S ?

---------------------

In R (0.50-0.60)


     model.matrix(formula =, data =)

 Arguments:

   formula: A model formula or terms object

      data: A data frame created with `model.frame'


In S-plus


  USAGE:
       model.matrix(object, ...)
       model.matrix.default(terms.object, data, contrasts)

  ARGUMENTS:

	.....

  contrasts:     an optional list giving contrasts for some or  all
       of  the  factors  appearing  in  the  terms  object.   The
       elements of the list should have  the  same  name  as  the
       variable   and   should   be   either  a  contrast  matrix
       (specifically, any full-rank matrix with as many  rows  as
       there  are  levels  in  the factor), or else a function to
       compute such a matrix given the  number  of  levels.   The
       complete contrast list (anything given as an argument plus
       any  additional  contrast  matrices  computed)   will   be
       returned as the "contrasts" attribute of the model matrix,
       and hence as the "contrasts" component  of  fitted  models
       returned by lm() and its descendants.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From thomas@biostat.washington.edu  Thu Dec  4 17:41:09 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 4 Dec 1997 09:41:09 -0800 (PST)
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
In-Reply-To: <199712041723.SAA05244@sophie.ethz.ch>
Message-ID: <Pine.LNX.3.96.971204093835.5784A-100000@buffy>

On Thu, 4 Dec 1997, Martin Maechler wrote:

> and this breaks  multinom from the nnet library
> 	[yes, Kurt, I'm working on that and I'll send you patches..]	
> 
> Is this a bug or an (half-)intentional difference to S ?
> 

I think it's a bug -- you should be able to specify contrasts on a
model-by-model basis if you really want to.  Fortunately it's very rare
for people to use this feature.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 14:00:45 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 15:00:45 +0100
Subject: R-alpha: Array indexing out of range -- difference to R-minus
Message-ID: <199712051400.PAA06534@sophie.ethz.ch>


> x <- cbind(1,1:3); x
     [,1] [,2]
[1,]    1    1
[2,]    1    2
[3,]    1    3
> x[5:6] <- 10
> x
     [,1] [,2]
[1,]    1    1
[2,]    1   10
[3,]    1   10
> x[5:7] <- 12 #<<<<< loses its dimension, because of `out of range' indexing
> x
[1]  1  1  1  1 12 12 12

     1  2  3  4  5  6  7

---
with S-plus or S4,
	x remains a 3 x 2  matrix;
	it only `silently' grows  *after* being coerced to vector 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Friedrich.Leisch@ci.tuwien.ac.at  Fri Dec  5 14:08:04 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Fri, 5 Dec 1997 15:08:04 +0100
Subject: R-alpha: is.vector of one-dimensional array
Message-ID: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>


maybe we've already diskussed this before, but Kurt and I can't
remember ...

is.vector() of an one-dimensional array returns FALSE. this is also the
behavior of Splus, but totally counter-intuitive for me ... IMO an
array of dimension 1 is exactly the definition of a vector ...

it also breaks our current plot.factor, which is simply a

	barplot(table(x))

table() returns an one-dimensional array, but barplot only accepts
vector and matrix arguments ...

of course one could check additionally for arrays with correct
dimension ... but ...

any opinions?

fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From pgilbert@bank-banque-canada.ca  Fri Dec  5 14:50:47 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 5 Dec 1997 09:50:47 -0500
Subject: R-alpha: is.vector of one-dimensional array
References: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>
Message-ID: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca>

>is.vector() of an one-dimensional array returns FALSE. this is also the
>behavior of Splus, but totally counter-intuitive for me ... IMO an
>array of dimension 1 is exactly the definition of a vector ...

I assume by "one-dimensional array" you mean a two or higher dimensional array
with all but one of the values from dim(x)  being 1. This is possibly
counter-intuitive, but there are cases where one needs to distinguish these.
Perhaps length(dim(x)) would be better, but dim returns NULL  for a vector. This
is even more counter-intuitive to me. I think it should return length(x) for a
vector. In any case there is lots of code out there that will break if you
change these.

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 17:24:25 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 18:24:25 +0100
Subject: R-alpha: is.vector of one-dimensional array
In-Reply-To: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Fri, 5 Dec 1997 09:50:47 -0500)
Message-ID: <199712051724.SAA06827@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    >> is.vector() of an one-dimensional array returns FALSE. this is also
    >> the behavior of Splus, but totally counter-intuitive for me ... IMO
    >> an array of dimension 1 is exactly the definition of a vector ...
not quite exactly.

I think we have agreed that 
	vector
and
	array
are mutually exclusive [i.e., their is.XXX test], 
and actually, the distinction arising by  is.null(dim(.)).


    PaulG> I assume by "one-dimensional array" you mean a two or higher
    PaulG> dimensional array with all but one of the values from dim(x)
    PaulG> being 1.
No, he meant the `rare' thing which table(.) produces 
	-- both in R and S -- 
which has  length(dim(.)) == 1:

> ta <- table(rpois(20,4))
> dim(ta)
[1] 9
> ta
0 1 2 3 4 5 6 7 8 
1 2 4 3 4 2 2 1 1 
> str(ta)
 int [, 1:9] 1 2 4 3 4 2 2 1 1
 - attr(*, "dimnames")=List of 1
  ..$ : chr [1:9] "0" "1" "2" "3" "4" "5" "6" "7" "8"
> 

    PaulG> This is possibly counter-intuitive, but there are cases
    PaulG> where one needs to distinguish these.  Perhaps length(dim(x))
    PaulG> would be better, but dim returns NULL for a vector. This is even
    PaulG> more counter-intuitive to me. I think it should return length(x)
    PaulG> for a vector. In any case there is lots of code out there that
    PaulG> will break if you change these.

Yes! - and we `must' live with these, I think.

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

From plummer@iarc.fr  Mon Dec  8 08:05:04 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Mon, 08 Dec 1997 09:05:04 +0100 (MET)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <XFMail.971208092400.plummer@iarc.fr>

Thanks to the core team for releasing R-0.60. I found a couple of 
bugs.

1) Segfault!
assign(character(0),1)
Fix: Obviously, check the string length. The same problem may occur
in other places but I haven't done an extensive search.
x <- 1
attr(x, character(0)) 


2) The function GStrHeight (graphics.c) uses the conversion factors
for the X axis instead of the Y axis. This causes strangeness in
legend() when the axes are on different scales.
Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with 
fig2dev.by, win2fig.by and ipr[1], respectively.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From ihaka@stat.auckland.ac.nz  Mon Dec  8 09:44:20 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Mon, 8 Dec 1997 22:44:20 +1300 (NZDT)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <199712080944.WAA13846@stat1.stat.auckland.ac.nz>

> From: Martyn Plummer <plummer@iarc.fr>
> To: r-devel@stat.math.ethz.ch
> Subject: R-alpha: Bugs in R-0.60
>
> Thanks to the core team for releasing R-0.60. I found a couple of
> bugs.
>
> 1) Segfault!
> assign(character(0),1)
> Fix: Obviously, check the string length. The same problem may occur
> in other places but I haven't done an extensive search.
> x <- 1
> attr(x, character(0))

	Fixed these two, but there may well be more ...


> 2) The function GStrHeight (graphics.c) uses the conversion factors
> for the X axis instead of the Y axis. This causes strangeness in
> legend() when the axes are on different scales.
> Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with
> fig2dev.by, win2fig.by and ipr[1], respectively.

	Fixed and committed.  Updates in 0.60.2

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 10:05:10 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 11:05:10 +0100
Subject: R-alpha: Bugs in R-0.60 --
In-Reply-To: <199712080944.WAA13846@stat1.stat.auckland.ac.nz> (message from
 Ross Ihaka on Mon, 8 Dec 1997 22:44:20 +1300 (NZDT))
Message-ID: <199712081005.LAA00745@sophie.ethz.ch>

Dear Ross,

>>>>> "Ross" == Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:

    >> From: Martyn Plummer <plummer@iarc.fr> To: r-devel@stat.math.ethz.ch
    >> Subject: R-alpha: Bugs in R-0.60

    >> 1) Segfault!  assign(character(0),1) Fix: Obviously, check the
    >> string length. The same problem may occur in other places but I
    >> haven't done an extensive search.  x <- 1 attr(x, character(0))

    Ross> 	Fixed these two, but there may well be more ...

things like these  remind me once more  
how very useful it would be to have an option like
	-dont-stop-on-error
for R (batch).

We could have many tests like these in a few  'test' files that would be
run through R...; 
Actually, I'm thinking of auto-generated function calls where most would
give  'Error: ..'  but none should give  segfault...

This could help very much to autodetect problems like these.

- Martin.




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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 11:13:37 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 12:13:37 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
Message-ID: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>



The function tapply is not working in the Windows version of R=20
(Version 0.50 Beta (Sept 29, 1997))

In

tapply <- function (x, INDEX, FUN=3DNULL, simplify=3DTRUE, ...)=20
...

The part:

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		names(ans)<-namelist[[1]]
		return(ans)
	}

should be replaced by

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		if(length(INDEX) =3D=3D 1) {
		names(ans) <- namelist[[1]]
		}
		else {
		dim(ans) <- extent
		dimnames(ans) <- namelist
		}
		return(ans)
	}

Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 11:30:08 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 12:30:08 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be> (message
 from Comblain muriel on Mon, 08 Dec 1997 12:13:37 +0100)
Message-ID: <199712081130.MAA00841@sophie.ethz.ch>

Dear Muriel,

the current Unix version of R, 0.60,
has the following definition of  tapply(.).

Can you check if it works for your examples?
If not, please send us a complete example (i.e. with input data, we can
regenerate).
Thank you for your report!

tapply <- function (x, INDEX, FUN=NULL, simplify=TRUE, ...) 
{
	if (is.character(FUN)) 
		FUN <- get(FUN, mode = "function")
	if (!is.null(FUN) && mode(FUN) != "function") 
		stop(paste("'", FUN, "' is not a function",sep=""))
	if (!is.list(INDEX)) INDEX <- list(INDEX)
	nI <- length(INDEX)
	namelist <- vector("list", nI)
	extent <- integer(nI)
	nx <- length(x)
	group <- rep(1, nx)#- to contain the splitting vector
	ngroup <- 1
	for (i in seq(INDEX)) {
		index <- as.factor(INDEX[[i]])
		if (length(index) != nx) 
			stop("arguments must have same length")
		namelist[[i]] <- levels(index)#- all of them, yes !
		extent[i] <- nlevels(index)
		group <- group + ngroup * (codes(index) - 1)
		ngroup <- ngroup * nlevels(index)
	}
	if (is.null(FUN)) return(group)
	ans <- lapply(split(x, group), FUN, ...)
	if (simplify && all(unlist(lapply(ans, length)) == 1)) {
		ansmat <- array(dim=extent, dimnames=namelist)
		ans <- unlist(ans, recursive = FALSE)
	}
	else  {
		ansmat <- array(vector("list", prod(extent)),
			dim=extent, dimnames=namelist)
	}
	ansmat[as.numeric(names(ans))] <- ans
	ansmat
}

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Mon Dec  8 12:08:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 08 Dec 1997 13:08:13 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: Comblain muriel's message of Mon, 08 Dec 1997 12:13:37 +0100
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <x2ra7oghqq.fsf@blueberry.kubism.ku.dk>

Comblain muriel <Muriel.Comblain@ulg.ac.be> writes:

> The function tapply is not working in the Windows version of R 
> (Version 0.50 Beta (Sept 29, 1997))
> 
..
> The part:
...
> should be replaced by
...

Thanks. One thing though:

Please, and this goes for everyone, remember to state the objective of
your fixes.

I think we know what this fix is about (the tapply(x,f,summary)
problem, right?), but this is not stated in your letter. As Martin
points out, the code has subsequently changed in the development
version and we have difficulty seeing whether it solves your problem
or not.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 15:58:45 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 16:58:45 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <199712081130.MAA00841@sophie.ethz.ch>
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <3.0.1.32.19971208165845.009538c0@pop3.mailst.ulg.ac.be>

At 12:30 08/12/97 +0100, Martin Maechler wrote:
>Dear Muriel,
>
>the current Unix version of R, 0.60,
>has the following definition of  tapply(.).
>
>Can you check if it works for your examples?
>If not, please send us a complete example (i.e. with input data, we can
>regenerate).
>Thank you for your report!
>
>...

I checked this form of the tapply function coming from the current unix
version (0.60) on my examples and it worked perfectly as well as the fix I
proposed. Sorry if my mail was not completely clear, I will try to do
better next time and thank you for your help.

=20
Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From pgilbert@bank-banque-canada.ca  Wed Dec 10 15:40:32 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 10 Dec 1997 10:40:32 -0500
Subject: R-alpha: "[.ts" in 0.60.1
Message-ID: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>

I have a class "tframe" with more specific classes indicating how time is being
represented, such as

> class(tframe(data))
[1] "ts"     "tframe"

but now "[.ts" produces warning messages

> tframe(data)[2]
Warning: Not returning a time series object
[1] 2006.25

Even my simplest tests produce hundreds of lines of warnings, so I've commented
out the line
#                        warning("Not returning a time series object")
in "[.ts". I'm not sure if this is the best solution, but something is
necessary.

Paul Gilbert

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







From alchemy@inconnect.com  Thu Dec 11 07:53:27 1997
From: alchemy@inconnect.com (Anthony Chavez)
Date: Thu, 11 Dec 1997 00:53:27 -0700 (MST)
Subject: R-alpha: Re: R-beta: time series structures
In-Reply-To: <348F139A.8032984A@stat.unipg.it>
Message-ID: <Pine.SOL.3.96.971211005155.12804C-100000@ultra1>

Please edit headers and keep non-announce topic off the R-announce list.  Some
of us are subscribed to R-announce for a *reason*.

--
-------------------------------------------------------------------------------
Anthony Chavez                 o   \o/  _ o          o    o-o  +===+  o   +===+
                              /|\   |    /\    __\o o_|   \ /  |   | /|\  |   |
alchemy@inconnect.com         / \  / \  | \   /) |   \\o  \|   |~~~| Co-"=|~~~|
Salt Lake City, Utah          o-o  o-o  o-o  o-o        \  o\  |___| / \  |___|

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:31:51 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:31:51 +0100
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
Message-ID: <199712110831.JAA00252@pc25.none>

>>>>> Paul Gilbert writes:

> I've been reviewing how the make process for my library should be set
> up and I noticed that the "How Can I Create an R Package?" part of the
> FAQ gives instructions to put a Makefile in pkg/src but the "How Can
> Add-on Packages Be Installed?" part of the FAQ does not seem to give
> any indication that a make may be necessary, unless
>      $ R INSTALL pkg lib
> does a make, which I don't think it does.

> Also, this Makefile has to be passed config information, so it must be
> called some way from the main R Makefile I think, but I don't see
> exactly how this is suppose to work, especially if the library is not
> under R/library. Can someone explain this?

Thomas already answered the above.

> A related question is that I am looking for a general strategy for
> distributing code which may get installed under R or S. To date, I
> have been working with one Makefile, which has different targets for R
> or for S. Obviously, the procedure for installing this is not quite as
> simple as suggested for add on packages in the FAQ. Does anyone have
> suggestions for a good way to organize this?

Under R, you need to organize everything as detailed in the FAQ.  There
is no need for a top-level Makefile, so you could use this for taking
care of the R- (S) part [having hinstall and qinstall or whatever they
are called targets].

However, keep in mind that in the long run, all R SOURCE files will need
to have a `.R' extension (as of 0.60, this is already a must for data).

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:43:55 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:43:55 +0100
Subject: R-alpha: libraries
In-Reply-To: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
References: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
Message-ID: <199712110843.JAA00277@pc25.none>

>>>>> Paul Gilbert writes:

> I have been trying to set up my time series library with the new
> library mechanism. It is a fairly large amount of code and previously
> I split it into five pieces in order to load it into R. (Has anything
> changed which might suggest I shouldn't need to do this anymore?)  The
> five files are called dse1, dse2, dsex1, dsex2, and tframe.With the
> new way of handling libraries I put these in
> /home/res/gilp/dse/pub/Rdse/R and ran

> [58] /home/res/gilp/dse/pub : R INSTALL Rdse dse1
> Installing package `Rdse' ...
> R
> DONE
> No man pages found in package `Rdse'

> (BTW this prepend $pwd to Rdse and does not seem to like a fully
> qualified path for the location, so it has to be done in the directory
> above Rdse)

> Indications seem to be that this worked (except for the man pages), but when I
> set RLIBS and run R the library is not found:
>> library()
> Packages in library `/home/res/gilp/dse/pub/Rdse':

> Packages in library `/home/res8/gilp/R-versions/R-0.60.1/R-0.60.1/library':
> ...

> However, if I call one of the files Rdse and do
> R INSTALL Rdse Rdse

> then things seem to work correctly in that it finds that file. Does
> this mean that the file with the code must have the same name as the
> package name, which must be the same as the directory name?
> (i.e. .../pkg/R/pkg) Does this mean that I have to create separate
> library directories for each of the pieces?

There is a bug in the R 0.60 INSTALL mechanism that will be fixed in the
next release.

What you are talking about is splitting a PACKAGE into separate MODULES
(Core Team, correct me if I am wrong, was this the term we agreed on?).
This would result in an extension of the current INSTALL and library()
scenario that I would very much appreciate.

Re loading, my idea was to have

	library(MODULE, pkg = PACKAGE, lib = LIBRARY)

or something similar which would allow you to load the module from the
package in the library.  Of course, the inferface is open for
discussion.

Re installing, this is not do easy.  One could have a Makefile in the
`R' subdir indicating how to combine the various .R files into modules,
but I am not quite sure how to do this right.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 08:49:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 09:49:03 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Wed, 10 Dec 1997 10:40:32 -0500)
Message-ID: <199712110849.JAA04605@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    PaulG> I have a class "tframe" with more specific classes indicating
    PaulG> how time is being represented, such as

    >> class(tframe(data))
    PaulG> [1] "ts" "tframe"

    PaulG> but now "[.ts" produces warning messages

    >> tframe(data)[2]
    PaulG> Warning: Not returning a time series object [1] 2006.25

    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
    PaulG> I've commented out the line # warning("Not returning a time
    PaulG> series object") in "[.ts". I'm not sure if this is the best
    PaulG> solution, but something is necessary.

I agree that this can be a pain.
On the other hand, I think it can be very helpful to get this warning
when you subscript a time-series and don't get one anymore.

I think we want
 1) No warning if only one element of a time-series is chosen
	(however, even this is debatable:
	 Think of a function containing code
		i <- !is.na(...) && a < b
		result.ts <- my.ts[i]

	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

 2) A warning otherwise -- which can be turned off ---
    I propose to create an option (one of `options()') to handle this.

Another -- maybe even better -- alternative :
We introduce an argument
				drop = TRUE
as for arrays.
Then the warning would only happen in the case  drop = FALSE
when it was really impossible to make an (equispaced) ts out of the
subscripted one.

------------------------------------------------------------

BTW: does anyone care if I completely drop the  "R-alpha:" string
						 --------
     that is automagically prepended to the subject on R-devel
	(unless it's already part of the subject) ?

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 09:05:48 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 10:05:48 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <199712110849.JAA04605@sophie.ethz.ch>
References: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>
 <199712110849.JAA04605@sophie.ethz.ch>
Message-ID: <199712110905.KAA02711@pc25.none>

>>>>> Martin Maechler writes:

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
PaulG> I have a class "tframe" with more specific classes indicating
PaulG> how time is being represented, such as

>>> class(tframe(data))
PaulG> [1] "ts" "tframe"

PaulG> but now "[.ts" produces warning messages

>>> tframe(data)[2]
PaulG> Warning: Not returning a time series object [1] 2006.25

PaulG> Even my simplest tests produce hundreds of lines of warnings, so
PaulG> I've commented out the line # warning("Not returning a time
PaulG> series object") in "[.ts". I'm not sure if this is the best
PaulG> solution, but something is necessary.

> I agree that this can be a pain.
> On the other hand, I think it can be very helpful to get this warning
> when you subscript a time-series and don't get one anymore.

> I think we want
>  1) No warning if only one element of a time-series is chosen
> 	(however, even this is debatable:
> 	 Think of a function containing code
> 		i <- !is.na(...) && a < b
> 		result.ts <- my.ts[i]

> 	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

>  2) A warning otherwise -- which can be turned off ---
>     I propose to create an option (one of `options()') to handle this.

> Another -- maybe even better -- alternative :
> We introduce an argument
> 				drop = TRUE
> as for arrays.
> Then the warning would only happen in the case  drop = FALSE
> when it was really impossible to make an (equispaced) ts out of the
> subscripted one.

This is not MAYBE better, but what we really should do.  It conforms
to the general logic of subscripting as was agreed upon.

> ------------------------------------------------------------

> BTW: does anyone care if I completely drop the  "R-alpha:" string
> 						 --------
>      that is automagically prepended to the subject on R-devel
> 	(unless it's already part of the subject) ?

No, of course not.

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

From plummer@iarc.fr  Thu Dec 11 10:02:05 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Thu, 11 Dec 1997 11:02:05 +0100 (MET)
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
Message-ID: <XFMail.971211111648.plummer@iarc.fr>

On 11-Dec-97 maechler@stat.math.ethz.ch wrote:
>>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
>
>    PaulG> I have a class "tframe" with more specific classes indicating
>    PaulG> how time is being represented, such as
>
>    >> class(tframe(data))
>    PaulG> [1] "ts" "tframe"
>
>    PaulG> but now "[.ts" produces warning messages
>
>    >> tframe(data)[2]
>    PaulG> Warning: Not returning a time series object [1] 2006.25
>
>    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
>    PaulG> I've commented out the line # warning("Not returning a time
>    PaulG> series object") in "[.ts". I'm not sure if this is the best
>    PaulG> solution, but something is necessary.
>
>I agree that this can be a pain.
>On the other hand, I think it can be very helpful to get this warning
>when you subscript a time-series and don't get one anymore.
>
>I think we want
> 1) No warning if only one element of a time-series is chosen
>       (however, even this is debatable:
>        Think of a function containing code
>               i <- !is.na(...) && a < b
>               result.ts <- my.ts[i]
>
>        wouldn't you want to be warned if `result.ts' is not a ts anymore? )
>
> 2) A warning otherwise -- which can be turned off ---
>    I propose to create an option (one of `options()') to handle this.
>
>Another -- maybe even better -- alternative :
>We introduce an argument
>                               drop = TRUE
>as for arrays.
>Then the warning would only happen in the case  drop = FALSE
>when it was really impossible to make an (equispaced) ts out of the
>subscripted one.

Sorry this is my fault. I suggested this code because the previous
version of [.ts<- did not allow you to subscript time series at all
without unclassing them.  The current version at least tries to preserve
time series objects.  I think what we really need is an irregular time
series class like the S-PLUS "its". Then array subscripting can do the
right thing, and do it silently. In the absence of such a class in R,
I put the warning in.  The message could be translated as "fix me", so
I'm glad you brought it up.

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

From steuer@gigamain.Statistik.Uni-Dortmund.DE  Thu Dec 11 10:21:09 1997
From: steuer@gigamain.Statistik.Uni-Dortmund.DE (Detlef Steuer)
Date: Thu, 11 Dec 1997 11:21:09 +0100 (MET)
Subject: R-alpha: fft does not act as described in help(fft)
Message-ID: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>

Hello!

thank you for your efforts creating R!

While preparing the next lessons I found that I had
to multiply with 1/length(x) by hand if I want to 
get the inverse Fouriertransform.

The help states it will do it by itself.

Version R-0.60.1, Linux

Seems to be pretty easy to correct either the fft or :-) the help(fft)!

Cu Detlef


Detlef Steuer Universitaet Dortmund	                	///////
LS Computergestuetzte Statistik         		 U N I D O ///  
steuer@gigamain.statistik.uni-dortmund.de         	______///////  
Tel: ++49 +231 755 3139 Fax: ++49 +231 755 4387         \_\_\_\/////
						         \_\_\_\///
						          \_\_\_\/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 11 11:37:27 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 11 Dec 1997 12:37:27 +0100 (MET)
Subject: R-alpha: core dumped when reloading a library
Message-ID: <Pine.OSF.3.96.971211123003.3031A-100000@alpha>

I am currently finalising the writing of a library named "stable".
When I consider the following sequence

> library(stable)
> detach("package:stable")
$ R INSTALL stable    (after some correction in my library)
>library(stable)
> dstable(0)      # computation of the stable density density at 0

I get a core dumped.

Can this be avoided?
 Philippe

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

From pgilbert@bank-banque-canada.ca  Thu Dec 11 16:46:37 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 11:46:37 -0500
Subject: R-alpha: Re: R-beta: R FAQ v0.60
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca> <199712110831.JAA00252@pc25.none>
Message-ID: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>

>However, keep in mind that in the long run, all R SOURCE files will need
>to have a `.R' extension (as of 0.60, this is already a must for data).

Does this mean that files like, for example, ../R/library/mva/R/mva should be
called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
the file name must end in .R? If the latter is being suggested then I object
very strongly. While this is a useful convention it is not something which
should be forced. The programs I use which do this are a real pain. If S where
to do a similar thing (.S) then I would be forced to maintain a complete
duplicate set of files (or use links which is also a pain).

(I haven't got as far as loading my data, so I may report on that later.)

Paul Gilbert

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

From thomas@biostat.washington.edu  Thu Dec 11 17:05:25 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 09:05:25 -0800 (PST)
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:
> >However, keep in mind that in the long run, all R SOURCE files will need
> >to have a `.R' extension (as of 0.60, this is already a must for data).
> 
> Does this mean that files like, for example, ../R/library/mva/R/mva should be
> called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> the file name must end in .R? 

It only applies to package source code: so

src/library/SOMEPKG/R/file	should be 
src/library/SOMEPKG/R/file.R    and 
src/library/SOMEPKG/data/datafile      should be
src/library/SOMEPKG/data/datafile.R    

for the installer to install them.

Similarly, the documentation must be in .Rd files

This has the benefit of ignoring things like emacs backup files while you
are developing a package, and of making packages easier to understand
(possibly).

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 17:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 18:56:31 +0100
Subject: R-alpha: fft does not act as described in help(fft)
In-Reply-To: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>
 (message from Detlef Steuer on Thu, 11 Dec 1997 11:21:09 +0100 (MET))
Message-ID: <199712111756.SAA05761@sophie.ethz.ch>

>>>>>  Detlef Steuer <steuer@gigamain.Statistik.Uni-Dortmund.DE> writes:

    Detlef> Hello!  thank you for your efforts creating R!

Thank you for reporting the inaccuracy!

Please ``R-develer''s,  keep these reports flowing..!

    Detlef> While preparing the next lessons
(which lessons? -- I am curious)
    Detlef> I found that I had to multiply
    Detlef> with 1/length(x) by hand if I want to get the inverse
    Detlef> Fouriertransform.

    Detlef> The help states it will do it by itself.

    Detlef> Seems to be pretty easy to correct either the fft or :-) the
    Detlef> help(fft)!

I corrected the  help(fft).  It is now clear about NOT dividing and
gives an example showing how the inverse is got from ``inverse = TRUE''

The current behavior is the same as S, 
and we do want this in these basic things.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Thu Dec 11 18:46:44 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 13:46:44 -0500
Subject: R-alpha: inheritance ([.ts)
Message-ID: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>

While commenting out the previously mentioned warning seems to work, I have been
reflecting on this problem and there seems to be an issue wrt inheritance that I
do not understand properly. Perhaps some gurus could comment.

As mentioned previously, I have a class "tframe" with more specific classes
indicating how time is being represented, such as
> class(tframe(data))
[1] "ts"     "tframe"
and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].

Now tframe(data) is NOT a "ts", it is a specific kind of "tframe". When I coded
this I was expecting it would use  "[.default", so to date I guess it has just
been working accidentally.

Does the fact that there is a class "ts" mean that one should not have another
class with "ts" as its more specific class? This seems like a pretty severe
limitation.

Paul Gilbert




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

From thomas@biostat.washington.edu  Thu Dec 11 18:59:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 10:59:39 -0800 (PST)
Subject: R-alpha: inheritance ([.ts)
In-Reply-To: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211105108.14909B-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:

> While commenting out the previously mentioned warning seems to work, I have been
> reflecting on this problem and there seems to be an issue wrt inheritance that I
> do not understand properly. Perhaps some gurus could comment.

There is no real "inheritance" mechanism in R.  Objects have a list of
classes, and UseMethod/NextMethod search this list from left to right,
pasting the class name on to the generic method name, until a function is
found. The ability to mimic inheritance relies on class names being
unique, so that, for example gee inherits from glm which inherits from lm.


> As mentioned previously, I have a class "tframe" with more specific classes
> indicating how time is being represented, such as
> > class(tframe(data))
> [1] "ts"     "tframe"
> and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].
 
> Does the fact that there is a class "ts" mean that one should not have another
> class with "ts" as its more specific class? This seems like a pretty severe
> limitation.

Yes it does. It is a limitation especially as there is only one namespace.
It is also unfortunate that a lot of people have used method-like names
the other way around, so that eg cox.zph is a proportional hazards test (z
ph) for a cox model, not a "cox" for a "zph" object.

The fix to this is to use something like 
	c("ts.tsframe", "tsframe")
for a more specific ts subclass of tsframe.  It's a bit ugly, but it
works.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 12 08:52:34 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 12 Dec 1997 09:52:34 +0100
Subject: probability and random numbers -- I'm looking at Brown's dcdflib
Message-ID: <199712120852.JAA06458@sophie.ethz.ch>

I'm looking at Brown's dcdflib
	(announced on S-news a few days ago)
in order to get code for  noncentral t and F   into R;
also the noncentral chisq is still not complete.

If anyone is particularly knowledgable in this field
or interested in testing, please let me know.
	(this is NOT a high priority project,
	 but I write to you in order to  coordinate work).

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/


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

From phlamber@luc.ac.be  Fri Dec 12 09:25:22 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Fri, 12 Dec 1997 10:25:22 +0100 (MET)
Subject: files ending by .R in packages
In-Reply-To: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>
Message-ID: <Pine.OSF.3.96.971212101301.16955B-100000@alpha>



On Thu, 11 Dec 1997, Thomas Lumley wrote:

> On Thu, 11 Dec 1997, Paul Gilbert wrote:
> > >However, keep in mind that in the long run, all R SOURCE files will need
> > >to have a `.R' extension (as of 0.60, this is already a must for data).
> > 
> > Does this mean that files like, for example, ../R/library/mva/R/mva should be
> > called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> > the file name must end in .R? 
> 
> It only applies to package source code: so
> 
> src/library/SOMEPKG/R/file	should be 
> src/library/SOMEPKG/R/file.R    and 
> src/library/SOMEPKG/data/datafile      should be
> src/library/SOMEPKG/data/datafile.R    
> 
> for the installer to install them.
> 

Personnally, I would appreciate that .r source files are also considered
when installing a package, as a .R file copied on a msdos floppy disk
becomes a .r file.

Philippe

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

From rossetti@stat.unipg.it  Fri Dec 12 20:47:58 1997
From: rossetti@stat.unipg.it (Andrea Rossetti)
Date: Fri, 12 Dec 1997 21:47:58 +0100
Subject: R-beta: new executable
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz>
Message-ID: <3491A2FE.55C098CF@stat.unipg.it>

Robert Gentleman wrote:

> I have just put up a new executable as a replacement for the one in
>   rseptbeta.zip
>  there have only been a few changes; mostly to the menu's. I am about
>  to start on a major overhaul including getting survival to work and
>  grabbing the 0.60 version once it's stable.
>
> --->> Please let me know about other enhancements you want....<<---

I'm very interested in time series anlaysis (acf, pacf, arima modelling, and all
other) is a possible enhancement for the WINDOWS 95 version of R!(?)

Thanks.

Andrea Rossetti.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Sat Dec 13 22:23:13 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Sat, 13 Dec 1997 23:23:13 +0100
Subject: time series software: more basic functions,  who?
In-Reply-To: <3491A2FE.55C098CF@stat.unipg.it> (message from Andrea Rossetti
 on Fri, 12 Dec 1997 21:47:58 +0100)
Message-ID: <199712132223.XAA14687@jessica.ethz.ch>

Caro Andrea,

si e possibile, prego, uilizi soltanto un solo dei gruppi  R-...
Questo va per il mio italiano...

Apropos Time Series Software, there's not much in the latest version
0.60.1,  for unix either.

Since there are several people interested in having time series functions
available, I'd propose  some of you `stand up' and say:
	I'll do this...
and then post code to R-devel.
Or alternatively, send it to Ross  (who had started on some of these some
months ago...)
or someone else who coordinates these.
What do you think?
Paul Gilbert, I think this complementary to your  DSE library?
If not, we should maybe wait till DSE is available as R package
(how ?) soon.

Who is interested in doing work here?
please reply to me, and I'll collect and summarize to R-devel.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 19:21:25 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 14:21:25 -0500
Subject: RedHat 5.0 Linux libc to glibc
Message-ID: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>

This was posted on another list I follow and I thought it might be important if
you are not already aware of the change:

>Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
>glibc version 2.0 as the standard C library. This arranges its include
>files differently and has resulted in MOST programs needing changes to
>compile under Redhat 5.0.

Paul Gilbert


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

From bates@stat.wisc.edu  Tue Dec 16 20:26:09 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 16 Dec 1997 14:26:09 -0600
Subject: RedHat 5.0 Linux libc to glibc
In-Reply-To: Paul Gilbert's message of Tue, 16 Dec 1997 14:21:25 -0500
References: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>
Message-ID: <6rpvmxhw66.fsf@franz.stat.wisc.edu>

Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

> This was posted on another list I follow and I thought it might be important if
> you are not already aware of the change:
> 
> >Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
> >glibc version 2.0 as the standard C library. This arranges its include
> >files differently and has resulted in MOST programs needing changes to
> >compile under Redhat 5.0.

The changes between Debian GNU/Linux versions 1.3 and 2.0 are also
primarily a change from libc5 to libc6 (a.k.a. glibc 2).   R-0.60.1
compiles cleanly under either.  There is no need for changes in the
source code for R.  I would expect that the same would be true under
RedHat.

I would be very interested in contacting people who are running RedHat 
5.0 to see if the version of libc6 on RedHat still has a problem with
the ecvt system function.   I reported a bug on that several months
ago and the libc6 versions I am using still have the same bug.

Here is a C source file that exercises the bug
#include <stdio.h>
#include <stdlib.h>

void main(int argc, char **argv)
{
  int decpt, sign; char * result;
  char buf[256];
  result = ecvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = gcvt((double) 1234.567, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) -987.654321, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) 0, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
}

When compiled and run it produces obviously incorrect results.
result is 11234.567, decpt is 4, sign is 0
result is 9987.6543, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result is 11234.567000, decpt is 4, sign is 0
result is 9987.654321, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result of gcvt is 1234.567
result of gcvt is -987.6543
result of gcvt is 0

For one thing the string returned as the result should not contain a
decimal point.  Is someone is running RedHat 5.0 could you check the
results on there?
-- 
Douglas Bates                            bates@stat.wisc.edu
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 20:08:38 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 15:08:38 -0500
Subject: time series
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz> <3491A2FE.55C098CF@stat.unipg.it>
Message-ID: <97Dec16.152847est.26753@mailgate.bank-banque-canada.ca>

>I'm very interested in time series anlaysis (acf, pacf, arima modelling, and
>all other) is a possible enhancement for the WINDOWS 95 version of R!(?)

I am still hoping to make a Unix version of my DSE library available this week.
If I don't make it then it will be after the New Year as I'm away for two weeks.
I will make all the source code available, so the only real sense in which this
is a Unix version is that the installation procedures are set up for Unix.

The library does a lot of linear, time-invariant, vector ARIMA and state space
stuff, but does not do ar, acf, pacf or arima.mle as supplied in Splus. Below is
a rough start at ar and acf, but they are not yet working right. If anyone is
interested in finishing them I would be very happy. I haven't tried pacf and
I've never had any interest in arima.mle as it did not work for vector series.

The library should work (with the exception of a few non-critical  functions) in
the existing Windows version of R, as I had most of it working in an older
version under Linux. I was going to wait until Robert has the Window version up
to 0.60, but the main problem is that I have little familiarity with Windows. So
if anyone wants to work on that, again, I would be more than happy.

There is a stand alone subset of the library (I call tframe) which is a kernel
for my other code.  I'm fairly sure this work in the Windows version of R. This
provides a "classes and methods" way of handling the time dimension of an
object,  which I think is very useful for making  code that can fairly easily
handle new time representations. It also provides a replacement for tsmatrix and
some plotting routines which are useful for time series.

Paul Gilbert
___________

ar.test <-function(x, aic=T, order.max=2, method="yule-walker")
   {# this seems to work, in the sense of producing estimates which are
    # asymtotically as good as (or as bad as) Splus ar, at least for
    # stationary data. But estimates are not the same.
    # For non-stationary data Splus ar does better, but neither method is really
valid.
    if(method=="burg") stop("burg method for ar not yet implemented.")
    warning(" ar function not complete and not checked & default order.max=2.")
    if (is.vector(x))x <- matrix(x, length(x),1)
    sampleT <- nrow(x)
    if (is.null(order.max)) order.max <- round(10*log10(sampleT/ncol(x)))
    AC <- array(NA, c(order.max+1, ncol(x), ncol(x)))
x <- unclass(x)
tsp(x) <-NULL
    x <- x - t(array(apply(x,2,sum)/nrow(x), rev(dim(x))))
    for (i in 0:order.max)
   {Om<- (t(x[(i+1):sampleT,,drop=F]) %*%
                   x[1:(sampleT-i),,drop=F])/(sampleT-i)
 #   Om<- cor(x[(i+1):sampleT,,drop=F],
        #            x[1:(sampleT-i),,drop=F]) # cor seems better than var
       #    if(i==0) Om0 <- solve(Om)
       #                     # nrow above for univariate case
       #    Om <- Om0 %*% Om  #Yule-Walker eqn. should solve without this
           AC[i+1,,] <-  Om
          }

   # now solve yule walker eqns.
   n <- ncol(x)
   a <- matrix(NA, n*(order.max), n*(order.max) )
   b <- matrix(NA, n*(order.max), n )
   # using AC[1,,] in place of I
   # there must be a better way (with outer?)
    for (i in 0:(order.max-1))
       for (j in 0:(order.max-1))
   a[(1+i*n):(n+i*n),(1+j*n):(n+j*n)] <- AC[abs(i-j)+1,,]
    for (i in 1:order.max)
   b[(1+(i-1)*n):(i*n),] <- AC[i+1,,]
   AR <-solve(a, b)
   if (n==1) AR <- matrix(AR, length(AR), 1)
   #AR <- solve(t(a),b) # the off-diag values may require this??
 #  ar <- aperm(array(AR,c(dim(AC)-c(1,0,0))), c(2,1,3))
    ar <- array(NA, c(order.max, ncol(x), ncol(x)))
    for (i in 1:order.max)
 ar[i,,] <- AR[(1+(i-1)*n):(i*n),]
   order <- order.max # need aic here
   list(ar=ar, order=order, order.max=order.max, method=method)
   }


acf <-function (residual, plot = F, type = "correlation")
       {if (plot) warning(" acf plot not yet supported.")
        if(0==charmatch(type,c("covariance","correlation","partial"),nomatch=0))

             stop("type not allowed in acf")
        if (is.vector(residual))residual <- matrix(residual, length(residual),1)

 sampleT <- nrow(residual)
        N <- round(10*(log10(sampleT)-log10(ncol(residual))))
        acf <- array(NA, c(N, ncol(residual), ncol(residual)))
 for (i in 0:(N-1))
   {Om<- cov(residual[(i+1):sampleT,,drop=F],
                    residual[1:(sampleT-i),,drop=F])
           if (type=="correlation")
                {if(i==0) Om0 <- diag(1/sqrt(diag(Om)),nrow=nrow(Om))
                            # nrow above for univariate case
                 Om <- Om0 %*% Om %*% Om0
                }
           acf[i+1,,] <-  Om
          }
        if (type=="partial")
          {warning("acf type partial not yet supported. 0 value being returned")

           acf <- array(0, dim(acf))
          }
 list(acf=acf, type=type )
       }


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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 10:28:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 11:28:31 +0100
Subject: "'" prints as "\'"
Message-ID: <199712171028.LAA01254@sophie.ethz.ch>

(This reported before).
In R,
	"'"
prints as

[1] "\'"

which is different from S, and is really unnecessary.
((it is just now uglyfying the output of a function which I wrote for S
  and now use in R)).

Is there any good reason for the current behavior?

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 10:38:00 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 11:38:00 +0100
Subject: "'" prints as "\'"
In-Reply-To: <199712171028.LAA01254@sophie.ethz.ch>
References: <199712171028.LAA01254@sophie.ethz.ch>
Message-ID: <199712171038.LAA04074@pc25.none>

>>>>> Martin Maechler writes:

> (This reported before).
> In R,
> 	"'"
> prints as

> [1] "\'"

> which is different from S, and is really unnecessary.
> ((it is just now uglyfying the output of a function which I wrote for S
>   and now use in R)).

> Is there any good reason for the current behavior?

Yes.  To have ESS font-lock the output correctly.

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

From rossini@math.sc.edu  Wed Dec 17 14:57:25 1997
From: rossini@math.sc.edu (Anthony Rossini)
Date: 17 Dec 1997 09:57:25 -0500
Subject: "'" prints as "\'"
In-Reply-To: Kurt Hornik's message of "Wed, 17 Dec 1997 11:38:00 +0100"
References: <199712171028.LAA01254@sophie.ethz.ch> <199712171038.LAA04074@pc25.none>
Message-ID: <wncvhwoqap6.fsf@fhat.stat.sc.edu>


>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >> (This reported before).
    >> In R,
    >> "'"
    >> prints as

    >> [1] "\'"

    >> which is different from S, and is really unnecessary.
    >> ((it is just now uglyfying the output of a function which I wrote for S
    >> and now use in R)).

    >> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

Poor justification.  I'll look into this more in Feb/Mar...

best,

-- 
-tony (Anthony Rossini)	           Statistics Dept., U South Carolina
rossini@stat.sc.edu	           Columbia, SC 29208
http://www.stat.sc.edu/~rossini/   803-777-3578(O) 803-777-4048 (fax)  
        "'Bother,' said Pooh, as Cthulhu rose up and ate him."
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Wed Dec 17 16:05:16 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 11:05:16 -0500
Subject: library/data
Message-ID: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>

I have some data files with my library which are used for examples and testing
the code. To date I have kept them in a subdirectory I called ../dse/dsedata,
but I am trying to move those to .../dse/data as perscribed for installing
libraries. However, these datasets are not all R object, some are just files
that I source from within a function, and one is accessed by a separate process
that I call from R.

1/ Should the data subdirectory be reserved for R objects?

2/ Could someone explain or point me to were I can find the explanation of how R
objects in this data subdirectory should be constructed? Are these objects
automatically loaded when a library is loaded?

3/ To date I have been able to find my subdirectory by setting a variable
indicating its location in the library file from which code is loaded.
Admittedly this was a kludge, but I could do it because I had my own make which
embedded the location in the file when it was installed. I was not very happy
with this trick, but it seems I completely lose this ability using R INSTALL.
>From within R is there a good way to find the location of a library when it is
loaded or after it is loaded?

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 16:30:52 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 17:30:52 +0100
Subject: "'" prints as "\'"
In-Reply-To: <wncvhwoqap6.fsf@fhat.stat.sc.edu> (message from Anthony Rossini
 on 17 Dec 1997 09:57:25 -0500)
Message-ID: <199712171630.RAA01763@sophie.ethz.ch>

>>>>> "tony" == Anthony Rossini <rossini@math.sc.edu> writes:

>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >>> (This reported before).  In R, "'" prints as

    >>> [1] "\'"

    >>> which is different from S, and is really unnecessary.  ((it is just
    >>> now uglyfying the output of a function which I wrote for S and now
    >>> use in R)).

    >>> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

    tony> Poor justification.  I'll look into this more in Feb/Mar...

It is actually wrong.  There's no problem with font-locking here...

I think we will change this, in the ``next after next'' release of R.

Martin

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 17:46:42 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 18:46:42 +0100
Subject: library/data
In-Reply-To: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
Message-ID: <199712171746.SAA04913@pc25.none>

>>>>> Paul Gilbert writes:

> I have some data files with my library which are used for examples and
> testing the code. To date I have kept them in a subdirectory I called
> ../dse/dsedata, but I am trying to move those to .../dse/data as
> perscribed for installing libraries. However, these datasets are not
> all R object, some are just files that I source from within a
> function, and one is accessed by a separate process that I call from
> R.

Official R speak actually is `package' for what you call `library'.

> 1/ Should the data subdirectory be reserved for R objects?

No.  You can have data of any kind ther.  However, currently data() only
works for R objects, i.e., files with R code and names ending in `.R'.
Within soon, this should be extended so that e.g. `.tab' is using for
tables (and we still have to determine how to treat headers ...).

> 2/ Could someone explain or point me to were I can find the
> explanation of how R objects in this data subdirectory should be
> constructed? Are these objects automatically loaded when a library is
> loaded?

No, they are not loaded automatically.  Currently, there is (still) no
way to attach a directory.  This will change eventually.

If you build a package for use with R and there is no reason to store
data in a specific format, you might as well try to dump() your object
and put the result of that into the data dir of the pkg (thus you'd have
sourceable R code etc.)  If you want to distribute something in some
other format, e.g. `file.of', then `file.R' should contain the R code
for reading the contents of `file.of' into R.

> 3/ To date I have been able to find my subdirectory by setting a
> variable indicating its location in the library file from which code
> is loaded.  Admittedly this was a kludge, but I could do it because I
> had my own make which embedded the location in the file when it was
> installed. I was not very happy with this trick, but it seems I
> completely lose this ability using R INSTALL.  >> From within R is
> there a good way to find the location of a library when it is loaded
> or after it is loaded?

Not quite.  There is a function called system.file() which does
something similar:

R> system.file("R/base")
[1] "/usr/local/lib/R/library/base/R/base"
R> system.file("data/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"
> system.file("*/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"

Would it be important to know the location of a package?

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

From pgilbert@bank-banque-canada.ca  Wed Dec 17 19:00:31 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 14:00:31 -0500
Subject: library/data
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca> <199712171746.SAA04913@pc25.none>
Message-ID: <97Dec17.140207est.26702@mailgate.bank-banque-canada.ca>

>Official R speak actually is `package' for what you call `library'.

Yes, I forgot, sorry.
Thanks for all the other details.

>Would it be important to know the location of a package?

Probably not for the code, but if I put data in .../dse/data then I need to know
where it is in order to load it (and sometimes to pass the location to other
processes to load it). The way I've done this in S is to set a global variable
in .First.lib using the library and section arguments, but I don't think this is
available in R yet.

Paul


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

From ihaka@stat.auckland.ac.nz  Wed Dec 17 22:51:06 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Thu, 18 Dec 1997 11:51:06 +1300 (NZDT)
Subject: Development Plans
Message-ID: <199712172251.LAA26527@stat1.stat.auckland.ac.nz>

I thought that it might be useful (to myself as well as others) to
write down my current plans for working on R.  I have indexed things
by my (vague) feeling of priority.  If you think my priorities are
completely wrong, please feel free to set me straight :-).
As you can see, I am confining myself almost entirely to internal
tinkering - if someone would put another 24 hours into the day I'll
take a look at applications too.

	Ross


1. Revision Of The Graphics System

Paul Murrell and I (mostly Paul) are revising the R graphics system so
that it will allow multiple active devices, better hardcopy facilities
and more flexible plot layouts.
[Status: well under way].


2. Make The Source Tree More Gnu Compatible

This means having a target installation directory in mind, (probably
defaulting to /usr/local/lib/R-x.xx) in mind rather than building the
distribution in place.  This would make it reasonable to peel back one
level of directory structure. I.e. move the source of the current src
director up one level.  The "graphics" subdirectory would also disappear,
to be replaced by one or two bigger code chunks.
[Status: this and the Fortran change below are relatively simple to put
in place, but keeping the cvs history intact could be a problem]


3. Fortran Integration

Work on a real integration of Fortran into R.  This would mean
adapting the configuration procedures used by Octave to detect and
use Fortran.  As a consequence, the current duplication of C and
F77 sources would disappear.  It would also it possible to incorporate
a much richer set of numerical and other capabilities into R.
[Status: I have done some basic experiments and it looks pretty
easy to do]


4. Demand Loading Of Objects

This would be similar in spirit to Thomas Lumley's approach, but
would go on at a somewhat lower level and also allow selective
freeing of such objects when memory demands are high.  It would
also make it possible to think in terms of "attaching" directories
of objects.  (At attach time all the objects in a directory would
be registered as loadables, and loaded when required).
[Status: I have thought a bit about this.  It should be pretty simple
but no doubt there are a few undiscovered gotchas in there]


5. Change Internal Handling of Lists

Do a rewrite of the internal handing of lists so that they are
really generic vectors.  This will mean large volumes of fairly
flakey subsetting and mutation code can be removed.
[Status: It is important to get this done, but it will be a big task.
Almost everything will break during the switch]


6. Memory Management

Revisit the memory management system.  In particular, we need a better
way of storing strings, and of allowing the heap to grow, rather than
having everything allocated up front.
[Status: Preliminary wishful thinking ...]


7. Miscellaneous

Do something about namespace management.
Finish writing persp (and some other graphics primitives).
Implement missing functionality such as "aov" and "persp".                 
[Status: I have played with some of this]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 08:10:54 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 18 Dec 1997 09:10:54 +0100
Subject: model.matrix(.) and all that
Message-ID: <199712180810.JAA02547@sophie.ethz.ch>

Maybe just a minor thing,
but since we are aiming for  S compatibility, here :

       R> x_ 1:5
       R> model.matrix(x ~ x)
       Error: length of namelist must equal dims

whereas in  S,

	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 18 09:50:36 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 18 Dec 1997 10:50:36 +0100 (MET)
Subject: library/data
In-Reply-To: <199712171746.SAA04913@pc25.none>
Message-ID: <Pine.OSF.3.96.971218104505.27754B-100000@alpha>


> > 1/ Should the data subdirectory be reserved for R objects?
> 
> No.  You can have data of any kind ther.  However, currently data() only
> works for R objects, i.e., files with R code and names ending in `.R'.

What about files ending in .r?
(= result of copying a .R file on a dos formatted floppy disk).
Will they be recognized as R code files?
I have already mentioned this problem a few days ago, but there has not
been any reaction.

Thanks,
 Philippe

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

From p.dalgaard@biostat.ku.dk  Thu Dec 18 10:31:06 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 18 Dec 1997 11:31:06 +0100
Subject: model.matrix(.) and all that
In-Reply-To: Martin Maechler's message of Thu, 18 Dec 1997 09:10:54 +0100
References: <199712180810.JAA02547@sophie.ethz.ch>
Message-ID: <x2pvmvdjth.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> 
> Maybe just a minor thing,
> but since we are aiming for  S compatibility, here :
> 
>        R> x_ 1:5
>        R> model.matrix(x ~ x)
>        Error: length of namelist must equal dims
> 
> whereas in  S,
> 
> 	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)

... where I would have expected model.matrix(~x). Does this have any
untoward consequences for delete.response and all that?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 23:15:05 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 19 Dec 1997 00:15:05 +0100
Subject: numeric(0)[FALSE]  bug[let]
Message-ID: <199712182315.AAA04804@jessica.ethz.ch>

This is not a joke, but a problem appearing in real code of mine.
I used ifelse in a context which can be simplified to

R> ifelse(T, 3, NULL)
Error: incompatible types in subset assignment
R> ifelse(T, 3, numeric(0))
Error: invalid subscript type
R> 
R> ifelse
function (test, yes, no) 
{
        ans <- test
        test <- as.logical(test)
        nas <- is.na(test)
        ans[test] <- rep(yes, length = length(ans))[test]
        ans[!test] <- rep(no, length = length(ans))[!test]
        ans[nas] <- NA
        ans
}
R> 
R> numeric(0)[F]
Error: invalid subscript type
R> NULL[F]
NULL
R> 

--------------------------------------------

whereas  S-plus does as I expect:

S> ifelse(T, 3, NULL)
[1] 3
S> ifelse(T, 3, numeric(0))
[1] 3
S> 
S> NULL[F]
NULL
S> numeric(0)[F]
numeric(0)
S> logical(0)[F]
logical(0)
S> 
-----------------
I see an easy workaround for either fixing  ifelse(.) and or
solving my problem.

However, I think

	anytype(0)[FALSE]  should  return   
	anytype(0)

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

From pgilbert@bank-banque-canada.ca  Fri Dec 19 18:46:18 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 19 Dec 1997 13:46:18 -0500
Subject: Error in parse
Message-ID: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>

In R 0.60.1 when I source a fairly large file of code I am getting:
Error in parse(file, n, text, prompt) : syntax error on line 2985

I don't see any error and it doesn't happen if I split the file in two pieces.
increasing  -v -n does not seem to help and does not change the location of the
error. Does anyone have suggestions?

Paul Gilbert


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

From Kurt.Hornik@ci.tuwien.ac.at  Mon Dec 22 09:24:20 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Mon, 22 Dec 1997 10:24:20 +0100
Subject: Error in parse
In-Reply-To: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
Message-ID: <199712220924.KAA08507@pc25.none>

>>>>> Paul Gilbert writes:

> In R 0.60.1 when I source a fairly large file of code I am getting:
> Error in parse(file, n, text, prompt) : syntax error on line 2985

> I don't see any error and it doesn't happen if I split the file in two
> pieces.  increasing -v -n does not seem to help and does not change
> the location of the error. Does anyone have suggestions?

Two suggestions:

* Does the problem occur at the end of the file?  Then, the problem
might be a final newline ...

* Does the file contain ASCII 0 characters?

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 16:38:14 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 17:38:14 +0100
Subject: $CRAN/src/contrib/devel
Message-ID: <199712221638.RAA16954@galadriel.ci.tuwien.ac.at>


I have created the above directory for contributed R packages that are
considered as ``in development''. It is intended as a central
marketplace for code that is for various reasons ``unstable'' or
``incomplete'' but might be useful for others. If you want to
contribute some code, please include a README file in the tar ball
describing the problems etc.

I have started porting the main library section of Venables & Ripley's
MASS ... but I had time only for lda and qda (these seem to be
working) ... they can be found in=20

	$CRAN/src/contrib/devel/mass-0.01-1.tar.gz



Frohe Weihnachten & ein gl=FCckliches neues Jahr,

Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 17:48:51 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 18:48:51 +0100
Subject: some unresolved symbols ... does anybody know them
Message-ID: <199712221748.SAA19722@galadriel.ci.tuwien.ac.at>


I've tried (again) to port Hastie/Tibshirani's mda package and still got
stuck with some unresolved symbols ... does anybody know where these
are defined:

	R.binary: can't resolve symbol 'dbksl_'=09
	R.binary: can't resolve symbol 'dblepr_'
	R.binary: can't resolve symbol 'dqrdca_'
	R.binary: can't resolve symbol 'intpr_'
	R.binary: can't resolve symbol 'pack_'
	R.binary: can't resolve symbol 'sgram_'
	R.binary: can't resolve symbol 'sknotl_'
	R.binary: can't resolve symbol 'unpack_'
	R.binary: can't resolve symbol 'wmean__'

I tried to ask the original authors, but got no response so far.

Best,
Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From bates@stat.wisc.edu  Tue Dec 23 21:28:36 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 23 Dec 1997 15:28:36 -0600 (CST)
Subject: Debian package for R-0.61 uploaded
Message-ID: <m0xkbsS-000hhtC@franz.stat.wisc.edu>

I have uploaded a Debian package r-base_0.61.0-2_i386.deb to the
incoming directory at ftp.ci.tuwien.ac.at.  This package is built
against libc5, not libc6.  Turns out that was a bit more complicated
than I had hoped.

I have also created an RPM file for the same binary distribution and
will upload that shortly as r-base-0.61.0-2.i386.rpm.  I enclose some
information regarding the two packaged versions below.  Notice that
the rpm query indicates that not only is there a call to
/usr/local/bin/perl but there appears to be vestigial @PERL@ calls in
some of the scripts somewhere in the tree.  It may just be that I have
not cleared out all the foo.in files - I'll try to check.

Why is this release 2 of the Debian package you ask?  Well I found out 
after I uploaded release 1 to master.debian.org that I had botched the 
renaming of the original tar file.  I think this time it is ok.  It
doesn't affect the binary package. It only affects people who are
going to try to build the package from the sources.

Merry Christmas and a Happy New Year to all.

 # dpkg-deb -I r-base_0.61.0-2_i386.deb 
  new debian package, version 2.0.
  size 982660 bytes: control archive= 25313 bytes.
      854 bytes,    16 lines      control              
     1074 bytes,    46 lines      du                   
    65122 bytes,   932 lines      md5sums              
       18 bytes,     2 lines      shlibs               
  Package: r-base
  Version: 0.61.0-2
  Architecture: i386
  Depends: ldso (>= 1.8.0-0), libc5 (>= 5.4.0-0), libreadline2 (>= 2.1), ncurses3.0, xlib6 (>= 3.3-0)
  Suggests: g77
  Installed-Size: 3491
  Maintainer: Douglas Bates <bates@stat.wisc.edu>
  Description: `GNU S' - A language and environment for statistical computing.
   R is described by its authors as "not unlike" S, which is a language
   developed at Bell Laboratories for statistical computing and graphics.
   It provides support for a variety of statistical and graphical analyses.
   R is a true computer language which contains a number of control-flow
   constructions for iteration and alternation.  It allows users to add
   additional functionality by defining new functions.  Fortran and C
   code can be linked and called at run time.
   S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -i
 Name        : r-base                      Distribution: Debian
 Version     : 0.61.0                            Vendor: (none)
 Release     : 2                             Build Date: Tue Dec 23 15:13:12 1997
 Install date: (not installed)               Build Host: franz.stat.wisc.edu
 Group       : Converted/Debian              Source RPM: r-base-0.61.0-2.src.rpm
 Size        : 2989093
 Summary     : `GNU S' - A language and environment for statistical computing.
 Description :
 R is described by its authors as "not unlike" S, which is a language
 developed at Bell Laboratories for statistical computing and graphics.
 It provides support for a variety of statistical and graphical analyses.
 R is a true computer language which contains a number of control-flow
 constructions for iteration and alternation.  It allows users to add
 additional functionality by defining new functions.  Fortran and C
 code can be linked and called at run time.
 S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -R
 @PERL@  
 /usr/local/bin/perl  
 /usr/bin/perl  
 /bin/sh  
 /bin/perl  
 libreadline.so.2  
 libncurses.so.3.0  
 libm.so.5  
 libdl.so.1  
 libc.so.5  
 libX11.so.6  
 libSM.so.6  
 libICE.so.6  
 /bin/sh  
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From warnes@biostat.washington.edu  Wed Dec 24 02:01:51 1997
From: warnes@biostat.washington.edu (Gregory R. Warnes)
Date: Tue, 23 Dec 1997 18:01:51 -0800 (PST)
Subject: package conversion script
In-Reply-To: <m0xkbsS-000hhtC@franz.stat.wisc.edu>
Message-ID: <Pine.LNX.3.96.971223173611.293F-200000@progress.biostat.washington.edu>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII


Attached is a script, UPDATELIBS, that does much of the work of converting
R packages/librares to the current format.  I've just used it to add
packages from my R-0.50-alpha-4 to R-0.61 (from the debian package
Douglass Bates just made available). 

It takes a list of package names/directories as parameters and does the
following:
  - renames $PACKAGE/funs to $PACKAGE/R
  - converts $PACKAGE/man/* to $PACKAGE/man/*.Rd using $RHOME/etc/Rman2Rd
  - compiles any C and FORTRAN functions in $PACKAGE/src and
    $PACKAGE/src-c using R COMPILE
  - creates a shared library from the resulting objects using R SHLIB and
  - installs the package using R INSTALL

Its pretty simple-minded, and I've done little error-handling except to
assure that the appropriate $PACKAGE/* directories exist .  Finally,
UPDATELIBS assumes that it is run in the parent directory of the package
file(s), (ie $PACKAGE/.. ) . 

I hope someone finds it useful.

-Greg

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=UPDATELIBS
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.971223180151.293G@progress.biostat.washington.edu>
Content-Description: 

IyEvYmluL3NoDQojIFVQREFURUxJQlMgOiB1cGRhdGUgUiBsaWJyYXJpZXMg
dG8gbmV3IGZvcm1hdCBhbmQgaW5zdGFsbA0KIw0KUkhPTUU9YFIgUkhPTUVg
DQpleHBvcnQgUkhPTUUNClRISVNESVI9YHB3ZGANCmV4cG9ydCBUSElTRElS
DQoNCmZvciBpIGluICQqDQpkbw0KICAgaWYgWyAtZCAkaSBdDQogICB0aGVu
DQogCSMgZmlyc3QgcmVuYW1lICJmdW5zIiB0byAiUiINCglpZiBbIC1kICRp
L2Z1bnMgXQ0KCXRoZW4NCgkJbXYgJGkvZnVucyAkaS9SDQoJZmkNCgkNCgkj
IG5vdyBjb252ZXJ0IG9sZCBoZWxwIGZpbGVzDQoJaWYgWyAtZCAkaS9tYW4g
XQ0KCXRoZW4NCgkgICBjZCAkaS9tYW4NCgkgICBmb3IgcCBpbiBgbHNgDQoJ
ICAgZG8NCgkgICAgICAkUkhPTUUvZXRjL1JtYW4yUmQgJHAgPiAkcC5SZA0K
CSAgIGRvbmUNCgkgICBjZCAkVEhJU0RJUg0KCWZpDQoJDQoJIyBjb21waWxl
IGNvZGUgICh0cnkgYm90aCBzcmMgYW5kIHNyYy1jKQ0KCWlmIFsgLWQgJGkv
c3JjIF0NCgl0aGVuDQoJICAgY2QgJGkvc3JjDQoJICAgUiBDT01QSUxFICou
YyAqLmYNCgkgICBSIFNITElCICRpLnNvICoubw0KCSAgIGNkICRUSElTRElS
DQoJZmkNCg0KICAgICAgICBpZiBbIC1kICRpL3NyYyBdDQogICAgICAgIHRo
ZW4NCiAgICAgICAgICAgY2QgJGkvc3JjLWMNCiAgICAgICAgICAgUiBDT01Q
SUxFICouYyAqLmYNCiAgICAgICAgICAgUiBTSExJQiAkaS5zbyAqLm8NCiAg
ICAgICAgICAgY2QgJFRISVNESVINCglmaQ0KDQoJIyBub3cgaW5zdGFsbA0K
CVIgSU5TVEFMTCAkaQ0KCQ0KICAgZWxzZQ0KICAgICAgCWVjaG8gKiogbGli
cmFyeSBkaXJlY3RvcnkgJGkgTk9UIEZPVU5EISAqKg0KICAgZmkNCmRvbmUN
Cg==
--8323328-376753582-882928911=:293--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From bates@stat.wisc.edu  Fri Dec 26 15:13:32 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 26 Dec 1997 09:13:32 -0600
Subject: "ifdef"'ing R/S code
Message-ID: <6rvhwcgmsj.fsf@franz.stat.wisc.edu>

I should have saved the messages about this but I didn't.  Can someone
remind me of what function or object to check from within a function
to determine if you are running R?  I need to make some changes in
code according to whether I am running it under R or under S and I
would prefer to keep one source tree.

Thomas Lumley:  I read your web page on porting S code to R.  It looks
very good.  You may want to change the parts about Calloc versus
calloc for the 0.61 release.  Also, little tidbits about the changes
in the interpreted code (such as the answer to the above query) could
help.  I realize that everything is in a state of flux so such
information quickly gets out of date but who trusts a web page more
than two weeks old anyway :-)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 26 15:27:14 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 26 Dec 1997 16:27:14 +0100
Subject: "ifdef"'ing R/S code:  if(is.R())
In-Reply-To: <6rvhwcgmsj.fsf@franz.stat.wisc.edu> (message from Douglas Bates
 on 26 Dec 1997 09:13:32 -0600)
Message-ID: <199712261527.QAA23058@jessica.ethz.ch>

>>>>> "DougB" == Douglas Bates <bates@stat.wisc.edu> writes:

    DougB> I should have saved the messages about this but I didn't.  Can
    DougB> someone remind me of what function or object to check from
    DougB> within a function to determine if you are running R?  I need to
    DougB> make some changes in code according to whether I am running it
    DougB> under R or under S and I would prefer to keep one source tree.

##>>>>>> This works in all of <<<<<
##-- S  (including "S version 4", (beta))
##-- R
##-- S-plus

is.R <- function() { ## returns  'TRUE'  iff we are using 'R'
  exists("version") && !is.null(vl <- version$language) && vl == "R"
}

#- some may want:
is.S <- function() !is.R()

--------------
I think I should add this function to the R base,
or do we need a new package  "Scompatibility"  which could server other
things as well? 

I for one, am having more and more need for an "Rcompatibility" package in
S...

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

From p.dalgaard@biostat.ku.dk  Sat Dec 27 01:50:53 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 27 Dec 1997 02:50:53 +0100
Subject: Error in parse
In-Reply-To: Kurt Hornik's message of Mon, 22 Dec 1997 10:24:20 +0100
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
 <199712220924.KAA08507@pc25.none>
Message-ID: <x2g1nfv9j6.fsf@blueberry.kubism.ku.dk>

Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

> 
> >>>>> Paul Gilbert writes:
> 
> > In R 0.60.1 when I source a fairly large file of code I am getting:
> > Error in parse(file, n, text, prompt) : syntax error on line 2985
> 
> > I don't see any error and it doesn't happen if I split the file in two
> > pieces.  increasing -v -n does not seem to help and does not change
> > the location of the error. Does anyone have suggestions?
> 
> Two suggestions:
> 
> * Does the problem occur at the end of the file?  Then, the problem
> might be a final newline ...
> 
> * Does the file contain ASCII 0 characters?

- and a third: 

Are you by any chance executing external programs with system()? This
is playing tricks on "make tests" at them moment, because the pager
eats up the remainder of the input file...I suspect that source()
within source() will do weird things too.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec 30 04:09:35 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 29 Dec 1997 22:09:35 -0600
Subject: as.name is not idempotent
Message-ID: <6rwwgnxyio.fsf@franz.stat.wisc.edu>

At least I think the word I want "idempotent" - it has been a long
debugging session and my brain is fried so I am not sure.

What I mean is that as.name applied to a name gives an error.
 > as.name("foo")
 foo
 > as.name(as.name("foo"))
 Error in as.name(x) : character argument required

It might help if it were a bit more flexible about the arguments it
accepts.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec 30 12:05:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 30 Dec 1997 13:05:13 +0100
Subject: as.name is not idempotent
In-Reply-To: Douglas Bates's message of 29 Dec 1997 22:09:35 -0600
References: <6rwwgnxyio.fsf@franz.stat.wisc.edu>
Message-ID: <x2d8ifjati.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> At least I think the word I want "idempotent" - it has been a long
> debugging session and my brain is fried so I am not sure.

I.: f(f(x)) == f(x) all x, so it's exactly the right term...

> What I mean is that as.name applied to a name gives an error.
>  > as.name("foo")
>  foo
>  > as.name(as.name("foo"))
>  Error in as.name(x) : character argument required
> 
> It might help if it were a bit more flexible about the arguments it
> accepts.

This is plainly a bug. If it bothers you badly, insert 

if(is.name(x)) return(x)

at the start of as.name.

In general, it should invariably hold that

is.xx(x) == TRUE implies as.xx(x) == x
and
is.xx(as.xx(x)) == TRUE unless as.xx fails

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From thomas@biostat.washington.edu  Wed Dec 31 21:03:23 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Wed, 31 Dec 1997 13:03:23 -0800 (PST)
Subject: debugger
In-Reply-To: <m0xnUm6-000hh5C@franz.stat.wisc.edu>
Message-ID: <Pine.SOL.3.95.971231130059.10B-100000@gorn>


Can we have some way to exit the debugger?  At the moment you have to use
(c)ontinue, which is annoying if the function is slow, or has unpleasant
side effects (like crashing R).


Thomas Lumley
------------------------------------------------------+------
Biostatistics		: "Never attribute to malice what  :
Uni of Washington	:  can be adequately explained by  :
Box 357232		:  incompetence" - Hanlon's Razor  :
Seattle WA 98195-7232	:				   :
------------------------------------------------------------


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

From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 09:34:04 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 10:34:04 +0100
Subject: R-alpha: Re^2: data file names
In-Reply-To: <199712020706.IAA10187@pc25.none> (message from Kurt Hornik on
 Tue, 2 Dec 1997 08:06:13 +0100)
Message-ID: <199712020934.KAA01688@sophie.ethz.ch>

	[R-devel'ers:  spill over from R-core .. -- MM]

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >> In preparing the next Windows release I want to make opening up
    >> system data files (and their documentation) more transparent. I
    >> would really like to adopt the convention that data files use the
    >> suffix .rdf (.dat seems like it's taken). This will make it easier
    >> to get the builtin Windows file browsers to work on it and save me
    >> some considerable work trying to figure out what is and isn't a data
    >> file.

    KH> What does `rdf' stand for?

R Data File ?

But why can't it just be `.R'  (-> `.r' in the ...OS)?

At least currently, these are simply files with valid  R code.
If they would end in `.R', ESS (Emacs Speaks Statistics) would
automatically be put in the proper mode.
Of course, we could also use a new ending,
but I think this would only make sense if the data files would internally
use a different format,
e.g.,  data.dump / data.restore, or one which works with  read.table.

We have discussed earlier that it would be nice to allow different formats
for data files, and maybe the file extension would tell the  data(.)
function in which way it has to read the data
(Of course, UNIX `file' would be much nicer than file extensions,
 but portability ...)

 


    >> It would also be nice if one of you great documentation folks
    >> thought of a html-like format for the .doc files so that I could
    >> simply pop them up. This would also ideally let index.doc be built
    >> on the fly....
yes

    >> I find it quite frustrating that I can't peek at the doc file while
    >> trying to decide which data file I want.
Hmm; in 0.60 we at least have
	data()
for the list
and
	?foodata
for the doc in foodata.doc.  This does already help me quite a bit..


    >> I'm hoping to get a browser
    >> that will let you peruse the documentation while selecting the file.

    >> Comments/opinions appreciated.

    KH> You are obviously right.  I think what we want is to have a unified
    KH> documentation format for both functions (which is what we have
    KH> until now been focussing on) and variables (``data files'').  In
    KH> the not too long run, will we be able to attach data directories so
    KH> that we can really treat the data files as variable objects?
Do you mean binary data files?  Or would they be `compiled' 
	from src/library/<pkg>/data/
	to   library/<pkg>/data/  ?


    KH> Anyway, I just realized that all .doc files now have the structure

    KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES

    KH> so it seems that we only need to add \format{} and \source{} to the
    KH> Rd standard.
yes; this would be one thing; the other being a script (or a person ..)
for translating all current the foodata.doc to foodata.Rd ...
But __YES__ , the earlier, the better  (but ``post release'');
I'd like to have this BEFORE the following is completely solved ..

    KH> And, well, to document the format we really need
    KH> tables.  FL, MM, what is the right way to do these?

As with \itemize , \enumerate and \describe
	(do they work now in HTML,  Fritz? -- would be nice for release ...).
HTML and LaTeX are `obvious'
(we  shouldn't be too fancy, I think, just use a common denominator of
	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
        Fritz will have to look at (a newer version of) latex2html once more)
and the real problem is  nroff.
 (yes, I do want to have simple fast online help using C-c C-v in ESS ...)



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

From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 11:26:32 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 12:26:32 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: <x2oh30m4h2.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 02 Dec 1997 11:20:09 +0100)
Message-ID: <199712021126.MAA01905@sophie.ethz.ch>

	[R-devel instead of  R-help]

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> 
    >> >>>>> Albrecht Gebhardt <agebhard@zidsrv.sci.uni-klu.ac.at> writes:
    >> 
    Albrecht> would it be possible to change the hist() function in future
    Albrecht> R Versions to accept a "plot=F" parameter (like hist() in S
    Albrecht> it should return a list with "breaks" and "counts" in this
    Albrecht> case). This change should be very simple.
    >> 
    >> it _was_ simple, and has been in the current sources for a while now.
    >> You'll see it in version 0.60 which should be released `real soon now'.
    >> 
    >> > hist(rnorm(50), plot=F)
    >> $breaks
    >> [1] -3 -2 -1  0  1  2  3
    >> 
    >> $counts
    >> [1]  1 11 12 20  5  1

    PD> Martin: Wouldn't it be better to return

    PD> invisible(list(breaks = breaks, counts = counts))

    PD> in the plot=T case? (currently it's  invisible(NULL) )

Yes, it would be better;
I even remember having thought about it....
ahh, the reason I did not implement it, is that S-plus is different:
It returns something else for  plot=TRUE:

S> x_ rnorm(50)
S> hi_ hist(x)
S> h2_ hist(x,plot=F)
S> hi
[1] -2.5 -1.5 -0.5  0.5  1.5  2.5
S> h2
$breaks:
[1] -3 -2 -1  0  1  2  3

$counts:
[1]  1  6 14 22  6  1

---
Do we want  S-compatibility here?
(At that time, I hated the idea that the return value is so different, just
 depending on the  plot=.. value).

At the moment, I have (only here, not yet commited)

In the case of  plot=FALSE, one wants (almost) always to
work with the result (and not just see it),i.e. one can have invisible
in both cases.
Therefore, I'd propose the following ``end of hist''
 ((Shall I commit this change later today, about GMT 15.00 ?)


	......

	if(plot) {
		plot.new()
		plot.window(xlim, ylim, "")
		title(main = main, xlab = xlab, ylab = ylab, ...)
		if(axes) {
			axis(1, ...)
			axis(2, ...)
		}
		rect(breaks[-nB], 0, breaks[-1], counts,
		     col = col, border = border)
	}
	invisible(list(breaks = breaks, counts = counts))
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 12:21:39 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 13:21:39 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: Martin Maechler's message of Tue, 2 Dec 1997 12:26:32 +0100
References: <199712021126.MAA01905@sophie.ethz.ch>
Message-ID: <x2lny4lyuk.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

>     PD> Martin: Wouldn't it be better to return
> 
>     PD> invisible(list(breaks = breaks, counts = counts))
> 
>     PD> in the plot=T case? (currently it's  invisible(NULL) )
> 
> Yes, it would be better;
> I even remember having thought about it....
> ahh, the reason I did not implement it, is that S-plus is different:
> It returns something else for  plot=TRUE:
> 
> S> x_ rnorm(50)
> S> hi_ hist(x)
> S> h2_ hist(x,plot=F)
> S> hi
> [1] -2.5 -1.5 -0.5  0.5  1.5  2.5
> S> h2
> $breaks:
> [1] -3 -2 -1  0  1  2  3
> 
> $counts:
> [1]  1  6 14 22  6  1
> 
> ---
> Do we want  S-compatibility here?
> (At that time, I hated the idea that the return value is so different, just
>  depending on the  plot=.. value).

Hmmm. In S, hist() calls barplot() with

VALUE:
       a non-printing vector which contains the x-coordinates  of
       the  centers  of  the  bars (y-coordinates if the bars are
       horizontal).  The returned value can be used if  you  want
       to add to the plot.

This is actually quite useful for placing labels, etc. However,
presumably you'd want the counts too, so a list containing the union
of the two might be ideal? How about relative frequencies, BTW?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 16:56:15 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 10:56:15 -0600 (CST)
Subject: R-alpha: NextMethod in 0.50-a4
Message-ID: <m0xcvcN-000hhXC@franz.stat.wisc.edu>

I am encountering difficulty with NextMethod in 0.50-a4.  We created a
class of groupedData objects which are data.frames with additional
attributes.  The most important attribute is a formula describing
roles of some of the variables in the experimental design.

The class of such objects ends in "groupedData", "data.frame".  The
print method for the groupedData class simply cat's the formula then
calls NextMethod.  In R this produces a peculiar message about not
being able to find the function print.groupedData which happens to be
the function that is currently being evaluated.  I tried different
forms of the call to NextMethod but to no avail.

The purpose and design of the groupedData class is described in

@InProceedings{	  bate:pinh:1997,
  author	= {Douglas M. Bates and Jos\'{e} C. Pinheiro},
  title		= {Software Design for Longitudinal Data},
  editor	= {Timothy G. Gregoire},
  booktitle	= {Modelling Longitudinal and Spatially Correlated Data:
		  Methods, Applications and Future Directions},
  year		= 1997,
  address	= {New York},
  publisher	= {Springer-Verlag},
  pages		= {37--48}
}

I created an artificial example using the "acid" data so it can be
reproduced by others.  (BTW, the acid.doc file has a misprint.  The
name of the second column is "optden", not "opt".)

 R> data(acid)
 R> acid
   carb optden
 1  0.1  0.086
 2  0.3  0.269
 3  0.5  0.446
 4  0.6  0.538
 5  0.7  0.626
 6  0.9  0.782
 R> class(acid)
 [1] "data.frame"
 R> attr(acid, "formula") <- optden ~ carb
 R> class(acid) <- c("groupedData", "data.frame")
 R> print.groupedData
 function (x, ...) 
 {
	 cat("Grouped Data: ")
	 print(attr(x, "formula"))
	 NextMethod()
 }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod(print, x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod("print", x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 17:49:55 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 18:49:55 +0100
Subject: R-alpha: NextMethod in 0.50-a4
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 10:56:15 -0600 (CST)
References: <m0xcvcN-000hhXC@franz.stat.wisc.edu>
Message-ID: <x27m9nmy7w.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

>  R> acid
>  Grouped Data: optden ~ carb
>  Error: couldn't find function "print.groupedData"

Same thing in my snapshot of 0.60.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 17:55:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 11:55:49 -0600 (CST)
Subject: R-alpha: two-sided to one-sided formula
Message-ID: <m0xcwY1-000hhXC@franz.stat.wisc.edu>

At times we want to convert a two-sided formula to a one-sided
formula.  In S we can do this by dropping the second entry in the
formula.  In R that object no longer has a formula class.
 R> ttt <- score ~ age | Infant
 R> class(ttt)
 [1] "formula"
 R> length(ttt)
 [1] 3
 R> ttt[-2]
 [[1]]
 ~

 [[2]]
 age | Infant

 R> class(ttt[-2])
 NULL
 R> do.call("~", ttt[-(1:2)])
 ~age | Infant

In general it would not be a good idea to propagate the formula class
to subsets but it does make sense in this case.  We can get around it
by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
opinions on whether ttt[-2] should still be a formula?
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 18:21:47 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 19:21:47 +0100
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 11:55:49 -0600 (CST)
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu>
Message-ID: <x267p7mwqs.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> In general it would not be a good idea to propagate the formula class
> to subsets but it does make sense in this case.  We can get around it
> by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> opinions on whether ttt[-2] should still be a formula?

Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
the idea of properties depending on the value of a parameter, so I'm
inclined to say no. BTW,

eval(as.call(ttt[-2]))

also works. And one would *think* that formula(as.call(ttt[-2])) did
too, but typeof(as.call(...))==language and !=call (is this weird or
not?), so formula.default protests.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 18:34:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 02 Dec 1997 12:34:49 -0600
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Peter Dalgaard BSA's message of 02 Dec 1997 19:21:47 +0100
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu> <x267p7mwqs.fsf@blueberry.kubism.ku.dk>
Message-ID: <6rafejiofq.fsf@franz.stat.wisc.edu>

Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

> Douglas Bates <bates@stat.wisc.edu> writes:
> 
> > In general it would not be a good idea to propagate the formula class
> > to subsets but it does make sense in this case.  We can get around it
> > by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> > opinions on whether ttt[-2] should still be a formula?
> 
> Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
> the idea of properties depending on the value of a parameter, so I'm
> inclined to say no. BTW,
> 
> eval(as.call(ttt[-2]))
> 
> also works.

I agree with Peter.  We will change our code.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec  2 19:21:08 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 14:21:08 -0500
Subject: R-alpha: compatability functions
Message-ID: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>

With some input from Martin Maechler and Martyn Plummer I think I now have a
fairly good set of functions for handling R/S and OS differences, however, I
still have two areas where I would appreciate input. These are largely S
problems, not R problems, but I am doing this so I can write code to work on
both.

1/ In Windows I have been trying to identify NT, 95, or 3.1, but Martyn (who
claims to have little experience but has lots more than I do) suggested that
Win16 vs Win32 might be a more important distinction.  Does anyone know about
this? The eventual purpose is to do things like opening a graphics window,
copying a file, deleting a file, getting date info on a file, starting another
process, getting host name info, or sending mail (from an R/S program).  I can
use machine() to define is.Win32 and is.Win16 in R, but does anyone know how to
do this in Splus?

2/ In S it is fairly easy to get information to define functions like
is.Linux(), is.Sun5(), but most of the time I just want to be able to use
is.unix().  I have two approaches, neither of which I like. One is to default to
unix if I don't identify Windows, and the other is to identify all the different
types of unix and then "or" them. Can anyone suggest a better way to define
is.unix() in S.

Paul Gilbert

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

From thomas@biostat.washington.edu  Tue Dec  2 19:31:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Tue, 2 Dec 1997 11:31:39 -0800 (PST)
Subject: R-alpha: compatability functions
In-Reply-To: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>

On Tue, 2 Dec 1997, Paul Gilbert wrote:
> 
> 2/ In S it is fairly easy to get information to define functions like
> is.Linux(), is.Sun5(), but most of the time I just want to be able to use
> is.unix().  I have two approaches, neither of which I like. One is to default to
> unix if I don't identify Windows, and the other is to identify all the different
> types of unix and then "or" them. Can anyone suggest a better way to define
> is.unix() in S.
> 

Doesn't  
	exists("unix") 
work?
	-thomas

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

From pgilbert@bank-banque-canada.ca  Tue Dec  2 20:02:06 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 15:02:06 -0500
Subject: R-alpha: compatability functions
References: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>
Message-ID: <97Dec2.150325est.26691@mailgate.bank-banque-canada.ca>

>Doesn't
>        exists("unix")
>work?

Yes. (At least it is true in unix, I can't verify that it is false otherwise.)
Thanks,
Paul

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

From rgentlem@stat.auckland.ac.nz  Tue Dec  2 21:00:30 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Wed, 3 Dec 1997 10:00:30 +1300 (NZDT)
Subject: R-alpha: Re^2: data file names
Message-ID: <199712022100.KAA25304@stat1.stat.auckland.ac.nz>


> 	[R-devel'ers:  spill over from R-core .. -- MM]
> 
> >>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
> 
> >>>>> Robert Gentleman writes:
>     >> In preparing the next Windows release I want to make opening up
>     >> system data files (and their documentation) more transparent. I
>     >> would really like to adopt the convention that data files use the
>     >> suffix .rdf (.dat seems like it's taken). This will make it easier
>     >> to get the builtin Windows file browsers to work on it and save me
>     >> some considerable work trying to figure out what is and isn't a data
>     >> file.
> 
>     KH> What does `rdf' stand for?
> 
> R Data File ?
> 
> But why can't it just be `.R'  (-> `.r' in the ...OS)?
> 
> At least currently, these are simply files with valid  R code.
> If they would end in `.R', ESS (Emacs Speaks Statistics) would
> automatically be put in the proper mode.
> Of course, we could also use a new ending,
> but I think this would only make sense if the data files would internally
> use a different format,
> e.g.,  data.dump / data.restore, or one which works with  read.table.

I agree with Martin. I would be happy with .R initially and later we could
add other suffixes if we have different data formats. I was just going to
slurp them in through source.
>  
> 
> 
>     >> It would also be nice if one of you great documentation folks
>     >> thought of a html-like format for the .doc files so that I could
>     >> simply pop them up. This would also ideally let index.doc be built
>     >> on the fly....
> yes
> 
>     >> I find it quite frustrating that I can't peek at the doc file while
>     >> trying to decide which data file I want.
> Hmm; in 0.60 we at least have
> 	data()
> for the list
> and
> 	?foodata
> for the doc in foodata.doc.  This does already help me quite a bit..
> 
> 
>     >> I'm hoping to get a browser
>     >> that will let you peruse the documentation while selecting the file.
> 
>     >> Comments/opinions appreciated.
> 
>     KH> You are obviously right.  I think what we want is to have a unified
>     KH> documentation format for both functions (which is what we have
>     KH> until now been focussing on) and variables (``data files'').  In
>     KH> the not too long run, will we be able to attach data directories so
>     KH> that we can really treat the data files as variable objects?
> Do you mean binary data files?  Or would they be `compiled' 
> 	from src/library/<pkg>/data/
> 	to   library/<pkg>/data/  ?
> 
> 
>     KH> Anyway, I just realized that all .doc files now have the structure
> 
>     KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES
> 
>     KH> so it seems that we only need to add \format{} and \source{} to the
>     KH> Rd standard.
> yes; this would be one thing; the other being a script (or a person ..)
> for translating all current the foodata.doc to foodata.Rd ...
> But __YES__ , the earlier, the better  (but ``post release'');
> I'd like to have this BEFORE the following is completely solved ..


I agree post 0.60 release (but somethings will have to slip in to the Windows
release of 0.60. I can't believe how hard it is to keep the two in sync. It 
would be handy if we could put the .R's on the data files before the release.
I could live with messy documentation but I really don't want to drop down
into the nuts and bolts of some of the windows dialog code.

>     KH> And, well, to document the format we really need
>     KH> tables.  FL, MM, what is the right way to do these?
> 
> As with \itemize , \enumerate and \describe
> 	(do they work now in HTML,  Fritz? -- would be nice for release ...).
> HTML and LaTeX are `obvious'
> (we  shouldn't be too fancy, I think, just use a common denominator of
> 	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
>         Fritz will have to look at (a newer version of) latex2html once more)
> and the real problem is  nroff.
>  (yes, I do want to have simple fast online help using C-c C-v in ESS .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 08:00:11 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 09:00:11 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <199712030723.IAA16264@pc25.none> (message from Kurt Hornik on
 Wed, 3 Dec 1997 08:23:24 +0100)
Message-ID: <199712030800.JAA03331@sophie.ethz.ch>

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >>> In preparing the next Windows
    >>> release I want to make opening up system data files (and their
    >>> documentation) more transparent. I would really like to adopt
    >>> the convention that data files use the suffix .rdf (.dat seems
    >>> like it's taken). This will make it easier to get the builtin
    >>> Windows file browsers to work on it and save me some
    >>> considerable work trying to figure out what is and isn't a data
    >>> file.

    MM> But why can't it just be `.R' (-> `.r' in the ...OS)?
    MM> 
    MM> At least currently, these are simply files with valid R code.  If
    MM> they would end in `.R', ESS (Emacs Speaks Statistics) would
    MM> automatically be put in the proper mode.  Of course, we could also
    MM> use a new ending, but I think this would only make sense if the
    MM> data files would internally use a different format, e.g., data.dump
    MM> / data.restore, or one which works with read.table.

    >> I agree with Martin. I would be happy with .R initially and later we
    >> could add other suffixes if we have different data formats. I was
    >> just going to slurp them in through source.

    KH> Shall we try to be consistent about other endings, too?  E.g.,

Yes, why not agree on this, now, even before implementation!
 
    KH> rdf	for R data file/format (data.dump/data.restore)

data.dump/data.restore  is hopefully going to be  S-plus compatible as much
as possible (that's why most of us would want it).
Hence, I think the `R' is really too much there.

Would just

	dmp	still be `free' (in Windoze I mean) ?


    KH> table	for tables

For portability, we'd probably rather need 3 letter expansions...
i.e.
	tab	for tables (to be readable by read.table ?!)
		Note, we have to agree if read.table will be called
		with  (...., header = TRUE)  or not.

		Here, mostly for teaching purposes, we have (almost) all
		our data files in the format

			nam.1  col.2  var.3 ...  var.<p>
			<x11>   <x12>  <x13> ...  <x1p>
			<x21>   <x22>  <x23> ...  <x2p>
			  ..      ..    ..         ..
			  ..      ..    ..         ..
			  ..      ..    ..         ..

		I.e. we don't have `rownames' most of the time and don't
		want to type '1' '2' ... 'n' in front of the variables.

	

	Maybe we should even have

	tab	for the above		 ->  read.table(<file>, header = T)
	tbr	for tables with rownames ->  read.table(<file>)


			col.1  col.2  var.3 ...  var.<p>
		r1	<x11>   <x12>  <x13> ...  <x1p>
		r2	<x21>   <x22>  <x23> ...  <x2p>
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..

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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 11:30:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 12:30:13 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 09:00:11 +0100
References: <199712030800.JAA03331@sophie.ethz.ch>
Message-ID: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Yes, why not agree on this, now, even before implementation!
>  
>     KH> rdf	for R data file/format (data.dump/data.restore)
> 
> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
> as possible (that's why most of us would want it).
> Hence, I think the `R' is really too much there.

I don't think so. The data.dump format is really just an efficient
encoding of the output of dput/dump. It won't be more compatible than
the data structures themselves. That is, unless someone wants to sit
down and catalog all the differences in internal data structures and
do the relevant transformation code....


-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From colin@geology.gla.ac.uk  Wed Dec  3 12:13:24 1997
From: colin@geology.gla.ac.uk (Colin Farrow)
Date: Wed, 3 Dec 1997 12:13:24 GMT
Subject: R-alpha: Two buglets and a difference
Message-ID: <199712031213.MAA24476@alligin.gla.ac.uk>


I have come across three problems in the past few days, in spell of
heavy R ( version  R0.50-a4/Sun Solaris2.5.1 ) use.

1.
I was using lwd=2 to get thicker lines on plots for printing, but
although the 'lwd' parameter works fine with x11(), the thickened lines
do not print with print.plot, or by using postscript() directly.


2.
Try the following,

	plot(1:10, -(1:10))
	mtext("distance", side=3, line=1)

where does the text disappear to, nothing appears on the plot.
The problem relates to the -y in the plot() call, as it works with
plot(1:10, 1:10). This occurs in a function to plot a variable with
 depth (-y), with depth increasing down the y axis.


3.
Less of a bug, more of a difference between implementations

foo <- function(x) {
	paste(substitute(x) )
}


In S
foo(lamp)
	"lamp"
foo(lamp$v)
	"lamp$v"
In R
foo(lamp)
	"lamp"
foo(lamp$v)
	"$" "lamp" "v"


which broke a number of functions I was porting to R

The fix which works in both is
	paste(deparse(substitute(x)))
which is an awful mouthful to get the name of the argument

Colin

--------------------
                     \
Colin Farrow          \
                       \---------------------------------------
                        \                                       \
Department of Geology,   \ E-mail: colin@geology.gla.ac.uk       \
University of Glasgow,    \                                       \
Glasgow, G12 8QQ. Scotland \ Tel: +44 (0)41 339 8855 x5466         \
                            \ Fax: +44 (0)41 330 4817               \
`````````````````````````````````````````````````````````````````````````
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 12:51:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 13:51:03 +0100
Subject: R-alpha: Two buglets and a difference
In-Reply-To: <199712031213.MAA24476@alligin.gla.ac.uk>
 (colin@geology.gla.ac.uk)
Message-ID: <199712031251.NAA03649@sophie.ethz.ch>

>>>>> "Colin" == Colin Farrow <colin@geology.gla.ac.uk> writes:

    Colin> I have come across three problems in the past few days, in spell
    Colin> of heavy R ( version R0.50-a4/Sun Solaris2.5.1 ) use.

thank you for reporting these.

    Colin> 1.  I was using lwd=2 to get thicker lines on plots for
    Colin> printing, but although the 'lwd' parameter works fine with
    Colin> x11(), the thickened lines do not print with print.plot, or by
    Colin> using postscript() directly.

Unfortunately, this is still true for the current source code version
(0.60). 

    Colin> 2.  Try the following,

    Colin> 	plot(1:10, -(1:10)) mtext("distance", side=3, line=1)

    Colin> where does the text disappear to, nothing appears on the plot.
    Colin> The problem relates to the -y in the plot() call, as it works
    Colin> with plot(1:10, 1:10). This occurs in a function to plot a
    Colin> variable with depth (-y), with depth increasing down the y axis.

this is a known bug which is fixed in the upcoming release

    Colin> 3.  Less of a bug, more of a difference between implementations

    Colin> foo <- function(x) { paste(substitute(x) ) }

    Colin> In S
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "lamp$v"

This is not true for my version of S-plus :

> version
Version 3.4 Release 1 for Sun SPARC, SunOS 5.3 : 1996 
> tst3 <- function(x) paste(substitute(x))
> tst3(lamp)
[1] "lamp"
> tst3(lamp$v)
[1] "$"     "lamp"  "\"v\""

    Colin> In R
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "$" "lamp" "v"

    Colin> which broke a number of functions I was porting to R

    Colin> The fix which works in both is paste(deparse(substitute(x)))
    Colin> which is an awful mouthful to get the name of the argument

You can omit the paste(.)  and use

	deparse(substitute(x))

in both cases  which is  THE  recommended way in both R and S, anyway.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 15:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 16:56:31 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 03 Dec 1997 12:30:13 +0100)
Message-ID: <199712031556.QAA03899@sophie.ethz.ch>

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> Yes, why not agree on this, now, even before implementation!
    >> 
    KH> rdf	for R data file/format (data.dump/data.restore)
    >> 
    >> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
    >> as possible (that's why most of us would want it).
    >> Hence, I think the `R' is really too much there.

    PD> I don't think so. The data.dump format is really just an efficient
    PD> encoding of the output of dput/dump.
right!  Actually I never looked at it this way.

    PD> It won't be more compatible than the data structures themselves.

but this will lead to really portable (between S and R) data.dump output
for many cases we want.

    PD> That is, unless someone wants to sit
    PD> down and catalog all the differences in internal data structures and
    PD> do the relevant transformation code....

not really; 
Actually  however, one case we may want to be `compatible' are
factors, since they are part of data.frames.
Factors are somewhat different in R and S
(internally: clear;  in 'dput(.)' -- maybe not necessary).



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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 20:58:07 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 21:58:07 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 16:56:31 +0100
References: <199712031556.QAA03899@sophie.ethz.ch>
Message-ID: <x2ra7ukuu8.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Factors are somewhat different in R and S
> (internally: clear;  in 'dput(.)' -- maybe not necessary).

Hmm:

R:

> dput(gl(4,1,8))
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))
> ff<-structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1",
"2", "3", "4"), 
+         class = "factor")
> dput(ff)
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))

Splus:

> dput(gl(4,1,8))
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")
> ff<-structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4),
+ class = "factor", .Label = c("1", 
"2", "3", "4"))
> dput(ff)
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")

I.e. when R creates a structure based on the output of Splus's dput(factor),
you get the same structure as if you had created the factor directly,
and vice versa. 

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From rgentlem@stat.auckland.ac.nz  Wed Dec  3 20:59:18 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Thu, 4 Dec 1997 09:59:18 +1300 (NZDT)
Subject: R-alpha: Re^3: data file names
Message-ID: <199712032059.JAA02106@stat1.stat.auckland.ac.nz>

I will make the changes needed for .R extensions to the library files
(and the code change given by Martin for 0.60; Ross will roll it out as
soon as we stop making last minute changes).

Currently I use .rmg as an extension for R images. I wasn't planning on
using anything else (but rdf for binary dumps is probably good). I don't
know if we really want to use extensions for tables. I was simply going to
make this a standard file dialog (under windows) followed by a pop-up
that would let you select the defaults for read.table.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec  4 17:23:23 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 4 Dec 1997 18:23:23 +0100
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
Message-ID: <199712041723.SAA05244@sophie.ethz.ch>

and this breaks  multinom from the nnet library
	[yes, Kurt, I'm working on that and I'll send you patches..]	

Is this a bug or an (half-)intentional difference to S ?

---------------------

In R (0.50-0.60)


     model.matrix(formula =, data =)

 Arguments:

   formula: A model formula or terms object

      data: A data frame created with `model.frame'


In S-plus


  USAGE:
       model.matrix(object, ...)
       model.matrix.default(terms.object, data, contrasts)

  ARGUMENTS:

	.....

  contrasts:     an optional list giving contrasts for some or  all
       of  the  factors  appearing  in  the  terms  object.   The
       elements of the list should have  the  same  name  as  the
       variable   and   should   be   either  a  contrast  matrix
       (specifically, any full-rank matrix with as many  rows  as
       there  are  levels  in  the factor), or else a function to
       compute such a matrix given the  number  of  levels.   The
       complete contrast list (anything given as an argument plus
       any  additional  contrast  matrices  computed)   will   be
       returned as the "contrasts" attribute of the model matrix,
       and hence as the "contrasts" component  of  fitted  models
       returned by lm() and its descendants.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From thomas@biostat.washington.edu  Thu Dec  4 17:41:09 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 4 Dec 1997 09:41:09 -0800 (PST)
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
In-Reply-To: <199712041723.SAA05244@sophie.ethz.ch>
Message-ID: <Pine.LNX.3.96.971204093835.5784A-100000@buffy>

On Thu, 4 Dec 1997, Martin Maechler wrote:

> and this breaks  multinom from the nnet library
> 	[yes, Kurt, I'm working on that and I'll send you patches..]	
> 
> Is this a bug or an (half-)intentional difference to S ?
> 

I think it's a bug -- you should be able to specify contrasts on a
model-by-model basis if you really want to.  Fortunately it's very rare
for people to use this feature.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 14:00:45 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 15:00:45 +0100
Subject: R-alpha: Array indexing out of range -- difference to R-minus
Message-ID: <199712051400.PAA06534@sophie.ethz.ch>


> x <- cbind(1,1:3); x
     [,1] [,2]
[1,]    1    1
[2,]    1    2
[3,]    1    3
> x[5:6] <- 10
> x
     [,1] [,2]
[1,]    1    1
[2,]    1   10
[3,]    1   10
> x[5:7] <- 12 #<<<<< loses its dimension, because of `out of range' indexing
> x
[1]  1  1  1  1 12 12 12

     1  2  3  4  5  6  7

---
with S-plus or S4,
	x remains a 3 x 2  matrix;
	it only `silently' grows  *after* being coerced to vector 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Friedrich.Leisch@ci.tuwien.ac.at  Fri Dec  5 14:08:04 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Fri, 5 Dec 1997 15:08:04 +0100
Subject: R-alpha: is.vector of one-dimensional array
Message-ID: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>


maybe we've already diskussed this before, but Kurt and I can't
remember ...

is.vector() of an one-dimensional array returns FALSE. this is also the
behavior of Splus, but totally counter-intuitive for me ... IMO an
array of dimension 1 is exactly the definition of a vector ...

it also breaks our current plot.factor, which is simply a

	barplot(table(x))

table() returns an one-dimensional array, but barplot only accepts
vector and matrix arguments ...

of course one could check additionally for arrays with correct
dimension ... but ...

any opinions?

fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From pgilbert@bank-banque-canada.ca  Fri Dec  5 14:50:47 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 5 Dec 1997 09:50:47 -0500
Subject: R-alpha: is.vector of one-dimensional array
References: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>
Message-ID: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca>

>is.vector() of an one-dimensional array returns FALSE. this is also the
>behavior of Splus, but totally counter-intuitive for me ... IMO an
>array of dimension 1 is exactly the definition of a vector ...

I assume by "one-dimensional array" you mean a two or higher dimensional array
with all but one of the values from dim(x)  being 1. This is possibly
counter-intuitive, but there are cases where one needs to distinguish these.
Perhaps length(dim(x)) would be better, but dim returns NULL  for a vector. This
is even more counter-intuitive to me. I think it should return length(x) for a
vector. In any case there is lots of code out there that will break if you
change these.

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 17:24:25 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 18:24:25 +0100
Subject: R-alpha: is.vector of one-dimensional array
In-Reply-To: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Fri, 5 Dec 1997 09:50:47 -0500)
Message-ID: <199712051724.SAA06827@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    >> is.vector() of an one-dimensional array returns FALSE. this is also
    >> the behavior of Splus, but totally counter-intuitive for me ... IMO
    >> an array of dimension 1 is exactly the definition of a vector ...
not quite exactly.

I think we have agreed that 
	vector
and
	array
are mutually exclusive [i.e., their is.XXX test], 
and actually, the distinction arising by  is.null(dim(.)).


    PaulG> I assume by "one-dimensional array" you mean a two or higher
    PaulG> dimensional array with all but one of the values from dim(x)
    PaulG> being 1.
No, he meant the `rare' thing which table(.) produces 
	-- both in R and S -- 
which has  length(dim(.)) == 1:

> ta <- table(rpois(20,4))
> dim(ta)
[1] 9
> ta
0 1 2 3 4 5 6 7 8 
1 2 4 3 4 2 2 1 1 
> str(ta)
 int [, 1:9] 1 2 4 3 4 2 2 1 1
 - attr(*, "dimnames")=List of 1
  ..$ : chr [1:9] "0" "1" "2" "3" "4" "5" "6" "7" "8"
> 

    PaulG> This is possibly counter-intuitive, but there are cases
    PaulG> where one needs to distinguish these.  Perhaps length(dim(x))
    PaulG> would be better, but dim returns NULL for a vector. This is even
    PaulG> more counter-intuitive to me. I think it should return length(x)
    PaulG> for a vector. In any case there is lots of code out there that
    PaulG> will break if you change these.

Yes! - and we `must' live with these, I think.

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

From plummer@iarc.fr  Mon Dec  8 08:05:04 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Mon, 08 Dec 1997 09:05:04 +0100 (MET)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <XFMail.971208092400.plummer@iarc.fr>

Thanks to the core team for releasing R-0.60. I found a couple of 
bugs.

1) Segfault!
assign(character(0),1)
Fix: Obviously, check the string length. The same problem may occur
in other places but I haven't done an extensive search.
x <- 1
attr(x, character(0)) 


2) The function GStrHeight (graphics.c) uses the conversion factors
for the X axis instead of the Y axis. This causes strangeness in
legend() when the axes are on different scales.
Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with 
fig2dev.by, win2fig.by and ipr[1], respectively.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From ihaka@stat.auckland.ac.nz  Mon Dec  8 09:44:20 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Mon, 8 Dec 1997 22:44:20 +1300 (NZDT)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <199712080944.WAA13846@stat1.stat.auckland.ac.nz>

> From: Martyn Plummer <plummer@iarc.fr>
> To: r-devel@stat.math.ethz.ch
> Subject: R-alpha: Bugs in R-0.60
>
> Thanks to the core team for releasing R-0.60. I found a couple of
> bugs.
>
> 1) Segfault!
> assign(character(0),1)
> Fix: Obviously, check the string length. The same problem may occur
> in other places but I haven't done an extensive search.
> x <- 1
> attr(x, character(0))

	Fixed these two, but there may well be more ...


> 2) The function GStrHeight (graphics.c) uses the conversion factors
> for the X axis instead of the Y axis. This causes strangeness in
> legend() when the axes are on different scales.
> Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with
> fig2dev.by, win2fig.by and ipr[1], respectively.

	Fixed and committed.  Updates in 0.60.2

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 10:05:10 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 11:05:10 +0100
Subject: R-alpha: Bugs in R-0.60 --
In-Reply-To: <199712080944.WAA13846@stat1.stat.auckland.ac.nz> (message from
 Ross Ihaka on Mon, 8 Dec 1997 22:44:20 +1300 (NZDT))
Message-ID: <199712081005.LAA00745@sophie.ethz.ch>

Dear Ross,

>>>>> "Ross" == Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:

    >> From: Martyn Plummer <plummer@iarc.fr> To: r-devel@stat.math.ethz.ch
    >> Subject: R-alpha: Bugs in R-0.60

    >> 1) Segfault!  assign(character(0),1) Fix: Obviously, check the
    >> string length. The same problem may occur in other places but I
    >> haven't done an extensive search.  x <- 1 attr(x, character(0))

    Ross> 	Fixed these two, but there may well be more ...

things like these  remind me once more  
how very useful it would be to have an option like
	-dont-stop-on-error
for R (batch).

We could have many tests like these in a few  'test' files that would be
run through R...; 
Actually, I'm thinking of auto-generated function calls where most would
give  'Error: ..'  but none should give  segfault...

This could help very much to autodetect problems like these.

- Martin.




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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 11:13:37 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 12:13:37 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
Message-ID: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>



The function tapply is not working in the Windows version of R=20
(Version 0.50 Beta (Sept 29, 1997))

In

tapply <- function (x, INDEX, FUN=3DNULL, simplify=3DTRUE, ...)=20
...

The part:

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		names(ans)<-namelist[[1]]
		return(ans)
	}

should be replaced by

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		if(length(INDEX) =3D=3D 1) {
		names(ans) <- namelist[[1]]
		}
		else {
		dim(ans) <- extent
		dimnames(ans) <- namelist
		}
		return(ans)
	}

Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 11:30:08 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 12:30:08 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be> (message
 from Comblain muriel on Mon, 08 Dec 1997 12:13:37 +0100)
Message-ID: <199712081130.MAA00841@sophie.ethz.ch>

Dear Muriel,

the current Unix version of R, 0.60,
has the following definition of  tapply(.).

Can you check if it works for your examples?
If not, please send us a complete example (i.e. with input data, we can
regenerate).
Thank you for your report!

tapply <- function (x, INDEX, FUN=NULL, simplify=TRUE, ...) 
{
	if (is.character(FUN)) 
		FUN <- get(FUN, mode = "function")
	if (!is.null(FUN) && mode(FUN) != "function") 
		stop(paste("'", FUN, "' is not a function",sep=""))
	if (!is.list(INDEX)) INDEX <- list(INDEX)
	nI <- length(INDEX)
	namelist <- vector("list", nI)
	extent <- integer(nI)
	nx <- length(x)
	group <- rep(1, nx)#- to contain the splitting vector
	ngroup <- 1
	for (i in seq(INDEX)) {
		index <- as.factor(INDEX[[i]])
		if (length(index) != nx) 
			stop("arguments must have same length")
		namelist[[i]] <- levels(index)#- all of them, yes !
		extent[i] <- nlevels(index)
		group <- group + ngroup * (codes(index) - 1)
		ngroup <- ngroup * nlevels(index)
	}
	if (is.null(FUN)) return(group)
	ans <- lapply(split(x, group), FUN, ...)
	if (simplify && all(unlist(lapply(ans, length)) == 1)) {
		ansmat <- array(dim=extent, dimnames=namelist)
		ans <- unlist(ans, recursive = FALSE)
	}
	else  {
		ansmat <- array(vector("list", prod(extent)),
			dim=extent, dimnames=namelist)
	}
	ansmat[as.numeric(names(ans))] <- ans
	ansmat
}

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Mon Dec  8 12:08:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 08 Dec 1997 13:08:13 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: Comblain muriel's message of Mon, 08 Dec 1997 12:13:37 +0100
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <x2ra7oghqq.fsf@blueberry.kubism.ku.dk>

Comblain muriel <Muriel.Comblain@ulg.ac.be> writes:

> The function tapply is not working in the Windows version of R 
> (Version 0.50 Beta (Sept 29, 1997))
> 
..
> The part:
...
> should be replaced by
...

Thanks. One thing though:

Please, and this goes for everyone, remember to state the objective of
your fixes.

I think we know what this fix is about (the tapply(x,f,summary)
problem, right?), but this is not stated in your letter. As Martin
points out, the code has subsequently changed in the development
version and we have difficulty seeing whether it solves your problem
or not.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 15:58:45 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 16:58:45 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <199712081130.MAA00841@sophie.ethz.ch>
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <3.0.1.32.19971208165845.009538c0@pop3.mailst.ulg.ac.be>

At 12:30 08/12/97 +0100, Martin Maechler wrote:
>Dear Muriel,
>
>the current Unix version of R, 0.60,
>has the following definition of  tapply(.).
>
>Can you check if it works for your examples?
>If not, please send us a complete example (i.e. with input data, we can
>regenerate).
>Thank you for your report!
>
>...

I checked this form of the tapply function coming from the current unix
version (0.60) on my examples and it worked perfectly as well as the fix I
proposed. Sorry if my mail was not completely clear, I will try to do
better next time and thank you for your help.

=20
Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From pgilbert@bank-banque-canada.ca  Wed Dec 10 15:40:32 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 10 Dec 1997 10:40:32 -0500
Subject: R-alpha: "[.ts" in 0.60.1
Message-ID: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>

I have a class "tframe" with more specific classes indicating how time is being
represented, such as

> class(tframe(data))
[1] "ts"     "tframe"

but now "[.ts" produces warning messages

> tframe(data)[2]
Warning: Not returning a time series object
[1] 2006.25

Even my simplest tests produce hundreds of lines of warnings, so I've commented
out the line
#                        warning("Not returning a time series object")
in "[.ts". I'm not sure if this is the best solution, but something is
necessary.

Paul Gilbert

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







From alchemy@inconnect.com  Thu Dec 11 07:53:27 1997
From: alchemy@inconnect.com (Anthony Chavez)
Date: Thu, 11 Dec 1997 00:53:27 -0700 (MST)
Subject: R-alpha: Re: R-beta: time series structures
In-Reply-To: <348F139A.8032984A@stat.unipg.it>
Message-ID: <Pine.SOL.3.96.971211005155.12804C-100000@ultra1>

Please edit headers and keep non-announce topic off the R-announce list.  Some
of us are subscribed to R-announce for a *reason*.

--
-------------------------------------------------------------------------------
Anthony Chavez                 o   \o/  _ o          o    o-o  +===+  o   +===+
                              /|\   |    /\    __\o o_|   \ /  |   | /|\  |   |
alchemy@inconnect.com         / \  / \  | \   /) |   \\o  \|   |~~~| Co-"=|~~~|
Salt Lake City, Utah          o-o  o-o  o-o  o-o        \  o\  |___| / \  |___|

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:31:51 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:31:51 +0100
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
Message-ID: <199712110831.JAA00252@pc25.none>

>>>>> Paul Gilbert writes:

> I've been reviewing how the make process for my library should be set
> up and I noticed that the "How Can I Create an R Package?" part of the
> FAQ gives instructions to put a Makefile in pkg/src but the "How Can
> Add-on Packages Be Installed?" part of the FAQ does not seem to give
> any indication that a make may be necessary, unless
>      $ R INSTALL pkg lib
> does a make, which I don't think it does.

> Also, this Makefile has to be passed config information, so it must be
> called some way from the main R Makefile I think, but I don't see
> exactly how this is suppose to work, especially if the library is not
> under R/library. Can someone explain this?

Thomas already answered the above.

> A related question is that I am looking for a general strategy for
> distributing code which may get installed under R or S. To date, I
> have been working with one Makefile, which has different targets for R
> or for S. Obviously, the procedure for installing this is not quite as
> simple as suggested for add on packages in the FAQ. Does anyone have
> suggestions for a good way to organize this?

Under R, you need to organize everything as detailed in the FAQ.  There
is no need for a top-level Makefile, so you could use this for taking
care of the R- (S) part [having hinstall and qinstall or whatever they
are called targets].

However, keep in mind that in the long run, all R SOURCE files will need
to have a `.R' extension (as of 0.60, this is already a must for data).

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:43:55 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:43:55 +0100
Subject: R-alpha: libraries
In-Reply-To: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
References: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
Message-ID: <199712110843.JAA00277@pc25.none>

>>>>> Paul Gilbert writes:

> I have been trying to set up my time series library with the new
> library mechanism. It is a fairly large amount of code and previously
> I split it into five pieces in order to load it into R. (Has anything
> changed which might suggest I shouldn't need to do this anymore?)  The
> five files are called dse1, dse2, dsex1, dsex2, and tframe.With the
> new way of handling libraries I put these in
> /home/res/gilp/dse/pub/Rdse/R and ran

> [58] /home/res/gilp/dse/pub : R INSTALL Rdse dse1
> Installing package `Rdse' ...
> R
> DONE
> No man pages found in package `Rdse'

> (BTW this prepend $pwd to Rdse and does not seem to like a fully
> qualified path for the location, so it has to be done in the directory
> above Rdse)

> Indications seem to be that this worked (except for the man pages), but when I
> set RLIBS and run R the library is not found:
>> library()
> Packages in library `/home/res/gilp/dse/pub/Rdse':

> Packages in library `/home/res8/gilp/R-versions/R-0.60.1/R-0.60.1/library':
> ...

> However, if I call one of the files Rdse and do
> R INSTALL Rdse Rdse

> then things seem to work correctly in that it finds that file. Does
> this mean that the file with the code must have the same name as the
> package name, which must be the same as the directory name?
> (i.e. .../pkg/R/pkg) Does this mean that I have to create separate
> library directories for each of the pieces?

There is a bug in the R 0.60 INSTALL mechanism that will be fixed in the
next release.

What you are talking about is splitting a PACKAGE into separate MODULES
(Core Team, correct me if I am wrong, was this the term we agreed on?).
This would result in an extension of the current INSTALL and library()
scenario that I would very much appreciate.

Re loading, my idea was to have

	library(MODULE, pkg = PACKAGE, lib = LIBRARY)

or something similar which would allow you to load the module from the
package in the library.  Of course, the inferface is open for
discussion.

Re installing, this is not do easy.  One could have a Makefile in the
`R' subdir indicating how to combine the various .R files into modules,
but I am not quite sure how to do this right.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 08:49:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 09:49:03 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Wed, 10 Dec 1997 10:40:32 -0500)
Message-ID: <199712110849.JAA04605@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    PaulG> I have a class "tframe" with more specific classes indicating
    PaulG> how time is being represented, such as

    >> class(tframe(data))
    PaulG> [1] "ts" "tframe"

    PaulG> but now "[.ts" produces warning messages

    >> tframe(data)[2]
    PaulG> Warning: Not returning a time series object [1] 2006.25

    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
    PaulG> I've commented out the line # warning("Not returning a time
    PaulG> series object") in "[.ts". I'm not sure if this is the best
    PaulG> solution, but something is necessary.

I agree that this can be a pain.
On the other hand, I think it can be very helpful to get this warning
when you subscript a time-series and don't get one anymore.

I think we want
 1) No warning if only one element of a time-series is chosen
	(however, even this is debatable:
	 Think of a function containing code
		i <- !is.na(...) && a < b
		result.ts <- my.ts[i]

	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

 2) A warning otherwise -- which can be turned off ---
    I propose to create an option (one of `options()') to handle this.

Another -- maybe even better -- alternative :
We introduce an argument
				drop = TRUE
as for arrays.
Then the warning would only happen in the case  drop = FALSE
when it was really impossible to make an (equispaced) ts out of the
subscripted one.

------------------------------------------------------------

BTW: does anyone care if I completely drop the  "R-alpha:" string
						 --------
     that is automagically prepended to the subject on R-devel
	(unless it's already part of the subject) ?

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 09:05:48 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 10:05:48 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <199712110849.JAA04605@sophie.ethz.ch>
References: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>
 <199712110849.JAA04605@sophie.ethz.ch>
Message-ID: <199712110905.KAA02711@pc25.none>

>>>>> Martin Maechler writes:

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
PaulG> I have a class "tframe" with more specific classes indicating
PaulG> how time is being represented, such as

>>> class(tframe(data))
PaulG> [1] "ts" "tframe"

PaulG> but now "[.ts" produces warning messages

>>> tframe(data)[2]
PaulG> Warning: Not returning a time series object [1] 2006.25

PaulG> Even my simplest tests produce hundreds of lines of warnings, so
PaulG> I've commented out the line # warning("Not returning a time
PaulG> series object") in "[.ts". I'm not sure if this is the best
PaulG> solution, but something is necessary.

> I agree that this can be a pain.
> On the other hand, I think it can be very helpful to get this warning
> when you subscript a time-series and don't get one anymore.

> I think we want
>  1) No warning if only one element of a time-series is chosen
> 	(however, even this is debatable:
> 	 Think of a function containing code
> 		i <- !is.na(...) && a < b
> 		result.ts <- my.ts[i]

> 	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

>  2) A warning otherwise -- which can be turned off ---
>     I propose to create an option (one of `options()') to handle this.

> Another -- maybe even better -- alternative :
> We introduce an argument
> 				drop = TRUE
> as for arrays.
> Then the warning would only happen in the case  drop = FALSE
> when it was really impossible to make an (equispaced) ts out of the
> subscripted one.

This is not MAYBE better, but what we really should do.  It conforms
to the general logic of subscripting as was agreed upon.

> ------------------------------------------------------------

> BTW: does anyone care if I completely drop the  "R-alpha:" string
> 						 --------
>      that is automagically prepended to the subject on R-devel
> 	(unless it's already part of the subject) ?

No, of course not.

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

From plummer@iarc.fr  Thu Dec 11 10:02:05 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Thu, 11 Dec 1997 11:02:05 +0100 (MET)
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
Message-ID: <XFMail.971211111648.plummer@iarc.fr>

On 11-Dec-97 maechler@stat.math.ethz.ch wrote:
>>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
>
>    PaulG> I have a class "tframe" with more specific classes indicating
>    PaulG> how time is being represented, such as
>
>    >> class(tframe(data))
>    PaulG> [1] "ts" "tframe"
>
>    PaulG> but now "[.ts" produces warning messages
>
>    >> tframe(data)[2]
>    PaulG> Warning: Not returning a time series object [1] 2006.25
>
>    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
>    PaulG> I've commented out the line # warning("Not returning a time
>    PaulG> series object") in "[.ts". I'm not sure if this is the best
>    PaulG> solution, but something is necessary.
>
>I agree that this can be a pain.
>On the other hand, I think it can be very helpful to get this warning
>when you subscript a time-series and don't get one anymore.
>
>I think we want
> 1) No warning if only one element of a time-series is chosen
>       (however, even this is debatable:
>        Think of a function containing code
>               i <- !is.na(...) && a < b
>               result.ts <- my.ts[i]
>
>        wouldn't you want to be warned if `result.ts' is not a ts anymore? )
>
> 2) A warning otherwise -- which can be turned off ---
>    I propose to create an option (one of `options()') to handle this.
>
>Another -- maybe even better -- alternative :
>We introduce an argument
>                               drop = TRUE
>as for arrays.
>Then the warning would only happen in the case  drop = FALSE
>when it was really impossible to make an (equispaced) ts out of the
>subscripted one.

Sorry this is my fault. I suggested this code because the previous
version of [.ts<- did not allow you to subscript time series at all
without unclassing them.  The current version at least tries to preserve
time series objects.  I think what we really need is an irregular time
series class like the S-PLUS "its". Then array subscripting can do the
right thing, and do it silently. In the absence of such a class in R,
I put the warning in.  The message could be translated as "fix me", so
I'm glad you brought it up.

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

From steuer@gigamain.Statistik.Uni-Dortmund.DE  Thu Dec 11 10:21:09 1997
From: steuer@gigamain.Statistik.Uni-Dortmund.DE (Detlef Steuer)
Date: Thu, 11 Dec 1997 11:21:09 +0100 (MET)
Subject: R-alpha: fft does not act as described in help(fft)
Message-ID: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>

Hello!

thank you for your efforts creating R!

While preparing the next lessons I found that I had
to multiply with 1/length(x) by hand if I want to 
get the inverse Fouriertransform.

The help states it will do it by itself.

Version R-0.60.1, Linux

Seems to be pretty easy to correct either the fft or :-) the help(fft)!

Cu Detlef


Detlef Steuer Universitaet Dortmund	                	///////
LS Computergestuetzte Statistik         		 U N I D O ///  
steuer@gigamain.statistik.uni-dortmund.de         	______///////  
Tel: ++49 +231 755 3139 Fax: ++49 +231 755 4387         \_\_\_\/////
						         \_\_\_\///
						          \_\_\_\/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 11 11:37:27 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 11 Dec 1997 12:37:27 +0100 (MET)
Subject: R-alpha: core dumped when reloading a library
Message-ID: <Pine.OSF.3.96.971211123003.3031A-100000@alpha>

I am currently finalising the writing of a library named "stable".
When I consider the following sequence

> library(stable)
> detach("package:stable")
$ R INSTALL stable    (after some correction in my library)
>library(stable)
> dstable(0)      # computation of the stable density density at 0

I get a core dumped.

Can this be avoided?
 Philippe

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

From pgilbert@bank-banque-canada.ca  Thu Dec 11 16:46:37 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 11:46:37 -0500
Subject: R-alpha: Re: R-beta: R FAQ v0.60
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca> <199712110831.JAA00252@pc25.none>
Message-ID: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>

>However, keep in mind that in the long run, all R SOURCE files will need
>to have a `.R' extension (as of 0.60, this is already a must for data).

Does this mean that files like, for example, ../R/library/mva/R/mva should be
called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
the file name must end in .R? If the latter is being suggested then I object
very strongly. While this is a useful convention it is not something which
should be forced. The programs I use which do this are a real pain. If S where
to do a similar thing (.S) then I would be forced to maintain a complete
duplicate set of files (or use links which is also a pain).

(I haven't got as far as loading my data, so I may report on that later.)

Paul Gilbert

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

From thomas@biostat.washington.edu  Thu Dec 11 17:05:25 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 09:05:25 -0800 (PST)
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:
> >However, keep in mind that in the long run, all R SOURCE files will need
> >to have a `.R' extension (as of 0.60, this is already a must for data).
> 
> Does this mean that files like, for example, ../R/library/mva/R/mva should be
> called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> the file name must end in .R? 

It only applies to package source code: so

src/library/SOMEPKG/R/file	should be 
src/library/SOMEPKG/R/file.R    and 
src/library/SOMEPKG/data/datafile      should be
src/library/SOMEPKG/data/datafile.R    

for the installer to install them.

Similarly, the documentation must be in .Rd files

This has the benefit of ignoring things like emacs backup files while you
are developing a package, and of making packages easier to understand
(possibly).

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 17:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 18:56:31 +0100
Subject: R-alpha: fft does not act as described in help(fft)
In-Reply-To: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>
 (message from Detlef Steuer on Thu, 11 Dec 1997 11:21:09 +0100 (MET))
Message-ID: <199712111756.SAA05761@sophie.ethz.ch>

>>>>>  Detlef Steuer <steuer@gigamain.Statistik.Uni-Dortmund.DE> writes:

    Detlef> Hello!  thank you for your efforts creating R!

Thank you for reporting the inaccuracy!

Please ``R-develer''s,  keep these reports flowing..!

    Detlef> While preparing the next lessons
(which lessons? -- I am curious)
    Detlef> I found that I had to multiply
    Detlef> with 1/length(x) by hand if I want to get the inverse
    Detlef> Fouriertransform.

    Detlef> The help states it will do it by itself.

    Detlef> Seems to be pretty easy to correct either the fft or :-) the
    Detlef> help(fft)!

I corrected the  help(fft).  It is now clear about NOT dividing and
gives an example showing how the inverse is got from ``inverse = TRUE''

The current behavior is the same as S, 
and we do want this in these basic things.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Thu Dec 11 18:46:44 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 13:46:44 -0500
Subject: R-alpha: inheritance ([.ts)
Message-ID: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>

While commenting out the previously mentioned warning seems to work, I have been
reflecting on this problem and there seems to be an issue wrt inheritance that I
do not understand properly. Perhaps some gurus could comment.

As mentioned previously, I have a class "tframe" with more specific classes
indicating how time is being represented, such as
> class(tframe(data))
[1] "ts"     "tframe"
and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].

Now tframe(data) is NOT a "ts", it is a specific kind of "tframe". When I coded
this I was expecting it would use  "[.default", so to date I guess it has just
been working accidentally.

Does the fact that there is a class "ts" mean that one should not have another
class with "ts" as its more specific class? This seems like a pretty severe
limitation.

Paul Gilbert




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

From thomas@biostat.washington.edu  Thu Dec 11 18:59:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 10:59:39 -0800 (PST)
Subject: R-alpha: inheritance ([.ts)
In-Reply-To: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211105108.14909B-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:

> While commenting out the previously mentioned warning seems to work, I have been
> reflecting on this problem and there seems to be an issue wrt inheritance that I
> do not understand properly. Perhaps some gurus could comment.

There is no real "inheritance" mechanism in R.  Objects have a list of
classes, and UseMethod/NextMethod search this list from left to right,
pasting the class name on to the generic method name, until a function is
found. The ability to mimic inheritance relies on class names being
unique, so that, for example gee inherits from glm which inherits from lm.


> As mentioned previously, I have a class "tframe" with more specific classes
> indicating how time is being represented, such as
> > class(tframe(data))
> [1] "ts"     "tframe"
> and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].
 
> Does the fact that there is a class "ts" mean that one should not have another
> class with "ts" as its more specific class? This seems like a pretty severe
> limitation.

Yes it does. It is a limitation especially as there is only one namespace.
It is also unfortunate that a lot of people have used method-like names
the other way around, so that eg cox.zph is a proportional hazards test (z
ph) for a cox model, not a "cox" for a "zph" object.

The fix to this is to use something like 
	c("ts.tsframe", "tsframe")
for a more specific ts subclass of tsframe.  It's a bit ugly, but it
works.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 12 08:52:34 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 12 Dec 1997 09:52:34 +0100
Subject: probability and random numbers -- I'm looking at Brown's dcdflib
Message-ID: <199712120852.JAA06458@sophie.ethz.ch>

I'm looking at Brown's dcdflib
	(announced on S-news a few days ago)
in order to get code for  noncentral t and F   into R;
also the noncentral chisq is still not complete.

If anyone is particularly knowledgable in this field
or interested in testing, please let me know.
	(this is NOT a high priority project,
	 but I write to you in order to  coordinate work).

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/


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

From phlamber@luc.ac.be  Fri Dec 12 09:25:22 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Fri, 12 Dec 1997 10:25:22 +0100 (MET)
Subject: files ending by .R in packages
In-Reply-To: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>
Message-ID: <Pine.OSF.3.96.971212101301.16955B-100000@alpha>



On Thu, 11 Dec 1997, Thomas Lumley wrote:

> On Thu, 11 Dec 1997, Paul Gilbert wrote:
> > >However, keep in mind that in the long run, all R SOURCE files will need
> > >to have a `.R' extension (as of 0.60, this is already a must for data).
> > 
> > Does this mean that files like, for example, ../R/library/mva/R/mva should be
> > called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> > the file name must end in .R? 
> 
> It only applies to package source code: so
> 
> src/library/SOMEPKG/R/file	should be 
> src/library/SOMEPKG/R/file.R    and 
> src/library/SOMEPKG/data/datafile      should be
> src/library/SOMEPKG/data/datafile.R    
> 
> for the installer to install them.
> 

Personnally, I would appreciate that .r source files are also considered
when installing a package, as a .R file copied on a msdos floppy disk
becomes a .r file.

Philippe

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

From rossetti@stat.unipg.it  Fri Dec 12 20:47:58 1997
From: rossetti@stat.unipg.it (Andrea Rossetti)
Date: Fri, 12 Dec 1997 21:47:58 +0100
Subject: R-beta: new executable
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz>
Message-ID: <3491A2FE.55C098CF@stat.unipg.it>

Robert Gentleman wrote:

> I have just put up a new executable as a replacement for the one in
>   rseptbeta.zip
>  there have only been a few changes; mostly to the menu's. I am about
>  to start on a major overhaul including getting survival to work and
>  grabbing the 0.60 version once it's stable.
>
> --->> Please let me know about other enhancements you want....<<---

I'm very interested in time series anlaysis (acf, pacf, arima modelling, and all
other) is a possible enhancement for the WINDOWS 95 version of R!(?)

Thanks.

Andrea Rossetti.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Sat Dec 13 22:23:13 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Sat, 13 Dec 1997 23:23:13 +0100
Subject: time series software: more basic functions,  who?
In-Reply-To: <3491A2FE.55C098CF@stat.unipg.it> (message from Andrea Rossetti
 on Fri, 12 Dec 1997 21:47:58 +0100)
Message-ID: <199712132223.XAA14687@jessica.ethz.ch>

Caro Andrea,

si e possibile, prego, uilizi soltanto un solo dei gruppi  R-...
Questo va per il mio italiano...

Apropos Time Series Software, there's not much in the latest version
0.60.1,  for unix either.

Since there are several people interested in having time series functions
available, I'd propose  some of you `stand up' and say:
	I'll do this...
and then post code to R-devel.
Or alternatively, send it to Ross  (who had started on some of these some
months ago...)
or someone else who coordinates these.
What do you think?
Paul Gilbert, I think this complementary to your  DSE library?
If not, we should maybe wait till DSE is available as R package
(how ?) soon.

Who is interested in doing work here?
please reply to me, and I'll collect and summarize to R-devel.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 19:21:25 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 14:21:25 -0500
Subject: RedHat 5.0 Linux libc to glibc
Message-ID: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>

This was posted on another list I follow and I thought it might be important if
you are not already aware of the change:

>Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
>glibc version 2.0 as the standard C library. This arranges its include
>files differently and has resulted in MOST programs needing changes to
>compile under Redhat 5.0.

Paul Gilbert


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

From bates@stat.wisc.edu  Tue Dec 16 20:26:09 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 16 Dec 1997 14:26:09 -0600
Subject: RedHat 5.0 Linux libc to glibc
In-Reply-To: Paul Gilbert's message of Tue, 16 Dec 1997 14:21:25 -0500
References: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>
Message-ID: <6rpvmxhw66.fsf@franz.stat.wisc.edu>

Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

> This was posted on another list I follow and I thought it might be important if
> you are not already aware of the change:
> 
> >Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
> >glibc version 2.0 as the standard C library. This arranges its include
> >files differently and has resulted in MOST programs needing changes to
> >compile under Redhat 5.0.

The changes between Debian GNU/Linux versions 1.3 and 2.0 are also
primarily a change from libc5 to libc6 (a.k.a. glibc 2).   R-0.60.1
compiles cleanly under either.  There is no need for changes in the
source code for R.  I would expect that the same would be true under
RedHat.

I would be very interested in contacting people who are running RedHat 
5.0 to see if the version of libc6 on RedHat still has a problem with
the ecvt system function.   I reported a bug on that several months
ago and the libc6 versions I am using still have the same bug.

Here is a C source file that exercises the bug
#include <stdio.h>
#include <stdlib.h>

void main(int argc, char **argv)
{
  int decpt, sign; char * result;
  char buf[256];
  result = ecvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = gcvt((double) 1234.567, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) -987.654321, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) 0, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
}

When compiled and run it produces obviously incorrect results.
result is 11234.567, decpt is 4, sign is 0
result is 9987.6543, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result is 11234.567000, decpt is 4, sign is 0
result is 9987.654321, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result of gcvt is 1234.567
result of gcvt is -987.6543
result of gcvt is 0

For one thing the string returned as the result should not contain a
decimal point.  Is someone is running RedHat 5.0 could you check the
results on there?
-- 
Douglas Bates                            bates@stat.wisc.edu
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 20:08:38 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 15:08:38 -0500
Subject: time series
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz> <3491A2FE.55C098CF@stat.unipg.it>
Message-ID: <97Dec16.152847est.26753@mailgate.bank-banque-canada.ca>

>I'm very interested in time series anlaysis (acf, pacf, arima modelling, and
>all other) is a possible enhancement for the WINDOWS 95 version of R!(?)

I am still hoping to make a Unix version of my DSE library available this week.
If I don't make it then it will be after the New Year as I'm away for two weeks.
I will make all the source code available, so the only real sense in which this
is a Unix version is that the installation procedures are set up for Unix.

The library does a lot of linear, time-invariant, vector ARIMA and state space
stuff, but does not do ar, acf, pacf or arima.mle as supplied in Splus. Below is
a rough start at ar and acf, but they are not yet working right. If anyone is
interested in finishing them I would be very happy. I haven't tried pacf and
I've never had any interest in arima.mle as it did not work for vector series.

The library should work (with the exception of a few non-critical  functions) in
the existing Windows version of R, as I had most of it working in an older
version under Linux. I was going to wait until Robert has the Window version up
to 0.60, but the main problem is that I have little familiarity with Windows. So
if anyone wants to work on that, again, I would be more than happy.

There is a stand alone subset of the library (I call tframe) which is a kernel
for my other code.  I'm fairly sure this work in the Windows version of R. This
provides a "classes and methods" way of handling the time dimension of an
object,  which I think is very useful for making  code that can fairly easily
handle new time representations. It also provides a replacement for tsmatrix and
some plotting routines which are useful for time series.

Paul Gilbert
___________

ar.test <-function(x, aic=T, order.max=2, method="yule-walker")
   {# this seems to work, in the sense of producing estimates which are
    # asymtotically as good as (or as bad as) Splus ar, at least for
    # stationary data. But estimates are not the same.
    # For non-stationary data Splus ar does better, but neither method is really
valid.
    if(method=="burg") stop("burg method for ar not yet implemented.")
    warning(" ar function not complete and not checked & default order.max=2.")
    if (is.vector(x))x <- matrix(x, length(x),1)
    sampleT <- nrow(x)
    if (is.null(order.max)) order.max <- round(10*log10(sampleT/ncol(x)))
    AC <- array(NA, c(order.max+1, ncol(x), ncol(x)))
x <- unclass(x)
tsp(x) <-NULL
    x <- x - t(array(apply(x,2,sum)/nrow(x), rev(dim(x))))
    for (i in 0:order.max)
   {Om<- (t(x[(i+1):sampleT,,drop=F]) %*%
                   x[1:(sampleT-i),,drop=F])/(sampleT-i)
 #   Om<- cor(x[(i+1):sampleT,,drop=F],
        #            x[1:(sampleT-i),,drop=F]) # cor seems better than var
       #    if(i==0) Om0 <- solve(Om)
       #                     # nrow above for univariate case
       #    Om <- Om0 %*% Om  #Yule-Walker eqn. should solve without this
           AC[i+1,,] <-  Om
          }

   # now solve yule walker eqns.
   n <- ncol(x)
   a <- matrix(NA, n*(order.max), n*(order.max) )
   b <- matrix(NA, n*(order.max), n )
   # using AC[1,,] in place of I
   # there must be a better way (with outer?)
    for (i in 0:(order.max-1))
       for (j in 0:(order.max-1))
   a[(1+i*n):(n+i*n),(1+j*n):(n+j*n)] <- AC[abs(i-j)+1,,]
    for (i in 1:order.max)
   b[(1+(i-1)*n):(i*n),] <- AC[i+1,,]
   AR <-solve(a, b)
   if (n==1) AR <- matrix(AR, length(AR), 1)
   #AR <- solve(t(a),b) # the off-diag values may require this??
 #  ar <- aperm(array(AR,c(dim(AC)-c(1,0,0))), c(2,1,3))
    ar <- array(NA, c(order.max, ncol(x), ncol(x)))
    for (i in 1:order.max)
 ar[i,,] <- AR[(1+(i-1)*n):(i*n),]
   order <- order.max # need aic here
   list(ar=ar, order=order, order.max=order.max, method=method)
   }


acf <-function (residual, plot = F, type = "correlation")
       {if (plot) warning(" acf plot not yet supported.")
        if(0==charmatch(type,c("covariance","correlation","partial"),nomatch=0))

             stop("type not allowed in acf")
        if (is.vector(residual))residual <- matrix(residual, length(residual),1)

 sampleT <- nrow(residual)
        N <- round(10*(log10(sampleT)-log10(ncol(residual))))
        acf <- array(NA, c(N, ncol(residual), ncol(residual)))
 for (i in 0:(N-1))
   {Om<- cov(residual[(i+1):sampleT,,drop=F],
                    residual[1:(sampleT-i),,drop=F])
           if (type=="correlation")
                {if(i==0) Om0 <- diag(1/sqrt(diag(Om)),nrow=nrow(Om))
                            # nrow above for univariate case
                 Om <- Om0 %*% Om %*% Om0
                }
           acf[i+1,,] <-  Om
          }
        if (type=="partial")
          {warning("acf type partial not yet supported. 0 value being returned")

           acf <- array(0, dim(acf))
          }
 list(acf=acf, type=type )
       }


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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 10:28:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 11:28:31 +0100
Subject: "'" prints as "\'"
Message-ID: <199712171028.LAA01254@sophie.ethz.ch>

(This reported before).
In R,
	"'"
prints as

[1] "\'"

which is different from S, and is really unnecessary.
((it is just now uglyfying the output of a function which I wrote for S
  and now use in R)).

Is there any good reason for the current behavior?

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 10:38:00 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 11:38:00 +0100
Subject: "'" prints as "\'"
In-Reply-To: <199712171028.LAA01254@sophie.ethz.ch>
References: <199712171028.LAA01254@sophie.ethz.ch>
Message-ID: <199712171038.LAA04074@pc25.none>

>>>>> Martin Maechler writes:

> (This reported before).
> In R,
> 	"'"
> prints as

> [1] "\'"

> which is different from S, and is really unnecessary.
> ((it is just now uglyfying the output of a function which I wrote for S
>   and now use in R)).

> Is there any good reason for the current behavior?

Yes.  To have ESS font-lock the output correctly.

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

From rossini@math.sc.edu  Wed Dec 17 14:57:25 1997
From: rossini@math.sc.edu (Anthony Rossini)
Date: 17 Dec 1997 09:57:25 -0500
Subject: "'" prints as "\'"
In-Reply-To: Kurt Hornik's message of "Wed, 17 Dec 1997 11:38:00 +0100"
References: <199712171028.LAA01254@sophie.ethz.ch> <199712171038.LAA04074@pc25.none>
Message-ID: <wncvhwoqap6.fsf@fhat.stat.sc.edu>


>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >> (This reported before).
    >> In R,
    >> "'"
    >> prints as

    >> [1] "\'"

    >> which is different from S, and is really unnecessary.
    >> ((it is just now uglyfying the output of a function which I wrote for S
    >> and now use in R)).

    >> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

Poor justification.  I'll look into this more in Feb/Mar...

best,

-- 
-tony (Anthony Rossini)	           Statistics Dept., U South Carolina
rossini@stat.sc.edu	           Columbia, SC 29208
http://www.stat.sc.edu/~rossini/   803-777-3578(O) 803-777-4048 (fax)  
        "'Bother,' said Pooh, as Cthulhu rose up and ate him."
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Wed Dec 17 16:05:16 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 11:05:16 -0500
Subject: library/data
Message-ID: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>

I have some data files with my library which are used for examples and testing
the code. To date I have kept them in a subdirectory I called ../dse/dsedata,
but I am trying to move those to .../dse/data as perscribed for installing
libraries. However, these datasets are not all R object, some are just files
that I source from within a function, and one is accessed by a separate process
that I call from R.

1/ Should the data subdirectory be reserved for R objects?

2/ Could someone explain or point me to were I can find the explanation of how R
objects in this data subdirectory should be constructed? Are these objects
automatically loaded when a library is loaded?

3/ To date I have been able to find my subdirectory by setting a variable
indicating its location in the library file from which code is loaded.
Admittedly this was a kludge, but I could do it because I had my own make which
embedded the location in the file when it was installed. I was not very happy
with this trick, but it seems I completely lose this ability using R INSTALL.
>From within R is there a good way to find the location of a library when it is
loaded or after it is loaded?

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 16:30:52 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 17:30:52 +0100
Subject: "'" prints as "\'"
In-Reply-To: <wncvhwoqap6.fsf@fhat.stat.sc.edu> (message from Anthony Rossini
 on 17 Dec 1997 09:57:25 -0500)
Message-ID: <199712171630.RAA01763@sophie.ethz.ch>

>>>>> "tony" == Anthony Rossini <rossini@math.sc.edu> writes:

>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >>> (This reported before).  In R, "'" prints as

    >>> [1] "\'"

    >>> which is different from S, and is really unnecessary.  ((it is just
    >>> now uglyfying the output of a function which I wrote for S and now
    >>> use in R)).

    >>> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

    tony> Poor justification.  I'll look into this more in Feb/Mar...

It is actually wrong.  There's no problem with font-locking here...

I think we will change this, in the ``next after next'' release of R.

Martin

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 17:46:42 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 18:46:42 +0100
Subject: library/data
In-Reply-To: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
Message-ID: <199712171746.SAA04913@pc25.none>

>>>>> Paul Gilbert writes:

> I have some data files with my library which are used for examples and
> testing the code. To date I have kept them in a subdirectory I called
> ../dse/dsedata, but I am trying to move those to .../dse/data as
> perscribed for installing libraries. However, these datasets are not
> all R object, some are just files that I source from within a
> function, and one is accessed by a separate process that I call from
> R.

Official R speak actually is `package' for what you call `library'.

> 1/ Should the data subdirectory be reserved for R objects?

No.  You can have data of any kind ther.  However, currently data() only
works for R objects, i.e., files with R code and names ending in `.R'.
Within soon, this should be extended so that e.g. `.tab' is using for
tables (and we still have to determine how to treat headers ...).

> 2/ Could someone explain or point me to were I can find the
> explanation of how R objects in this data subdirectory should be
> constructed? Are these objects automatically loaded when a library is
> loaded?

No, they are not loaded automatically.  Currently, there is (still) no
way to attach a directory.  This will change eventually.

If you build a package for use with R and there is no reason to store
data in a specific format, you might as well try to dump() your object
and put the result of that into the data dir of the pkg (thus you'd have
sourceable R code etc.)  If you want to distribute something in some
other format, e.g. `file.of', then `file.R' should contain the R code
for reading the contents of `file.of' into R.

> 3/ To date I have been able to find my subdirectory by setting a
> variable indicating its location in the library file from which code
> is loaded.  Admittedly this was a kludge, but I could do it because I
> had my own make which embedded the location in the file when it was
> installed. I was not very happy with this trick, but it seems I
> completely lose this ability using R INSTALL.  >> From within R is
> there a good way to find the location of a library when it is loaded
> or after it is loaded?

Not quite.  There is a function called system.file() which does
something similar:

R> system.file("R/base")
[1] "/usr/local/lib/R/library/base/R/base"
R> system.file("data/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"
> system.file("*/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"

Would it be important to know the location of a package?

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

From pgilbert@bank-banque-canada.ca  Wed Dec 17 19:00:31 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 14:00:31 -0500
Subject: library/data
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca> <199712171746.SAA04913@pc25.none>
Message-ID: <97Dec17.140207est.26702@mailgate.bank-banque-canada.ca>

>Official R speak actually is `package' for what you call `library'.

Yes, I forgot, sorry.
Thanks for all the other details.

>Would it be important to know the location of a package?

Probably not for the code, but if I put data in .../dse/data then I need to know
where it is in order to load it (and sometimes to pass the location to other
processes to load it). The way I've done this in S is to set a global variable
in .First.lib using the library and section arguments, but I don't think this is
available in R yet.

Paul


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

From ihaka@stat.auckland.ac.nz  Wed Dec 17 22:51:06 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Thu, 18 Dec 1997 11:51:06 +1300 (NZDT)
Subject: Development Plans
Message-ID: <199712172251.LAA26527@stat1.stat.auckland.ac.nz>

I thought that it might be useful (to myself as well as others) to
write down my current plans for working on R.  I have indexed things
by my (vague) feeling of priority.  If you think my priorities are
completely wrong, please feel free to set me straight :-).
As you can see, I am confining myself almost entirely to internal
tinkering - if someone would put another 24 hours into the day I'll
take a look at applications too.

	Ross


1. Revision Of The Graphics System

Paul Murrell and I (mostly Paul) are revising the R graphics system so
that it will allow multiple active devices, better hardcopy facilities
and more flexible plot layouts.
[Status: well under way].


2. Make The Source Tree More Gnu Compatible

This means having a target installation directory in mind, (probably
defaulting to /usr/local/lib/R-x.xx) in mind rather than building the
distribution in place.  This would make it reasonable to peel back one
level of directory structure. I.e. move the source of the current src
director up one level.  The "graphics" subdirectory would also disappear,
to be replaced by one or two bigger code chunks.
[Status: this and the Fortran change below are relatively simple to put
in place, but keeping the cvs history intact could be a problem]


3. Fortran Integration

Work on a real integration of Fortran into R.  This would mean
adapting the configuration procedures used by Octave to detect and
use Fortran.  As a consequence, the current duplication of C and
F77 sources would disappear.  It would also it possible to incorporate
a much richer set of numerical and other capabilities into R.
[Status: I have done some basic experiments and it looks pretty
easy to do]


4. Demand Loading Of Objects

This would be similar in spirit to Thomas Lumley's approach, but
would go on at a somewhat lower level and also allow selective
freeing of such objects when memory demands are high.  It would
also make it possible to think in terms of "attaching" directories
of objects.  (At attach time all the objects in a directory would
be registered as loadables, and loaded when required).
[Status: I have thought a bit about this.  It should be pretty simple
but no doubt there are a few undiscovered gotchas in there]


5. Change Internal Handling of Lists

Do a rewrite of the internal handing of lists so that they are
really generic vectors.  This will mean large volumes of fairly
flakey subsetting and mutation code can be removed.
[Status: It is important to get this done, but it will be a big task.
Almost everything will break during the switch]


6. Memory Management

Revisit the memory management system.  In particular, we need a better
way of storing strings, and of allowing the heap to grow, rather than
having everything allocated up front.
[Status: Preliminary wishful thinking ...]


7. Miscellaneous

Do something about namespace management.
Finish writing persp (and some other graphics primitives).
Implement missing functionality such as "aov" and "persp".                 
[Status: I have played with some of this]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 08:10:54 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 18 Dec 1997 09:10:54 +0100
Subject: model.matrix(.) and all that
Message-ID: <199712180810.JAA02547@sophie.ethz.ch>

Maybe just a minor thing,
but since we are aiming for  S compatibility, here :

       R> x_ 1:5
       R> model.matrix(x ~ x)
       Error: length of namelist must equal dims

whereas in  S,

	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 18 09:50:36 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 18 Dec 1997 10:50:36 +0100 (MET)
Subject: library/data
In-Reply-To: <199712171746.SAA04913@pc25.none>
Message-ID: <Pine.OSF.3.96.971218104505.27754B-100000@alpha>


> > 1/ Should the data subdirectory be reserved for R objects?
> 
> No.  You can have data of any kind ther.  However, currently data() only
> works for R objects, i.e., files with R code and names ending in `.R'.

What about files ending in .r?
(= result of copying a .R file on a dos formatted floppy disk).
Will they be recognized as R code files?
I have already mentioned this problem a few days ago, but there has not
been any reaction.

Thanks,
 Philippe

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

From p.dalgaard@biostat.ku.dk  Thu Dec 18 10:31:06 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 18 Dec 1997 11:31:06 +0100
Subject: model.matrix(.) and all that
In-Reply-To: Martin Maechler's message of Thu, 18 Dec 1997 09:10:54 +0100
References: <199712180810.JAA02547@sophie.ethz.ch>
Message-ID: <x2pvmvdjth.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> 
> Maybe just a minor thing,
> but since we are aiming for  S compatibility, here :
> 
>        R> x_ 1:5
>        R> model.matrix(x ~ x)
>        Error: length of namelist must equal dims
> 
> whereas in  S,
> 
> 	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)

... where I would have expected model.matrix(~x). Does this have any
untoward consequences for delete.response and all that?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 23:15:05 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 19 Dec 1997 00:15:05 +0100
Subject: numeric(0)[FALSE]  bug[let]
Message-ID: <199712182315.AAA04804@jessica.ethz.ch>

This is not a joke, but a problem appearing in real code of mine.
I used ifelse in a context which can be simplified to

R> ifelse(T, 3, NULL)
Error: incompatible types in subset assignment
R> ifelse(T, 3, numeric(0))
Error: invalid subscript type
R> 
R> ifelse
function (test, yes, no) 
{
        ans <- test
        test <- as.logical(test)
        nas <- is.na(test)
        ans[test] <- rep(yes, length = length(ans))[test]
        ans[!test] <- rep(no, length = length(ans))[!test]
        ans[nas] <- NA
        ans
}
R> 
R> numeric(0)[F]
Error: invalid subscript type
R> NULL[F]
NULL
R> 

--------------------------------------------

whereas  S-plus does as I expect:

S> ifelse(T, 3, NULL)
[1] 3
S> ifelse(T, 3, numeric(0))
[1] 3
S> 
S> NULL[F]
NULL
S> numeric(0)[F]
numeric(0)
S> logical(0)[F]
logical(0)
S> 
-----------------
I see an easy workaround for either fixing  ifelse(.) and or
solving my problem.

However, I think

	anytype(0)[FALSE]  should  return   
	anytype(0)

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

From pgilbert@bank-banque-canada.ca  Fri Dec 19 18:46:18 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 19 Dec 1997 13:46:18 -0500
Subject: Error in parse
Message-ID: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>

In R 0.60.1 when I source a fairly large file of code I am getting:
Error in parse(file, n, text, prompt) : syntax error on line 2985

I don't see any error and it doesn't happen if I split the file in two pieces.
increasing  -v -n does not seem to help and does not change the location of the
error. Does anyone have suggestions?

Paul Gilbert


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

From Kurt.Hornik@ci.tuwien.ac.at  Mon Dec 22 09:24:20 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Mon, 22 Dec 1997 10:24:20 +0100
Subject: Error in parse
In-Reply-To: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
Message-ID: <199712220924.KAA08507@pc25.none>

>>>>> Paul Gilbert writes:

> In R 0.60.1 when I source a fairly large file of code I am getting:
> Error in parse(file, n, text, prompt) : syntax error on line 2985

> I don't see any error and it doesn't happen if I split the file in two
> pieces.  increasing -v -n does not seem to help and does not change
> the location of the error. Does anyone have suggestions?

Two suggestions:

* Does the problem occur at the end of the file?  Then, the problem
might be a final newline ...

* Does the file contain ASCII 0 characters?

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 16:38:14 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 17:38:14 +0100
Subject: $CRAN/src/contrib/devel
Message-ID: <199712221638.RAA16954@galadriel.ci.tuwien.ac.at>


I have created the above directory for contributed R packages that are
considered as ``in development''. It is intended as a central
marketplace for code that is for various reasons ``unstable'' or
``incomplete'' but might be useful for others. If you want to
contribute some code, please include a README file in the tar ball
describing the problems etc.

I have started porting the main library section of Venables & Ripley's
MASS ... but I had time only for lda and qda (these seem to be
working) ... they can be found in=20

	$CRAN/src/contrib/devel/mass-0.01-1.tar.gz



Frohe Weihnachten & ein gl=FCckliches neues Jahr,

Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 17:48:51 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 18:48:51 +0100
Subject: some unresolved symbols ... does anybody know them
Message-ID: <199712221748.SAA19722@galadriel.ci.tuwien.ac.at>


I've tried (again) to port Hastie/Tibshirani's mda package and still got
stuck with some unresolved symbols ... does anybody know where these
are defined:

	R.binary: can't resolve symbol 'dbksl_'=09
	R.binary: can't resolve symbol 'dblepr_'
	R.binary: can't resolve symbol 'dqrdca_'
	R.binary: can't resolve symbol 'intpr_'
	R.binary: can't resolve symbol 'pack_'
	R.binary: can't resolve symbol 'sgram_'
	R.binary: can't resolve symbol 'sknotl_'
	R.binary: can't resolve symbol 'unpack_'
	R.binary: can't resolve symbol 'wmean__'

I tried to ask the original authors, but got no response so far.

Best,
Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From bates@stat.wisc.edu  Tue Dec 23 21:28:36 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 23 Dec 1997 15:28:36 -0600 (CST)
Subject: Debian package for R-0.61 uploaded
Message-ID: <m0xkbsS-000hhtC@franz.stat.wisc.edu>

I have uploaded a Debian package r-base_0.61.0-2_i386.deb to the
incoming directory at ftp.ci.tuwien.ac.at.  This package is built
against libc5, not libc6.  Turns out that was a bit more complicated
than I had hoped.

I have also created an RPM file for the same binary distribution and
will upload that shortly as r-base-0.61.0-2.i386.rpm.  I enclose some
information regarding the two packaged versions below.  Notice that
the rpm query indicates that not only is there a call to
/usr/local/bin/perl but there appears to be vestigial @PERL@ calls in
some of the scripts somewhere in the tree.  It may just be that I have
not cleared out all the foo.in files - I'll try to check.

Why is this release 2 of the Debian package you ask?  Well I found out 
after I uploaded release 1 to master.debian.org that I had botched the 
renaming of the original tar file.  I think this time it is ok.  It
doesn't affect the binary package. It only affects people who are
going to try to build the package from the sources.

Merry Christmas and a Happy New Year to all.

 # dpkg-deb -I r-base_0.61.0-2_i386.deb 
  new debian package, version 2.0.
  size 982660 bytes: control archive= 25313 bytes.
      854 bytes,    16 lines      control              
     1074 bytes,    46 lines      du                   
    65122 bytes,   932 lines      md5sums              
       18 bytes,     2 lines      shlibs               
  Package: r-base
  Version: 0.61.0-2
  Architecture: i386
  Depends: ldso (>= 1.8.0-0), libc5 (>= 5.4.0-0), libreadline2 (>= 2.1), ncurses3.0, xlib6 (>= 3.3-0)
  Suggests: g77
  Installed-Size: 3491
  Maintainer: Douglas Bates <bates@stat.wisc.edu>
  Description: `GNU S' - A language and environment for statistical computing.
   R is described by its authors as "not unlike" S, which is a language
   developed at Bell Laboratories for statistical computing and graphics.
   It provides support for a variety of statistical and graphical analyses.
   R is a true computer language which contains a number of control-flow
   constructions for iteration and alternation.  It allows users to add
   additional functionality by defining new functions.  Fortran and C
   code can be linked and called at run time.
   S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -i
 Name        : r-base                      Distribution: Debian
 Version     : 0.61.0                            Vendor: (none)
 Release     : 2                             Build Date: Tue Dec 23 15:13:12 1997
 Install date: (not installed)               Build Host: franz.stat.wisc.edu
 Group       : Converted/Debian              Source RPM: r-base-0.61.0-2.src.rpm
 Size        : 2989093
 Summary     : `GNU S' - A language and environment for statistical computing.
 Description :
 R is described by its authors as "not unlike" S, which is a language
 developed at Bell Laboratories for statistical computing and graphics.
 It provides support for a variety of statistical and graphical analyses.
 R is a true computer language which contains a number of control-flow
 constructions for iteration and alternation.  It allows users to add
 additional functionality by defining new functions.  Fortran and C
 code can be linked and called at run time.
 S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -R
 @PERL@  
 /usr/local/bin/perl  
 /usr/bin/perl  
 /bin/sh  
 /bin/perl  
 libreadline.so.2  
 libncurses.so.3.0  
 libm.so.5  
 libdl.so.1  
 libc.so.5  
 libX11.so.6  
 libSM.so.6  
 libICE.so.6  
 /bin/sh  
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From warnes@biostat.washington.edu  Wed Dec 24 02:01:51 1997
From: warnes@biostat.washington.edu (Gregory R. Warnes)
Date: Tue, 23 Dec 1997 18:01:51 -0800 (PST)
Subject: package conversion script
In-Reply-To: <m0xkbsS-000hhtC@franz.stat.wisc.edu>
Message-ID: <Pine.LNX.3.96.971223173611.293F-200000@progress.biostat.washington.edu>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII


Attached is a script, UPDATELIBS, that does much of the work of converting
R packages/librares to the current format.  I've just used it to add
packages from my R-0.50-alpha-4 to R-0.61 (from the debian package
Douglass Bates just made available). 

It takes a list of package names/directories as parameters and does the
following:
  - renames $PACKAGE/funs to $PACKAGE/R
  - converts $PACKAGE/man/* to $PACKAGE/man/*.Rd using $RHOME/etc/Rman2Rd
  - compiles any C and FORTRAN functions in $PACKAGE/src and
    $PACKAGE/src-c using R COMPILE
  - creates a shared library from the resulting objects using R SHLIB and
  - installs the package using R INSTALL

Its pretty simple-minded, and I've done little error-handling except to
assure that the appropriate $PACKAGE/* directories exist .  Finally,
UPDATELIBS assumes that it is run in the parent directory of the package
file(s), (ie $PACKAGE/.. ) . 

I hope someone finds it useful.

-Greg

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=UPDATELIBS
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.971223180151.293G@progress.biostat.washington.edu>
Content-Description: 

IyEvYmluL3NoDQojIFVQREFURUxJQlMgOiB1cGRhdGUgUiBsaWJyYXJpZXMg
dG8gbmV3IGZvcm1hdCBhbmQgaW5zdGFsbA0KIw0KUkhPTUU9YFIgUkhPTUVg
DQpleHBvcnQgUkhPTUUNClRISVNESVI9YHB3ZGANCmV4cG9ydCBUSElTRElS
DQoNCmZvciBpIGluICQqDQpkbw0KICAgaWYgWyAtZCAkaSBdDQogICB0aGVu
DQogCSMgZmlyc3QgcmVuYW1lICJmdW5zIiB0byAiUiINCglpZiBbIC1kICRp
L2Z1bnMgXQ0KCXRoZW4NCgkJbXYgJGkvZnVucyAkaS9SDQoJZmkNCgkNCgkj
IG5vdyBjb252ZXJ0IG9sZCBoZWxwIGZpbGVzDQoJaWYgWyAtZCAkaS9tYW4g
XQ0KCXRoZW4NCgkgICBjZCAkaS9tYW4NCgkgICBmb3IgcCBpbiBgbHNgDQoJ
ICAgZG8NCgkgICAgICAkUkhPTUUvZXRjL1JtYW4yUmQgJHAgPiAkcC5SZA0K
CSAgIGRvbmUNCgkgICBjZCAkVEhJU0RJUg0KCWZpDQoJDQoJIyBjb21waWxl
IGNvZGUgICh0cnkgYm90aCBzcmMgYW5kIHNyYy1jKQ0KCWlmIFsgLWQgJGkv
c3JjIF0NCgl0aGVuDQoJICAgY2QgJGkvc3JjDQoJICAgUiBDT01QSUxFICou
YyAqLmYNCgkgICBSIFNITElCICRpLnNvICoubw0KCSAgIGNkICRUSElTRElS
DQoJZmkNCg0KICAgICAgICBpZiBbIC1kICRpL3NyYyBdDQogICAgICAgIHRo
ZW4NCiAgICAgICAgICAgY2QgJGkvc3JjLWMNCiAgICAgICAgICAgUiBDT01Q
SUxFICouYyAqLmYNCiAgICAgICAgICAgUiBTSExJQiAkaS5zbyAqLm8NCiAg
ICAgICAgICAgY2QgJFRISVNESVINCglmaQ0KDQoJIyBub3cgaW5zdGFsbA0K
CVIgSU5TVEFMTCAkaQ0KCQ0KICAgZWxzZQ0KICAgICAgCWVjaG8gKiogbGli
cmFyeSBkaXJlY3RvcnkgJGkgTk9UIEZPVU5EISAqKg0KICAgZmkNCmRvbmUN
Cg==
--8323328-376753582-882928911=:293--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From bates@stat.wisc.edu  Fri Dec 26 15:13:32 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 26 Dec 1997 09:13:32 -0600
Subject: "ifdef"'ing R/S code
Message-ID: <6rvhwcgmsj.fsf@franz.stat.wisc.edu>

I should have saved the messages about this but I didn't.  Can someone
remind me of what function or object to check from within a function
to determine if you are running R?  I need to make some changes in
code according to whether I am running it under R or under S and I
would prefer to keep one source tree.

Thomas Lumley:  I read your web page on porting S code to R.  It looks
very good.  You may want to change the parts about Calloc versus
calloc for the 0.61 release.  Also, little tidbits about the changes
in the interpreted code (such as the answer to the above query) could
help.  I realize that everything is in a state of flux so such
information quickly gets out of date but who trusts a web page more
than two weeks old anyway :-)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 26 15:27:14 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 26 Dec 1997 16:27:14 +0100
Subject: "ifdef"'ing R/S code:  if(is.R())
In-Reply-To: <6rvhwcgmsj.fsf@franz.stat.wisc.edu> (message from Douglas Bates
 on 26 Dec 1997 09:13:32 -0600)
Message-ID: <199712261527.QAA23058@jessica.ethz.ch>

>>>>> "DougB" == Douglas Bates <bates@stat.wisc.edu> writes:

    DougB> I should have saved the messages about this but I didn't.  Can
    DougB> someone remind me of what function or object to check from
    DougB> within a function to determine if you are running R?  I need to
    DougB> make some changes in code according to whether I am running it
    DougB> under R or under S and I would prefer to keep one source tree.

##>>>>>> This works in all of <<<<<
##-- S  (including "S version 4", (beta))
##-- R
##-- S-plus

is.R <- function() { ## returns  'TRUE'  iff we are using 'R'
  exists("version") && !is.null(vl <- version$language) && vl == "R"
}

#- some may want:
is.S <- function() !is.R()

--------------
I think I should add this function to the R base,
or do we need a new package  "Scompatibility"  which could server other
things as well? 

I for one, am having more and more need for an "Rcompatibility" package in
S...

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

From p.dalgaard@biostat.ku.dk  Sat Dec 27 01:50:53 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 27 Dec 1997 02:50:53 +0100
Subject: Error in parse
In-Reply-To: Kurt Hornik's message of Mon, 22 Dec 1997 10:24:20 +0100
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
 <199712220924.KAA08507@pc25.none>
Message-ID: <x2g1nfv9j6.fsf@blueberry.kubism.ku.dk>

Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

> 
> >>>>> Paul Gilbert writes:
> 
> > In R 0.60.1 when I source a fairly large file of code I am getting:
> > Error in parse(file, n, text, prompt) : syntax error on line 2985
> 
> > I don't see any error and it doesn't happen if I split the file in two
> > pieces.  increasing -v -n does not seem to help and does not change
> > the location of the error. Does anyone have suggestions?
> 
> Two suggestions:
> 
> * Does the problem occur at the end of the file?  Then, the problem
> might be a final newline ...
> 
> * Does the file contain ASCII 0 characters?

- and a third: 

Are you by any chance executing external programs with system()? This
is playing tricks on "make tests" at them moment, because the pager
eats up the remainder of the input file...I suspect that source()
within source() will do weird things too.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec 30 04:09:35 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 29 Dec 1997 22:09:35 -0600
Subject: as.name is not idempotent
Message-ID: <6rwwgnxyio.fsf@franz.stat.wisc.edu>

At least I think the word I want "idempotent" - it has been a long
debugging session and my brain is fried so I am not sure.

What I mean is that as.name applied to a name gives an error.
 > as.name("foo")
 foo
 > as.name(as.name("foo"))
 Error in as.name(x) : character argument required

It might help if it were a bit more flexible about the arguments it
accepts.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec 30 12:05:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 30 Dec 1997 13:05:13 +0100
Subject: as.name is not idempotent
In-Reply-To: Douglas Bates's message of 29 Dec 1997 22:09:35 -0600
References: <6rwwgnxyio.fsf@franz.stat.wisc.edu>
Message-ID: <x2d8ifjati.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> At least I think the word I want "idempotent" - it has been a long
> debugging session and my brain is fried so I am not sure.

I.: f(f(x)) == f(x) all x, so it's exactly the right term...

> What I mean is that as.name applied to a name gives an error.
>  > as.name("foo")
>  foo
>  > as.name(as.name("foo"))
>  Error in as.name(x) : character argument required
> 
> It might help if it were a bit more flexible about the arguments it
> accepts.

This is plainly a bug. If it bothers you badly, insert 

if(is.name(x)) return(x)

at the start of as.name.

In general, it should invariably hold that

is.xx(x) == TRUE implies as.xx(x) == x
and
is.xx(as.xx(x)) == TRUE unless as.xx fails

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From thomas@biostat.washington.edu  Wed Dec 31 21:03:23 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Wed, 31 Dec 1997 13:03:23 -0800 (PST)
Subject: debugger
In-Reply-To: <m0xnUm6-000hh5C@franz.stat.wisc.edu>
Message-ID: <Pine.SOL.3.95.971231130059.10B-100000@gorn>


Can we have some way to exit the debugger?  At the moment you have to use
(c)ontinue, which is annoying if the function is slow, or has unpleasant
side effects (like crashing R).


Thomas Lumley
------------------------------------------------------+------
Biostatistics		: "Never attribute to malice what  :
Uni of Washington	:  can be adequately explained by  :
Box 357232		:  incompetence" - Hanlon's Razor  :
Seattle WA 98195-7232	:				   :
------------------------------------------------------------


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

From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 09:34:04 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 10:34:04 +0100
Subject: R-alpha: Re^2: data file names
In-Reply-To: <199712020706.IAA10187@pc25.none> (message from Kurt Hornik on
 Tue, 2 Dec 1997 08:06:13 +0100)
Message-ID: <199712020934.KAA01688@sophie.ethz.ch>

	[R-devel'ers:  spill over from R-core .. -- MM]

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >> In preparing the next Windows release I want to make opening up
    >> system data files (and their documentation) more transparent. I
    >> would really like to adopt the convention that data files use the
    >> suffix .rdf (.dat seems like it's taken). This will make it easier
    >> to get the builtin Windows file browsers to work on it and save me
    >> some considerable work trying to figure out what is and isn't a data
    >> file.

    KH> What does `rdf' stand for?

R Data File ?

But why can't it just be `.R'  (-> `.r' in the ...OS)?

At least currently, these are simply files with valid  R code.
If they would end in `.R', ESS (Emacs Speaks Statistics) would
automatically be put in the proper mode.
Of course, we could also use a new ending,
but I think this would only make sense if the data files would internally
use a different format,
e.g.,  data.dump / data.restore, or one which works with  read.table.

We have discussed earlier that it would be nice to allow different formats
for data files, and maybe the file extension would tell the  data(.)
function in which way it has to read the data
(Of course, UNIX `file' would be much nicer than file extensions,
 but portability ...)

 


    >> It would also be nice if one of you great documentation folks
    >> thought of a html-like format for the .doc files so that I could
    >> simply pop them up. This would also ideally let index.doc be built
    >> on the fly....
yes

    >> I find it quite frustrating that I can't peek at the doc file while
    >> trying to decide which data file I want.
Hmm; in 0.60 we at least have
	data()
for the list
and
	?foodata
for the doc in foodata.doc.  This does already help me quite a bit..


    >> I'm hoping to get a browser
    >> that will let you peruse the documentation while selecting the file.

    >> Comments/opinions appreciated.

    KH> You are obviously right.  I think what we want is to have a unified
    KH> documentation format for both functions (which is what we have
    KH> until now been focussing on) and variables (``data files'').  In
    KH> the not too long run, will we be able to attach data directories so
    KH> that we can really treat the data files as variable objects?
Do you mean binary data files?  Or would they be `compiled' 
	from src/library/<pkg>/data/
	to   library/<pkg>/data/  ?


    KH> Anyway, I just realized that all .doc files now have the structure

    KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES

    KH> so it seems that we only need to add \format{} and \source{} to the
    KH> Rd standard.
yes; this would be one thing; the other being a script (or a person ..)
for translating all current the foodata.doc to foodata.Rd ...
But __YES__ , the earlier, the better  (but ``post release'');
I'd like to have this BEFORE the following is completely solved ..

    KH> And, well, to document the format we really need
    KH> tables.  FL, MM, what is the right way to do these?

As with \itemize , \enumerate and \describe
	(do they work now in HTML,  Fritz? -- would be nice for release ...).
HTML and LaTeX are `obvious'
(we  shouldn't be too fancy, I think, just use a common denominator of
	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
        Fritz will have to look at (a newer version of) latex2html once more)
and the real problem is  nroff.
 (yes, I do want to have simple fast online help using C-c C-v in ESS ...)



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

From Martin Maechler <maechler@stat.math.ethz.ch>  Tue Dec  2 11:26:32 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Tue, 2 Dec 1997 12:26:32 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: <x2oh30m4h2.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 02 Dec 1997 11:20:09 +0100)
Message-ID: <199712021126.MAA01905@sophie.ethz.ch>

	[R-devel instead of  R-help]

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> 
    >> >>>>> Albrecht Gebhardt <agebhard@zidsrv.sci.uni-klu.ac.at> writes:
    >> 
    Albrecht> would it be possible to change the hist() function in future
    Albrecht> R Versions to accept a "plot=F" parameter (like hist() in S
    Albrecht> it should return a list with "breaks" and "counts" in this
    Albrecht> case). This change should be very simple.
    >> 
    >> it _was_ simple, and has been in the current sources for a while now.
    >> You'll see it in version 0.60 which should be released `real soon now'.
    >> 
    >> > hist(rnorm(50), plot=F)
    >> $breaks
    >> [1] -3 -2 -1  0  1  2  3
    >> 
    >> $counts
    >> [1]  1 11 12 20  5  1

    PD> Martin: Wouldn't it be better to return

    PD> invisible(list(breaks = breaks, counts = counts))

    PD> in the plot=T case? (currently it's  invisible(NULL) )

Yes, it would be better;
I even remember having thought about it....
ahh, the reason I did not implement it, is that S-plus is different:
It returns something else for  plot=TRUE:

S> x_ rnorm(50)
S> hi_ hist(x)
S> h2_ hist(x,plot=F)
S> hi
[1] -2.5 -1.5 -0.5  0.5  1.5  2.5
S> h2
$breaks:
[1] -3 -2 -1  0  1  2  3

$counts:
[1]  1  6 14 22  6  1

---
Do we want  S-compatibility here?
(At that time, I hated the idea that the return value is so different, just
 depending on the  plot=.. value).

At the moment, I have (only here, not yet commited)

In the case of  plot=FALSE, one wants (almost) always to
work with the result (and not just see it),i.e. one can have invisible
in both cases.
Therefore, I'd propose the following ``end of hist''
 ((Shall I commit this change later today, about GMT 15.00 ?)


	......

	if(plot) {
		plot.new()
		plot.window(xlim, ylim, "")
		title(main = main, xlab = xlab, ylab = ylab, ...)
		if(axes) {
			axis(1, ...)
			axis(2, ...)
		}
		rect(breaks[-nB], 0, breaks[-1], counts,
		     col = col, border = border)
	}
	invisible(list(breaks = breaks, counts = counts))
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 12:21:39 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 13:21:39 +0100
Subject: R-alpha: Re: wish ``hist() returning ..'' --- and if plot=T ?
In-Reply-To: Martin Maechler's message of Tue, 2 Dec 1997 12:26:32 +0100
References: <199712021126.MAA01905@sophie.ethz.ch>
Message-ID: <x2lny4lyuk.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

>     PD> Martin: Wouldn't it be better to return
> 
>     PD> invisible(list(breaks = breaks, counts = counts))
> 
>     PD> in the plot=T case? (currently it's  invisible(NULL) )
> 
> Yes, it would be better;
> I even remember having thought about it....
> ahh, the reason I did not implement it, is that S-plus is different:
> It returns something else for  plot=TRUE:
> 
> S> x_ rnorm(50)
> S> hi_ hist(x)
> S> h2_ hist(x,plot=F)
> S> hi
> [1] -2.5 -1.5 -0.5  0.5  1.5  2.5
> S> h2
> $breaks:
> [1] -3 -2 -1  0  1  2  3
> 
> $counts:
> [1]  1  6 14 22  6  1
> 
> ---
> Do we want  S-compatibility here?
> (At that time, I hated the idea that the return value is so different, just
>  depending on the  plot=.. value).

Hmmm. In S, hist() calls barplot() with

VALUE:
       a non-printing vector which contains the x-coordinates  of
       the  centers  of  the  bars (y-coordinates if the bars are
       horizontal).  The returned value can be used if  you  want
       to add to the plot.

This is actually quite useful for placing labels, etc. However,
presumably you'd want the counts too, so a list containing the union
of the two might be ideal? How about relative frequencies, BTW?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 16:56:15 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 10:56:15 -0600 (CST)
Subject: R-alpha: NextMethod in 0.50-a4
Message-ID: <m0xcvcN-000hhXC@franz.stat.wisc.edu>

I am encountering difficulty with NextMethod in 0.50-a4.  We created a
class of groupedData objects which are data.frames with additional
attributes.  The most important attribute is a formula describing
roles of some of the variables in the experimental design.

The class of such objects ends in "groupedData", "data.frame".  The
print method for the groupedData class simply cat's the formula then
calls NextMethod.  In R this produces a peculiar message about not
being able to find the function print.groupedData which happens to be
the function that is currently being evaluated.  I tried different
forms of the call to NextMethod but to no avail.

The purpose and design of the groupedData class is described in

@InProceedings{	  bate:pinh:1997,
  author	= {Douglas M. Bates and Jos\'{e} C. Pinheiro},
  title		= {Software Design for Longitudinal Data},
  editor	= {Timothy G. Gregoire},
  booktitle	= {Modelling Longitudinal and Spatially Correlated Data:
		  Methods, Applications and Future Directions},
  year		= 1997,
  address	= {New York},
  publisher	= {Springer-Verlag},
  pages		= {37--48}
}

I created an artificial example using the "acid" data so it can be
reproduced by others.  (BTW, the acid.doc file has a misprint.  The
name of the second column is "optden", not "opt".)

 R> data(acid)
 R> acid
   carb optden
 1  0.1  0.086
 2  0.3  0.269
 3  0.5  0.446
 4  0.6  0.538
 5  0.7  0.626
 6  0.9  0.782
 R> class(acid)
 [1] "data.frame"
 R> attr(acid, "formula") <- optden ~ carb
 R> class(acid) <- c("groupedData", "data.frame")
 R> print.groupedData
 function (x, ...) 
 {
	 cat("Grouped Data: ")
	 print(attr(x, "formula"))
	 NextMethod()
 }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod(print, x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
 R> print.groupedData <-
 +   function(x, ...)
 + {
 +   cat("Grouped Data: ")
 +   print(attr(x, "formula"))
 +   NextMethod("print", x, ...)
 + }
 R> acid
 Grouped Data: optden ~ carb
 Error: couldn't find function "print.groupedData"
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 17:49:55 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 18:49:55 +0100
Subject: R-alpha: NextMethod in 0.50-a4
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 10:56:15 -0600 (CST)
References: <m0xcvcN-000hhXC@franz.stat.wisc.edu>
Message-ID: <x27m9nmy7w.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

>  R> acid
>  Grouped Data: optden ~ carb
>  Error: couldn't find function "print.groupedData"

Same thing in my snapshot of 0.60.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 17:55:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 2 Dec 1997 11:55:49 -0600 (CST)
Subject: R-alpha: two-sided to one-sided formula
Message-ID: <m0xcwY1-000hhXC@franz.stat.wisc.edu>

At times we want to convert a two-sided formula to a one-sided
formula.  In S we can do this by dropping the second entry in the
formula.  In R that object no longer has a formula class.
 R> ttt <- score ~ age | Infant
 R> class(ttt)
 [1] "formula"
 R> length(ttt)
 [1] 3
 R> ttt[-2]
 [[1]]
 ~

 [[2]]
 age | Infant

 R> class(ttt[-2])
 NULL
 R> do.call("~", ttt[-(1:2)])
 ~age | Infant

In general it would not be a good idea to propagate the formula class
to subsets but it does make sense in this case.  We can get around it
by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
opinions on whether ttt[-2] should still be a formula?
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec  2 18:21:47 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 02 Dec 1997 19:21:47 +0100
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Douglas Bates's message of Tue, 2 Dec 1997 11:55:49 -0600 (CST)
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu>
Message-ID: <x267p7mwqs.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> In general it would not be a good idea to propagate the formula class
> to subsets but it does make sense in this case.  We can get around it
> by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> opinions on whether ttt[-2] should still be a formula?

Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
the idea of properties depending on the value of a parameter, so I'm
inclined to say no. BTW,

eval(as.call(ttt[-2]))

also works. And one would *think* that formula(as.call(ttt[-2])) did
too, but typeof(as.call(...))==language and !=call (is this weird or
not?), so formula.default protests.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec  2 18:34:49 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 02 Dec 1997 12:34:49 -0600
Subject: R-alpha: two-sided to one-sided formula
In-Reply-To: Peter Dalgaard BSA's message of 02 Dec 1997 19:21:47 +0100
References: <m0xcwY1-000hhXC@franz.stat.wisc.edu> <x267p7mwqs.fsf@blueberry.kubism.ku.dk>
Message-ID: <6rafejiofq.fsf@franz.stat.wisc.edu>

Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

> Douglas Bates <bates@stat.wisc.edu> writes:
> 
> > In general it would not be a good idea to propagate the formula class
> > to subsets but it does make sense in this case.  We can get around it
> > by replacing ttt[-2] by do.call("~", ttt[-(1:2)]) I suppose.  Any
> > opinions on whether ttt[-2] should still be a formula?
> 
> Hum. tt[-i] is a well-defined formula iff (i != 1). Somehow, I dislike
> the idea of properties depending on the value of a parameter, so I'm
> inclined to say no. BTW,
> 
> eval(as.call(ttt[-2]))
> 
> also works.

I agree with Peter.  We will change our code.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec  2 19:21:08 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 14:21:08 -0500
Subject: R-alpha: compatability functions
Message-ID: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>

With some input from Martin Maechler and Martyn Plummer I think I now have a
fairly good set of functions for handling R/S and OS differences, however, I
still have two areas where I would appreciate input. These are largely S
problems, not R problems, but I am doing this so I can write code to work on
both.

1/ In Windows I have been trying to identify NT, 95, or 3.1, but Martyn (who
claims to have little experience but has lots more than I do) suggested that
Win16 vs Win32 might be a more important distinction.  Does anyone know about
this? The eventual purpose is to do things like opening a graphics window,
copying a file, deleting a file, getting date info on a file, starting another
process, getting host name info, or sending mail (from an R/S program).  I can
use machine() to define is.Win32 and is.Win16 in R, but does anyone know how to
do this in Splus?

2/ In S it is fairly easy to get information to define functions like
is.Linux(), is.Sun5(), but most of the time I just want to be able to use
is.unix().  I have two approaches, neither of which I like. One is to default to
unix if I don't identify Windows, and the other is to identify all the different
types of unix and then "or" them. Can anyone suggest a better way to define
is.unix() in S.

Paul Gilbert

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

From thomas@biostat.washington.edu  Tue Dec  2 19:31:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Tue, 2 Dec 1997 11:31:39 -0800 (PST)
Subject: R-alpha: compatability functions
In-Reply-To: <97Dec2.142228est.26688@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>

On Tue, 2 Dec 1997, Paul Gilbert wrote:
> 
> 2/ In S it is fairly easy to get information to define functions like
> is.Linux(), is.Sun5(), but most of the time I just want to be able to use
> is.unix().  I have two approaches, neither of which I like. One is to default to
> unix if I don't identify Windows, and the other is to identify all the different
> types of unix and then "or" them. Can anyone suggest a better way to define
> is.unix() in S.
> 

Doesn't  
	exists("unix") 
work?
	-thomas

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

From pgilbert@bank-banque-canada.ca  Tue Dec  2 20:02:06 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 2 Dec 1997 15:02:06 -0500
Subject: R-alpha: compatability functions
References: <Pine.SUN.3.95.971202113056.15243B-100000@chekov>
Message-ID: <97Dec2.150325est.26691@mailgate.bank-banque-canada.ca>

>Doesn't
>        exists("unix")
>work?

Yes. (At least it is true in unix, I can't verify that it is false otherwise.)
Thanks,
Paul

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

From rgentlem@stat.auckland.ac.nz  Tue Dec  2 21:00:30 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Wed, 3 Dec 1997 10:00:30 +1300 (NZDT)
Subject: R-alpha: Re^2: data file names
Message-ID: <199712022100.KAA25304@stat1.stat.auckland.ac.nz>


> 	[R-devel'ers:  spill over from R-core .. -- MM]
> 
> >>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
> 
> >>>>> Robert Gentleman writes:
>     >> In preparing the next Windows release I want to make opening up
>     >> system data files (and their documentation) more transparent. I
>     >> would really like to adopt the convention that data files use the
>     >> suffix .rdf (.dat seems like it's taken). This will make it easier
>     >> to get the builtin Windows file browsers to work on it and save me
>     >> some considerable work trying to figure out what is and isn't a data
>     >> file.
> 
>     KH> What does `rdf' stand for?
> 
> R Data File ?
> 
> But why can't it just be `.R'  (-> `.r' in the ...OS)?
> 
> At least currently, these are simply files with valid  R code.
> If they would end in `.R', ESS (Emacs Speaks Statistics) would
> automatically be put in the proper mode.
> Of course, we could also use a new ending,
> but I think this would only make sense if the data files would internally
> use a different format,
> e.g.,  data.dump / data.restore, or one which works with  read.table.

I agree with Martin. I would be happy with .R initially and later we could
add other suffixes if we have different data formats. I was just going to
slurp them in through source.
>  
> 
> 
>     >> It would also be nice if one of you great documentation folks
>     >> thought of a html-like format for the .doc files so that I could
>     >> simply pop them up. This would also ideally let index.doc be built
>     >> on the fly....
> yes
> 
>     >> I find it quite frustrating that I can't peek at the doc file while
>     >> trying to decide which data file I want.
> Hmm; in 0.60 we at least have
> 	data()
> for the list
> and
> 	?foodata
> for the doc in foodata.doc.  This does already help me quite a bit..
> 
> 
>     >> I'm hoping to get a browser
>     >> that will let you peruse the documentation while selecting the file.
> 
>     >> Comments/opinions appreciated.
> 
>     KH> You are obviously right.  I think what we want is to have a unified
>     KH> documentation format for both functions (which is what we have
>     KH> until now been focussing on) and variables (``data files'').  In
>     KH> the not too long run, will we be able to attach data directories so
>     KH> that we can really treat the data files as variable objects?
> Do you mean binary data files?  Or would they be `compiled' 
> 	from src/library/<pkg>/data/
> 	to   library/<pkg>/data/  ?
> 
> 
>     KH> Anyway, I just realized that all .doc files now have the structure
> 
>     KH> 	NAME DESCRIPTION FORMAT SOURCE REFERENCES
> 
>     KH> so it seems that we only need to add \format{} and \source{} to the
>     KH> Rd standard.
> yes; this would be one thing; the other being a script (or a person ..)
> for translating all current the foodata.doc to foodata.Rd ...
> But __YES__ , the earlier, the better  (but ``post release'');
> I'd like to have this BEFORE the following is completely solved ..


I agree post 0.60 release (but somethings will have to slip in to the Windows
release of 0.60. I can't believe how hard it is to keep the two in sync. It 
would be handy if we could put the .R's on the data files before the release.
I could live with messy documentation but I really don't want to drop down
into the nuts and bolts of some of the windows dialog code.

>     KH> And, well, to document the format we really need
>     KH> tables.  FL, MM, what is the right way to do these?
> 
> As with \itemize , \enumerate and \describe
> 	(do they work now in HTML,  Fritz? -- would be nice for release ...).
> HTML and LaTeX are `obvious'
> (we  shouldn't be too fancy, I think, just use a common denominator of
> 	\begin{tabular}{..} ... \end{tabular}  and <TABLE> ...
>         Fritz will have to look at (a newer version of) latex2html once more)
> and the real problem is  nroff.
>  (yes, I do want to have simple fast online help using C-c C-v in ESS .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 08:00:11 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 09:00:11 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <199712030723.IAA16264@pc25.none> (message from Kurt Hornik on
 Wed, 3 Dec 1997 08:23:24 +0100)
Message-ID: <199712030800.JAA03331@sophie.ethz.ch>

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Robert Gentleman writes:
    >>> In preparing the next Windows
    >>> release I want to make opening up system data files (and their
    >>> documentation) more transparent. I would really like to adopt
    >>> the convention that data files use the suffix .rdf (.dat seems
    >>> like it's taken). This will make it easier to get the builtin
    >>> Windows file browsers to work on it and save me some
    >>> considerable work trying to figure out what is and isn't a data
    >>> file.

    MM> But why can't it just be `.R' (-> `.r' in the ...OS)?
    MM> 
    MM> At least currently, these are simply files with valid R code.  If
    MM> they would end in `.R', ESS (Emacs Speaks Statistics) would
    MM> automatically be put in the proper mode.  Of course, we could also
    MM> use a new ending, but I think this would only make sense if the
    MM> data files would internally use a different format, e.g., data.dump
    MM> / data.restore, or one which works with read.table.

    >> I agree with Martin. I would be happy with .R initially and later we
    >> could add other suffixes if we have different data formats. I was
    >> just going to slurp them in through source.

    KH> Shall we try to be consistent about other endings, too?  E.g.,

Yes, why not agree on this, now, even before implementation!
 
    KH> rdf	for R data file/format (data.dump/data.restore)

data.dump/data.restore  is hopefully going to be  S-plus compatible as much
as possible (that's why most of us would want it).
Hence, I think the `R' is really too much there.

Would just

	dmp	still be `free' (in Windoze I mean) ?


    KH> table	for tables

For portability, we'd probably rather need 3 letter expansions...
i.e.
	tab	for tables (to be readable by read.table ?!)
		Note, we have to agree if read.table will be called
		with  (...., header = TRUE)  or not.

		Here, mostly for teaching purposes, we have (almost) all
		our data files in the format

			nam.1  col.2  var.3 ...  var.<p>
			<x11>   <x12>  <x13> ...  <x1p>
			<x21>   <x22>  <x23> ...  <x2p>
			  ..      ..    ..         ..
			  ..      ..    ..         ..
			  ..      ..    ..         ..

		I.e. we don't have `rownames' most of the time and don't
		want to type '1' '2' ... 'n' in front of the variables.

	

	Maybe we should even have

	tab	for the above		 ->  read.table(<file>, header = T)
	tbr	for tables with rownames ->  read.table(<file>)


			col.1  col.2  var.3 ...  var.<p>
		r1	<x11>   <x12>  <x13> ...  <x1p>
		r2	<x21>   <x22>  <x23> ...  <x2p>
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..
		..	  ..      ..    ..         ..

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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 11:30:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 12:30:13 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 09:00:11 +0100
References: <199712030800.JAA03331@sophie.ethz.ch>
Message-ID: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Yes, why not agree on this, now, even before implementation!
>  
>     KH> rdf	for R data file/format (data.dump/data.restore)
> 
> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
> as possible (that's why most of us would want it).
> Hence, I think the `R' is really too much there.

I don't think so. The data.dump format is really just an efficient
encoding of the output of dput/dump. It won't be more compatible than
the data structures themselves. That is, unless someone wants to sit
down and catalog all the differences in internal data structures and
do the relevant transformation code....


-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From colin@geology.gla.ac.uk  Wed Dec  3 12:13:24 1997
From: colin@geology.gla.ac.uk (Colin Farrow)
Date: Wed, 3 Dec 1997 12:13:24 GMT
Subject: R-alpha: Two buglets and a difference
Message-ID: <199712031213.MAA24476@alligin.gla.ac.uk>


I have come across three problems in the past few days, in spell of
heavy R ( version  R0.50-a4/Sun Solaris2.5.1 ) use.

1.
I was using lwd=2 to get thicker lines on plots for printing, but
although the 'lwd' parameter works fine with x11(), the thickened lines
do not print with print.plot, or by using postscript() directly.


2.
Try the following,

	plot(1:10, -(1:10))
	mtext("distance", side=3, line=1)

where does the text disappear to, nothing appears on the plot.
The problem relates to the -y in the plot() call, as it works with
plot(1:10, 1:10). This occurs in a function to plot a variable with
 depth (-y), with depth increasing down the y axis.


3.
Less of a bug, more of a difference between implementations

foo <- function(x) {
	paste(substitute(x) )
}


In S
foo(lamp)
	"lamp"
foo(lamp$v)
	"lamp$v"
In R
foo(lamp)
	"lamp"
foo(lamp$v)
	"$" "lamp" "v"


which broke a number of functions I was porting to R

The fix which works in both is
	paste(deparse(substitute(x)))
which is an awful mouthful to get the name of the argument

Colin

--------------------
                     \
Colin Farrow          \
                       \---------------------------------------
                        \                                       \
Department of Geology,   \ E-mail: colin@geology.gla.ac.uk       \
University of Glasgow,    \                                       \
Glasgow, G12 8QQ. Scotland \ Tel: +44 (0)41 339 8855 x5466         \
                            \ Fax: +44 (0)41 330 4817               \
`````````````````````````````````````````````````````````````````````````
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 12:51:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 13:51:03 +0100
Subject: R-alpha: Two buglets and a difference
In-Reply-To: <199712031213.MAA24476@alligin.gla.ac.uk>
 (colin@geology.gla.ac.uk)
Message-ID: <199712031251.NAA03649@sophie.ethz.ch>

>>>>> "Colin" == Colin Farrow <colin@geology.gla.ac.uk> writes:

    Colin> I have come across three problems in the past few days, in spell
    Colin> of heavy R ( version R0.50-a4/Sun Solaris2.5.1 ) use.

thank you for reporting these.

    Colin> 1.  I was using lwd=2 to get thicker lines on plots for
    Colin> printing, but although the 'lwd' parameter works fine with
    Colin> x11(), the thickened lines do not print with print.plot, or by
    Colin> using postscript() directly.

Unfortunately, this is still true for the current source code version
(0.60). 

    Colin> 2.  Try the following,

    Colin> 	plot(1:10, -(1:10)) mtext("distance", side=3, line=1)

    Colin> where does the text disappear to, nothing appears on the plot.
    Colin> The problem relates to the -y in the plot() call, as it works
    Colin> with plot(1:10, 1:10). This occurs in a function to plot a
    Colin> variable with depth (-y), with depth increasing down the y axis.

this is a known bug which is fixed in the upcoming release

    Colin> 3.  Less of a bug, more of a difference between implementations

    Colin> foo <- function(x) { paste(substitute(x) ) }

    Colin> In S
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "lamp$v"

This is not true for my version of S-plus :

> version
Version 3.4 Release 1 for Sun SPARC, SunOS 5.3 : 1996 
> tst3 <- function(x) paste(substitute(x))
> tst3(lamp)
[1] "lamp"
> tst3(lamp$v)
[1] "$"     "lamp"  "\"v\""

    Colin> In R
    Colin>  foo(lamp)
    Colin>  "lamp"
    Colin>  foo(lamp$v)
    Colin>  "$" "lamp" "v"

    Colin> which broke a number of functions I was porting to R

    Colin> The fix which works in both is paste(deparse(substitute(x)))
    Colin> which is an awful mouthful to get the name of the argument

You can omit the paste(.)  and use

	deparse(substitute(x))

in both cases  which is  THE  recommended way in both R and S, anyway.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec  3 15:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 3 Dec 1997 16:56:31 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: <x27m9m1x6i.fsf@blueberry.kubism.ku.dk> (message from Peter
 Dalgaard BSA on 03 Dec 1997 12:30:13 +0100)
Message-ID: <199712031556.QAA03899@sophie.ethz.ch>

>>>>> "PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:

    PD> Martin Maechler <maechler@stat.math.ethz.ch> writes:
    >> Yes, why not agree on this, now, even before implementation!
    >> 
    KH> rdf	for R data file/format (data.dump/data.restore)
    >> 
    >> data.dump/data.restore  is hopefully going to be  S-plus compatible as much
    >> as possible (that's why most of us would want it).
    >> Hence, I think the `R' is really too much there.

    PD> I don't think so. The data.dump format is really just an efficient
    PD> encoding of the output of dput/dump.
right!  Actually I never looked at it this way.

    PD> It won't be more compatible than the data structures themselves.

but this will lead to really portable (between S and R) data.dump output
for many cases we want.

    PD> That is, unless someone wants to sit
    PD> down and catalog all the differences in internal data structures and
    PD> do the relevant transformation code....

not really; 
Actually  however, one case we may want to be `compatible' are
factors, since they are part of data.frames.
Factors are somewhat different in R and S
(internally: clear;  in 'dput(.)' -- maybe not necessary).



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

From p.dalgaard@biostat.ku.dk  Wed Dec  3 20:58:07 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 03 Dec 1997 21:58:07 +0100
Subject: R-alpha: Re^3: data file names
In-Reply-To: Martin Maechler's message of Wed, 3 Dec 1997 16:56:31 +0100
References: <199712031556.QAA03899@sophie.ethz.ch>
Message-ID: <x2ra7ukuu8.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> Factors are somewhat different in R and S
> (internally: clear;  in 'dput(.)' -- maybe not necessary).

Hmm:

R:

> dput(gl(4,1,8))
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))
> ff<-structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1",
"2", "3", "4"), 
+         class = "factor")
> dput(ff)
structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4), class =
"factor", .Label = c("1", 
"2", "3", "4"))

Splus:

> dput(gl(4,1,8))
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")
> ff<-structure(factor(c(1, 2, 3, 4, 1, 2, 3, 4), levels=1:4),
+ class = "factor", .Label = c("1", 
"2", "3", "4"))
> dput(ff)
structure(.Data = c(1, 2, 3, 4, 1, 2, 3, 4), .Label = c("1", "2", "3", "4"), 
        class = "factor")

I.e. when R creates a structure based on the output of Splus's dput(factor),
you get the same structure as if you had created the factor directly,
and vice versa. 

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From rgentlem@stat.auckland.ac.nz  Wed Dec  3 20:59:18 1997
From: rgentlem@stat.auckland.ac.nz (Robert Gentleman)
Date: Thu, 4 Dec 1997 09:59:18 +1300 (NZDT)
Subject: R-alpha: Re^3: data file names
Message-ID: <199712032059.JAA02106@stat1.stat.auckland.ac.nz>

I will make the changes needed for .R extensions to the library files
(and the code change given by Martin for 0.60; Ross will roll it out as
soon as we stop making last minute changes).

Currently I use .rmg as an extension for R images. I wasn't planning on
using anything else (but rdf for binary dumps is probably good). I don't
know if we really want to use extensions for tables. I was simply going to
make this a standard file dialog (under windows) followed by a pop-up
that would let you select the defaults for read.table.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec  4 17:23:23 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 4 Dec 1997 18:23:23 +0100
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
Message-ID: <199712041723.SAA05244@sophie.ethz.ch>

and this breaks  multinom from the nnet library
	[yes, Kurt, I'm working on that and I'll send you patches..]	

Is this a bug or an (half-)intentional difference to S ?

---------------------

In R (0.50-0.60)


     model.matrix(formula =, data =)

 Arguments:

   formula: A model formula or terms object

      data: A data frame created with `model.frame'


In S-plus


  USAGE:
       model.matrix(object, ...)
       model.matrix.default(terms.object, data, contrasts)

  ARGUMENTS:

	.....

  contrasts:     an optional list giving contrasts for some or  all
       of  the  factors  appearing  in  the  terms  object.   The
       elements of the list should have  the  same  name  as  the
       variable   and   should   be   either  a  contrast  matrix
       (specifically, any full-rank matrix with as many  rows  as
       there  are  levels  in  the factor), or else a function to
       compute such a matrix given the  number  of  levels.   The
       complete contrast list (anything given as an argument plus
       any  additional  contrast  matrices  computed)   will   be
       returned as the "contrasts" attribute of the model matrix,
       and hence as the "contrasts" component  of  fitted  models
       returned by lm() and its descendants.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From thomas@biostat.washington.edu  Thu Dec  4 17:41:09 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 4 Dec 1997 09:41:09 -0800 (PST)
Subject: R-alpha: model.matrix(.) does not allow `contrasts' ..
In-Reply-To: <199712041723.SAA05244@sophie.ethz.ch>
Message-ID: <Pine.LNX.3.96.971204093835.5784A-100000@buffy>

On Thu, 4 Dec 1997, Martin Maechler wrote:

> and this breaks  multinom from the nnet library
> 	[yes, Kurt, I'm working on that and I'll send you patches..]	
> 
> Is this a bug or an (half-)intentional difference to S ?
> 

I think it's a bug -- you should be able to specify contrasts on a
model-by-model basis if you really want to.  Fortunately it's very rare
for people to use this feature.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 14:00:45 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 15:00:45 +0100
Subject: R-alpha: Array indexing out of range -- difference to R-minus
Message-ID: <199712051400.PAA06534@sophie.ethz.ch>


> x <- cbind(1,1:3); x
     [,1] [,2]
[1,]    1    1
[2,]    1    2
[3,]    1    3
> x[5:6] <- 10
> x
     [,1] [,2]
[1,]    1    1
[2,]    1   10
[3,]    1   10
> x[5:7] <- 12 #<<<<< loses its dimension, because of `out of range' indexing
> x
[1]  1  1  1  1 12 12 12

     1  2  3  4  5  6  7

---
with S-plus or S4,
	x remains a 3 x 2  matrix;
	it only `silently' grows  *after* being coerced to vector 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Friedrich.Leisch@ci.tuwien.ac.at  Fri Dec  5 14:08:04 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Fri, 5 Dec 1997 15:08:04 +0100
Subject: R-alpha: is.vector of one-dimensional array
Message-ID: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>


maybe we've already diskussed this before, but Kurt and I can't
remember ...

is.vector() of an one-dimensional array returns FALSE. this is also the
behavior of Splus, but totally counter-intuitive for me ... IMO an
array of dimension 1 is exactly the definition of a vector ...

it also breaks our current plot.factor, which is simply a

	barplot(table(x))

table() returns an one-dimensional array, but barplot only accepts
vector and matrix arguments ...

of course one could check additionally for arrays with correct
dimension ... but ...

any opinions?

fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From pgilbert@bank-banque-canada.ca  Fri Dec  5 14:50:47 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 5 Dec 1997 09:50:47 -0500
Subject: R-alpha: is.vector of one-dimensional array
References: <199712051408.PAA06749@galadriel.ci.tuwien.ac.at>
Message-ID: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca>

>is.vector() of an one-dimensional array returns FALSE. this is also the
>behavior of Splus, but totally counter-intuitive for me ... IMO an
>array of dimension 1 is exactly the definition of a vector ...

I assume by "one-dimensional array" you mean a two or higher dimensional array
with all but one of the values from dim(x)  being 1. This is possibly
counter-intuitive, but there are cases where one needs to distinguish these.
Perhaps length(dim(x)) would be better, but dim returns NULL  for a vector. This
is even more counter-intuitive to me. I think it should return length(x) for a
vector. In any case there is lots of code out there that will break if you
change these.

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec  5 17:24:25 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 5 Dec 1997 18:24:25 +0100
Subject: R-alpha: is.vector of one-dimensional array
In-Reply-To: <97Dec5.121337est.26929@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Fri, 5 Dec 1997 09:50:47 -0500)
Message-ID: <199712051724.SAA06827@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    >> is.vector() of an one-dimensional array returns FALSE. this is also
    >> the behavior of Splus, but totally counter-intuitive for me ... IMO
    >> an array of dimension 1 is exactly the definition of a vector ...
not quite exactly.

I think we have agreed that 
	vector
and
	array
are mutually exclusive [i.e., their is.XXX test], 
and actually, the distinction arising by  is.null(dim(.)).


    PaulG> I assume by "one-dimensional array" you mean a two or higher
    PaulG> dimensional array with all but one of the values from dim(x)
    PaulG> being 1.
No, he meant the `rare' thing which table(.) produces 
	-- both in R and S -- 
which has  length(dim(.)) == 1:

> ta <- table(rpois(20,4))
> dim(ta)
[1] 9
> ta
0 1 2 3 4 5 6 7 8 
1 2 4 3 4 2 2 1 1 
> str(ta)
 int [, 1:9] 1 2 4 3 4 2 2 1 1
 - attr(*, "dimnames")=List of 1
  ..$ : chr [1:9] "0" "1" "2" "3" "4" "5" "6" "7" "8"
> 

    PaulG> This is possibly counter-intuitive, but there are cases
    PaulG> where one needs to distinguish these.  Perhaps length(dim(x))
    PaulG> would be better, but dim returns NULL for a vector. This is even
    PaulG> more counter-intuitive to me. I think it should return length(x)
    PaulG> for a vector. In any case there is lots of code out there that
    PaulG> will break if you change these.

Yes! - and we `must' live with these, I think.

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

From plummer@iarc.fr  Mon Dec  8 08:05:04 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Mon, 08 Dec 1997 09:05:04 +0100 (MET)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <XFMail.971208092400.plummer@iarc.fr>

Thanks to the core team for releasing R-0.60. I found a couple of 
bugs.

1) Segfault!
assign(character(0),1)
Fix: Obviously, check the string length. The same problem may occur
in other places but I haven't done an extensive search.
x <- 1
attr(x, character(0)) 


2) The function GStrHeight (graphics.c) uses the conversion factors
for the X axis instead of the Y axis. This causes strangeness in
legend() when the axes are on different scales.
Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with 
fig2dev.by, win2fig.by and ipr[1], respectively.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From ihaka@stat.auckland.ac.nz  Mon Dec  8 09:44:20 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Mon, 8 Dec 1997 22:44:20 +1300 (NZDT)
Subject: R-alpha: Bugs in R-0.60
Message-ID: <199712080944.WAA13846@stat1.stat.auckland.ac.nz>

> From: Martyn Plummer <plummer@iarc.fr>
> To: r-devel@stat.math.ethz.ch
> Subject: R-alpha: Bugs in R-0.60
>
> Thanks to the core team for releasing R-0.60. I found a couple of
> bugs.
>
> 1) Segfault!
> assign(character(0),1)
> Fix: Obviously, check the string length. The same problem may occur
> in other places but I haven't done an extensive search.
> x <- 1
> attr(x, character(0))

	Fixed these two, but there may well be more ...


> 2) The function GStrHeight (graphics.c) uses the conversion factors
> for the X axis instead of the Y axis. This causes strangeness in
> legend() when the axes are on different scales.
> Fix: Replace fig2dev.bx, win2fig.bx and ipr[0] with
> fig2dev.by, win2fig.by and ipr[1], respectively.

	Fixed and committed.  Updates in 0.60.2

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 10:05:10 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 11:05:10 +0100
Subject: R-alpha: Bugs in R-0.60 --
In-Reply-To: <199712080944.WAA13846@stat1.stat.auckland.ac.nz> (message from
 Ross Ihaka on Mon, 8 Dec 1997 22:44:20 +1300 (NZDT))
Message-ID: <199712081005.LAA00745@sophie.ethz.ch>

Dear Ross,

>>>>> "Ross" == Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:

    >> From: Martyn Plummer <plummer@iarc.fr> To: r-devel@stat.math.ethz.ch
    >> Subject: R-alpha: Bugs in R-0.60

    >> 1) Segfault!  assign(character(0),1) Fix: Obviously, check the
    >> string length. The same problem may occur in other places but I
    >> haven't done an extensive search.  x <- 1 attr(x, character(0))

    Ross> 	Fixed these two, but there may well be more ...

things like these  remind me once more  
how very useful it would be to have an option like
	-dont-stop-on-error
for R (batch).

We could have many tests like these in a few  'test' files that would be
run through R...; 
Actually, I'm thinking of auto-generated function calls where most would
give  'Error: ..'  but none should give  segfault...

This could help very much to autodetect problems like these.

- Martin.




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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 11:13:37 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 12:13:37 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
Message-ID: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>



The function tapply is not working in the Windows version of R=20
(Version 0.50 Beta (Sept 29, 1997))

In

tapply <- function (x, INDEX, FUN=3DNULL, simplify=3DTRUE, ...)=20
...

The part:

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		names(ans)<-namelist[[1]]
		return(ans)
	}

should be replaced by

	if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) {
		ans <- unlist(ans, recursive =3D FALSE)
		if(length(INDEX) =3D=3D 1) {
		names(ans) <- namelist[[1]]
		}
		else {
		dim(ans) <- extent
		dimnames(ans) <- namelist
		}
		return(ans)
	}

Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Mon Dec  8 11:30:08 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Mon, 8 Dec 1997 12:30:08 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be> (message
 from Comblain muriel on Mon, 08 Dec 1997 12:13:37 +0100)
Message-ID: <199712081130.MAA00841@sophie.ethz.ch>

Dear Muriel,

the current Unix version of R, 0.60,
has the following definition of  tapply(.).

Can you check if it works for your examples?
If not, please send us a complete example (i.e. with input data, we can
regenerate).
Thank you for your report!

tapply <- function (x, INDEX, FUN=NULL, simplify=TRUE, ...) 
{
	if (is.character(FUN)) 
		FUN <- get(FUN, mode = "function")
	if (!is.null(FUN) && mode(FUN) != "function") 
		stop(paste("'", FUN, "' is not a function",sep=""))
	if (!is.list(INDEX)) INDEX <- list(INDEX)
	nI <- length(INDEX)
	namelist <- vector("list", nI)
	extent <- integer(nI)
	nx <- length(x)
	group <- rep(1, nx)#- to contain the splitting vector
	ngroup <- 1
	for (i in seq(INDEX)) {
		index <- as.factor(INDEX[[i]])
		if (length(index) != nx) 
			stop("arguments must have same length")
		namelist[[i]] <- levels(index)#- all of them, yes !
		extent[i] <- nlevels(index)
		group <- group + ngroup * (codes(index) - 1)
		ngroup <- ngroup * nlevels(index)
	}
	if (is.null(FUN)) return(group)
	ans <- lapply(split(x, group), FUN, ...)
	if (simplify && all(unlist(lapply(ans, length)) == 1)) {
		ansmat <- array(dim=extent, dimnames=namelist)
		ans <- unlist(ans, recursive = FALSE)
	}
	else  {
		ansmat <- array(vector("list", prod(extent)),
			dim=extent, dimnames=namelist)
	}
	ansmat[as.numeric(names(ans))] <- ans
	ansmat
}

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Mon Dec  8 12:08:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 08 Dec 1997 13:08:13 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: Comblain muriel's message of Mon, 08 Dec 1997 12:13:37 +0100
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <x2ra7oghqq.fsf@blueberry.kubism.ku.dk>

Comblain muriel <Muriel.Comblain@ulg.ac.be> writes:

> The function tapply is not working in the Windows version of R 
> (Version 0.50 Beta (Sept 29, 1997))
> 
..
> The part:
...
> should be replaced by
...

Thanks. One thing though:

Please, and this goes for everyone, remember to state the objective of
your fixes.

I think we know what this fix is about (the tapply(x,f,summary)
problem, right?), but this is not stated in your letter. As Martin
points out, the code has subsequently changed in the development
version and we have difficulty seeing whether it solves your problem
or not.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Muriel.Comblain@ulg.ac.be  Mon Dec  8 15:58:45 1997
From: Muriel.Comblain@ulg.ac.be (Comblain muriel)
Date: Mon, 08 Dec 1997 16:58:45 +0100
Subject: R-alpha: Bug in tapply in the Windows version of September
In-Reply-To: <199712081130.MAA00841@sophie.ethz.ch>
References: <3.0.1.32.19971208121337.008f44a0@pop3.mailst.ulg.ac.be>
Message-ID: <3.0.1.32.19971208165845.009538c0@pop3.mailst.ulg.ac.be>

At 12:30 08/12/97 +0100, Martin Maechler wrote:
>Dear Muriel,
>
>the current Unix version of R, 0.60,
>has the following definition of  tapply(.).
>
>Can you check if it works for your examples?
>If not, please send us a complete example (i.e. with input data, we can
>regenerate).
>Thank you for your report!
>
>...

I checked this form of the tapply function coming from the current unix
version (0.60) on my examples and it worked perfectly as well as the fix I
proposed. Sorry if my mail was not completely clear, I will try to do
better next time and thank you for your help.

=20
Muriel Comblain
M=E9thodologie Quantitative
Facult=E9 de Sociologie
Universit=E9 de Li=E8ge=20
Bvd du Rectorat, 7
B4000 Liege, Belgique


Tel: +32 4 366 30 91
E-mail: Muriel.Comblain

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

From pgilbert@bank-banque-canada.ca  Wed Dec 10 15:40:32 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 10 Dec 1997 10:40:32 -0500
Subject: R-alpha: "[.ts" in 0.60.1
Message-ID: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>

I have a class "tframe" with more specific classes indicating how time is being
represented, such as

> class(tframe(data))
[1] "ts"     "tframe"

but now "[.ts" produces warning messages

> tframe(data)[2]
Warning: Not returning a time series object
[1] 2006.25

Even my simplest tests produce hundreds of lines of warnings, so I've commented
out the line
#                        warning("Not returning a time series object")
in "[.ts". I'm not sure if this is the best solution, but something is
necessary.

Paul Gilbert

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







From alchemy@inconnect.com  Thu Dec 11 07:53:27 1997
From: alchemy@inconnect.com (Anthony Chavez)
Date: Thu, 11 Dec 1997 00:53:27 -0700 (MST)
Subject: R-alpha: Re: R-beta: time series structures
In-Reply-To: <348F139A.8032984A@stat.unipg.it>
Message-ID: <Pine.SOL.3.96.971211005155.12804C-100000@ultra1>

Please edit headers and keep non-announce topic off the R-announce list.  Some
of us are subscribed to R-announce for a *reason*.

--
-------------------------------------------------------------------------------
Anthony Chavez                 o   \o/  _ o          o    o-o  +===+  o   +===+
                              /|\   |    /\    __\o o_|   \ /  |   | /|\  |   |
alchemy@inconnect.com         / \  / \  | \   /) |   \\o  \|   |~~~| Co-"=|~~~|
Salt Lake City, Utah          o-o  o-o  o-o  o-o        \  o\  |___| / \  |___|

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:31:51 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:31:51 +0100
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca>
Message-ID: <199712110831.JAA00252@pc25.none>

>>>>> Paul Gilbert writes:

> I've been reviewing how the make process for my library should be set
> up and I noticed that the "How Can I Create an R Package?" part of the
> FAQ gives instructions to put a Makefile in pkg/src but the "How Can
> Add-on Packages Be Installed?" part of the FAQ does not seem to give
> any indication that a make may be necessary, unless
>      $ R INSTALL pkg lib
> does a make, which I don't think it does.

> Also, this Makefile has to be passed config information, so it must be
> called some way from the main R Makefile I think, but I don't see
> exactly how this is suppose to work, especially if the library is not
> under R/library. Can someone explain this?

Thomas already answered the above.

> A related question is that I am looking for a general strategy for
> distributing code which may get installed under R or S. To date, I
> have been working with one Makefile, which has different targets for R
> or for S. Obviously, the procedure for installing this is not quite as
> simple as suggested for add on packages in the FAQ. Does anyone have
> suggestions for a good way to organize this?

Under R, you need to organize everything as detailed in the FAQ.  There
is no need for a top-level Makefile, so you could use this for taking
care of the R- (S) part [having hinstall and qinstall or whatever they
are called targets].

However, keep in mind that in the long run, all R SOURCE files will need
to have a `.R' extension (as of 0.60, this is already a must for data).

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

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 08:43:55 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 09:43:55 +0100
Subject: R-alpha: libraries
In-Reply-To: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
References: <97Dec10.152221est.26766@mailgate.bank-banque-canada.ca>
Message-ID: <199712110843.JAA00277@pc25.none>

>>>>> Paul Gilbert writes:

> I have been trying to set up my time series library with the new
> library mechanism. It is a fairly large amount of code and previously
> I split it into five pieces in order to load it into R. (Has anything
> changed which might suggest I shouldn't need to do this anymore?)  The
> five files are called dse1, dse2, dsex1, dsex2, and tframe.With the
> new way of handling libraries I put these in
> /home/res/gilp/dse/pub/Rdse/R and ran

> [58] /home/res/gilp/dse/pub : R INSTALL Rdse dse1
> Installing package `Rdse' ...
> R
> DONE
> No man pages found in package `Rdse'

> (BTW this prepend $pwd to Rdse and does not seem to like a fully
> qualified path for the location, so it has to be done in the directory
> above Rdse)

> Indications seem to be that this worked (except for the man pages), but when I
> set RLIBS and run R the library is not found:
>> library()
> Packages in library `/home/res/gilp/dse/pub/Rdse':

> Packages in library `/home/res8/gilp/R-versions/R-0.60.1/R-0.60.1/library':
> ...

> However, if I call one of the files Rdse and do
> R INSTALL Rdse Rdse

> then things seem to work correctly in that it finds that file. Does
> this mean that the file with the code must have the same name as the
> package name, which must be the same as the directory name?
> (i.e. .../pkg/R/pkg) Does this mean that I have to create separate
> library directories for each of the pieces?

There is a bug in the R 0.60 INSTALL mechanism that will be fixed in the
next release.

What you are talking about is splitting a PACKAGE into separate MODULES
(Core Team, correct me if I am wrong, was this the term we agreed on?).
This would result in an extension of the current INSTALL and library()
scenario that I would very much appreciate.

Re loading, my idea was to have

	library(MODULE, pkg = PACKAGE, lib = LIBRARY)

or something similar which would allow you to load the module from the
package in the library.  Of course, the inferface is open for
discussion.

Re installing, this is not do easy.  One could have a Makefile in the
`R' subdir indicating how to combine the various .R files into modules,
but I am not quite sure how to do this right.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 08:49:03 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 09:49:03 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca> (message
 from Paul Gilbert on Wed, 10 Dec 1997 10:40:32 -0500)
Message-ID: <199712110849.JAA04605@sophie.ethz.ch>

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

    PaulG> I have a class "tframe" with more specific classes indicating
    PaulG> how time is being represented, such as

    >> class(tframe(data))
    PaulG> [1] "ts" "tframe"

    PaulG> but now "[.ts" produces warning messages

    >> tframe(data)[2]
    PaulG> Warning: Not returning a time series object [1] 2006.25

    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
    PaulG> I've commented out the line # warning("Not returning a time
    PaulG> series object") in "[.ts". I'm not sure if this is the best
    PaulG> solution, but something is necessary.

I agree that this can be a pain.
On the other hand, I think it can be very helpful to get this warning
when you subscript a time-series and don't get one anymore.

I think we want
 1) No warning if only one element of a time-series is chosen
	(however, even this is debatable:
	 Think of a function containing code
		i <- !is.na(...) && a < b
		result.ts <- my.ts[i]

	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

 2) A warning otherwise -- which can be turned off ---
    I propose to create an option (one of `options()') to handle this.

Another -- maybe even better -- alternative :
We introduce an argument
				drop = TRUE
as for arrays.
Then the warning would only happen in the case  drop = FALSE
when it was really impossible to make an (equispaced) ts out of the
subscripted one.

------------------------------------------------------------

BTW: does anyone care if I completely drop the  "R-alpha:" string
						 --------
     that is automagically prepended to the subject on R-devel
	(unless it's already part of the subject) ?

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Kurt.Hornik@ci.tuwien.ac.at  Thu Dec 11 09:05:48 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 11 Dec 1997 10:05:48 +0100
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
In-Reply-To: <199712110849.JAA04605@sophie.ethz.ch>
References: <97Dec10.141431est.27328@mailgate.bank-banque-canada.ca>
 <199712110849.JAA04605@sophie.ethz.ch>
Message-ID: <199712110905.KAA02711@pc25.none>

>>>>> Martin Maechler writes:

>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
PaulG> I have a class "tframe" with more specific classes indicating
PaulG> how time is being represented, such as

>>> class(tframe(data))
PaulG> [1] "ts" "tframe"

PaulG> but now "[.ts" produces warning messages

>>> tframe(data)[2]
PaulG> Warning: Not returning a time series object [1] 2006.25

PaulG> Even my simplest tests produce hundreds of lines of warnings, so
PaulG> I've commented out the line # warning("Not returning a time
PaulG> series object") in "[.ts". I'm not sure if this is the best
PaulG> solution, but something is necessary.

> I agree that this can be a pain.
> On the other hand, I think it can be very helpful to get this warning
> when you subscript a time-series and don't get one anymore.

> I think we want
>  1) No warning if only one element of a time-series is chosen
> 	(however, even this is debatable:
> 	 Think of a function containing code
> 		i <- !is.na(...) && a < b
> 		result.ts <- my.ts[i]

> 	 wouldn't you want to be warned if `result.ts' is not a ts anymore? )

>  2) A warning otherwise -- which can be turned off ---
>     I propose to create an option (one of `options()') to handle this.

> Another -- maybe even better -- alternative :
> We introduce an argument
> 				drop = TRUE
> as for arrays.
> Then the warning would only happen in the case  drop = FALSE
> when it was really impossible to make an (equispaced) ts out of the
> subscripted one.

This is not MAYBE better, but what we really should do.  It conforms
to the general logic of subscripting as was agreed upon.

> ------------------------------------------------------------

> BTW: does anyone care if I completely drop the  "R-alpha:" string
> 						 --------
>      that is automagically prepended to the subject on R-devel
> 	(unless it's already part of the subject) ?

No, of course not.

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

From plummer@iarc.fr  Thu Dec 11 10:02:05 1997
From: plummer@iarc.fr (Martyn Plummer)
Date: Thu, 11 Dec 1997 11:02:05 +0100 (MET)
Subject: R-alpha: "[.ts"  warning "Not returning time series.."
Message-ID: <XFMail.971211111648.plummer@iarc.fr>

On 11-Dec-97 maechler@stat.math.ethz.ch wrote:
>>>>>> "PaulG" == Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
>
>    PaulG> I have a class "tframe" with more specific classes indicating
>    PaulG> how time is being represented, such as
>
>    >> class(tframe(data))
>    PaulG> [1] "ts" "tframe"
>
>    PaulG> but now "[.ts" produces warning messages
>
>    >> tframe(data)[2]
>    PaulG> Warning: Not returning a time series object [1] 2006.25
>
>    PaulG> Even my simplest tests produce hundreds of lines of warnings, so
>    PaulG> I've commented out the line # warning("Not returning a time
>    PaulG> series object") in "[.ts". I'm not sure if this is the best
>    PaulG> solution, but something is necessary.
>
>I agree that this can be a pain.
>On the other hand, I think it can be very helpful to get this warning
>when you subscript a time-series and don't get one anymore.
>
>I think we want
> 1) No warning if only one element of a time-series is chosen
>       (however, even this is debatable:
>        Think of a function containing code
>               i <- !is.na(...) && a < b
>               result.ts <- my.ts[i]
>
>        wouldn't you want to be warned if `result.ts' is not a ts anymore? )
>
> 2) A warning otherwise -- which can be turned off ---
>    I propose to create an option (one of `options()') to handle this.
>
>Another -- maybe even better -- alternative :
>We introduce an argument
>                               drop = TRUE
>as for arrays.
>Then the warning would only happen in the case  drop = FALSE
>when it was really impossible to make an (equispaced) ts out of the
>subscripted one.

Sorry this is my fault. I suggested this code because the previous
version of [.ts<- did not allow you to subscript time series at all
without unclassing them.  The current version at least tries to preserve
time series objects.  I think what we really need is an irregular time
series class like the S-PLUS "its". Then array subscripting can do the
right thing, and do it silently. In the absence of such a class in R,
I put the warning in.  The message could be translated as "fix me", so
I'm glad you brought it up.

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

From steuer@gigamain.Statistik.Uni-Dortmund.DE  Thu Dec 11 10:21:09 1997
From: steuer@gigamain.Statistik.Uni-Dortmund.DE (Detlef Steuer)
Date: Thu, 11 Dec 1997 11:21:09 +0100 (MET)
Subject: R-alpha: fft does not act as described in help(fft)
Message-ID: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>

Hello!

thank you for your efforts creating R!

While preparing the next lessons I found that I had
to multiply with 1/length(x) by hand if I want to 
get the inverse Fouriertransform.

The help states it will do it by itself.

Version R-0.60.1, Linux

Seems to be pretty easy to correct either the fft or :-) the help(fft)!

Cu Detlef


Detlef Steuer Universitaet Dortmund	                	///////
LS Computergestuetzte Statistik         		 U N I D O ///  
steuer@gigamain.statistik.uni-dortmund.de         	______///////  
Tel: ++49 +231 755 3139 Fax: ++49 +231 755 4387         \_\_\_\/////
						         \_\_\_\///
						          \_\_\_\/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 11 11:37:27 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 11 Dec 1997 12:37:27 +0100 (MET)
Subject: R-alpha: core dumped when reloading a library
Message-ID: <Pine.OSF.3.96.971211123003.3031A-100000@alpha>

I am currently finalising the writing of a library named "stable".
When I consider the following sequence

> library(stable)
> detach("package:stable")
$ R INSTALL stable    (after some correction in my library)
>library(stable)
> dstable(0)      # computation of the stable density density at 0

I get a core dumped.

Can this be avoided?
 Philippe

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

From pgilbert@bank-banque-canada.ca  Thu Dec 11 16:46:37 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 11:46:37 -0500
Subject: R-alpha: Re: R-beta: R FAQ v0.60
References: <199712091748.SAA29807@aragorn.ci.tuwien.ac.at>
 <97Dec10.164307est.26514@mailgate.bank-banque-canada.ca> <199712110831.JAA00252@pc25.none>
Message-ID: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>

>However, keep in mind that in the long run, all R SOURCE files will need
>to have a `.R' extension (as of 0.60, this is already a must for data).

Does this mean that files like, for example, ../R/library/mva/R/mva should be
called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
the file name must end in .R? If the latter is being suggested then I object
very strongly. While this is a useful convention it is not something which
should be forced. The programs I use which do this are a real pain. If S where
to do a similar thing (.S) then I would be forced to maintain a complete
duplicate set of files (or use links which is also a pain).

(I haven't got as far as loading my data, so I may report on that later.)

Paul Gilbert

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

From thomas@biostat.washington.edu  Thu Dec 11 17:05:25 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 09:05:25 -0800 (PST)
Subject: R-alpha: Re: R-beta: R FAQ v0.60
In-Reply-To: <97Dec11.114820est.26586@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:
> >However, keep in mind that in the long run, all R SOURCE files will need
> >to have a `.R' extension (as of 0.60, this is already a must for data).
> 
> Does this mean that files like, for example, ../R/library/mva/R/mva should be
> called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> the file name must end in .R? 

It only applies to package source code: so

src/library/SOMEPKG/R/file	should be 
src/library/SOMEPKG/R/file.R    and 
src/library/SOMEPKG/data/datafile      should be
src/library/SOMEPKG/data/datafile.R    

for the installer to install them.

Similarly, the documentation must be in .Rd files

This has the benefit of ignoring things like emacs backup files while you
are developing a package, and of making packages easier to understand
(possibly).

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 11 17:56:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 11 Dec 1997 18:56:31 +0100
Subject: R-alpha: fft does not act as described in help(fft)
In-Reply-To: <XFMail.971211112706.steuer@gigamain.statistik.uni-dortmund.de>
 (message from Detlef Steuer on Thu, 11 Dec 1997 11:21:09 +0100 (MET))
Message-ID: <199712111756.SAA05761@sophie.ethz.ch>

>>>>>  Detlef Steuer <steuer@gigamain.Statistik.Uni-Dortmund.DE> writes:

    Detlef> Hello!  thank you for your efforts creating R!

Thank you for reporting the inaccuracy!

Please ``R-develer''s,  keep these reports flowing..!

    Detlef> While preparing the next lessons
(which lessons? -- I am curious)
    Detlef> I found that I had to multiply
    Detlef> with 1/length(x) by hand if I want to get the inverse
    Detlef> Fouriertransform.

    Detlef> The help states it will do it by itself.

    Detlef> Seems to be pretty easy to correct either the fft or :-) the
    Detlef> help(fft)!

I corrected the  help(fft).  It is now clear about NOT dividing and
gives an example showing how the inverse is got from ``inverse = TRUE''

The current behavior is the same as S, 
and we do want this in these basic things.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Thu Dec 11 18:46:44 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Thu, 11 Dec 1997 13:46:44 -0500
Subject: R-alpha: inheritance ([.ts)
Message-ID: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>

While commenting out the previously mentioned warning seems to work, I have been
reflecting on this problem and there seems to be an issue wrt inheritance that I
do not understand properly. Perhaps some gurus could comment.

As mentioned previously, I have a class "tframe" with more specific classes
indicating how time is being represented, such as
> class(tframe(data))
[1] "ts"     "tframe"
and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].

Now tframe(data) is NOT a "ts", it is a specific kind of "tframe". When I coded
this I was expecting it would use  "[.default", so to date I guess it has just
been working accidentally.

Does the fact that there is a class "ts" mean that one should not have another
class with "ts" as its more specific class? This seems like a pretty severe
limitation.

Paul Gilbert




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

From thomas@biostat.washington.edu  Thu Dec 11 18:59:39 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Thu, 11 Dec 1997 10:59:39 -0800 (PST)
Subject: R-alpha: inheritance ([.ts)
In-Reply-To: <97Dec11.134831est.26628@mailgate.bank-banque-canada.ca>
Message-ID: <Pine.SUN.3.95.971211105108.14909B-100000@chekov>

On Thu, 11 Dec 1997, Paul Gilbert wrote:

> While commenting out the previously mentioned warning seems to work, I have been
> reflecting on this problem and there seems to be an issue wrt inheritance that I
> do not understand properly. Perhaps some gurus could comment.

There is no real "inheritance" mechanism in R.  Objects have a list of
classes, and UseMethod/NextMethod search this list from left to right,
pasting the class name on to the generic method name, until a function is
found. The ability to mimic inheritance relies on class names being
unique, so that, for example gee inherits from glm which inherits from lm.


> As mentioned previously, I have a class "tframe" with more specific classes
> indicating how time is being represented, such as
> > class(tframe(data))
> [1] "ts"     "tframe"
> and in R0.60 "[.ts" produces warning messages when I use tframe(data)[2].
 
> Does the fact that there is a class "ts" mean that one should not have another
> class with "ts" as its more specific class? This seems like a pretty severe
> limitation.

Yes it does. It is a limitation especially as there is only one namespace.
It is also unfortunate that a lot of people have used method-like names
the other way around, so that eg cox.zph is a proportional hazards test (z
ph) for a cox model, not a "cox" for a "zph" object.

The fix to this is to use something like 
	c("ts.tsframe", "tsframe")
for a more specific ts subclass of tsframe.  It's a bit ugly, but it
works.

	-thomas

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 12 08:52:34 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 12 Dec 1997 09:52:34 +0100
Subject: probability and random numbers -- I'm looking at Brown's dcdflib
Message-ID: <199712120852.JAA06458@sophie.ethz.ch>

I'm looking at Brown's dcdflib
	(announced on S-news a few days ago)
in order to get code for  noncentral t and F   into R;
also the noncentral chisq is still not complete.

If anyone is particularly knowledgable in this field
or interested in testing, please let me know.
	(this is NOT a high priority project,
	 but I write to you in order to  coordinate work).

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/


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

From phlamber@luc.ac.be  Fri Dec 12 09:25:22 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Fri, 12 Dec 1997 10:25:22 +0100 (MET)
Subject: files ending by .R in packages
In-Reply-To: <Pine.SUN.3.95.971211090029.13765C-100000@chekov>
Message-ID: <Pine.OSF.3.96.971212101301.16955B-100000@alpha>



On Thu, 11 Dec 1997, Thomas Lumley wrote:

> On Thu, 11 Dec 1997, Paul Gilbert wrote:
> > >However, keep in mind that in the long run, all R SOURCE files will need
> > >to have a `.R' extension (as of 0.60, this is already a must for data).
> > 
> > Does this mean that files like, for example, ../R/library/mva/R/mva should be
> > called ../R/library/mva/R/mva.R or does it mean that in R when I use source()
> > the file name must end in .R? 
> 
> It only applies to package source code: so
> 
> src/library/SOMEPKG/R/file	should be 
> src/library/SOMEPKG/R/file.R    and 
> src/library/SOMEPKG/data/datafile      should be
> src/library/SOMEPKG/data/datafile.R    
> 
> for the installer to install them.
> 

Personnally, I would appreciate that .r source files are also considered
when installing a package, as a .R file copied on a msdos floppy disk
becomes a .r file.

Philippe

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

From rossetti@stat.unipg.it  Fri Dec 12 20:47:58 1997
From: rossetti@stat.unipg.it (Andrea Rossetti)
Date: Fri, 12 Dec 1997 21:47:58 +0100
Subject: R-beta: new executable
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz>
Message-ID: <3491A2FE.55C098CF@stat.unipg.it>

Robert Gentleman wrote:

> I have just put up a new executable as a replacement for the one in
>   rseptbeta.zip
>  there have only been a few changes; mostly to the menu's. I am about
>  to start on a major overhaul including getting survival to work and
>  grabbing the 0.60 version once it's stable.
>
> --->> Please let me know about other enhancements you want....<<---

I'm very interested in time series anlaysis (acf, pacf, arima modelling, and all
other) is a possible enhancement for the WINDOWS 95 version of R!(?)

Thanks.

Andrea Rossetti.

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Sat Dec 13 22:23:13 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Sat, 13 Dec 1997 23:23:13 +0100
Subject: time series software: more basic functions,  who?
In-Reply-To: <3491A2FE.55C098CF@stat.unipg.it> (message from Andrea Rossetti
 on Fri, 12 Dec 1997 21:47:58 +0100)
Message-ID: <199712132223.XAA14687@jessica.ethz.ch>

Caro Andrea,

si e possibile, prego, uilizi soltanto un solo dei gruppi  R-...
Questo va per il mio italiano...

Apropos Time Series Software, there's not much in the latest version
0.60.1,  for unix either.

Since there are several people interested in having time series functions
available, I'd propose  some of you `stand up' and say:
	I'll do this...
and then post code to R-devel.
Or alternatively, send it to Ross  (who had started on some of these some
months ago...)
or someone else who coordinates these.
What do you think?
Paul Gilbert, I think this complementary to your  DSE library?
If not, we should maybe wait till DSE is available as R package
(how ?) soon.

Who is interested in doing work here?
please reply to me, and I'll collect and summarize to R-devel.

Martin Maechler <maechler@stat.math.ethz.ch>		 <><
Seminar fuer Statistik, SOL G1
ETH (Federal Inst. Technology)	8092 Zurich	 SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086
http://www.stat.math.ethz.ch/~maechler/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 19:21:25 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 14:21:25 -0500
Subject: RedHat 5.0 Linux libc to glibc
Message-ID: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>

This was posted on another list I follow and I thought it might be important if
you are not already aware of the change:

>Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
>glibc version 2.0 as the standard C library. This arranges its include
>files differently and has resulted in MOST programs needing changes to
>compile under Redhat 5.0.

Paul Gilbert


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

From bates@stat.wisc.edu  Tue Dec 16 20:26:09 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 16 Dec 1997 14:26:09 -0600
Subject: RedHat 5.0 Linux libc to glibc
In-Reply-To: Paul Gilbert's message of Tue, 16 Dec 1997 14:21:25 -0500
References: <97Dec16.142336est.26740@mailgate.bank-banque-canada.ca>
Message-ID: <6rpvmxhw66.fsf@franz.stat.wisc.edu>

Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

> This was posted on another list I follow and I thought it might be important if
> you are not already aware of the change:
> 
> >Between Redhat 4.2 and Redhat 5.0, Redhat changed from libc version 5 to
> >glibc version 2.0 as the standard C library. This arranges its include
> >files differently and has resulted in MOST programs needing changes to
> >compile under Redhat 5.0.

The changes between Debian GNU/Linux versions 1.3 and 2.0 are also
primarily a change from libc5 to libc6 (a.k.a. glibc 2).   R-0.60.1
compiles cleanly under either.  There is no need for changes in the
source code for R.  I would expect that the same would be true under
RedHat.

I would be very interested in contacting people who are running RedHat 
5.0 to see if the version of libc6 on RedHat still has a problem with
the ecvt system function.   I reported a bug on that several months
ago and the libc6 versions I am using still have the same bug.

Here is a C source file that exercises the bug
#include <stdio.h>
#include <stdlib.h>

void main(int argc, char **argv)
{
  int decpt, sign; char * result;
  char buf[256];
  result = ecvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = ecvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 1234.567, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) -987.654321, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = fcvt((double) 0, (size_t) 7, &decpt, &sign);
  printf("result is %s, decpt is %d, sign is %d\n", result, decpt, sign);
  result = gcvt((double) 1234.567, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) -987.654321, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
  result = gcvt((double) 0, (size_t) 7, buf);
  printf("result of gcvt is %s\n", result);
}

When compiled and run it produces obviously incorrect results.
result is 11234.567, decpt is 4, sign is 0
result is 9987.6543, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result is 11234.567000, decpt is 4, sign is 0
result is 9987.654321, decpt is 3, sign is 1
result is 00.000000, decpt is 1, sign is 0
result of gcvt is 1234.567
result of gcvt is -987.6543
result of gcvt is 0

For one thing the string returned as the result should not contain a
decimal point.  Is someone is running RedHat 5.0 could you check the
results on there?
-- 
Douglas Bates                            bates@stat.wisc.edu
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Tue Dec 16 20:08:38 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Tue, 16 Dec 1997 15:08:38 -0500
Subject: time series
References: <199710290308.QAA12299@stat1.stat.auckland.ac.nz> <3491A2FE.55C098CF@stat.unipg.it>
Message-ID: <97Dec16.152847est.26753@mailgate.bank-banque-canada.ca>

>I'm very interested in time series anlaysis (acf, pacf, arima modelling, and
>all other) is a possible enhancement for the WINDOWS 95 version of R!(?)

I am still hoping to make a Unix version of my DSE library available this week.
If I don't make it then it will be after the New Year as I'm away for two weeks.
I will make all the source code available, so the only real sense in which this
is a Unix version is that the installation procedures are set up for Unix.

The library does a lot of linear, time-invariant, vector ARIMA and state space
stuff, but does not do ar, acf, pacf or arima.mle as supplied in Splus. Below is
a rough start at ar and acf, but they are not yet working right. If anyone is
interested in finishing them I would be very happy. I haven't tried pacf and
I've never had any interest in arima.mle as it did not work for vector series.

The library should work (with the exception of a few non-critical  functions) in
the existing Windows version of R, as I had most of it working in an older
version under Linux. I was going to wait until Robert has the Window version up
to 0.60, but the main problem is that I have little familiarity with Windows. So
if anyone wants to work on that, again, I would be more than happy.

There is a stand alone subset of the library (I call tframe) which is a kernel
for my other code.  I'm fairly sure this work in the Windows version of R. This
provides a "classes and methods" way of handling the time dimension of an
object,  which I think is very useful for making  code that can fairly easily
handle new time representations. It also provides a replacement for tsmatrix and
some plotting routines which are useful for time series.

Paul Gilbert
___________

ar.test <-function(x, aic=T, order.max=2, method="yule-walker")
   {# this seems to work, in the sense of producing estimates which are
    # asymtotically as good as (or as bad as) Splus ar, at least for
    # stationary data. But estimates are not the same.
    # For non-stationary data Splus ar does better, but neither method is really
valid.
    if(method=="burg") stop("burg method for ar not yet implemented.")
    warning(" ar function not complete and not checked & default order.max=2.")
    if (is.vector(x))x <- matrix(x, length(x),1)
    sampleT <- nrow(x)
    if (is.null(order.max)) order.max <- round(10*log10(sampleT/ncol(x)))
    AC <- array(NA, c(order.max+1, ncol(x), ncol(x)))
x <- unclass(x)
tsp(x) <-NULL
    x <- x - t(array(apply(x,2,sum)/nrow(x), rev(dim(x))))
    for (i in 0:order.max)
   {Om<- (t(x[(i+1):sampleT,,drop=F]) %*%
                   x[1:(sampleT-i),,drop=F])/(sampleT-i)
 #   Om<- cor(x[(i+1):sampleT,,drop=F],
        #            x[1:(sampleT-i),,drop=F]) # cor seems better than var
       #    if(i==0) Om0 <- solve(Om)
       #                     # nrow above for univariate case
       #    Om <- Om0 %*% Om  #Yule-Walker eqn. should solve without this
           AC[i+1,,] <-  Om
          }

   # now solve yule walker eqns.
   n <- ncol(x)
   a <- matrix(NA, n*(order.max), n*(order.max) )
   b <- matrix(NA, n*(order.max), n )
   # using AC[1,,] in place of I
   # there must be a better way (with outer?)
    for (i in 0:(order.max-1))
       for (j in 0:(order.max-1))
   a[(1+i*n):(n+i*n),(1+j*n):(n+j*n)] <- AC[abs(i-j)+1,,]
    for (i in 1:order.max)
   b[(1+(i-1)*n):(i*n),] <- AC[i+1,,]
   AR <-solve(a, b)
   if (n==1) AR <- matrix(AR, length(AR), 1)
   #AR <- solve(t(a),b) # the off-diag values may require this??
 #  ar <- aperm(array(AR,c(dim(AC)-c(1,0,0))), c(2,1,3))
    ar <- array(NA, c(order.max, ncol(x), ncol(x)))
    for (i in 1:order.max)
 ar[i,,] <- AR[(1+(i-1)*n):(i*n),]
   order <- order.max # need aic here
   list(ar=ar, order=order, order.max=order.max, method=method)
   }


acf <-function (residual, plot = F, type = "correlation")
       {if (plot) warning(" acf plot not yet supported.")
        if(0==charmatch(type,c("covariance","correlation","partial"),nomatch=0))

             stop("type not allowed in acf")
        if (is.vector(residual))residual <- matrix(residual, length(residual),1)

 sampleT <- nrow(residual)
        N <- round(10*(log10(sampleT)-log10(ncol(residual))))
        acf <- array(NA, c(N, ncol(residual), ncol(residual)))
 for (i in 0:(N-1))
   {Om<- cov(residual[(i+1):sampleT,,drop=F],
                    residual[1:(sampleT-i),,drop=F])
           if (type=="correlation")
                {if(i==0) Om0 <- diag(1/sqrt(diag(Om)),nrow=nrow(Om))
                            # nrow above for univariate case
                 Om <- Om0 %*% Om %*% Om0
                }
           acf[i+1,,] <-  Om
          }
        if (type=="partial")
          {warning("acf type partial not yet supported. 0 value being returned")

           acf <- array(0, dim(acf))
          }
 list(acf=acf, type=type )
       }


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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 10:28:31 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 11:28:31 +0100
Subject: "'" prints as "\'"
Message-ID: <199712171028.LAA01254@sophie.ethz.ch>

(This reported before).
In R,
	"'"
prints as

[1] "\'"

which is different from S, and is really unnecessary.
((it is just now uglyfying the output of a function which I wrote for S
  and now use in R)).

Is there any good reason for the current behavior?

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 10:38:00 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 11:38:00 +0100
Subject: "'" prints as "\'"
In-Reply-To: <199712171028.LAA01254@sophie.ethz.ch>
References: <199712171028.LAA01254@sophie.ethz.ch>
Message-ID: <199712171038.LAA04074@pc25.none>

>>>>> Martin Maechler writes:

> (This reported before).
> In R,
> 	"'"
> prints as

> [1] "\'"

> which is different from S, and is really unnecessary.
> ((it is just now uglyfying the output of a function which I wrote for S
>   and now use in R)).

> Is there any good reason for the current behavior?

Yes.  To have ESS font-lock the output correctly.

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

From rossini@math.sc.edu  Wed Dec 17 14:57:25 1997
From: rossini@math.sc.edu (Anthony Rossini)
Date: 17 Dec 1997 09:57:25 -0500
Subject: "'" prints as "\'"
In-Reply-To: Kurt Hornik's message of "Wed, 17 Dec 1997 11:38:00 +0100"
References: <199712171028.LAA01254@sophie.ethz.ch> <199712171038.LAA04074@pc25.none>
Message-ID: <wncvhwoqap6.fsf@fhat.stat.sc.edu>


>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >> (This reported before).
    >> In R,
    >> "'"
    >> prints as

    >> [1] "\'"

    >> which is different from S, and is really unnecessary.
    >> ((it is just now uglyfying the output of a function which I wrote for S
    >> and now use in R)).

    >> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

Poor justification.  I'll look into this more in Feb/Mar...

best,

-- 
-tony (Anthony Rossini)	           Statistics Dept., U South Carolina
rossini@stat.sc.edu	           Columbia, SC 29208
http://www.stat.sc.edu/~rossini/   803-777-3578(O) 803-777-4048 (fax)  
        "'Bother,' said Pooh, as Cthulhu rose up and ate him."
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From pgilbert@bank-banque-canada.ca  Wed Dec 17 16:05:16 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 11:05:16 -0500
Subject: library/data
Message-ID: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>

I have some data files with my library which are used for examples and testing
the code. To date I have kept them in a subdirectory I called ../dse/dsedata,
but I am trying to move those to .../dse/data as perscribed for installing
libraries. However, these datasets are not all R object, some are just files
that I source from within a function, and one is accessed by a separate process
that I call from R.

1/ Should the data subdirectory be reserved for R objects?

2/ Could someone explain or point me to were I can find the explanation of how R
objects in this data subdirectory should be constructed? Are these objects
automatically loaded when a library is loaded?

3/ To date I have been able to find my subdirectory by setting a variable
indicating its location in the library file from which code is loaded.
Admittedly this was a kludge, but I could do it because I had my own make which
embedded the location in the file when it was installed. I was not very happy
with this trick, but it seems I completely lose this ability using R INSTALL.
>From within R is there a good way to find the location of a library when it is
loaded or after it is loaded?

Paul Gilbert

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Wed Dec 17 16:30:52 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 17 Dec 1997 17:30:52 +0100
Subject: "'" prints as "\'"
In-Reply-To: <wncvhwoqap6.fsf@fhat.stat.sc.edu> (message from Anthony Rossini
 on 17 Dec 1997 09:57:25 -0500)
Message-ID: <199712171630.RAA01763@sophie.ethz.ch>

>>>>> "tony" == Anthony Rossini <rossini@math.sc.edu> writes:

>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Martin Maechler writes:
    >>> (This reported before).  In R, "'" prints as

    >>> [1] "\'"

    >>> which is different from S, and is really unnecessary.  ((it is just
    >>> now uglyfying the output of a function which I wrote for S and now
    >>> use in R)).

    >>> Is there any good reason for the current behavior?

    Kurt> Yes.  To have ESS font-lock the output correctly.

    tony> Poor justification.  I'll look into this more in Feb/Mar...

It is actually wrong.  There's no problem with font-locking here...

I think we will change this, in the ``next after next'' release of R.

Martin

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

From Kurt.Hornik@ci.tuwien.ac.at  Wed Dec 17 17:46:42 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Wed, 17 Dec 1997 18:46:42 +0100
Subject: library/data
In-Reply-To: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca>
Message-ID: <199712171746.SAA04913@pc25.none>

>>>>> Paul Gilbert writes:

> I have some data files with my library which are used for examples and
> testing the code. To date I have kept them in a subdirectory I called
> ../dse/dsedata, but I am trying to move those to .../dse/data as
> perscribed for installing libraries. However, these datasets are not
> all R object, some are just files that I source from within a
> function, and one is accessed by a separate process that I call from
> R.

Official R speak actually is `package' for what you call `library'.

> 1/ Should the data subdirectory be reserved for R objects?

No.  You can have data of any kind ther.  However, currently data() only
works for R objects, i.e., files with R code and names ending in `.R'.
Within soon, this should be extended so that e.g. `.tab' is using for
tables (and we still have to determine how to treat headers ...).

> 2/ Could someone explain or point me to were I can find the
> explanation of how R objects in this data subdirectory should be
> constructed? Are these objects automatically loaded when a library is
> loaded?

No, they are not loaded automatically.  Currently, there is (still) no
way to attach a directory.  This will change eventually.

If you build a package for use with R and there is no reason to store
data in a specific format, you might as well try to dump() your object
and put the result of that into the data dir of the pkg (thus you'd have
sourceable R code etc.)  If you want to distribute something in some
other format, e.g. `file.of', then `file.R' should contain the R code
for reading the contents of `file.of' into R.

> 3/ To date I have been able to find my subdirectory by setting a
> variable indicating its location in the library file from which code
> is loaded.  Admittedly this was a kludge, but I could do it because I
> had my own make which embedded the location in the file when it was
> installed. I was not very happy with this trick, but it seems I
> completely lose this ability using R INSTALL.  >> From within R is
> there a good way to find the location of a library when it is loaded
> or after it is loaded?

Not quite.  There is a function called system.file() which does
something similar:

R> system.file("R/base")
[1] "/usr/local/lib/R/library/base/R/base"
R> system.file("data/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"
> system.file("*/index.doc")
[1] "/usr/local/lib/R/library/base/data/index.doc"

Would it be important to know the location of a package?

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

From pgilbert@bank-banque-canada.ca  Wed Dec 17 19:00:31 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Wed, 17 Dec 1997 14:00:31 -0500
Subject: library/data
References: <97Dec17.110640est.26756@mailgate.bank-banque-canada.ca> <199712171746.SAA04913@pc25.none>
Message-ID: <97Dec17.140207est.26702@mailgate.bank-banque-canada.ca>

>Official R speak actually is `package' for what you call `library'.

Yes, I forgot, sorry.
Thanks for all the other details.

>Would it be important to know the location of a package?

Probably not for the code, but if I put data in .../dse/data then I need to know
where it is in order to load it (and sometimes to pass the location to other
processes to load it). The way I've done this in S is to set a global variable
in .First.lib using the library and section arguments, but I don't think this is
available in R yet.

Paul


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

From ihaka@stat.auckland.ac.nz  Wed Dec 17 22:51:06 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Thu, 18 Dec 1997 11:51:06 +1300 (NZDT)
Subject: Development Plans
Message-ID: <199712172251.LAA26527@stat1.stat.auckland.ac.nz>

I thought that it might be useful (to myself as well as others) to
write down my current plans for working on R.  I have indexed things
by my (vague) feeling of priority.  If you think my priorities are
completely wrong, please feel free to set me straight :-).
As you can see, I am confining myself almost entirely to internal
tinkering - if someone would put another 24 hours into the day I'll
take a look at applications too.

	Ross


1. Revision Of The Graphics System

Paul Murrell and I (mostly Paul) are revising the R graphics system so
that it will allow multiple active devices, better hardcopy facilities
and more flexible plot layouts.
[Status: well under way].


2. Make The Source Tree More Gnu Compatible

This means having a target installation directory in mind, (probably
defaulting to /usr/local/lib/R-x.xx) in mind rather than building the
distribution in place.  This would make it reasonable to peel back one
level of directory structure. I.e. move the source of the current src
director up one level.  The "graphics" subdirectory would also disappear,
to be replaced by one or two bigger code chunks.
[Status: this and the Fortran change below are relatively simple to put
in place, but keeping the cvs history intact could be a problem]


3. Fortran Integration

Work on a real integration of Fortran into R.  This would mean
adapting the configuration procedures used by Octave to detect and
use Fortran.  As a consequence, the current duplication of C and
F77 sources would disappear.  It would also it possible to incorporate
a much richer set of numerical and other capabilities into R.
[Status: I have done some basic experiments and it looks pretty
easy to do]


4. Demand Loading Of Objects

This would be similar in spirit to Thomas Lumley's approach, but
would go on at a somewhat lower level and also allow selective
freeing of such objects when memory demands are high.  It would
also make it possible to think in terms of "attaching" directories
of objects.  (At attach time all the objects in a directory would
be registered as loadables, and loaded when required).
[Status: I have thought a bit about this.  It should be pretty simple
but no doubt there are a few undiscovered gotchas in there]


5. Change Internal Handling of Lists

Do a rewrite of the internal handing of lists so that they are
really generic vectors.  This will mean large volumes of fairly
flakey subsetting and mutation code can be removed.
[Status: It is important to get this done, but it will be a big task.
Almost everything will break during the switch]


6. Memory Management

Revisit the memory management system.  In particular, we need a better
way of storing strings, and of allowing the heap to grow, rather than
having everything allocated up front.
[Status: Preliminary wishful thinking ...]


7. Miscellaneous

Do something about namespace management.
Finish writing persp (and some other graphics primitives).
Implement missing functionality such as "aov" and "persp".                 
[Status: I have played with some of this]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 08:10:54 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Thu, 18 Dec 1997 09:10:54 +0100
Subject: model.matrix(.) and all that
Message-ID: <199712180810.JAA02547@sophie.ethz.ch>

Maybe just a minor thing,
but since we are aiming for  S compatibility, here :

       R> x_ 1:5
       R> model.matrix(x ~ x)
       Error: length of namelist must equal dims

whereas in  S,

	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From phlamber@luc.ac.be  Thu Dec 18 09:50:36 1997
From: phlamber@luc.ac.be (Philippe Lambert)
Date: Thu, 18 Dec 1997 10:50:36 +0100 (MET)
Subject: library/data
In-Reply-To: <199712171746.SAA04913@pc25.none>
Message-ID: <Pine.OSF.3.96.971218104505.27754B-100000@alpha>


> > 1/ Should the data subdirectory be reserved for R objects?
> 
> No.  You can have data of any kind ther.  However, currently data() only
> works for R objects, i.e., files with R code and names ending in `.R'.

What about files ending in .r?
(= result of copying a .R file on a dos formatted floppy disk).
Will they be recognized as R code files?
I have already mentioned this problem a few days ago, but there has not
been any reaction.

Thanks,
 Philippe

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

From p.dalgaard@biostat.ku.dk  Thu Dec 18 10:31:06 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 18 Dec 1997 11:31:06 +0100
Subject: model.matrix(.) and all that
In-Reply-To: Martin Maechler's message of Thu, 18 Dec 1997 09:10:54 +0100
References: <199712180810.JAA02547@sophie.ethz.ch>
Message-ID: <x2pvmvdjth.fsf@blueberry.kubism.ku.dk>

Martin Maechler <maechler@stat.math.ethz.ch> writes:

> 
> Maybe just a minor thing,
> but since we are aiming for  S compatibility, here :
> 
>        R> x_ 1:5
>        R> model.matrix(x ~ x)
>        Error: length of namelist must equal dims
> 
> whereas in  S,
> 
> 	model.matrix(x ~ x)  ===  model.matrix(x ~ 1)

... where I would have expected model.matrix(~x). Does this have any
untoward consequences for delete.response and all that?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From Martin Maechler <maechler@stat.math.ethz.ch>  Thu Dec 18 23:15:05 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 19 Dec 1997 00:15:05 +0100
Subject: numeric(0)[FALSE]  bug[let]
Message-ID: <199712182315.AAA04804@jessica.ethz.ch>

This is not a joke, but a problem appearing in real code of mine.
I used ifelse in a context which can be simplified to

R> ifelse(T, 3, NULL)
Error: incompatible types in subset assignment
R> ifelse(T, 3, numeric(0))
Error: invalid subscript type
R> 
R> ifelse
function (test, yes, no) 
{
        ans <- test
        test <- as.logical(test)
        nas <- is.na(test)
        ans[test] <- rep(yes, length = length(ans))[test]
        ans[!test] <- rep(no, length = length(ans))[!test]
        ans[nas] <- NA
        ans
}
R> 
R> numeric(0)[F]
Error: invalid subscript type
R> NULL[F]
NULL
R> 

--------------------------------------------

whereas  S-plus does as I expect:

S> ifelse(T, 3, NULL)
[1] 3
S> ifelse(T, 3, numeric(0))
[1] 3
S> 
S> NULL[F]
NULL
S> numeric(0)[F]
numeric(0)
S> logical(0)[F]
logical(0)
S> 
-----------------
I see an easy workaround for either fixing  ifelse(.) and or
solving my problem.

However, I think

	anytype(0)[FALSE]  should  return   
	anytype(0)

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

From pgilbert@bank-banque-canada.ca  Fri Dec 19 18:46:18 1997
From: pgilbert@bank-banque-canada.ca (Paul Gilbert)
Date: Fri, 19 Dec 1997 13:46:18 -0500
Subject: Error in parse
Message-ID: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>

In R 0.60.1 when I source a fairly large file of code I am getting:
Error in parse(file, n, text, prompt) : syntax error on line 2985

I don't see any error and it doesn't happen if I split the file in two pieces.
increasing  -v -n does not seem to help and does not change the location of the
error. Does anyone have suggestions?

Paul Gilbert


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

From Kurt.Hornik@ci.tuwien.ac.at  Mon Dec 22 09:24:20 1997
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Mon, 22 Dec 1997 10:24:20 +0100
Subject: Error in parse
In-Reply-To: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
Message-ID: <199712220924.KAA08507@pc25.none>

>>>>> Paul Gilbert writes:

> In R 0.60.1 when I source a fairly large file of code I am getting:
> Error in parse(file, n, text, prompt) : syntax error on line 2985

> I don't see any error and it doesn't happen if I split the file in two
> pieces.  increasing -v -n does not seem to help and does not change
> the location of the error. Does anyone have suggestions?

Two suggestions:

* Does the problem occur at the end of the file?  Then, the problem
might be a final newline ...

* Does the file contain ASCII 0 characters?

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 16:38:14 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 17:38:14 +0100
Subject: $CRAN/src/contrib/devel
Message-ID: <199712221638.RAA16954@galadriel.ci.tuwien.ac.at>


I have created the above directory for contributed R packages that are
considered as ``in development''. It is intended as a central
marketplace for code that is for various reasons ``unstable'' or
``incomplete'' but might be useful for others. If you want to
contribute some code, please include a README file in the tar ball
describing the problems etc.

I have started porting the main library section of Venables & Ripley's
MASS ... but I had time only for lda and qda (these seem to be
working) ... they can be found in=20

	$CRAN/src/contrib/devel/mass-0.01-1.tar.gz



Frohe Weihnachten & ein gl=FCckliches neues Jahr,

Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From Friedrich.Leisch@ci.tuwien.ac.at  Mon Dec 22 17:48:51 1997
From: Friedrich.Leisch@ci.tuwien.ac.at (Friedrich Leisch)
Date: Mon, 22 Dec 1997 18:48:51 +0100
Subject: some unresolved symbols ... does anybody know them
Message-ID: <199712221748.SAA19722@galadriel.ci.tuwien.ac.at>


I've tried (again) to port Hastie/Tibshirani's mda package and still got
stuck with some unresolved symbols ... does anybody know where these
are defined:

	R.binary: can't resolve symbol 'dbksl_'=09
	R.binary: can't resolve symbol 'dblepr_'
	R.binary: can't resolve symbol 'dqrdca_'
	R.binary: can't resolve symbol 'intpr_'
	R.binary: can't resolve symbol 'pack_'
	R.binary: can't resolve symbol 'sgram_'
	R.binary: can't resolve symbol 'sknotl_'
	R.binary: can't resolve symbol 'unpack_'
	R.binary: can't resolve symbol 'wmean__'

I tried to ask the original authors, but got no response so far.

Best,
Fritz

--=20
-------------------------------------------------------------------
                        Friedrich  Leisch                            =20
Institut f=FCr Statistik                      Tel: (+43 1) 58801 4541
Technische Universit=E4t Wien                 Fax: (+43 1)  504 14 98
Wiedner Hauptstra=DFe 8-10/1071      Friedrich.Leisch@ci.tuwien.ac.at
A-1040 Wien, Austria             http://www.ci.tuwien.ac.at/~leisch
     PGP public key http://www.ci.tuwien.ac.at/~leisch/pgp.key
-------------------------------------------------------------------

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

From bates@stat.wisc.edu  Tue Dec 23 21:28:36 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: Tue, 23 Dec 1997 15:28:36 -0600 (CST)
Subject: Debian package for R-0.61 uploaded
Message-ID: <m0xkbsS-000hhtC@franz.stat.wisc.edu>

I have uploaded a Debian package r-base_0.61.0-2_i386.deb to the
incoming directory at ftp.ci.tuwien.ac.at.  This package is built
against libc5, not libc6.  Turns out that was a bit more complicated
than I had hoped.

I have also created an RPM file for the same binary distribution and
will upload that shortly as r-base-0.61.0-2.i386.rpm.  I enclose some
information regarding the two packaged versions below.  Notice that
the rpm query indicates that not only is there a call to
/usr/local/bin/perl but there appears to be vestigial @PERL@ calls in
some of the scripts somewhere in the tree.  It may just be that I have
not cleared out all the foo.in files - I'll try to check.

Why is this release 2 of the Debian package you ask?  Well I found out 
after I uploaded release 1 to master.debian.org that I had botched the 
renaming of the original tar file.  I think this time it is ok.  It
doesn't affect the binary package. It only affects people who are
going to try to build the package from the sources.

Merry Christmas and a Happy New Year to all.

 # dpkg-deb -I r-base_0.61.0-2_i386.deb 
  new debian package, version 2.0.
  size 982660 bytes: control archive= 25313 bytes.
      854 bytes,    16 lines      control              
     1074 bytes,    46 lines      du                   
    65122 bytes,   932 lines      md5sums              
       18 bytes,     2 lines      shlibs               
  Package: r-base
  Version: 0.61.0-2
  Architecture: i386
  Depends: ldso (>= 1.8.0-0), libc5 (>= 5.4.0-0), libreadline2 (>= 2.1), ncurses3.0, xlib6 (>= 3.3-0)
  Suggests: g77
  Installed-Size: 3491
  Maintainer: Douglas Bates <bates@stat.wisc.edu>
  Description: `GNU S' - A language and environment for statistical computing.
   R is described by its authors as "not unlike" S, which is a language
   developed at Bell Laboratories for statistical computing and graphics.
   It provides support for a variety of statistical and graphical analyses.
   R is a true computer language which contains a number of control-flow
   constructions for iteration and alternation.  It allows users to add
   additional functionality by defining new functions.  Fortran and C
   code can be linked and called at run time.
   S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -i
 Name        : r-base                      Distribution: Debian
 Version     : 0.61.0                            Vendor: (none)
 Release     : 2                             Build Date: Tue Dec 23 15:13:12 1997
 Install date: (not installed)               Build Host: franz.stat.wisc.edu
 Group       : Converted/Debian              Source RPM: r-base-0.61.0-2.src.rpm
 Size        : 2989093
 Summary     : `GNU S' - A language and environment for statistical computing.
 Description :
 R is described by its authors as "not unlike" S, which is a language
 developed at Bell Laboratories for statistical computing and graphics.
 It provides support for a variety of statistical and graphical analyses.
 R is a true computer language which contains a number of control-flow
 constructions for iteration and alternation.  It allows users to add
 additional functionality by defining new functions.  Fortran and C
 code can be linked and called at run time.
 S is the statistician's Matlab and R is to S what Octave is to Matlab.
 # rpm -q -p /usr/src/redhat/RPMS/i386/r-base-0.61.0-2.i386.rpm -R
 @PERL@  
 /usr/local/bin/perl  
 /usr/bin/perl  
 /bin/sh  
 /bin/perl  
 libreadline.so.2  
 libncurses.so.3.0  
 libm.so.5  
 libdl.so.1  
 libc.so.5  
 libX11.so.6  
 libSM.so.6  
 libICE.so.6  
 /bin/sh  
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From warnes@biostat.washington.edu  Wed Dec 24 02:01:51 1997
From: warnes@biostat.washington.edu (Gregory R. Warnes)
Date: Tue, 23 Dec 1997 18:01:51 -0800 (PST)
Subject: package conversion script
In-Reply-To: <m0xkbsS-000hhtC@franz.stat.wisc.edu>
Message-ID: <Pine.LNX.3.96.971223173611.293F-200000@progress.biostat.washington.edu>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII


Attached is a script, UPDATELIBS, that does much of the work of converting
R packages/librares to the current format.  I've just used it to add
packages from my R-0.50-alpha-4 to R-0.61 (from the debian package
Douglass Bates just made available). 

It takes a list of package names/directories as parameters and does the
following:
  - renames $PACKAGE/funs to $PACKAGE/R
  - converts $PACKAGE/man/* to $PACKAGE/man/*.Rd using $RHOME/etc/Rman2Rd
  - compiles any C and FORTRAN functions in $PACKAGE/src and
    $PACKAGE/src-c using R COMPILE
  - creates a shared library from the resulting objects using R SHLIB and
  - installs the package using R INSTALL

Its pretty simple-minded, and I've done little error-handling except to
assure that the appropriate $PACKAGE/* directories exist .  Finally,
UPDATELIBS assumes that it is run in the parent directory of the package
file(s), (ie $PACKAGE/.. ) . 

I hope someone finds it useful.

-Greg

--8323328-376753582-882928911=:293
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=UPDATELIBS
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.971223180151.293G@progress.biostat.washington.edu>
Content-Description: 

IyEvYmluL3NoDQojIFVQREFURUxJQlMgOiB1cGRhdGUgUiBsaWJyYXJpZXMg
dG8gbmV3IGZvcm1hdCBhbmQgaW5zdGFsbA0KIw0KUkhPTUU9YFIgUkhPTUVg
DQpleHBvcnQgUkhPTUUNClRISVNESVI9YHB3ZGANCmV4cG9ydCBUSElTRElS
DQoNCmZvciBpIGluICQqDQpkbw0KICAgaWYgWyAtZCAkaSBdDQogICB0aGVu
DQogCSMgZmlyc3QgcmVuYW1lICJmdW5zIiB0byAiUiINCglpZiBbIC1kICRp
L2Z1bnMgXQ0KCXRoZW4NCgkJbXYgJGkvZnVucyAkaS9SDQoJZmkNCgkNCgkj
IG5vdyBjb252ZXJ0IG9sZCBoZWxwIGZpbGVzDQoJaWYgWyAtZCAkaS9tYW4g
XQ0KCXRoZW4NCgkgICBjZCAkaS9tYW4NCgkgICBmb3IgcCBpbiBgbHNgDQoJ
ICAgZG8NCgkgICAgICAkUkhPTUUvZXRjL1JtYW4yUmQgJHAgPiAkcC5SZA0K
CSAgIGRvbmUNCgkgICBjZCAkVEhJU0RJUg0KCWZpDQoJDQoJIyBjb21waWxl
IGNvZGUgICh0cnkgYm90aCBzcmMgYW5kIHNyYy1jKQ0KCWlmIFsgLWQgJGkv
c3JjIF0NCgl0aGVuDQoJICAgY2QgJGkvc3JjDQoJICAgUiBDT01QSUxFICou
YyAqLmYNCgkgICBSIFNITElCICRpLnNvICoubw0KCSAgIGNkICRUSElTRElS
DQoJZmkNCg0KICAgICAgICBpZiBbIC1kICRpL3NyYyBdDQogICAgICAgIHRo
ZW4NCiAgICAgICAgICAgY2QgJGkvc3JjLWMNCiAgICAgICAgICAgUiBDT01Q
SUxFICouYyAqLmYNCiAgICAgICAgICAgUiBTSExJQiAkaS5zbyAqLm8NCiAg
ICAgICAgICAgY2QgJFRISVNESVINCglmaQ0KDQoJIyBub3cgaW5zdGFsbA0K
CVIgSU5TVEFMTCAkaQ0KCQ0KICAgZWxzZQ0KICAgICAgCWVjaG8gKiogbGli
cmFyeSBkaXJlY3RvcnkgJGkgTk9UIEZPVU5EISAqKg0KICAgZmkNCmRvbmUN
Cg==
--8323328-376753582-882928911=:293--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From bates@stat.wisc.edu  Fri Dec 26 15:13:32 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 26 Dec 1997 09:13:32 -0600
Subject: "ifdef"'ing R/S code
Message-ID: <6rvhwcgmsj.fsf@franz.stat.wisc.edu>

I should have saved the messages about this but I didn't.  Can someone
remind me of what function or object to check from within a function
to determine if you are running R?  I need to make some changes in
code according to whether I am running it under R or under S and I
would prefer to keep one source tree.

Thomas Lumley:  I read your web page on porting S code to R.  It looks
very good.  You may want to change the parts about Calloc versus
calloc for the 0.61 release.  Also, little tidbits about the changes
in the interpreted code (such as the answer to the above query) could
help.  I realize that everything is in a state of flux so such
information quickly gets out of date but who trusts a web page more
than two weeks old anyway :-)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From Martin Maechler <maechler@stat.math.ethz.ch>  Fri Dec 26 15:27:14 1997
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Fri, 26 Dec 1997 16:27:14 +0100
Subject: "ifdef"'ing R/S code:  if(is.R())
In-Reply-To: <6rvhwcgmsj.fsf@franz.stat.wisc.edu> (message from Douglas Bates
 on 26 Dec 1997 09:13:32 -0600)
Message-ID: <199712261527.QAA23058@jessica.ethz.ch>

>>>>> "DougB" == Douglas Bates <bates@stat.wisc.edu> writes:

    DougB> I should have saved the messages about this but I didn't.  Can
    DougB> someone remind me of what function or object to check from
    DougB> within a function to determine if you are running R?  I need to
    DougB> make some changes in code according to whether I am running it
    DougB> under R or under S and I would prefer to keep one source tree.

##>>>>>> This works in all of <<<<<
##-- S  (including "S version 4", (beta))
##-- R
##-- S-plus

is.R <- function() { ## returns  'TRUE'  iff we are using 'R'
  exists("version") && !is.null(vl <- version$language) && vl == "R"
}

#- some may want:
is.S <- function() !is.R()

--------------
I think I should add this function to the R base,
or do we need a new package  "Scompatibility"  which could server other
things as well? 

I for one, am having more and more need for an "Rcompatibility" package in
S...

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

From p.dalgaard@biostat.ku.dk  Sat Dec 27 01:50:53 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 27 Dec 1997 02:50:53 +0100
Subject: Error in parse
In-Reply-To: Kurt Hornik's message of Mon, 22 Dec 1997 10:24:20 +0100
References: <97Dec19.134854est.27048@mailgate.bank-banque-canada.ca>
 <199712220924.KAA08507@pc25.none>
Message-ID: <x2g1nfv9j6.fsf@blueberry.kubism.ku.dk>

Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

> 
> >>>>> Paul Gilbert writes:
> 
> > In R 0.60.1 when I source a fairly large file of code I am getting:
> > Error in parse(file, n, text, prompt) : syntax error on line 2985
> 
> > I don't see any error and it doesn't happen if I split the file in two
> > pieces.  increasing -v -n does not seem to help and does not change
> > the location of the error. Does anyone have suggestions?
> 
> Two suggestions:
> 
> * Does the problem occur at the end of the file?  Then, the problem
> might be a final newline ...
> 
> * Does the file contain ASCII 0 characters?

- and a third: 

Are you by any chance executing external programs with system()? This
is playing tricks on "make tests" at them moment, because the pager
eats up the remainder of the input file...I suspect that source()
within source() will do weird things too.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From bates@stat.wisc.edu  Tue Dec 30 04:09:35 1997
From: bates@stat.wisc.edu (Douglas Bates)
Date: 29 Dec 1997 22:09:35 -0600
Subject: as.name is not idempotent
Message-ID: <6rwwgnxyio.fsf@franz.stat.wisc.edu>

At least I think the word I want "idempotent" - it has been a long
debugging session and my brain is fried so I am not sure.

What I mean is that as.name applied to a name gives an error.
 > as.name("foo")
 foo
 > as.name(as.name("foo"))
 Error in as.name(x) : character argument required

It might help if it were a bit more flexible about the arguments it
accepts.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From p.dalgaard@biostat.ku.dk  Tue Dec 30 12:05:13 1997
From: p.dalgaard@biostat.ku.dk (Peter Dalgaard BSA)
Date: 30 Dec 1997 13:05:13 +0100
Subject: as.name is not idempotent
In-Reply-To: Douglas Bates's message of 29 Dec 1997 22:09:35 -0600
References: <6rwwgnxyio.fsf@franz.stat.wisc.edu>
Message-ID: <x2d8ifjati.fsf@blueberry.kubism.ku.dk>

Douglas Bates <bates@stat.wisc.edu> writes:

> At least I think the word I want "idempotent" - it has been a long
> debugging session and my brain is fried so I am not sure.

I.: f(f(x)) == f(x) all x, so it's exactly the right term...

> What I mean is that as.name applied to a name gives an error.
>  > as.name("foo")
>  foo
>  > as.name(as.name("foo"))
>  Error in as.name(x) : character argument required
> 
> It might help if it were a bit more flexible about the arguments it
> accepts.

This is plainly a bug. If it bothers you badly, insert 

if(is.name(x)) return(x)

at the start of as.name.

In general, it should invariably hold that

is.xx(x) == TRUE implies as.xx(x) == x
and
is.xx(as.xx(x)) == TRUE unless as.xx fails

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

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

From thomas@biostat.washington.edu  Wed Dec 31 21:03:23 1997
From: thomas@biostat.washington.edu (Thomas Lumley)
Date: Wed, 31 Dec 1997 13:03:23 -0800 (PST)
Subject: debugger
In-Reply-To: <m0xnUm6-000hh5C@franz.stat.wisc.edu>
Message-ID: <Pine.SOL.3.95.971231130059.10B-100000@gorn>


Can we have some way to exit the debugger?  At the moment you have to use
(c)ontinue, which is annoying if the function is slow, or has unpleasant
side effects (like crashing R).


Thomas Lumley
------------------------------------------------------+------
Biostatistics		: "Never attribute to malice what  :
Uni of Washington	:  can be adequately explained by  :
Box 357232		:  incompetence" - Hanlon's Razor  :
Seattle WA 98195-7232	:				   :
------------------------------------------------------------


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