Re: [Rd] [R] color palette from red to blue passing white (shifted from R-help)
> "Paul" == Paul Murrell <[EMAIL PROTECTED]> > on Wed, 05 Dec 2007 08:53:10 +1300 writes: Paul> Hi Paul> Achim and I have been looking at tidying up the colorspace package (see Paul> http://r-forge.r-project.org/projects/colorspace/) to fix a few Paul> inaccuracies, PLUS the possibility of declaring R's internal color space Paul> to be sRGB. Paul> I have started an RFC on the r-developer site Paul> (http://developer.r-project.org/sRGB-RFC.html) to discuss some possible Paul> changes to the core engine and add-on packages. Paul> One of the issues will be consolidating some of the double-ups (e.g., Paul> hcl() in base and the counterpart in package 'colorspace'; I did not Paul> even know about convertColor()!). Paul> Ideally, we would have only one copy of the conversions between the Paul> various colorspaces (probably C code, then the various R-level front Paul> ends can all just run off the same internal code). Paul> A lot of these conversions exist now in 'colorspace', but as Thomas Paul> pointed out, the S4-ness of 'colorspace' is a problem for making these Paul> conversions part of base R. Hmm, I think we are currently only required to keep 'base' not dependent on 'methods'. Why should 'grDevices' or new "standard R" package not be dependent on 'methods' ? Many of us would like to see S4 been used much more widely. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] color palette from red to blue passing white (shifted from R-help)
Just a few small additions to what Paul already wrote:
> Achim and I have been looking at tidying up the colorspace package (see
> http://r-forge.r-project.org/projects/colorspace/) to fix a few
> inaccuracies, PLUS the possibility of declaring R's internal color space
> to be sRGB.
Also, we moved the color palettes out of "vcd" into "colorspace" so that
this is all in one place. That version is not on CRAN yet...but on
R-Forge.
> > AZ> levelplot(x, col.regions = diverg_hcl(16))
> >
> > Hmm, I would have recommended
> >
> > colorRampPalette(c('dark red','white','dark blue'),
> >space = "Lab")
> >
> > where the 'space = "Lab"' part also makes sure that a
> > "perceptually-based" space rather than RGB is used.
But that does not help you if your starting points are not balanced. "dark
red" and "dark blue" do not correspond to the same luminance coordinate
in HCL (or also LUV/LAB) space. As both use 139 in RGB, look at
R> dark <- RGB(c(139/255, 0, 0), c(0, 139/255, 0), c(0, 0, 139/255))
R> as(dark, "polarLUV")
L C H
[1,] 40.56124 136.40188 12.17395
[2,] 68.73912 106.38239 127.72353
[3,] 23.45176 94.89138 265.87278
There are certainly diverging palettes in use with more serious problems,
but why not simply use the canned solution in "vcd" which avoids this
problem?
BTW: Some background information about the stuff we did for "vcd" is
available in
http://epub.wu-wien.ac.at/dyn/openURL?id=oai:epub.wu-wien.ac.at:epub-wu-01_c87
And, Ken, apologies for using bad terminology again...:-)
grx,
Z
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R install problem on MacOS 10.5.1 (PR#10476)
Dan, I have just encountered this issue on my iMac at home yesterday which I have upgraded from Tiger to Leopard, so I'm pretty sure that this is caused either by the upgrade or by Xcode 3 installation (I did both at once, so I didn't check the status immediately after upgrade). I didn't install MacPorts, so I'm pretty sure that Apple it creating this mess. And yes, moving "lib 1" to lib fixes it. Cheers, Simon On Dec 5, 2007, at 7:18 AM, dankelley wrote: > > Simon, quoted below, is correct about the /usr/local/lib infinite- > reference being a problem. In case it's of any use to other OSX > users, my guess is that macPorts caused that error. I infer that > based on the time at which the symlink was created, which was at the > time when I was trying to install MacPorts. (That install failed. > I cannot pin down the time too well because it took several hours of > compilation to fail.) > > I am putting a link to a posting I made on this issue below, in case > its thread expands to provide good hints for other R/Leopard users. > (Simon's suggestion about moving "lib 1" to "lib" worked for me.) > > http://www.nabble.com/problem-installing-2.6.1-on-OSX-Leopard-%28after-failed-MacPorts-install%29-tf4933141.html#a14119813 > > > > Simon Urbanek wrote: >> >> >> >> No. The failure is due to a strange symlink in /usr/local/lib that >> points to itself. I suspect that this has something to do with an >> upgrade from Tiger to Leopard or Xcode 3 installation and that Apple >> actually creates that infinite symlink. Given that there is "/usr/ >> loca/ >> lib 1" lingering around, I'd bet that >> >> sudo rm /usr/local/lib >> sudo mv '/usr/local/lib 1' /usr/local/lib >> >> will fix the problem. >> >> > > -- > View this message in context: > http://www.nabble.com/R-install-problem-on-MacOS-10.5.1-%28PR-10476%29-tf4897418.html#a14170397 > Sent from the R devel mailing list archive at Nabble.com. > > __ > 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] R install problem on MacOS 10.5.1 (PR#10476)
Simon, quoted below, is correct about the /usr/local/lib infinite-reference being a problem. In case it's of any use to other OSX users, my guess is that macPorts caused that error. I infer that based on the time at which the symlink was created, which was at the time when I was trying to install MacPorts. (That install failed. I cannot pin down the time too well because it took several hours of compilation to fail.) I am putting a link to a posting I made on this issue below, in case its thread expands to provide good hints for other R/Leopard users. (Simon's suggestion about moving "lib 1" to "lib" worked for me.) http://www.nabble.com/problem-installing-2.6.1-on-OSX-Leopard-%28after-failed-MacPorts-install%29-tf4933141.html#a14119813 Simon Urbanek wrote: > > > > No. The failure is due to a strange symlink in /usr/local/lib that > points to itself. I suspect that this has something to do with an > upgrade from Tiger to Leopard or Xcode 3 installation and that Apple > actually creates that infinite symlink. Given that there is "/usr/loca/ > lib 1" lingering around, I'd bet that > > sudo rm /usr/local/lib > sudo mv '/usr/local/lib 1' /usr/local/lib > > will fix the problem. > > -- View this message in context: http://www.nabble.com/R-install-problem-on-MacOS-10.5.1-%28PR-10476%29-tf4897418.html#a14170397 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: mention Vectorize in 'outer' man page (PR#10490)
Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
>
>>> antonio fabio <[EMAIL PROTECTED]>
>>> on Tue, 4 Dec 2007 20:25:21 +0100 (CET) writes:
>>>
>>>
>> > --=_Part_13308_28087893.1196796187581
>> > Content-Type: text/plain; charset=ISO-8859-1
>> > Content-Transfer-Encoding: 7bit
>> > Content-Disposition: inline
>>
>> > Here a possible patch. What do you think about it?
>>
>> attachments don't make it through R-bugs -> R-devel correctly.
>>
>> Please use cut & paste instead.
>>
>>
> base64 -di is not THAT hard. I'll apply it to R-devel
>
(The patch, not base64, or course...).
Done. Actually, I ended up polishing a bit more:
--- src/library/base/man/outer.Rd (revision 43598)
+++ src/library/base/man/outer.Rd (working copy)
@@ -26,13 +26,15 @@
\item{\dots}{optional arguments to be passed to \code{FUN}.}
}
\details{
- \code{FUN} must be a function (or the name of it) which expects at
- least two arguments and which operates elementwise.
-
\code{X} and \code{Y} must be suitable arguments for \code{FUN}. Each
will be extended by \code{\link{rep}} to length the products of the
lengths of \code{X} and \code{Y} before \code{FUN} is called.
+ \code{FUN} is called with these two extended vectors as
+ arguments. Therefore, it must be a vectorized function (or the
+ name of one), expecting at
+ least two arguments.
+
Where they exist, the [dim]names of \code{X} and \code{Y} will be
copied to the answer, and a dimension assigned which is the
concatenation of the dimensions of \code{X} and \code{Y} (or lengths
@@ -54,7 +56,8 @@
\seealso{
\code{\link{\%*\%}} for usual (\emph{inner}) matrix vector
multiplication;
- \code{\link{kronecker}} which is based on \code{outer}.
+ \code{\link{kronecker}} which is based on \code{outer};
+ \code{\link{Vectorize}} for vectorizing a non-vectorized function.
}
\examples{
x <- 1:9; names(x) <- x
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: mention Vectorize in 'outer' man page (PR#10490)
> antonio fabio <[EMAIL PROTECTED]> > on Tue, 4 Dec 2007 20:25:21 +0100 (CET) writes: > --=_Part_13308_28087893.1196796187581 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > Here a possible patch. What do you think about it? attachments don't make it through R-bugs -> R-devel correctly. Please use cut & paste instead. Martin Maechler, ETH Zurich > 2007/12/4, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: >> Full_Name: Antonio, Fabio Di Narzo >> Version: 2.6.1 >> OS: linux >> Submission from: (NULL) (213.140.16.187) >> >> >> In 'outer' man page, there is no mention of the Vectorize function. >> Moreover, I think it isn't underlined enough that the FUN argument to 'outer' >> must be a vectorized function (doc speaks about a function which has to 'operate >> elementwise'). >> >> A cross-reference from outer to Vectorize (which already has 'outer' usage >> examples) would be great. >> >> > R.version >> _ >> platform i686-pc-linux-gnu >> arch i686 >> os linux-gnu >> system i686, linux-gnu >> status >> major 2 >> minor 6.1 >> year 2007 >> month 11 >> day26 >> svn rev43537 >> language R >> version.string R version 2.6.1 (2007-11-26) >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- > Antonio, Fabio Di Narzo > Ph.D. student at > Department of Statistical Sciences > University of Bologna, Italy > --=_Part_13308_28087893.1196796187581 > Content-Type: application/octet-stream; name=patch > Content-Transfer-Encoding: base64 > X-Attachment-Id: f_f9stff63 > Content-Disposition: attachment; filename=patch > ZGlmZiAtLWdpdCBhL3NyYy9saWJyYXJ5L2Jhc2UvbWFuL291dGVyLlJkIGIvc3JjL2xpYnJhcnkv > YmFzZS9tYW4vb3V0ZXIuUmQKaW5kZXggOWYzMmI3OC4uNzVlOGM4NyAxMDA2NDQKLS0tIGEvc3Jj > L2xpYnJhcnkvYmFzZS9tYW4vb3V0ZXIuUmQKKysrIGIvc3JjL2xpYnJhcnkvYmFzZS9tYW4vb3V0 > ZXIuUmQKQEAgLTI2LDggKzI2LDggQEAgWCBcJW9cJSBZCiAgIFxpdGVte1xkb3RzfXtvcHRpb25h > bCBhcmd1bWVudHMgdG8gYmUgcGFzc2VkIHRvIFxjb2Rle0ZVTn0ufQogfQogXGRldGFpbHN7Ci0g > IFxjb2Rle0ZVTn0gbXVzdCBiZSBhIGZ1bmN0aW9uIChvciB0aGUgbmFtZSBvZiBpdCkgd2hpY2gg > ZXhwZWN0cyBhdAotICBsZWFzdCB0d28gYXJndW1lbnRzIGFuZCB3aGljaCBvcGVyYXRlcyBlbGVt > ZW50d2lzZS4KKyAgXGNvZGV7RlVOfSBtdXN0IGJlIGEgdmVjdG9yaXplZCBmdW5jdGlvbiAob3Ig > dGhlIG5hbWUgb2YgaXQpIHdoaWNoIGV4cGVjdHMgYXQKKyAgbGVhc3QgdHdvIGFyZ3VtZW50cy4K > IAogICBcY29kZXtYfSBhbmQgXGNvZGV7WX0gbXVzdCBiZSBzdWl0YWJsZSBhcmd1bWVudHMgZm9y > IFxjb2Rle0ZVTn0uICBFYWNoCiAgIHdpbGwgYmUgZXh0ZW5kZWQgYnkgXGNvZGV7XGxpbmt7cmVw > fX0gdG8gbGVuZ3RoIHRoZSBwcm9kdWN0cyBvZiB0aGUKQEAgLTU0LDcgKzU0LDggQEAgWCBcJW9c > JSBZCiBcc2VlYWxzb3sKICAgXGNvZGV7XGxpbmt7XCUqXCV9fSBmb3IgdXN1YWwgKFxlbXBoe2lu > bmVyfSkgbWF0cml4IHZlY3RvcgogICBtdWx0aXBsaWNhdGlvbjsKLSAgXGNvZGV7XGxpbmt7a3Jv > bmVja2VyfX0gd2hpY2ggaXMgYmFzZWQgb24gXGNvZGV7b3V0ZXJ9LgorICBcY29kZXtcbGlua3tr > cm9uZWNrZXJ9fSB3aGljaCBpcyBiYXNlZCBvbiBcY29kZXtvdXRlcn07CisgIFxjb2Rle1xsaW5r > e1ZlY3Rvcml6ZX19IGZvciB2ZWN0b3JpemluZyBhIG5vbi12ZWN0b3JpemVkIGZ1bmN0aW9uLgog > fQogXGV4YW1wbGVzewogeCA8LSAxOjk7IG5hbWVzKHgpIDwtIHgK > --=_Part_13308_28087893.1196796187581-- > __ > 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] Wishlist: mention Vectorize in 'outer' man page (PR#10490)
Wow.
Now it seems much more explicit and clear than before. Thanks!
2007/12/5, Peter Dalgaard <[EMAIL PROTECTED]>:
> Peter Dalgaard wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>> antonio fabio <[EMAIL PROTECTED]>
> >>> on Tue, 4 Dec 2007 20:25:21 +0100 (CET) writes:
> >>>
> >>>
> >> > --=_Part_13308_28087893.1196796187581
> >> > Content-Type: text/plain; charset=ISO-8859-1
> >> > Content-Transfer-Encoding: 7bit
> >> > Content-Disposition: inline
> >>
> >> > Here a possible patch. What do you think about it?
> >>
> >> attachments don't make it through R-bugs -> R-devel correctly.
> >>
> >> Please use cut & paste instead.
> >>
> >>
> > base64 -di is not THAT hard. I'll apply it to R-devel
> >
> (The patch, not base64, or course...).
>
> Done. Actually, I ended up polishing a bit more:
>
> --- src/library/base/man/outer.Rd (revision 43598)
> +++ src/library/base/man/outer.Rd (working copy)
> @@ -26,13 +26,15 @@
>\item{\dots}{optional arguments to be passed to \code{FUN}.}
> }
> \details{
> - \code{FUN} must be a function (or the name of it) which expects at
> - least two arguments and which operates elementwise.
> -
>\code{X} and \code{Y} must be suitable arguments for \code{FUN}. Each
>will be extended by \code{\link{rep}} to length the products of the
>lengths of \code{X} and \code{Y} before \code{FUN} is called.
>
> + \code{FUN} is called with these two extended vectors as
> + arguments. Therefore, it must be a vectorized function (or the
> + name of one), expecting at
> + least two arguments.
> +
>Where they exist, the [dim]names of \code{X} and \code{Y} will be
>copied to the answer, and a dimension assigned which is the
>concatenation of the dimensions of \code{X} and \code{Y} (or lengths
> @@ -54,7 +56,8 @@
> \seealso{
>\code{\link{\%*\%}} for usual (\emph{inner}) matrix vector
>multiplication;
> - \code{\link{kronecker}} which is based on \code{outer}.
> + \code{\link{kronecker}} which is based on \code{outer};
> + \code{\link{Vectorize}} for vectorizing a non-vectorized function.
> }
> \examples{
> x <- 1:9; names(x) <- x
>
> --
>O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
>
>
--
Antonio, Fabio Di Narzo
Ph.D. student at
Department of Statistical Sciences
University of Bologna, Italy
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial formatting typo in summary(lm()) (PR#10480)
[EMAIL PROTECTED] wrote: > I'm about to commit a fix to this "age old" typo, > using "R-squared" in both cases as Jeff suggests, > unless some R-corer tells me I should not. > > Yes, indeed, two *.Rout.save files need to be replaced too, > but I don't think that this --- and the fact that the output in many > books will eventually be "wrong" by a difference of > ' "r" - "R" ' > would be good enough reason to keep this inconsistency. > > Ok? > I think so. (At least one of the books is in the process of being updated anyway...) The thing NOT to do (or at least be very careful with) is to mess with things that are actually NAMES of something (like the "Sum of Sq" in some anova() output), because someone might be using them for indexing. > Martin > > > >> "JR" == Jeffrey Racine <[EMAIL PROTECTED]> >> on Fri, 30 Nov 2007 19:40:12 +0100 (CET) writes: >> > > JR> Full_Name: Jeffrey Racine > JR> Version: 2.6.1 and previous... > JR> OS: FreeBSD > JR> Submission from: (NULL) (130.113.139.86) > > > JR> Hi. > > JR> I almost feel bad reporting this, but here goes. > > JR> The summary() for lm() (and possibly others?) uses a capitalized `S' > in Multiple > JR> R-Squared but a lowercase `s' in Adjusted R-squared. For instance, > > JR> Residual standard error: 0.5608 on 202 degrees of freedom > JR> Multiple R-Squared: 0.2308, Adjusted R-squared: 0.2232 > JR> F-statistic: 30.3 on 2 and 202 DF, p-value: 3.103e-12 > > JR> Perhaps they both ought to be lowercase? Again, truly trivial but > perhaps it > JR> adds to the overall polish... > > JR> -- Jeff > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial formatting typo in summary(lm()) (PR#10480)
I'm about to commit a fix to this "age old" typo, using "R-squared" in both cases as Jeff suggests, unless some R-corer tells me I should not. Yes, indeed, two *.Rout.save files need to be replaced too, but I don't think that this --- and the fact that the output in many books will eventually be "wrong" by a difference of ' "r" - "R" ' would be good enough reason to keep this inconsistency. Ok? Martin > "JR" == Jeffrey Racine <[EMAIL PROTECTED]> > on Fri, 30 Nov 2007 19:40:12 +0100 (CET) writes: JR> Full_Name: Jeffrey Racine JR> Version: 2.6.1 and previous... JR> OS: FreeBSD JR> Submission from: (NULL) (130.113.139.86) JR> Hi. JR> I almost feel bad reporting this, but here goes. JR> The summary() for lm() (and possibly others?) uses a capitalized `S' in Multiple JR> R-Squared but a lowercase `s' in Adjusted R-squared. For instance, JR> Residual standard error: 0.5608 on 202 degrees of freedom JR> Multiple R-Squared: 0.2308, Adjusted R-squared: 0.2232 JR> F-statistic: 30.3 on 2 and 202 DF, p-value: 3.103e-12 JR> Perhaps they both ought to be lowercase? Again, truly trivial but perhaps it JR> adds to the overall polish... JR> -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] confint for coefficients from lm model (PR#10496)
[EMAIL PROTECTED] wrote:
> Full_Name: Christian Lajaunie
> Version: 2.5.1
> OS: Fedora fc6
> Submission from: (NULL) (193.251.63.39)
>
>
> confint() does not use the appropriate variance term when the design
> matrix contains a zero column (which of course should not happen).
> Example:
>
> A 10x2 matrix with trivial column 1:
>
>
>> junk <- data.frame(x=rep(0,10), u=factor(sample(c("Y", "N"), 10, replace=T)))
>>
>
> The response:
>
>> ans <- as.integer(junk$u) + rnorm(10)
>>
> and the model:
>
>> junk.model <- lm(ans ~ junk$x + junk$u)
>>
>
> 3 coefficients:
>
>
>> coefficients(junk.model)
>>
> (Intercept) junk$x junk$uY
> 0.6808802 NA 1.5912192
>
> and a 2x2 variance (X^tX)^-1:
>
>
>> vcov(junk.model)
>>
> (Intercept) junk$uY
> (Intercept) 0.09905378 -0.09905378
> junk$uY -0.09905378 0.19810756
>
> result in no confidence interval for the third term:
>
>
>> confint(junk.model)
>>
> 2.5 % 97.5 %
> (Intercept) -0.04488412 1.406644
> junk$x NA NA
> junk$uY NA NA
>
> confint() seems to be looking for diag(vcov(junk.model))[3]
> instead of diag(vcov(junk.model))[2]
>
(You should upgrade, but this is the same in 2.6.1)
Yes. And confint.glm and confint.default are bad too. The glm method
must be a different issue, but the other two share the vcov issue.
I'm a bit unsure what is the right fix, though. Is vcov really
returning the wrong thing? Should we rather have
> vcov(junk.model)
[,1] [,2] [,3]
[1,] 0.5525259 NA -0.5525259
[2,] NA NA NA
[3,] -0.5525259 NA 0.6906574
which is not massively hard to achieve.
Alternatively we could just skip the aliased coefficients. For GLMs we
definitely do not want to profile them...
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: mention Vectorize in 'outer' man page (PR#10490)
[EMAIL PROTECTED] wrote:
>> antonio fabio <[EMAIL PROTECTED]>
>> on Tue, 4 Dec 2007 20:25:21 +0100 (CET) writes:
>>
>
> > --=_Part_13308_28087893.1196796187581
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
>
> > Here a possible patch. What do you think about it?
>
> attachments don't make it through R-bugs -> R-devel correctly.
>
> Please use cut & paste instead.
>
base64 -di is not THAT hard. I'll apply it to R-devel
diff --git a/src/library/base/man/outer.Rd b/src/library/base/man/outer.Rd
index 9f32b78..75e8c87 100644
--- a/src/library/base/man/outer.Rd
+++ b/src/library/base/man/outer.Rd
@@ -26,8 +26,8 @@ X \%o\% Y
\item{\dots}{optional arguments to be passed to \code{FUN}.}
}
\details{
- \code{FUN} must be a function (or the name of it) which expects at
- least two arguments and which operates elementwise.
+ \code{FUN} must be a vectorized function (or the name of it) which
expects at
+ least two arguments.
\code{X} and \code{Y} must be suitable arguments for \code{FUN}. Each
will be extended by \code{\link{rep}} to length the products of the
@@ -54,7 +54,8 @@ X \%o\% Y
\seealso{
\code{\link{\%*\%}} for usual (\emph{inner}) matrix vector
multiplication;
- \code{\link{kronecker}} which is based on \code{outer}.
+ \code{\link{kronecker}} which is based on \code{outer};
+ \code{\link{Vectorize}} for vectorizing a non-vectorized function.
}
\examples{
x <- 1:9; names(x) <- x
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] os x crash using rpanel and tcltk (PR#10495)
[EMAIL PROTECTED] wrote:
> Hello,
> I've recently discovered a persistent issue with rpanel when running
> R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any
> apparent error, and the interactive panels appear to work as expected,
> however upon closing the panels rpanel has created I get catastrophic
> errors and R crashes completely. For the most part R manages to crash
> with dignity and work can be saved, but sometimes it will crash
> straight out. Below is an example of an entire work session (only base
> packages loaded) with the crash at the end typical of those
> encountered:
>
>
>> library(tcltk)
>>
> Loading Tcl/Tk interface ... done
>
>> library(rpanel)
>>
> Package `rpanel', version 1.0-4
> type help(rpanel) for summary information
>
>> density.draw <- function(panel) {
>>
> + plot(density(panel$x, bw = panel$h))
> + panel
> + }
>
>> panel <- rp.control(x = rnorm(50))
>> rp.slider(panel, h, 0.5, 5, log = TRUE, action = density.draw)
>>
>
> *** caught bus error ***
> address 0x0, cause 'non-existent physical address'
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
>
> All packages that are required are up to date, and I can find no
> evidence of similar issues from searching the mailing lists. Any
> suggestions would be appreciated.
>
>
Can you run this under gdb? A breakpoint in the error handler and a
backtrace could be valuable.
> Aaron
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] color palette from red to blue passing white (shifted from R-help)
Hi Martin Maechler wrote: >> "Paul" == Paul Murrell <[EMAIL PROTECTED]> >> on Wed, 05 Dec 2007 08:53:10 +1300 writes: > > Paul> Hi > Paul> Achim and I have been looking at tidying up the colorspace package > (see > Paul> http://r-forge.r-project.org/projects/colorspace/) to fix a few > Paul> inaccuracies, PLUS the possibility of declaring R's internal color > space > Paul> to be sRGB. > > Paul> I have started an RFC on the r-developer site > Paul> (http://developer.r-project.org/sRGB-RFC.html) to discuss some > possible > Paul> changes to the core engine and add-on packages. > > Paul> One of the issues will be consolidating some of the double-ups > (e.g., > Paul> hcl() in base and the counterpart in package 'colorspace'; I did > not > Paul> even know about convertColor()!). > > Paul> Ideally, we would have only one copy of the conversions between the > Paul> various colorspaces (probably C code, then the various R-level front > Paul> ends can all just run off the same internal code). > > Paul> A lot of these conversions exist now in 'colorspace', but as Thomas > Paul> pointed out, the S4-ness of 'colorspace' is a problem for making > these > Paul> conversions part of base R. > > Hmm, I think we are currently only required to keep 'base' not > dependent on 'methods'. > Why should 'grDevices' or new "standard R" package not be > dependent on 'methods' ? > Many of us would like to see S4 been used much more widely. Great. I will keep working on the RFC to see if I can propose a way to reconcile all of the color-conversion and palette-selection code based on a single sRGB representation in the R core and only one set of conversion functions. Paul > Martin -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] os x crash using rpanel and tcltk (PR#10495)
Hello,
I've recently discovered a persistent issue with rpanel when running
R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any
apparent error, and the interactive panels appear to work as expected,
however upon closing the panels rpanel has created I get catastrophic
errors and R crashes completely. For the most part R manages to crash
with dignity and work can be saved, but sometimes it will crash
straight out. Below is an example of an entire work session (only base
packages loaded) with the crash at the end typical of those
encountered:
> library(tcltk)
Loading Tcl/Tk interface ... done
> library(rpanel)
Package `rpanel', version 1.0-4
type help(rpanel) for summary information
> density.draw <- function(panel) {
+ plot(density(panel$x, bw = panel$h))
+ panel
+ }
> panel <- rp.control(x = rnorm(50))
> rp.slider(panel, h, 0.5, 5, log = TRUE, action = density.draw)
*** caught bus error ***
address 0x0, cause 'non-existent physical address'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
All packages that are required are up to date, and I can find no
evidence of similar issues from searching the mailing lists. Any
suggestions would be appreciated.
Aaron
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] confint for coefficients from lm model (PR#10496)
Full_Name: Christian Lajaunie
Version: 2.5.1
OS: Fedora fc6
Submission from: (NULL) (193.251.63.39)
confint() does not use the appropriate variance term when the design
matrix contains a zero column (which of course should not happen).
Example:
A 10x2 matrix with trivial column 1:
> junk <- data.frame(x=rep(0,10), u=factor(sample(c("Y", "N"), 10, replace=T)))
The response:
> ans <- as.integer(junk$u) + rnorm(10)
and the model:
> junk.model <- lm(ans ~ junk$x + junk$u)
3 coefficients:
> coefficients(junk.model)
(Intercept) junk$x junk$uY
0.6808802 NA 1.5912192
and a 2x2 variance (X^tX)^-1:
> vcov(junk.model)
(Intercept) junk$uY
(Intercept) 0.09905378 -0.09905378
junk$uY -0.09905378 0.19810756
result in no confidence interval for the third term:
> confint(junk.model)
2.5 % 97.5 %
(Intercept) -0.04488412 1.406644
junk$x NA NA
junk$uY NA NA
confint() seems to be looking for diag(vcov(junk.model))[3]
instead of diag(vcov(junk.model))[2]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] confint for coefficients from lm model (PR#10496)
Yes, vcov is doing the right thing, and it does return dimnames. (Note
what the help page says about what parameters.)
If you do this via names not numbers it works out. I have the .lm and
.default cases working, but need more time to look into others.
On Wed, 5 Dec 2007, Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
>> Full_Name: Christian Lajaunie
>> Version: 2.5.1
>> OS: Fedora fc6
>> Submission from: (NULL) (193.251.63.39)
>>
>>
>> confint() does not use the appropriate variance term when the design
>> matrix contains a zero column (which of course should not happen).
>> Example:
>>
>> A 10x2 matrix with trivial column 1:
>>
>>
>>> junk <- data.frame(x=rep(0,10), u=factor(sample(c("Y", "N"), 10,
>>> replace=T)))
>>>
>>
>> The response:
>>
>>> ans <- as.integer(junk$u) + rnorm(10)
>>>
>> and the model:
>>
>>> junk.model <- lm(ans ~ junk$x + junk$u)
>>>
>>
>> 3 coefficients:
>>
>>
>>> coefficients(junk.model)
>>>
>> (Intercept) junk$x junk$uY
>> 0.6808802 NA 1.5912192
>>
>> and a 2x2 variance (X^tX)^-1:
>>
>>
>>> vcov(junk.model)
>>>
>> (Intercept) junk$uY
>> (Intercept) 0.09905378 -0.09905378
>> junk$uY -0.09905378 0.19810756
>>
>> result in no confidence interval for the third term:
>>
>>
>>> confint(junk.model)
>>>
>> 2.5 % 97.5 %
>> (Intercept) -0.04488412 1.406644
>> junk$x NA NA
>> junk$uY NA NA
>>
>> confint() seems to be looking for diag(vcov(junk.model))[3]
>> instead of diag(vcov(junk.model))[2]
>>
> (You should upgrade, but this is the same in 2.6.1)
>
> Yes. And confint.glm and confint.default are bad too. The glm method
> must be a different issue, but the other two share the vcov issue.
>
> I'm a bit unsure what is the right fix, though. Is vcov really
> returning the wrong thing? Should we rather have
>
> > vcov(junk.model)
> [,1] [,2] [,3]
> [1,] 0.5525259 NA -0.5525259
> [2,] NA NA NA
> [3,] -0.5525259 NA 0.6906574
>
> which is not massively hard to achieve.
>
> Alternatively we could just skip the aliased coefficients. For GLMs we
> definitely do not want to profile them...
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
