Re: [Rd] plot(): new behavior in R-2.2.0 alpha

2005-09-14 Thread John Maindonald
Following the >20 messages that Martin mentioned, I had
private discussion with John Fox, which in part lies behind
following questions:

(1) In plot 5, should we have, maybe as an option, vertical
lines at 2hbar and 3hbar, as in the plots produced by the
function that John Fox sent me.  I think this would be a useful
addition, but made no move to add it at that time, considering
it best to put that on a toThink About list.

(2) John also sent code for a plot that place contours of the
covratio on the points that are shown in plot 5.  This could
be added as an option to plot 5.
(The covratio statistic is a measure of the effect of omitting a
point on the variance-covariance matrix.  It is a function of
the residual and the leverage.)  Also there is the possibility
(I am not keen on this) to show Bonferroni critical values for
studentized residuals.

(3) My reaction to the new plot 6 (David Firth's proposal) is
sufficiently similar to John Fox's that I would not use it as a
matter of course.  I think it useful however, precisely because
it does offer a perspective on the information in plot 5 that
is, at first look, startlingly different.

(4) Are there other diagnostics that ought to be included in
stats? (perhaps in a function other than plot.lm(), which risks
being overloaded).  One strong claiment is vif() (variance
inflation factor), of which there are versions both in car and
(written by myself) in DAAG.  John Fox's function does more
than mine.  Thus, assuming that he is willing for it to be taken
across, that should go into stats.

(5) termplot() provides partial residual (component + residual)
plots, which I think extraordinarily useful.  They deserve to be
widely used.
Should partial regression plots also be available?

(6) It should be fairly easy to construct a function that would
examine the distribution of statistics of interest under repeated
bootstrap sampling or simulation.  This can be useful when
with small samples, when it is easy to over-interpret diagnostic
statistics.

(7) There are special issues, not just for aov models, but also
for glm() and (extending the discussion quite a lot) the models
that are fitted by lme()/lmer() [nlme/lme4].

(8) Are there special issues that require attention for large
datasets? [I'm sure there are, but regression diagnostics may
not be the best point of entry into the discussion.]

(9) How about a help(Diagnostics) entry?

(10) Maybe it would be useful to form a (small?) group to look at
what should go into:
  (a) stats
  (b) a specialist diagnostics package
Even if this idea is taken up, some preliminary wider canvassing
of the opinions of members of this list seems desirable.

John Maindonald.


On 14 Sep 2005, at 12:17 AM, Martin Maechler wrote:

> As some of you R-devel readers may know, the plot() method for
> "lm" objects is based in large parts on contributions by John
> Maindonald, subsequently "massaged" by me and other R-core
> members.
>
> In the statistics litterature on applied regression, people have
> had  diverse oppinions on what (and how many!) plots should be
> used for goodness-of-fit / residual diagnostics, and to my
> knowledge most people have agreed to want to see one (or more)
> version of a Tukey-Anscombe plot {Residuals ~ Fitted} and a QQ
> normal plot.
> Another consideration was to be somewhat close to what S
> (S-plus) was doing.  So we have two versions of residuals vs
> fitted, one for checking  E[error] = 0, the other for checking
> Var[error] = constant.  So we got to the first three plots of
> plot.lm() about which I don't want to debate at the moment
> {though, there's room for improvement even there: e.g., I know of at
>  least one case where plot() wasn't used because the user
>  was missing the qqline() she was so used to in the QQ plot}
>
> The topic of this e-mail is the (default) 4th plot which I had
> changed; really prompted by the following:
> More than three months ago, John wrote
>   http://tolstoy.newcastle.edu.au/R/devel/05/04/0594.html
> (which became a thread of about 20 messages, from Apr.23 -- 29,  
> 2005)
>
> and currently,
> NEWS for R 2.2.0 alpha contains
>
>
>>> USER-VISIBLE CHANGES
>>>
>>>o plot() uses a new default for the fourth panel when
>>>  'which' is not specified.
>>>  ___ may change before release ___
>>>
>
> and the header is
>
> plot.lm <-
> function (x, which = c(1:3, 5),
>   caption = c("Residuals vs Fitted",
>   "Normal Q-Q", "Scale-Location",
>   "Cook's distance", "Residuals vs Leverage",
>   "Cook's distance vs Leverage"),
>. ) {..}
>
> So we now have 6 possible plots, where 1,2,3 and 5 are the
> defaults (and 1,2,3,4 where the old defaults).
>
> For the influential points and combination of 'influential' and  
> 'outlier'
> there have been quite a few more proposals in the past. R <= 2.1.x
> has been plotting the  Cook's distances vs. observation number,  
> whereas
> quite a few people

[Rd] R CMD check

2005-09-14 Thread jing hua zhao
Dear r-devel members,

I tried to build R packages on a PC running Windows XP but experience 
problems. However, it is ok when there is no inst directory in a package.

Any help would be appreciated.

The following is an example,

C:\work>R CMD check VR_7.2-19.tar.gz
* checking for working latex ... OK
* using log directory 'C:/work/VR.Rcheck'
* using R version 2.1.1, 2005-06-20
* checking for file 'VR/DESCRIPTION' ... OK
* looks like 'VR' is a package bundle
* this is bundle 'VR' version '7.2-19'
* checking if this is a source bundle ... OK

installing R.css in C:/work/VR.Rcheck

Looks like `C:/work/VR.Rcheck/00_pkg_src/VR' is a package bundle


-- Making package MASS 
  adding build stamp to DESCRIPTION
  installing NAMESPACE file and metadata
  making DLL ...
making MASS.d from MASS.c
making lqs.d from lqs.c
gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c MASS.c -o MASS.o
gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c lqs.c -o lqs.o
ar cr MASS.a MASS.o lqs.o
ranlib MASS.a
windres --include-dir c:/PROGRA~1/r/rw2011/include  -i MASS_res.rc -o 
MASS_res.

gcc  --shared -s  -o MASS.dll MASS.def MASS.a MASS_res.o  
-c:/PROGRA~1/r/rw201/src/gnuwin32   -lg2c -lR
  ... DLL made
  installing DLL
  installing R files
  installing inst files
FIND: Parameter format not correct
make[2]: *** [C:/work/VR.Rcheck/MASS/inst] Error 2
make[1]: *** [all] Error 2
make: *** [pkg-MASS] Error 2
*** Installation of MASS failed ***

ERROR
Installation failed.

C:\work> path

PATH=C:\texmf\miktex\bin;C:\Perl\bin\;C:\Program 
Files\Insightful\splus62\;C:\WI
NDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
Files\Hummingbird\
Connectivity\9.00\Accessories\;C:\Program Files\Common 
Files\GTK\2.0\bin;C:\Prog
ram Files\WinSCP3\;C:\Program Files\PC-Pine



Jing Hua Zhao

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] plot(): new behavior in R-2.2.0 alpha

2005-09-14 Thread Martin Maechler
Thank you, John, for
Dear 
> "JohnF" == John Fox <[EMAIL PROTECTED]>
> on Tue, 13 Sep 2005 16:41:28 -0400 writes:

JohnF> A couple of comments on the new plots (numbers 5 and 6):
JohnF> Perhaps some more thought could be given to the
JohnF> plotted contours for Cook's D (which are 0.5 and 1.0
JohnF> in the example -- large Cook's Ds). A rule-of-thumb
JohnF> cut-off for this example is 4/(n - p) = 4/(50 - 5) =
JohnF> 0.089, and the discrepancy will grow with n.

That's an interesting suggestion.  Where does the 4/(n-p) come
from? or put differently, should I better read in of your books? ;-)

Honestly, I'm so much a fan of R_i / h_ii that I didn't even
know that.

JohnF> I'm not terribly fond of number 6, since it seems
JohnF> natural to me to think of the relationship among
JohnF> these quantities as influence on coefficients =
JohnF> leverage * outlyingness (which corresponds to 5);
JohnF> also note how in the example, the labels for large
JohnF> residuals overplot.

I think John mainly proposed '6' because other proposed it as another
good alternative.  From the few examples I've looked at, I
haven't got fond at all either.

JohnF> Finally, your remarks about balanced data are cogent
JohnF> and suggest going with 1:3 in this case (since R_i
JohnF> vs. i is pretty redundant with the QQ plot).

Ah, that's another, maybe better alternative to my proposal.

One drawback of it is for situations where people do something
likepar(mfrow=c(2,2))
before calling  plot() for several fitted lm models,
assuming to fill one page for each of the plots.
and I think that's something I would have done always in such
situations where several different models are fitted and compared.

Maybe plot.lm() should "advance an empty frame" as soon as
 prod(par("mfrow")) >= 4 
in that case?

Martin

JohnF> 
JohnF> John Fox
JohnF> Department of Sociology
JohnF> McMaster University
JohnF> Hamilton, Ontario
JohnF> Canada L8S 4M4
JohnF> 905-525-9140x23604
JohnF> http://socserv.mcmaster.ca/jfox 
JohnF>  

>> -Original Message-
>> From: Martin Maechler [mailto:[EMAIL PROTECTED] 
>> Sent: Tuesday, September 13, 2005 9:18 AM
>> To: R-devel@stat.math.ethz.ch
>> Cc: John Maindonald; Werner Stahel; John Fox
>> Subject: plot(): new behavior in R-2.2.0 alpha
>> 
>> As some of you R-devel readers may know, the plot() method 
>> for "lm" objects is based in large parts on contributions by 
>> John Maindonald, subsequently "massaged" by me and other 
>> R-core members.
>> 
>> In the statistics litterature on applied regression, people 
>> have had  diverse oppinions on what (and how many!) plots 
>> should be used for goodness-of-fit / residual diagnostics, 
>> and to my knowledge most people have agreed to want to see 
>> one (or more) version of a Tukey-Anscombe plot {Residuals ~ 
>> Fitted} and a QQ normal plot.
>> Another consideration was to be somewhat close to what S
>> (S-plus) was doing.  So we have two versions of residuals vs 
>> fitted, one for checking  E[error] = 0, the other for 
>> checking Var[error] = constant.  So we got to the first three plots of
>> plot.lm() about which I don't want to debate at the moment 
>> {though, there's room for improvement even there: e.g., I 
>> know of at  least one case where plot() wasn't used 
>> because the user  was missing the qqline() she was so used to 
>> in the QQ plot}
>> 
>> The topic of this e-mail is the (default) 4th plot which I 
>> had changed; really prompted by the following:
>> More than three months ago, John wrote
>> http://tolstoy.newcastle.edu.au/R/devel/05/04/0594.html
>> (which became a thread of about 20 messages, from Apr.23 
>> -- 29, 2005)
>> 
>> and currently,
>> NEWS for R 2.2.0 alpha contains
>> 
>> >> USER-VISIBLE CHANGES
>> >> 
>> >>o plot() uses a new default for the fourth panel when
>> >>  'which' is not specified.
>> >>  ___ may change before release ___
>> 
>> and the header is
>> 
>> plot.lm <-
>> function (x, which = c(1:3, 5), 
>> caption = c("Residuals vs Fitted", 
>> "Normal Q-Q", "Scale-Location", 
>> "Cook's distance", "Residuals vs Leverage", 
>> "Cook's distance vs Leverage"), 
>> . ) {..}
>> 
>> So we now have 6 possible plots, where 1,2,3 and 5 are the 
>> defaults (and 1,2,3,4 where the old defaults).
>> 
>> For the influential points and combination of 'influential' 
>> and 'outlier'
>> there have been quite a few more proposals in the past. R <= 
>> 2.1.x has been plotting the  Cook's distances vs. observation 
>> number, whereas quite a few people in the past have noted 
>> that all influ

Re: [Rd] R CMD check

2005-09-14 Thread Duncan Murdoch
jing hua zhao wrote:
> Dear r-devel members,
> 
> I tried to build R packages on a PC running Windows XP but experience 
> problems. However, it is ok when there is no inst directory in a package.
> 
> Any help would be appreciated.
> 
> The following is an example,
> 
> C:\work>R CMD check VR_7.2-19.tar.gz
> * checking for working latex ... OK
> * using log directory 'C:/work/VR.Rcheck'
> * using R version 2.1.1, 2005-06-20
> * checking for file 'VR/DESCRIPTION' ... OK
> * looks like 'VR' is a package bundle
> * this is bundle 'VR' version '7.2-19'
> * checking if this is a source bundle ... OK
> 
> installing R.css in C:/work/VR.Rcheck
> 
> Looks like `C:/work/VR.Rcheck/00_pkg_src/VR' is a package bundle
> 
> 
> -- Making package MASS 
>   adding build stamp to DESCRIPTION
>   installing NAMESPACE file and metadata
>   making DLL ...
> making MASS.d from MASS.c
> making lqs.d from lqs.c
> gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c MASS.c -o MASS.o
> gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c lqs.c -o lqs.o
> ar cr MASS.a MASS.o lqs.o
> ranlib MASS.a
> windres --include-dir c:/PROGRA~1/r/rw2011/include  -i MASS_res.rc -o 
> MASS_res.
> 
> gcc  --shared -s  -o MASS.dll MASS.def MASS.a MASS_res.o  
> -c:/PROGRA~1/r/rw201/src/gnuwin32   -lg2c -lR
>   ... DLL made
>   installing DLL
>   installing R files
>   installing inst files
> FIND: Parameter format not correct

Looks like a path problem.  There's a find command in the R tools, and a 
completely different one in Windows.  You need to set your path to find 
the R one first.

Duncan Murdoch

> make[2]: *** [C:/work/VR.Rcheck/MASS/inst] Error 2
> make[1]: *** [all] Error 2
> make: *** [pkg-MASS] Error 2
> *** Installation of MASS failed ***
> 
> ERROR
> Installation failed.
> 
> C:\work> path
> 
> PATH=C:\texmf\miktex\bin;C:\Perl\bin\;C:\Program 
> Files\Insightful\splus62\;C:\WI
> NDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
> Files\Hummingbird\
> Connectivity\9.00\Accessories\;C:\Program Files\Common 
> Files\GTK\2.0\bin;C:\Prog
> ram Files\WinSCP3\;C:\Program Files\PC-Pine
> 
> 
> 
> Jing Hua Zhao
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] as.Date() , feature or bug?

