Re: [Rd] assign(FALSE, TRUE)
PD == Peter Dalgaard [EMAIL PROTECTED]
on Tue, 18 Nov 2008 15:07:04 +0100 writes:
PD Martin Maechler wrote:
PD == Peter Dalgaard [EMAIL PROTECTED] on
Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD Martin Maechler wrote:
But in spite of all that I agree that I'd have liked
`FALSE` - whatever to signal an error about the
fact that it is a reserved word.
RT This is clearly not a very important issue, but it might
RT bear some thinking about.
Yes. I'd propose that R-core look into how to make
assignment to a reserved word an error.
PD I disagree. In a sense, this is the point of having the
PD backtick operator: allowing you to work with names that
PD would otherwise be syntax errors (notice that such names
PD are sometimes created outside your control, e.g. via
PD column names in data frames). If you start disallowing
PD some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise
syntax errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
PD Please unconvince yourself then... You are solving a
PD problem that isn't there: In R, you can assign to
PD `FALSE` and access it as `FALSE`. You can not access it
PD as FALSE because that is a keyword and you cannot assign
PD to FALSE either.
I now have been unconvinced,
((so the following is just some clarification ...))
but notably not mainly by the above. I'd consider the backtick
operator as -- very nice -- syntactic sugar for
assign() and get().
And, for normal identifiers,
foo - 1
`foo` - 1
assign(foo, 1)
and
foo
`foo`
get(foo)
are each three-fold equivalent. If a user does not *know* about
keywords/reserved words, (s)he can get a bit confused by
how e.g. break or `break` e.g. are handled:
Recall that Joe Average User does not know about assign, get,
`..` etc, but does know about ls() and typing an object name:
If he does ls(), sees break (which stems from previous
assign(break, 3) or `break` - 3)
and then types
break
or
str(break)
into the R console to inspect the variable he has seen in
ls(), the result will be a bit confusing to such
a user, and I had wanted that we'd evade that confusion.
The example with FALSE or `FALSE` is different but with similar
potential confusion.
{ S / S-plus does not either and gives a nice error
message:
S assign(FALSE, TRUE)
Problem: The name FALSE is reserved -- assignments to
it are not allowed }
PD But FALSE is not a keyword in S. In R this would
PD correspond to locking down F and T.
Hmm,... maybe. Brian has already answered to that.
Martin
PD There's another issue, namely that some keywords do have
PD associated functions; e.g., `if` exists as a variable,
PD and walls do come tumbling down if you redefine it (to a
PD different function). However, that is a completely
PD different thing, more related to redefining +.
PD (Incidentally, how hard would it be to ensure that such
PD symbols were always looked up in the base namespace?).
PD -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
PD c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014
PD Cph. K (*) \(*) -- University of Copenhagen Denmark Ph:
PD (+45) 35327918 ~~ - ([EMAIL PROTECTED])
PD FAX: (+45) 35327907
PD __
PD R-devel@r-project.org mailing list
PD 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] (PR#13234) Problems with Sweave and pdf.options(encoding=ISOLatin7)
I can't actually check what happens since the message has been
garbled en route to me. Can you please send what you intended using
\u escapes so it is portable. (What I have is what appears to be
UTF-8 re-encoded in UTF-8, things like c3 84 3f.)
And can you also confirm that the example works correctly directly in
pdf()?
On Fri, 31 Oct 2008, [EMAIL PROTECTED] wrote:
Hi,
Sweave for some reason does not respect encoding setting in pdf.options.
Rather it uses its own setting. I think you need to set option
pdf.encoding=ISOLatin7 on the Sweave call.
It would probably be better if Sweave() fetched the default for
options$pdf.encoding from pdf.options(), and definitely that this was
documented.
Everything is OK with ps.options. Thus when using non-default encoding
for graphs, resulting graphics eps file is correct, but pdf file is
not. Workaround is very simple, just use latex-dvips-ps2pdf chain to
get the intended pdf document. I tried to find the explanation for this,
but I did not find anything. If this is documented behaviour, I am sorry
for the disturbance.
After Sweaving the file below, pdflatex and latex-dvips-ps2pdf will
produce different pdfs. The tex file compiled succesfully in Ubuntu
8.04, and TeXLive 2007.
Sincerely yours,
Vaidotas Zemlys
test.Rnw file:
\documentclass[a4paper]{article}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\title{Problem with pdf.options}
\author{Vaidotas Zemlys}
\begin{document}
\maketitle
Note the Lithuanian letters in latex will not display correctly, you
need
additional package. This does not matter to R, since we use Unicode and
pass the
correct encoding.
\begin{center}
fig=TRUE,echo=TRUE=
pdf.options(enc=ISOLatin7)
ps.options(enc=ISOLatin7)
plot(rnorm(100),main=Ä?žųÄ?Å¡Ä?Ä?įū)
@
\end{center}
\end{document}
--please do not edit the information below--
Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 8.0
year = 2008
month = 10
day = 20
svn rev = 46754
language = R
version.string = R version 2.8.0 (2008-10-20)
Locale:
[EMAIL PROTECTED];LC_NUMERIC=C;[EMAIL PROTECTED];[EMAIL
PROTECTED];LC_MONETARY=C;[EMAIL PROTECTED];[EMAIL
PROTECTED];LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;[EMAIL
PROTECTED];LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
__
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
Re: [Rd] assign(FALSE, TRUE)
Martin Maechler wrote: but notably not mainly by the above. I'd consider the backtick operator as -- very nice -- syntactic sugar for assign() and get(). And, for normal identifiers, foo - 1 `foo` - 1 assign(foo, 1) foo - 1 # same effect as above and foo `foo` get(foo) foo # not 1? (that is to say, i find this a tiny little bit incoherent, but perhaps useful for assignments, as is easier to get from my keyboard than `) are each three-fold equivalent. If a user does not *know* about keywords/reserved words, (s)he can get a bit confused by how e.g. break or `break` e.g. are handled: Recall that Joe Average User does not know about assign, get, `..` etc, but does know about ls() and typing an object name: If he does ls(), sees break (which stems from previous assign(break, 3) or `break` - 3) and then types break or str(break) btw. i find the following sequence of error messages a tiny little bit confusing: break(1) # Error: no loop to break from, jumping to top level break = function(arg) arg break(1) # Error in break : argument arg is missing, with no default break = function(arg=1) arg break(1) # Error: attempt to apply non-function if = function(arg) arg if(1) # keeps waiting for more input if(1) 2 # Error in if (1) 2 : unused argument(s) (2) vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292)
constant at unb.br writes: For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is obviously incorrect and inversely proportional to the number of replicates: data(HairEyeColor) x - margin.table(HairEyeColor, c(1, 2)) chisq.test(x,simulate.p.value=TRUE,B=2000) Pearson's Chi-squared test with simulated p-value (based on 2000 replicates) data: x X-squared = 138.2898, df = NA, p-value = 0.0004998 chisq.test(x,simulate.p.value=TRUE,B=1) X-squared = 138.2898, df = NA, p-value = 1e-04 chisq.test(x,simulate.p.value=TRUE,B=10) X-squared = 138.2898, df = NA, p-value = 1e-05 chisq.test(x,simulate.p.value=TRUE,B=100) X-squared = 138.2898, df = NA, p-value = 1e-06 ... Tried to answer this the other day but the answer must have gotten lost. The standard analytical chi-squared test here gives p2.2e-16 (i.e. very very small). The values given above, up to limited display of significant digits, are precisely 1/(B+1); that is, the simulated chi-squared values are never less than the observed chi-squared statistic (the observed value itself is included in the ensemble, so the p-value is given as 1/(B+1) rather that 1/B; you can read about the reasons for this elsewhere [?]). Bottom line: why do you think these results are obviously incorrect? Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist - better object.size() function
Some time ago I came across the function object.size() to estimate the
size of an R object. I don't know if the behavior of the function is
intended to be quite user unfriendly as it is right now or if just
nobody was thinking/caring about it.
I have two suggestions to improve it:
- Why is it named object.size() and not just size()? The latter would be
far more intuitive and shorter and as far as I know there is no other
function size (in the base distribution).
- Why is the function returning the size in bytes? This is (in most
cases) overly accurate and for humans hard to read. I would suggest to
have it printed in mb per default and additionally add a switch to
choose the appropriate unit.
This is a first proposal:
size - function(x, type=c(mb,byte,kb,gb), digits=3){
type - match.arg(type)
RET - switch(type,
byte = object.size(x),
kb = object.size(x)/1024,
mb = object.size(x)/(1024^2),
gb = object.size(x)/(1024^3))
cat(round(RET,digits), type, \n)
invisible(RET)
}
I think this would improve the usability of the function a lot.
Thanks,
Benjamin
--
**
Dipl.-Stat. Benjamin Hofner
Institut für Medizininformatik, Biometrie und Epidemiologie
Friedrich-Alexander-Universität Erlangen-Nürnberg
Waldstr. 6 - 91054 Erlangen - Germany
Tel: +49-9131-85-22707
Fax: +49-9131-85-25740
http://www.imbe.med.uni-erlangen.de/~hofnerb/
http://www.benjaminhofner.de
**
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding=ISOLatin7)
2008/11/19 Prof Brian Ripley [EMAIL PROTECTED]: I can't actually check what happens since the message has been garbled en route to me. Can you please send what you intended using \u escapes so it is portable. (What I have is what appears to be UTF-8 re-encoded in UTF-8, things like c3 84 3f.) And can you also confirm that the example works correctly directly in pdf()? OK, the modified R code is: plot(rnorm(100),main=\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E) It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. On Fri, 31 Oct 2008, [EMAIL PROTECTED] wrote: Hi, Sweave for some reason does not respect encoding setting in pdf.options. Rather it uses its own setting. I think you need to set option pdf.encoding=ISOLatin7 on the Sweave call. Is it possible to do that? Sweave function in R, does not support that, and using SweaveHooks produced the same result. It would probably be better if Sweave() fetched the default for options$pdf.encoding from pdf.options(), and definitely that this was documented. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. I looked at the code of RweaveLatexSetup, and saw that pdf.encoding is defined explicitly, that is how I figured out, that probably eps files are probably ok. Sorry for the garbled message, next time I will send unicode portable code without relying on email encodings. Sincerely yours, Vaidotas Zemlys __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R license: GPL v2 or v3?
There is an analysis of the R license here:
http://www.ohloh.net/projects/rproject/analyses/latest
On Tue, Nov 18, 2008 at 5:24 PM, Gabriel Gellner [EMAIL PROTECTED] wrote:
For a project I am porting some of R's source code, and I want to
get the license for my project correct, but the top level COPYING file
for R's source states GPL v2, but when using:
license()
(which also states GPL version 2) points me towards:
RShowDoc('COPYING')
which states GPL v3. Which is correct?
Thanks for clarification (and the amazing amount of code!).
Gabriel
__
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] (PR#13234) Problems with Sweave and pdf.options(encoding=ISOLatin7)
On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: 2008/11/19 Prof Brian Ripley [EMAIL PROTECTED]: I can't actually check what happens since the message has been garbled en route to me. Can you please send what you intended using \u escapes so it is portable. (What I have is what appears to be UTF-8 re-encoded in UTF-8, things like c3 84 3f.) And can you also confirm that the example works correctly directly in pdf()? OK, the modified R code is: plot(rnorm(100),main=\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E) It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. It works for me in xpdf, but not Acroread 8.1.3. On Fri, 31 Oct 2008, [EMAIL PROTECTED] wrote: Hi, Sweave for some reason does not respect encoding setting in pdf.options. Rather it uses its own setting. I think you need to set option pdf.encoding=ISOLatin7 on the Sweave call. Is it possible to do that? Sweave function in R, does not support that, and using SweaveHooks produced the same result. So it is not recognizing the option, it seems: Yes, RweaveLatexSetup does not know about it. It would probably be better if Sweave() fetched the default for options$pdf.encoding from pdf.options(), and definitely that this was documented. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. Yes, Sweave is supposedly frozen pending unbundling. Note that this does work (at least for me) in lt_LT.utf8: it is because you were in fr_FR.utf8 that you had a problem. So I think the solution is actually pretty simple: use the correct locale. I've changed R-patched to take the defaults from pdf.options(), but Sweave should still be able to set them. I looked at the code of RweaveLatexSetup, and saw that pdf.encoding is defined explicitly, that is how I figured out, that probably eps files are probably ok. Sorry for the garbled message, next time I will send unicode portable code without relying on email encodings. Sincerely yours, Vaidotas Zemlys -- 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
[Rd] Buggy trellis.focus() with xyplot ?
Hi:
(Tried to find a bug report about this issue, but was unable to find it, let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using R 2.8 with lattice 0.17-15
*** To replicate the bug:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and have large margins in the left hand
and right hand side.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenotes:
There are other problems with the focus in JavaGD but I just wanted to
include a simple self contained example in this mail.
If you make the window smaller, trellis.focus() works fine, you have to make
it bigger than the initial size.
*** To Fix the bug:
I tried to fix this bug in interraction.R but I was unsuccesful.
The problem should stem from the a bad calculation of the pads in the
follwoing lines :
leftPad -
convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary constants to
make it work for a particular instance of a xyplot with a particular size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad + Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any plot
with any window size, but I might be valuable information.
*** Questions:
- Is this a real bug ?
- Any suggestions for fixing it ?
- If it can't be fixed, is there a way around this bug ?
(For example, setting the margins to be zero and set a fixed size for the
xplot)
Thanks.
Daniel.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - better object.size() function
Benjamin Hofner Benjamin.Hofner at imbe.med.uni-erlangen.de writes: ... - Why is the function returning the size in bytes? This is (in most cases) overly accurate and for humans hard to read. I would suggest to have it printed in mb per default and additionally add a switch to choose the appropriate unit. This is a first proposal: ... There was a such proposal some time ago. See https://stat.ethz.ch/pipermail/r-devel/2006-August/038935.html https://stat.ethz.ch/pipermail/r-devel/2006-September/042673.html http://tolstoy.newcastle.edu.au/R/e2/devel/06/09/0181.html Unfortunatelly, there was no interest in adding this to R. I removed the files mentioned in above posts. However, the proposed implementation was added to my private-playground package ggmisc. The package can be downloaded at http://gregor.gorjanc.googlepages.com/ggmisc_0.2.1.tar.gz http://gregor.gorjanc.googlepages.com/ggmisc_0.2.1.zip gg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure.vars arg needed for install.packages
Currently, install.packages takes a 'configure.args' argument that adds a --configure-args to the eventual call to R CMD INSTALL. It does not, however, have a 'configure.vars' argument to similarly add the --configure-vars option to R CMD INSTALL, which seems to be an oversight. -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding=ISOLatin7)
Just to close the loop on this, the following works in en_GB.utf8 on 2.8.0: fig=TRUE,echo=TRUE,pdf.encoding=ISOLatin7= pdf.options(enc=ISOLatin7) ps.options(enc=ISOLatin7) plot(rnorm(100),main=\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E) @ I think the point is that you can use different encodings for different figures in one Sweave document. But in R-devel you can now pass any option via the Sweave() call as I at least expected from the documentation. Vaidotas Zemlys wrote: 2008/11/19 Prof Brian Ripley [EMAIL PROTECTED]: On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: OK, the modified R code is: plot(rnorm(100),main=\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E) It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. It works for me in xpdf, but not Acroread 8.1.3. Yes, I checked only with evince, and assumed, that Acroread will be similar. Acrobat 9 (on windows) shows the letters, but they are bunched up together. Changing the default family to URWHelvetica did not help either. So that rules out using pdf for me. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. Yes, Sweave is supposedly frozen pending unbundling. Note that this does work (at least for me) in lt_LT.utf8: it is because you were in fr_FR.utf8 that you had a problem. So I think the solution is actually pretty simple: use the correct locale. I've changed R-patched to take the defaults from pdf.options(), but Sweave should still be able to set them. Aah, this does not occured to me. I thought that because locale is unicode it should not matter which unicode letters I use. That is a not correct assumption. Thank you for your answers, Vaidotas Zemlys -- 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
[Rd] doc buglet / attr method
Under Value section for attr:
For the extractor, the value of the attribute matched,
or \code{NULL} if no exact match is found and no or more
^^
than one partial match is found.
R version 2.7.2 (2008-08-25)
-- and --
https://svn.r-project.org/R/trunk/src/library/base/man/attr.Rd
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Buggy trellis.focus() with xyplot in JavaGD ?
Hi:
(Tried to find a bug report about this issue, but was unable to find it, let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using JGR R 2.8 with lattice 0.17-15
Note: It's important to you use JGR to use the Java Graphics Device.
*** To Replicate the Bug ***:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and to have large margins on all sides.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenote:
If you make the window smaller, trellis.focus() works fine, you have to make
it bigger than the initial size.
*** To Fix the Bug ***:
I tried to fix this bug in interraction.R but I was unsuccessful.
The problem should stem from the a bad calculation of the margins.
Notice that if you set the margins to 0 size the bug above does not appear.
You can test this with:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
par.settings=list(
layout.widths=list(left.padding=0, right.padding=0),
layout.heights=list(top.padding=0, bottom.padding=0))
)
I traced the a bad calculation of the pads in the following lines :
leftPad - convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]),
npc, valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary constants to
make it work for a particular instance of a xyplot with a particular size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad + Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any plot
with any window size, but I might be valuable information.
*** Questions ***:
- Is this a real bug ?
- Any suggestions for fixing it ?
- The only way around I have found around this bug is to make the margins 0
is there any other way.
IMPORTANT NOTE:
I have found other problems with the focus in JavaGD but did not mention
them since I just wanted to include a simple self contained example in this
mail.
Thanks.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strategy for downloading packages
I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. Is there an automated tool to do this? That is: - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strategy for downloading packages
On Nov 19, 2008, at 15:52 , Duncan Murdoch wrote: I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. Why would that be necessary? The order is plays no role, since all it's just unpacking, so you can as well burn the content of the installed library and you're set... Or am I missing something? Cheers, S Is there an automated tool to do this? That is: - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch __ 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] Strategy for downloading packages
On Wed, 19 Nov 2008, Duncan Murdoch wrote: I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. I don't think the install order matters for binary packages (on Windows or elsewhere). install.packages() certainly does not optimize it. Is there an automated tool to do this? That is: The easiest way is to copy a repository to the CD-ROM, and point repos at that (as a file::// URL). You can even add files and rebuild the PACKAGES file (using tools::write_PACKAGES). But if the list of packages never changes, why not just install them in a separate library and burn that on the CD-ROM? - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch __ 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
Re: [Rd] Strategy for downloading packages
On 11/19/2008 4:07 PM, Simon Urbanek wrote: On Nov 19, 2008, at 15:52 , Duncan Murdoch wrote: I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. Why would that be necessary? The order is plays no role, since all it's just unpacking, so you can as well burn the content of the installed library and you're set... Or am I missing something? Thanks, I didn't realize that the install order doesn't matter. But in the longer term, he'll probably want to do this himself, so he'll still need to generate the list of dependencies and download them. Or maybe just burning a copy of the installed library is what he should do --- I'd just be worried about versioning issues if he tries to update the install without starting from scratch. Duncan Murdoch Cheers, S Is there an automated tool to do this? That is: - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strategy for downloading packages
On 11/19/2008 4:16 PM, Prof Brian Ripley wrote: On Wed, 19 Nov 2008, Duncan Murdoch wrote: I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. I don't think the install order matters for binary packages (on Windows or elsewhere). install.packages() certainly does not optimize it. Thanks, as I mentioned to Simon I didn't know this. That definitely makes things simpler. Is there an automated tool to do this? That is: The easiest way is to copy a repository to the CD-ROM, and point repos at that (as a file::// URL). You can even add files and rebuild the PACKAGES file (using tools::write_PACKAGES). But if the list of packages never changes, why not just install them in a separate library and burn that on the CD-ROM? In the long run, the first order dependencies won't likely change, but their dependencies might. We didn't write those packages, we just use them. Duncan Murdoch - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch __ 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] grid error: protection stack overflow
Hi
Felix Andrews wrote:
I have isolated an error that can be reproduced by the following code.
The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the
try() code is ending up in the display list, or something?
The problem was that the *unsuccessful* downViewport() was ending up on
the display list (which lead to an infinite loop on a display list
replay, which produced the error). I have committed a fix to r-devel.
Thanks for the report!
Paul
p.s. A side-bug that this investigation exposed is that using try() on
graphics code can have the effect (when an error occurs) of turning off
display list recording for the device. No solution in sight for that
bug, so best to stay away from try() for now, as your follow up email
suggested.
library(grid)
library(lattice)
xyplot(1:100 ~ 1:100)
test - try(downViewport(pageAnnotationVp), silent = TRUE)
downViewport(trellis.vpname(toplevel))
pushViewport(viewport(name = pageAnnotationVp, yscale = c(1, 0)))
upViewport(0)
## resize device to trigger a couple of redraws...
Error: protect(): protection stack overflow
Enter a frame number, or 0 to exit
1: no.children(environment)
2: ls(children, all.names = TRUE)
3: try(name)
4: tryCatch(expr, error = function(e) {
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatchOne(expr, names, parentenv, handlers[[1]])
7: doTryCatch(return(expr), name, parentenv, handler)
sessionInfo()
R version 2.8.0 Patched (2008-11-10 r46884)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
other attached packages:
[1] lattice_0.17-15
--
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] paste() retains quotes (PR#13304)
Full_Name: Giles L Crane Version: 2.8.0 2008-10-20 OS: Windows XP Submission from: (NULL) (71.168.215.186) paste(rep( ,10),sep=) [1] As I read the documentation for paste(), this should have produced that is, all spaces pasted together. Hope this is helpful. GLC __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding=ISOLatin7)
2008/11/19 Prof Brian Ripley [EMAIL PROTECTED]: On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: OK, the modified R code is: plot(rnorm(100),main=\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E) It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. It works for me in xpdf, but not Acroread 8.1.3. Yes, I checked only with evince, and assumed, that Acroread will be similar. Acrobat 9 (on windows) shows the letters, but they are bunched up together. Changing the default family to URWHelvetica did not help either. So that rules out using pdf for me. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. Yes, Sweave is supposedly frozen pending unbundling. Note that this does work (at least for me) in lt_LT.utf8: it is because you were in fr_FR.utf8 that you had a problem. So I think the solution is actually pretty simple: use the correct locale. I've changed R-patched to take the defaults from pdf.options(), but Sweave should still be able to set them. Aah, this does not occured to me. I thought that because locale is unicode it should not matter which unicode letters I use. That is a not correct assumption. Thank you for your answers, Vaidotas Zemlys __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] qr.coef and complex numbers - still busted for non-square case? (PR#13305)
Full_Name: Rick Sayre
Version: 2.8.0
OS: windows, linux, os x
Submission from: (NULL) (138.72.153.166)
PR#8476 and PR#8478
http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8478
http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8476
discuss fixing qr.coef to handle complex matrices correctly
But it appears the solution now shipping only handles square matrices.
In 2.8.0 [linux, windows, and os x] non-square complex arguments cause
an error.
qr.solve(cbind(1:11,1),2*(20:30))
[1] 2 38
qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30)))
Error in coef[qr$pivot, ] - .Call(qr_coef_cmplx, qr, y, PACKAGE = base) :
number of items to replace is not a multiple of replacement length
If I change the section shown by context below from qr.coef as follows:
if (is.complex(qr$qr)) {
if (!is.complex(y))
y[] - as.complex(y)
coef - matrix(NA_complex_, nrow = p, ncol = ny)
#coef[qr$pivot, ] - .Call(qr_coef_cmplx, qr, y, PACKAGE = base)
coef[qr$pivot, ] - .Call(qr_coef_cmplx, qr, y, PACKAGE =
base)[1:p,]
return(if (im) coef else c(coef))
}
then i get goodness:
my.qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30)))
[1] 2+0i 38+0i
I do not pretend to fully understand the afflicted code, so it is very likely
I'm doing it wrong. What I just did above is exactly what Chris
proposed in #8478, but it appears this was declared to be incorrect and
changed.
The current code in qr.coef seems to handle square complex matrices, but as you
see above, it does not handle non-square conditions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste() retains quotes (PR#13304)
On Wed, 19 Nov 2008, [EMAIL PROTECTED] wrote: Full_Name: Giles L Crane Version: 2.8.0 2008-10-20 OS: Windows XP Submission from: (NULL) (71.168.215.186) paste(rep( ,10),sep=) [1] As I read the documentation for paste(), this should have produced that is, all spaces pasted together. You read it wrong: that is what collapse= does. Hope this is helpful. Quite the reverse, a beginners' mistake. GLC __ 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
Re: [Rd] Buggy trellis.focus() with xyplot ?
On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
Hi:
(Tried to find a bug report about this issue, but was unable to find it, let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using R 2.8 with lattice 0.17-15
*** To replicate the bug:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and have large margins in the left hand
and right hand side.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenotes:
There are other problems with the focus in JavaGD but I just wanted to
include a simple self contained example in this mail.
If you make the window smaller, trellis.focus() works fine, you have to make
it bigger than the initial size.
*** To Fix the bug:
I tried to fix this bug in interraction.R but I was unsuccesful.
The problem should stem from the a bad calculation of the pads in the
follwoing lines :
leftPad -
convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary constants to
make it work for a particular instance of a xyplot with a particular size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad + Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any plot
with any window size, but I might be valuable information.
*** Questions:
- Is this a real bug ?
- Any suggestions for fixing it ?
- If it can't be fixed, is there a way around this bug ?
(For example, setting the margins to be zero and set a fixed size for the
xplot)
It appears that the conversions used in the current implementation
(contributed by Felix Andrews) don't work when aspect != fill
(probably leading back to the use of 'respect = TRUE' in grid.layout).
The right way to do this is to first go down to the subregion
containing just the panels, and then locate the click location within
it. But this requires a suitable viewport to be predefined.
I have changed print.trellis to create such a dummy viewport
(accessible by trellis.focus(figure)), and modified trellis.focus()
to use it. I will test it a bit more before uploading a new version
(and also give Felix a chance to see if this breaks anything in
playwith etc.). To see if the fix works, you can try the svn copy at
https://svn.r-project.org/R-packages/trunk/lattice
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Buggy trellis.focus() with xyplot ?
2008/11/20 Deepayan Sarkar [EMAIL PROTECTED]:
On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
Hi:
(Tried to find a bug report about this issue, but was unable to find it, let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using R 2.8 with lattice 0.17-15
*** To replicate the bug:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and have large margins in the left hand
and right hand side.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenotes:
There are other problems with the focus in JavaGD but I just wanted to
include a simple self contained example in this mail.
If you make the window smaller, trellis.focus() works fine, you have to make
it bigger than the initial size.
*** To Fix the bug:
I tried to fix this bug in interraction.R but I was unsuccesful.
The problem should stem from the a bad calculation of the pads in the
follwoing lines :
leftPad -
convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary constants to
make it work for a particular instance of a xyplot with a particular size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad + Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any plot
with any window size, but I might be valuable information.
*** Questions:
- Is this a real bug ?
- Any suggestions for fixing it ?
- If it can't be fixed, is there a way around this bug ?
(For example, setting the margins to be zero and set a fixed size for the
xplot)
It appears that the conversions used in the current implementation
(contributed by Felix Andrews) don't work when aspect != fill
(probably leading back to the use of 'respect = TRUE' in grid.layout).
Yep, my fault, didn't think it through.
The right way to do this is to first go down to the subregion
containing just the panels, and then locate the click location within
it. But this requires a suitable viewport to be predefined.
I have changed print.trellis to create such a dummy viewport
(accessible by trellis.focus(figure)), and modified trellis.focus()
to use it. I will test it a bit more before uploading a new version
(and also give Felix a chance to see if this breaks anything in
It won't affect playwith; playwith now uses a different approach: a function
inViewport(x.px, y.px, viewport)
reports whether a click location in pixels is inside the given
viewport. I loop through each panel viewport and check whether the
click is inside.
playwith etc.). To see if the fix works, you can try the svn copy at
https://svn.r-project.org/R-packages/trunk/lattice
-Deepayan
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Buggy trellis.focus() with xyplot ?
Thanks a lot for taking this on guys !
Some more background in case you are interested:
I have almost a working version of focus for selecting a panel with mouse
over in a stanalone Java application using an REngine I only have two
issues:
- trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes
1.5 seconds to unfocus, do you know any way to speed it up ?
- the conversion problem that Deepayan referred too in the previous, but I
guess that will be fixed soon. :-)
I am working in a bastardized version of trellis.focus taking an x and y
from an event handler (in Java, C, etc ...) which focuses and highlights the
panel so the REngine instance can perform more operations on the selected
panel.
This would be very useful for easily creating GUI for interactive
visualizations exploration of large multidimensional data sets using lattice
and geared towards non programmers.
I don't really know what I am getting into, so any advice would be welcomed.
Daniel.
2008/11/19 Felix Andrews [EMAIL PROTECTED]
2008/11/20 Deepayan Sarkar [EMAIL PROTECTED]:
On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
Hi:
(Tried to find a bug report about this issue, but was unable to find it,
let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using R 2.8 with lattice 0.17-15
*** To replicate the bug:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and have large margins in the left
hand
and right hand side.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenotes:
There are other problems with the focus in JavaGD but I just wanted to
include a simple self contained example in this mail.
If you make the window smaller, trellis.focus() works fine, you have to
make
it bigger than the initial size.
*** To Fix the bug:
I tried to fix this bug in interraction.R but I was unsuccesful.
The problem should stem from the a bad calculation of the pads in the
follwoing lines :
leftPad -
convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]),
npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]),
npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary
constants to
make it work for a particular instance of a xyplot with a particular
size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad +
Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad +
Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any
plot
with any window size, but I might be valuable information.
*** Questions:
- Is this a real bug ?
- Any suggestions for fixing it ?
- If it can't be fixed, is there a way around this bug ?
(For example, setting the margins to be zero and set a fixed size for
the
xplot)
It appears that the conversions used in the current implementation
(contributed by Felix Andrews) don't work when aspect != fill
(probably leading back to the use of 'respect = TRUE' in grid.layout).
Yep, my fault, didn't think it through.
The right way to do this is to first go down to the subregion
containing just the panels, and then locate the click location within
it. But this requires a suitable viewport to be predefined.
I have changed print.trellis to create such a dummy viewport
(accessible by trellis.focus(figure)), and modified trellis.focus()
to use it. I will test it a bit more before uploading a new version
(and also give Felix a chance to see if this breaks anything in
It won't affect playwith; playwith now uses a different approach: a
function
inViewport(x.px, y.px, viewport)
reports whether a click location in pixels is inside the given
viewport. I loop through each panel viewport and check whether the
click is inside.
playwith etc.). To see if the
Re: [Rd] Buggy trellis.focus() with xyplot ?
2008/11/20 Daniel Kornhauser [EMAIL PROTECTED]:
Thanks a lot for taking this on guys !
Some more background in case you are interested:
I have almost a working version of focus for selecting a panel with mouse
over in a stanalone Java application using an REngine I only have two
issues:
- trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes
1.5 seconds to unfocus, do you know any way to speed it up ?
Yep, redrawing R plots is slow. If you remove a grob the whole plot
needs to be redrawn. The solution is to use highlight = FALSE in the
trellis.focus() command. Obviously then there will be no visual
indication (red outline) of which panel is in focus. (If you need that
you could draw it yourself and then overpaint it with white to hide
it, maybe... the best solution would be to draw it using Java
graphics, rather than R graphics, and store a buffer, but I don't know
whether that's possible in your system).
- the conversion problem that Deepayan referred too in the previous, but I
guess that will be fixed soon. :-)
I am working in a bastardized version of trellis.focus taking an x and y
from an event handler (in Java, C, etc ...) which focuses and highlights the
panel so the REngine instance can perform more operations on the selected
panel.
This would be very useful for easily creating GUI for interactive
visualizations exploration of large multidimensional data sets using lattice
and geared towards non programmers.
I don't really know what I am getting into, so any advice would be welcomed.
Sounds similar to some of the functionality of the 'playwith' and/or
'latticist' packages. You might want to look at them. playwith is
built with GTK+.
Daniel.
2008/11/19 Felix Andrews [EMAIL PROTECTED]
2008/11/20 Deepayan Sarkar [EMAIL PROTECTED]:
On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
Hi:
(Tried to find a bug report about this issue, but was unable to find
it, let
me know if this is a known issue)
I have been working on an interface to highlight xyplot panels on mouse
overs in JavaGD but I have stumbled with what seems to be a bug in
trellis.focus.
I am using R 2.8 with lattice 0.17-15
*** To replicate the bug:
1.- display an xyplot. For example, from the xyplot help page:
library(lattice)
require(stats)
EE - equal.count(ethanol$E, number=9, overlap=1/4)
## Constructing panel functions on the fly; prepanel
xyplot(NOx ~ C | EE, data = ethanol,
prepanel = function(x, y) prepanel.loess(x, y, span = 1),
xlab = Compression Ratio, ylab = NOx (micrograms/J),
panel = function(x, y) {
panel.grid(h=-1, v= 2)
panel.xyplot(x, y)
panel.loess(x,y, span=1)
},
aspect = xy)
2.- resize to window be rectangular and have large margins in the left
hand
and right hand side.
3.- run trellis.focus() and try to select the first or last panel, you
should observe that it does not select the right one.
sidenotes:
There are other problems with the focus in JavaGD but I just wanted to
include a simple self contained example in this mail.
If you make the window smaller, trellis.focus() works fine, you have to
make
it bigger than the initial size.
*** To Fix the bug:
I tried to fix this bug in interraction.R but I was unsuccesful.
The problem should stem from the a bad calculation of the pads in the
follwoing lines :
leftPad -
convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
valueOnly = TRUE)
rightPad -
convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]),
npc,
valueOnly = TRUE)
topPad -
convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
valueOnly = TRUE)
botPad -
convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]),
npc,
valueOnly = TRUE)
I was succesful in tweaking the follwing lines adding arbitrary
constants to
make it work for a particular instance of a xyplot with a particular
size of
a window
clickXScaled - (as.numeric(clickLoc$x) - leftPad +
Danielconstant1)
/ (1 - leftPad - rightPad + Danielconstant1)
clickYScaled - (as.numeric(clickLoc$y) - botPad +
Danielconstant2)
/ (1 - botPad - topPad + Danielconstant3)
This is of course a useless fix, since you want the fix to work for any
plot
with any window size, but I might be valuable information.
*** Questions:
- Is this a real bug ?
- Any suggestions for fixing it ?
- If it can't be fixed, is there a way around this bug ?
(For example, setting the margins to be zero and set a fixed size for
the
xplot)
It appears that the conversions used in the current implementation
(contributed by Felix Andrews) don't work when aspect != fill
(probably leading back to the use of 'respect = TRUE' in grid.layout).
Yep, my fault, didn't think it through.
The right way
Re: [Rd] Buggy trellis.focus() with xyplot ?
On 11/19/08, Daniel Kornhauser [EMAIL PROTECTED] wrote: Thanks a lot for taking this on guys ! Some more background in case you are interested: I have almost a working version of focus for selecting a panel with mouse over in a stanalone Java application using an REngine I only have two issues: - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes 1.5 seconds to unfocus, do you know any way to speed it up ? Call as trellis.unfocus(highlight=FALSE). Unhighlighting essentially redraws the whole thing (this would be true whenever any component is removed, though adding is fine). -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
