[Rd] Wish: Option to configure the default par() (PR#9545)
Full_Name: Thomas Friedrichsmeier
Version: 2.4.1
OS: linux (Debian unstable)
Submission from: (NULL) (84.60.113.185)
Summary: It would be nice to have a centralized option for setting default par()
options for all devices and all plots. This would ease producing graphs in a
customized but consistent way. Suggesting options("par.default").
Example problem: Make all graphs look like
par(bg="light gray", las=2)
both on screen and for various produced file formats such as png() and
postscript().
Current situation: To solve the example problem, two approaches come to mind:
1) Always call par() before the next plot. This could be wrapped into a function
to make it easier to stay consistent. E.g.:
postscript()
myDefaultPar() # calls par(bg="light gray", las=2)
plot(...)
2) Create wrappers for all devices of interest, like e.g. (not quite correct,
but good enough for this example):
myX11 <- function(...) {
X11(...)
par(bg="light gray", las=2)
}
Both solutions work, but are not entirely elegant. The drawback of 1) is that
you still need to add the given line manually at all places. The drawback of 2)
is that a similar wrapper will have to be created (and used) for each different
device.
Wish:
Add a new option: options("par.default"), similar to the existing
options("par.ask.default"). This option would accept a list of all par settings
to set a custom default for:
options(par.default=list(bg="light gray", las=2))
par() options specified while creating the device, in calls to plot() or in
subsequent calls to par() would take precendence over options("par.default").
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish: Option to configure the default par() (PR#9545)
Another approach may be to use hooks (see ?setHook). The plot.new
function already has a hook, so you could do your option #1
automatically by setting that hook.
Better would be if all the graphics device functions had hooks (or a
common hook), then you could set that hook to set your graphics
parameters and they would be set every time a new graphics device was
started.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, March 06, 2007 7:04 AM
> To: r-devel@stat.math.ethz.ch
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] Wish: Option to configure the default par() (PR#9545)
>
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.1
> OS: linux (Debian unstable)
> Submission from: (NULL) (84.60.113.185)
>
>
> Summary: It would be nice to have a centralized option for
> setting default par() options for all devices and all plots.
> This would ease producing graphs in a customized but
> consistent way. Suggesting options("par.default").
>
> Example problem: Make all graphs look like
>
> par(bg="light gray", las=2)
>
> both on screen and for various produced file formats such as
> png() and postscript().
>
> Current situation: To solve the example problem, two
> approaches come to mind:
> 1) Always call par() before the next plot. This could be
> wrapped into a function to make it easier to stay consistent. E.g.:
>
> postscript()
> myDefaultPar() # calls par(bg="light gray", las=2)
> plot(...)
>
> 2) Create wrappers for all devices of interest, like e.g.
> (not quite correct, but good enough for this example):
>
> myX11 <- function(...) {
> X11(...)
> par(bg="light gray", las=2)
> }
>
> Both solutions work, but are not entirely elegant. The
> drawback of 1) is that you still need to add the given line
> manually at all places. The drawback of 2) is that a similar
> wrapper will have to be created (and used) for each different device.
>
> Wish:
> Add a new option: options("par.default"), similar to the
> existing options("par.ask.default"). This option would accept
> a list of all par settings to set a custom default for:
>
> options(par.default=list(bg="light gray", las=2))
>
> par() options specified while creating the device, in calls
> to plot() or in subsequent calls to par() would take
> precendence over options("par.default").
>
> __
> 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] Wish: Option to configure the default par() (PR#9545)
Another approach may be to use hooks (see ?setHook). The plot.new
function already has a hook, so you could do your option #1
automatically by setting that hook.
Better would be if all the graphics device functions had hooks (or a
common hook), then you could set that hook to set your graphics
parameters and they would be set every time a new graphics device was
started.
--=20
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
=20
=20
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of=20
> [EMAIL PROTECTED]
> Sent: Tuesday, March 06, 2007 7:04 AM
> To: r-devel@stat.math.ethz.ch
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] Wish: Option to configure the default par() (PR#9545)
>=20
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.1
> OS: linux (Debian unstable)
> Submission from: (NULL) (84.60.113.185)
>=20
>=20
> Summary: It would be nice to have a centralized option for=20
> setting default par() options for all devices and all plots.=20
> This would ease producing graphs in a customized but=20
> consistent way. Suggesting options("par.default").
>=20
> Example problem: Make all graphs look like
>=20
> par(bg=3D"light gray", las=3D2)
>=20
> both on screen and for various produced file formats such as=20
> png() and postscript().
>=20
> Current situation: To solve the example problem, two=20
> approaches come to mind:
> 1) Always call par() before the next plot. This could be=20
> wrapped into a function to make it easier to stay consistent. E.g.:
>=20
> postscript()
> myDefaultPar() # calls par(bg=3D"light gray", las=3D2)
> plot(...)
>=20
> 2) Create wrappers for all devices of interest, like e.g.=20
> (not quite correct, but good enough for this example):
>=20
> myX11 <- function(...) {
> X11(...)
> par(bg=3D"light gray", las=3D2)
> }
>=20
> Both solutions work, but are not entirely elegant. The=20
> drawback of 1) is that you still need to add the given line=20
> manually at all places. The drawback of 2) is that a similar=20
> wrapper will have to be created (and used) for each different device.
>=20
> Wish:
> Add a new option: options("par.default"), similar to the=20
> existing options("par.ask.default"). This option would accept=20
> a list of all par settings to set a custom default for:
>=20
> options(par.default=3Dlist(bg=3D"light gray", las=3D2))
>=20
> par() options specified while creating the device, in calls=20
> to plot() or in subsequent calls to par() would take=20
> precendence over options("par.default").
>=20
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>=20
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] parse error with if else (PR#9551)
Full_Name: Stephanie MAHEVAS
Version: 2.4.1
OS: Windows NT
Submission from: (NULL) (134.246.55.50)
the two following instructions provide a synthax error :
if ( 5 > 4 ) cat("ok1")
else cat("ok2")
and
if ( 5 > 4 ){ cat("ok1")}
else cat("ok2")
whereas these ones don't
if ( 5 > 4 ) cat("ok1") else cat("ok2")
and
if ( 5 > 4 ){ cat("ok1")
}else cat("ok2")
It looks like a parser problem. If else is not on the same line as if or if the
end of block statement of if } is not paste to else, else does not seem linked
with if
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse error with if else (PR#9551)
[EMAIL PROTECTED] wrote:
> Full_Name: Stephanie MAHEVAS
> Version: 2.4.1
> OS: Windows NT
> Submission from: (NULL) (134.246.55.50)
>
>
>
> the two following instructions provide a synthax error :
>
> if ( 5 > 4 ) cat("ok1")
> else cat("ok2")
This is not a bug!
Since you are allowed to omit the else, R cannot know whether you want
to provide it and thinks you have finished, since
if ( 5 > 4 ) cat("ok1")
already is a valid and complete expression.
Therefore
else cat("ok2")
is a *new* expression which obviously is not valid without if() before.
If you want that R looks at the whole at first, either do as below or
make it a whole expression by putting it into braces as in:
{
if ( 5 > 4 ) cat("ok1")
else cat("ok2")
}
Uwe Ligges
> and
>
> if ( 5 > 4 ){ cat("ok1")}
> else cat("ok2")
>
> whereas these ones don't
>
> if ( 5 > 4 ) cat("ok1") else cat("ok2")
>
> and
>
> if ( 5 > 4 ){ cat("ok1")
> }else cat("ok2")
>
> It looks like a parser problem. If else is not on the same line as if or if
> the
> end of block statement of if } is not paste to else, else does not seem linked
> with if
>
> __
> 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] parse error with if else (PR#9551)
On 3/6/2007 12:15 PM, [EMAIL PROTECTED] wrote:
> Full_Name: Stephanie MAHEVAS
> Version: 2.4.1
> OS: Windows NT
> Submission from: (NULL) (134.246.55.50)
>
>
>
> the two following instructions provide a synthax error :
>
> if ( 5 > 4 ) cat("ok1")
> else cat("ok2")
>
> and
>
> if ( 5 > 4 ){ cat("ok1")}
> else cat("ok2")
>
> whereas these ones don't
>
> if ( 5 > 4 ) cat("ok1") else cat("ok2")
>
> and
>
> if ( 5 > 4 ){ cat("ok1")
> }else cat("ok2")
>
> It looks like a parser problem. If else is not on the same line as if or if
> the
> end of block statement of if } is not paste to else, else does not seem linked
> with if
This is a documented "feature" of the language, not a bug. (See the
language guide, section 3.2.1 "if", around the 4th paragraph.)
It arises because R tries to evaluate a statement as soon as it is
complete, and
if ( 5 > 4 ) cat("ok1")
is a complete statement. You can get the behaviour you want by wrapping
the whole think in curly brackets so that R doesn't start evaluating too
early, e.g.
> {
+ if ( 5 > 4 ) cat("ok1")
+ else cat("ok2")
+ }
ok1>
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug: sticky symbol refs? (PR#9555)
Hello. What happens in the following is that I create two simple functions, f
and g, on the workspace. Then I
replace g. When I then call f, it uses the old version of g. Now clearly, the
circumstances for this to happen
must be quite special and rare. But I'd say they're not pathological. It seems
to require two things: 1) masked versions
of f and g on a search position lower down the search list (but I'm not sure
that's necessary), and 2) using
source() to create the objects, but evaluated in a local environment, not the
global one. I'm pretty confident that
2) is necessary for the bug.
Practical impact: like I suppose many users, I maintain my own R functions in a
.RData file which I've always got
attached at pos 2. Periodically I dump() them to file, take that file to
another site, and source() them in there.
However I don't want all the functions to be created on search pos'n 1, so I
have a wrapper my.source() which creates
them in a local environment then copies from that down to search pos 2. So
that's all fairly innocent, and probably
not uncommon.
How to reproduce:
## put this code in /temp/myFuns.R:
`f` <-
function (x)
{
g(x)
}
`g` <-
function(x)
{
is.null(x)
}
# now create a fresh .RData and attach it at pos 2:
> save(list = character(0), file = "/temp/.RData")# to create it
> attach( "/temp/.RData", pos=2 )
# now source() /temp/myFuns.R in a local env, then copy new objs to search pos
2:
> newEnv <- new.env()
> eval(expression(source(file = "/temp/myFuns.R", local = T)), envir=newEnv)
> for( objName in objects(envir = newEnv, all.names = T) ) {
assign(objName, get(objName, envir = newEnv), pos = 2)
}
> f <- f # copy from pos 2 to workspace; (needed?)
> g <- g # copy from pos 2 to workspace; (needed?)
> f(1) # gives correct answer
[1] FALSE
> g <- function(x) stop( "this is the new g" )
> f(1) # gives wrong answer; uses the old g();
[1] FALSE
# now re-create f from scratch, assign under new name:
> f2 <- eval( parse( text=deparse(f) ) )
> f2(1) # gives correct answer
Error in g(x) : this is the new g
# note that the original f() continues to malfunction;
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 4.1
year = 2006
month = 12
day = 18
svn rev = 40228
language = R
version.string = R version 2.4.1 (2006-12-18)
Windows XP Professional (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
Kingdom.1252;LC_MONETARY=English_United
Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
Search Path:
.GlobalEnv, file:/temp/.RData, file:c:/schupl/R/myRLib/.RData,
file:c:/schupl/R/myFinanceLib/.RData, file:c:/schupl/R/recycler/.RData,
package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, package:base
---
This e-mail may contain confidential and/or privileged infor...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SVG and tooltips, hyperlinks
Dear all, is there a good way to create SVG plots with R whose elements have titles (tooltips) or act as hyperlinks? I am using the RSvgDevice package, which works great - but it doesn't seem to support the notion that plot objects have titles or are act as hyperlinks, so I am helping myself by giving the objects funny unique colors and then postprocessing the .svg file. I wonder whether somebody has already implemented this in a more elegant way. Best wishes Wolfgang -- Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVG and tooltips, hyperlinks
Hi Wolfgang Huber wrote: > Dear all, > > is there a good way to create SVG plots with R whose elements have > titles (tooltips) or act as hyperlinks? > > I am using the RSvgDevice package, which works great - but it doesn't > seem to support the notion that plot objects have titles or are act as > hyperlinks, so I am helping myself by giving the objects funny unique > colors and then postprocessing the .svg file. > > I wonder whether somebody has already implemented this in a more elegant > way. Well, elegance is in the eye of the beholder, but you might want to take a look at the gridSVG package anyway ... http://www.stat.auckland.ac.nz/~paul/index.html Paul > Best wishes >Wolfgang > > -- > Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- 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] Reordering the search path?
Hi, without arguing for doing it or not, is the following a correct
way to reorder the search path:
moveInSearchPath <- function(from, to) {
# Excluding validation of 'from' and 'to' here etc.
# Get enviroment to be moved
env <- pos.to.env(from);
# Detach old position without side effects, cf. detach().
.Internal(detach(from));
if (to > from)
to <- to - 1;
# Attach at new position
attach(env, pos=to, name=attr(env, "name"));
}
Thanks
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug: sticky symbol refs? (PR#9555)
[EMAIL PROTECTED] wrote:
> Hello. What happens in the following is that I create two simple functions, f
> and g, on the workspace. Then I
> replace g. When I then call f, it uses the old version of g. Now clearly, the
> circumstances for this to happen
> must be quite special and rare. But I'd say they're not pathological. It
> seems to require two things: 1) masked versions
> of f and g on a search position lower down the search list (but I'm not sure
> that's necessary), and 2) using
> source() to create the objects, but evaluated in a local environment, not the
> global one. I'm pretty confident that
> 2) is necessary for the bug.
>
> Practical impact: like I suppose many users, I maintain my own R functions in
> a .RData file which I've always got
> attached at pos 2. Periodically I dump() them to file, take that file to
> another site, and source() them in there.
> However I don't want all the functions to be created on search pos'n 1, so I
> have a wrapper my.source() which creates
> them in a local environment then copies from that down to search pos 2. So
> that's all fairly innocent, and probably
> not uncommon.
>
> How to reproduce:
>
> ## put this code in /temp/myFuns.R:
> `f` <-
> function (x)
> {
> g(x)
> }
> `g` <-
> function(x)
> {
> is.null(x)
> }
>
>
> # now create a fresh .RData and attach it at pos 2:
>
>> save(list = character(0), file = "/temp/.RData")# to create it
>> attach( "/temp/.RData", pos=2 )
>>
>
> # now source() /temp/myFuns.R in a local env, then copy new objs to search
> pos 2:
>
>> newEnv <- new.env()
>> eval(expression(source(file = "/temp/myFuns.R", local = T)), envir=newEnv)
>> for( objName in objects(envir = newEnv, all.names = T) ) {
>>
> assign(objName, get(objName, envir = newEnv), pos = 2)
> }
>
>
>> f <- f # copy from pos 2 to workspace; (needed?)
>> g <- g # copy from pos 2 to workspace; (needed?)
>> f(1) # gives correct answer
>>
> [1] FALSE
>
>> g <- function(x) stop( "this is the new g" )
>> f(1) # gives wrong answer; uses the old g();
>>
> [1] FALSE
>
> # now re-create f from scratch, assign under new name:
>
>> f2 <- eval( parse( text=deparse(f) ) )
>> f2(1) # gives correct answer
>>
> Error in g(x) : this is the new g
>
> # note that the original f() continues to malfunction;
>
Not a bug, as far as I can see. The environment of f is newEnv, and
this is where it goes looking for g copying f to the global environment
doesn't change that. That information is part of the function object not
a matter of where the object is bound to a variable. Look at
environment(f), resp. f2 to see the point.
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
> Kingdom.1252;LC_MONETARY=English_United
>
> Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
>
> Search Path:
> .GlobalEnv, file:/temp/.RData, file:c:/schupl/R/myRLib/.RData,
> file:c:/schupl/R/myFinanceLib/.RData, file:c:/schupl/R/recycler/.RData,
>
> package:stats, package:graphics, package:grDevices, package:utils,
> package:datasets, package:methods, Autoloads, package:base
> ---
>
> This e-mail may contain confidential and/or privileged infor...{{dropped}}
>
> __
> 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