2005-09-14 Thread Uwe Ligges
Bo Peng wrote:

> Under linux and windows,
> 
> 
>>as.Date("-06-06")
> 
> [1] "-06-06"
> 
>>as.Date("-07-07")
> 
> [1] "1970-01-01"
> 
> 
> Feature? Bug? help(as.Date) does not mention this case.

Well, bug, if you really want to call it a bug that you cannot represent 
the year . ;-)

I guess this is some overflow in do_POSIXlt2D that is not protected 
against misuse. Don't see the point right now, I have to admit.


 > as.Date("6970-12-31")
[1] "6970-12-31"
 > as.Date("6971-01-01")
[1] "1970-01-01"


So we cannot represent more than 5000 years into the future, roughly 
speaking. *Guess* the problem is that we need more than 4 digits for +/- 
5000 years (sum=1).

Uwe Ligges


> Bo.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] plot(): new behavior in R-2.2.0 alpha

2005-09-14 Thread John Fox
Dear John,


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of John Maindonald
> Sent: Wednesday, September 14, 2005 1:09 AM
> To: Martin Maechler
> Cc: Werner Stahel; R-devel@stat.math.ethz.ch; John Fox
> Subject: Re: [Rd] plot(): new behavior in R-2.2.0 alpha
> 
> Following the >20 messages that Martin mentioned, I had 
> private discussion with John Fox, which in part lies behind 
> following questions:
> 
> (1) In plot 5, should we have, maybe as an option, vertical 
> lines at 2hbar and 3hbar, as in the plots produced by the 
> function that John Fox sent me.  I think this would be a 
> useful addition, but made no move to add it at that time, 
> considering it best to put that on a toThink About list.
> 
> (2) John also sent code for a plot that place contours of the 
> covratio on the points that are shown in plot 5.  This could 
> be added as an option to plot 5.
> (The covratio statistic is a measure of the effect of 
> omitting a point on the variance-covariance matrix.  It is a 
> function of the residual and the leverage.)  Also there is 
> the possibility (I am not keen on this) to show Bonferroni 
> critical values for studentized residuals.
> 
> (3) My reaction to the new plot 6 (David Firth's proposal) is 
> sufficiently similar to John Fox's that I would not use it as 
> a matter of course.  I think it useful however, precisely 
> because it does offer a perspective on the information in 
> plot 5 that is, at first look, startlingly different.
> 
> (4) Are there other diagnostics that ought to be included in 
> stats? (perhaps in a function other than plot.lm(), which 
> risks being overloaded).  One strong claiment is vif() 
> (variance inflation factor), of which there are versions both 
> in car and (written by myself) in DAAG.  John Fox's function 
> does more than mine.  Thus, assuming that he is willing for 
> it to be taken across, that should go into stats.
> 

Fine with me, but the latest version of this function (in the car package)
was rewritten by Henric Nilsson, so he should be asked as well (but see
comments at the end).

> (5) termplot() provides partial residual (component + 
> residual) plots, which I think extraordinarily useful.  They 
> deserve to be widely used.

If I remember right, the cr.plots() function in the car package is a bit
more general.

> Should partial regression plots also be available?
> 

They're implemented in the av.plots() function in the car package.

> (6) It should be fairly easy to construct a function that 
> would examine the distribution of statistics of interest 
> under repeated bootstrap sampling or simulation.  This can be 
> useful when with small samples, when it is easy to 
> over-interpret diagnostic statistics.
> 

I think that this is particularly useful for QQ plots of residuals (as
suggested by Atkinson). The .glm and .lm methods for qq.plot in the car
package do this.

> (7) There are special issues, not just for aov models, but 
> also for glm() and (extending the discussion quite a lot) the 
> models that are fitted by lme()/lmer() [nlme/lme4].
> 
> (8) Are there special issues that require attention for large 
> datasets? [I'm sure there are, but regression diagnostics may 
> not be the best point of entry into the discussion.]
> 
> (9) How about a help(Diagnostics) entry?
> 
> (10) Maybe it would be useful to form a (small?) group to 
> look at what should go into:
>   (a) stats
>   (b) a specialist diagnostics package

This seems to me a good idea, before making changes to stats. Certainly it's
not a great idea to try to cram everything into plot.lm (not that you're
recommending that).

Regards,
 John

> Even if this idea is taken up, some preliminary wider 
> canvassing of the opinions of members of this list seems desirable.
> 
> John Maindonald.
> 
> 
> On 14 Sep 2005, at 12:17 AM, Martin Maechler wrote:
> 
> > As some of you R-devel readers may know, the plot() method for "lm" 
> > objects is based in large parts on contributions by John 
> Maindonald, 
> > subsequently "massaged" by me and other R-core members.
> >
> > In the statistics litterature on applied regression, people 
> have had  
> > diverse oppinions on what (and how many!) plots should be used for 
> > goodness-of-fit / residual diagnostics, and to my knowledge most 
> > people have agreed to want to see one (or more) version of a 
> > Tukey-Anscombe plot {Residuals ~ Fitted} and a QQ normal plot.
> > Another consideration was to be somewhat close to what S
> > (S-plus) was doing.  So we have two versions of residuals 
> vs fitted, 
> > one for checking  E[error] = 0, the other for checking Var[error] = 
> > constant.  So we got to the first three plots of
> > plot.lm() about which I don't want to debate at the moment {though, 
> > there's room for improvement even there: e.g., I know of at 
>  least one 
> > case where plot() wasn't used because the user  was missing the 
> > qqline() she was so used to in th

Re: [Rd] plot(): new behavior in R-2.2.0 alpha

2005-09-14 Thread John Fox
Dear Martin,

> -Original Message-
> From: Martin Maechler [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, September 14, 2005 3:56 AM
> To: John Fox
> Cc: 'Martin Maechler'; 'Werner Stahel'; 'John Maindonald'; 
> R-devel@stat.math.ethz.ch
> Subject: Re: [Rd] plot(): new behavior in R-2.2.0 alpha
> 
> Thank you, John, for
> Dear 
> > "JohnF" == John Fox <[EMAIL PROTECTED]>
> > on Tue, 13 Sep 2005 16:41:28 -0400 writes:
> 
> JohnF> A couple of comments on the new plots (numbers 5 and 6):
> JohnF> Perhaps some more thought could be given to the
> JohnF> plotted contours for Cook's D (which are 0.5 and 1.0
> JohnF> in the example -- large Cook's Ds). A rule-of-thumb
> JohnF> cut-off for this example is 4/(n - p) = 4/(50 - 5) =
> JohnF> 0.089, and the discrepancy will grow with n.
> 
> That's an interesting suggestion.  Where does the 4/(n-p) 
> come from? or put differently, should I better read in of 
> your books? ;-)

I believe that I got this by transforming a cutoff suggested by Chatterjee
and Hadi for dffits to the Cook's D scale.

> 
> Honestly, I'm so much a fan of R_i / h_ii that I didn't even 
> know that.
> 
> JohnF> I'm not terribly fond of number 6, since it seems
> JohnF> natural to me to think of the relationship among
> JohnF> these quantities as influence on coefficients =
> JohnF> leverage * outlyingness (which corresponds to 5);
> JohnF> also note how in the example, the labels for large
> JohnF> residuals overplot.
> 
> I think John mainly proposed '6' because other proposed it as 
> another good alternative.  From the few examples I've looked 
> at, I haven't got fond at all either.
> 
> JohnF> Finally, your remarks about balanced data are cogent
> JohnF> and suggest going with 1:3 in this case (since R_i
> JohnF> vs. i is pretty redundant with the QQ plot).
> 
> Ah, that's another, maybe better alternative to my proposal.
> 
> One drawback of it is for situations where people do something
> like  par(mfrow=c(2,2))
> before calling  plot() for several fitted lm models, 
> assuming to fill one page for each of the plots.

Good point -- I do that myself in the Rcmdr package.

> and I think that's something I would have done always in such 
> situations where several different models are fitted and compared.
> 
> Maybe plot.lm() should "advance an empty frame" as soon as
>  prod(par("mfrow")) >= 4
> in that case?
> 

That seems a good idea, at least for the default behaviour. An unlikely
complication would occur if the user wanted to put the plots generated by
plot.lm() on a page along with other plots.

Regards,
 John

> Martin
> 
> JohnF> 
> JohnF> John Fox
> JohnF> Department of Sociology
> JohnF> McMaster University
> JohnF> Hamilton, Ontario
> JohnF> Canada L8S 4M4
> JohnF> 905-525-9140x23604
> JohnF> http://socserv.mcmaster.ca/jfox 
> JohnF>  
> 
> >> -Original Message-
> >> From: Martin Maechler [mailto:[EMAIL PROTECTED] 
> >> Sent: Tuesday, September 13, 2005 9:18 AM
> >> To: R-devel@stat.math.ethz.ch
> >> Cc: John Maindonald; Werner Stahel; John Fox
> >> Subject: plot(): new behavior in R-2.2.0 alpha
> >> 
> >> As some of you R-devel readers may know, the plot() method 
> >> for "lm" objects is based in large parts on contributions by 
> >> John Maindonald, subsequently "massaged" by me and other 
> >> R-core members.
> >> 
> >> In the statistics litterature on applied regression, people 
> >> have had  diverse oppinions on what (and how many!) plots 
> >> should be used for goodness-of-fit / residual diagnostics, 
> >> and to my knowledge most people have agreed to want to see 
> >> one (or more) version of a Tukey-Anscombe plot {Residuals ~ 
> >> Fitted} and a QQ normal plot.
> >> Another consideration was to be somewhat close to what S
> >> (S-plus) was doing.  So we have two versions of residuals vs 
> >> fitted, one for checking  E[error] = 0, the other for 
> >> checking Var[error] = constant.  So we got to the 
> first three plots of
> >> plot.lm() about which I don't want to debate at the moment 
> >> {though, there's room for improvement even there: e.g., I 
> >> know of at  least one case where plot() wasn't used 
> >> because the user  was missing the qqline() she was so used to 
> >> in the QQ plot}
> >> 
> >> The topic of this e-mail is the (default) 4th plot which I 
> >> had changed; really prompted by the following:
> >> More than three months ago, John wrote
> >> http://tolstoy.newcastle.edu.au/R/devel/05/04/0594.html
> >> (which became a thread of about 20 messages, from Apr.23 
> >> -- 29, 2005)
> >> 
> >> and currently,
> >> NEWS for R 2.2.0 alpha contains
> >> 
> >> >> USER-VISIBLE CHANGES
> >> >> 
> >> >>o 

Re: [Rd] R CMD check

2005-09-14 Thread jing hua zhao
yes, it does work now by putting the R environments in front of the original 
%path%.


>From: Duncan Murdoch <[EMAIL PROTECTED]>
>To: jing hua zhao <[EMAIL PROTECTED]>
>CC: r-devel@r-project.org
>Subject: Re: [Rd] R CMD check
>Date: Wed, 14 Sep 2005 07:04:57 -0400
>
>jing hua zhao wrote:
>>Dear r-devel members,
>>
>>I tried to build R packages on a PC running Windows XP but experience 
>>problems. However, it is ok when there is no inst directory in a package.
>>
>>Any help would be appreciated.
>>
>>The following is an example,
>>
>>C:\work>R CMD check VR_7.2-19.tar.gz
>>* checking for working latex ... OK
>>* using log directory 'C:/work/VR.Rcheck'
>>* using R version 2.1.1, 2005-06-20
>>* checking for file 'VR/DESCRIPTION' ... OK
>>* looks like 'VR' is a package bundle
>>* this is bundle 'VR' version '7.2-19'
>>* checking if this is a source bundle ... OK
>>
>>installing R.css in C:/work/VR.Rcheck
>>
>>Looks like `C:/work/VR.Rcheck/00_pkg_src/VR' is a package bundle
>>
>>
>>-- Making package MASS 
>>   adding build stamp to DESCRIPTION
>>   installing NAMESPACE file and metadata
>>   making DLL ...
>>making MASS.d from MASS.c
>>making lqs.d from lqs.c
>>gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c MASS.c -o MASS.o
>>gcc   -Ic:/PROGRA~1/r/rw2011/include -Wall -O2   -c lqs.c -o lqs.o
>>ar cr MASS.a MASS.o lqs.o
>>ranlib MASS.a
>>windres --include-dir c:/PROGRA~1/r/rw2011/include  -i MASS_res.rc -o 
>>MASS_res.
>>
>>gcc  --shared -s  -o MASS.dll MASS.def MASS.a MASS_res.o  
>>-c:/PROGRA~1/r/rw201/src/gnuwin32   -lg2c -lR
>>   ... DLL made
>>   installing DLL
>>   installing R files
>>   installing inst files
>>FIND: Parameter format not correct
>
>Looks like a path problem.  There's a find command in the R tools, and a 
>completely different one in Windows.  You need to set your path to find the 
>R one first.
>
>Duncan Murdoch
>
>>make[2]: *** [C:/work/VR.Rcheck/MASS/inst] Error 2
>>make[1]: *** [all] Error 2
>>make: *** [pkg-MASS] Error 2
>>*** Installation of MASS failed ***
>>
>>ERROR
>>Installation failed.
>>
>>C:\work> path
>>
>>PATH=C:\texmf\miktex\bin;C:\Perl\bin\;C:\Program 
>>Files\Insightful\splus62\;C:\WI
>>NDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
>>Files\Hummingbird\
>>Connectivity\9.00\Accessories\;C:\Program Files\Common 
>>Files\GTK\2.0\bin;C:\Prog
>>ram Files\WinSCP3\;C:\Program Files\PC-Pine
>>
>>
>>
>>Jing Hua Zhao
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] as.Date() , feature or bug?

2005-09-14 Thread Bo Peng
> Well, bug, if you really want to call it a bug that you cannot represent
> the year . ;-)

So I guess we need a warning message and a line in help(as.Date)?

Bo

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] NUMERIC_POINTER question

2005-09-14 Thread Witold Eryk Wolski

Thanks Roger, Simon, Reid,


It's indeed trivial, if you stop to believe that S4 provides any type of 
type safety. However, having in mind all the arguments why S4, and that 
it  was designed in order to incorporate type safety on both the R and C 
side I was not expecting that when trying for the *first* time, the 
get_slot and set_slot "stuff" I will run in exactly the problems which 
S4 is supposed to solve.


Of course I knew that "matrix" is not S4 and it is therefore even not a 
proper class. But this complexity sometimes blows your mind.


Cheers
Eryk.


Simon Urbanek wrote:

Eryk,

On Sep 13, 2005, at 2:26 PM, nwew wrote:


printf("%f\n",NUMERIC_POINTER(mat)[1]);
[...]
However it prints
0.
if [EMAIL PROTECTED] are integers ( [EMAIL PROTECTED]<-matrix(1:12,3,4) ).

Can anyone explain it to me why?
I thought that NUMERIC_POINTER makes it clear that i expect  datatype 
numeric.

(Why otherwise the distinction with INTEGER_POINTER)



You answered your own question - NUMERIC_POINTER expects that the  SEXP 
you pass to it is numeric=double. When you use it, it's your  
responsibility to make sure that the SEXP is numeric and not integer  or 
anything else. Probably you may want to use AS_NUMERIC to ensure  that. 
[btw: NUMERIC_POINTER() is a compatibility macro for REAL() and  
AS_NUMERIC(x) for coerceVector(x,REALSXP)].


Also you should be aware that C uses 0-based indices so  
NUMERIC_POINTER(mat)[1] accesses the 2nd element of the vector.


Cheers,
Simon


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] as.Date() , feature or bug?

2005-09-14 Thread Uwe Ligges
Bo Peng wrote:

>>Well, bug, if you really want to call it a bug that you cannot represent
>>the year . ;-)
> 
> 
> So I guess we need a warning message and a line in help(as.Date)?

Even better a fix (than an *error* message), since the POSIX classes can 
handle the date and I do not (yet) see the reason why Date cannot. But I 
have no time to dig deeper (at least not this week).


Uwe Ligges


> Bo
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] simulate in stats

2005-09-14 Thread Paul Gilbert
Can the arguments nsim and seed be passed as part of ... in the new 
simulate generic in R-2.2.0alpha package stats?

This would potentially allow me to use the stats generic rather than the 
one I define in dse. There are contexts where nsim and seed do not make 
sense. I realize that the default arguments could be ignored, but it 
does not really make sense to introduce a new generic with that in mind. 
(I would also prefer that the "object" argument was called "model" but 
this is less important.)

Paul Gilbert

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] simulate in stats

2005-09-14 Thread Paul Gilbert
(Sorry if this was posted twice. I seem to be having some email issues.)

Can the arguments nsim and seed be passed as part of ... in the new 
simulate generic in R-2.2.0alpha package stats?

This would potentially allow me to use the stats generic rather than the 
one I define in dse. There are contexts where nsim and seed do not make 
sense. I realize that the default arguments could be ignored, but it 
does not really make sense to introduce a new generic with that in mind. 
(I would also prefer that the "object" argument was called "model" but 
this is less important.)

Paul Gilbert

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel