[Rd] Request to Replace Recordplot ,, replayplot
Record plot which stores a plot to an internal R data structure and Replay Plot which replays the plot enables one to keep plots around and use them accross sessions at least until version 3. If you cannot restore old plots and treat them as data and save accross sessions, there is little reason for recordPlot. Either R needs to dispense with internal formats entirelly, a bad move in my opinion or revise the structure so that it can be read from a file and then replayed and augmented. This internal facility, in some ways equivalent to the matlab fig is good to have around. It would not be needed if one of the data formats already stored i.e. pdf ... etc. could be read in and used then as internal plot. Your thoughts --mike -- Michael Cohen Work: 808 Commonwealth Avenue, Actuarial Sciences, Boston Mass Home: 25 Stearns Road #3 Brookline, MA Ph: 1-857-389-3432(c) 1-617-758-5509(w) 617-734-8828(h) Fax: 617-353-7755 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request to Replace Recordplot ,, replayplot
Hi Michael, It is not needed to post this two days in a row on the same mailing list. Also if you search the archives, you find several previous discussions on this topic that might be helpful to develop a more informed opinion on the topic. In short: the problem is well known. Several people have argued for the benefits of supporting (serializable) plot objects similar to matlab figs, however apparently this is not trivial to implement. As with most software, the challenging aspect is to maintain backward compatibility so that it doesn't break everything that currently relies on it. Perhaps if you study the source code of the R graphics device to gain better understanding of the problem, you can develop a proposal or implement a proof of concept of how you think this could be realized. That might provide a more constructive basis for discussion. On Thu, May 1, 2014 at 11:58 AM, Michael Cohen wrote: > > Record plot which stores a plot to an internal R data structure and Replay > Plot which > replays the plot enables one to keep plots around and use them accross > sessions at least until version 3. If you cannot restore old plots and > treat them as data and save accross sessions, there is little reason for > recordPlot. Either R needs to dispense with internal formats entirelly, a > bad move in my opinion or revise the structure so that it can be read from > a file and then replayed and augmented. This internal facility, in some > ways equivalent to the matlab fig is good to have around. It would not be > needed if one of the data formats already stored i.e. pdf ... etc. could be > read in and used then as internal plot. Your thoughts > --mike > > -- > Michael Cohen > Work: 808 Commonwealth Avenue, Actuarial Sciences, Boston Mass > Home: 25 Stearns Road #3 Brookline, MA > Ph: 1-857-389-3432(c) 1-617-758-5509(w) 617-734-8828(h) Fax: 617-353-7755 > > [[alternative HTML version deleted]] > > __ > 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] Quantile issue
> Therneau, Terry M , Ph D
> on Wed, 30 Apr 2014 12:00:33 -0500 writes:
> This is likely yet another instance of round off error,
> but it caught me by surprise. tmt% R --vanilla (headers
> skipped, version 3.0.2 on Linux)
>> load('qtest.rda') length(temp)
> [1] 3622
>> max(temp) >= quantile(temp, .98)
>98% FALSE
> I can send the file to anyone who would like to understand
> this more deeply. The top 3% of the vector is a single
> repeated value.
Hmm... this may be the same as PR#15746 :
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15746
on which I commented that it was an example of FAQ 7.31 :
> Martin Maechler 2014-04-10 07:10:41 UTC
> What really happens is simply
> > x0 <- 0.000384478262997113
> > h <- (1:9)/10
> > diff(range((1-h)*x0 + h*x0))
> [1] 1.084202e-19
> >
> and that of course *is* just R FAQ 7.31
> I'm not sure this is something we want to amend; we *could*
> ensure
>min(x) <= quantile(x, *) <= max(x)
> with a bit of extra code that makes *all* calls of quantile
> slower than
> now... just for the sake of this one very very rare exception ?
> Alternatively we just document it ..
> Maybe this needs public discussion on R-devel
and so I did bring it to R-devel.
If look at the fuller report, you also see that I claim that
this seems to happen only for very rare numbers...,
I had a loop running, searching for such numbers as the above x0
and it did not find one in many hours...,
OTOH, you now found a second example (of the same phenomenon I think).
So, yes, please, send me the qtest.rda...
or to all of us a dput(.) of the top 5% of the data which may
suffice for a reproducible example.
Also, it seems that for these rare examples we may need to rewrite
the code of quantile.default() ... making it less nice, less
transparent, not something I think we should commit lightly.
Martin
> Terry Therneau
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to test if an object/argument is "parse tree" - without evaluating it?
This may have been asked before, but is there an elegant way to check
whether an variable/argument passed to a function is a "parse tree"
for an (unevaluated) expression or not, *without* evaluating it if
not?
Currently, I do various rather ad hoc eval()+substitute() tricks for
this that most likely only work under certain circumstances. Ideally,
I'm looking for a isParseTree() function such that I can call:
expr0 <- foo({ x <- 1 })
expr1 <- foo(expr0)
stopifnot(identical(expr1, expr0))
where foo() is:
foo <- function(expr) {
if (!isParseTree(expr))
expr <- substitute(expr)
expr
}
I also want to be able to do:
expr2 <- foo(foo(foo(foo(expr0
stopifnot(identical(expr2, expr0))
and calling foo() from within other functions that may use the same
"tricks". The alternative is of course to do:
foo <- function(expr, substitute=TRUE) {
if (substitute) expr <- substitute(expr)
expr
}
but it would be neat to do this without passing an extra argument. If
this is not possible to implement in plain R, can this be done
internally inspecting SEXP:s and so on? Even better would be if
substitute() could do this for me, e.g.
expr <- substitute(expr, unlessAlreadyDone=TRUE)
Any suggestions?
Thanks,
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quantile issue
[this was meant as "reply to all" to R-devel :]
> Therneau, Terry M , Ph D
> on Wed, 30 Apr 2014 12:00:33 -0500 writes:
> This is likely yet another instance of round off error,
> but it caught me by surprise. tmt% R --vanilla (headers
> skipped, version 3.0.2 on Linux)
>> load('qtest.rda') length(temp)
> [1] 3622
>> max(temp) >= quantile(temp, .98)
>98% FALSE
> I can send the file to anyone who would like to understand
> this more deeply. The top 3% of the vector is a single
> repeated value.
Hmm... this may be the same as PR#15746 :
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15746
on which I commented that it was an example of FAQ 7.31 :
> Martin Maechler 2014-04-10 07:10:41 UTC
> What really happens is simply
> > x0 <- 0.000384478262997113
> > h <- (1:9)/10
> > diff(range((1-h)*x0 + h*x0))
> [1] 1.084202e-19
> >
> and that of course *is* just R FAQ 7.31
> I'm not sure this is something we want to amend; we *could*
> ensure
>min(x) <= quantile(x, *) <= max(x)
> with a bit of extra code that makes *all* calls of quantile
> slower than
> now... just for the sake of this one very very rare exception ?
> Alternatively we just document it ..
> Maybe this needs public discussion on R-devel
and so I did bring it to R-devel.
If look at the fuller report, you also see that I claim that
this seems to happen only for very rare numbers...,
I had a loop running, searching for such numbers as the above x0
and it did not find one in many hours...,
OTOH, you now found a second example (of the same phenomenon I think).
So, yes, please, send me the qtest.rda...
or to all of us a dput(.) of the top 5% of the data which may
suffice for a reproducible example.
Also, it seems that for these rare examples we may need to rewrite
the code of quantile.default() ... making it less nice, less
transparent, not something I think we should commit lightly.
Martin
> Terry Therneau
> __
> 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] How to test if an object/argument is "parse tree" - without evaluating it?
On 01/05/2014, 4:39 PM, Henrik Bengtsson wrote:
This may have been asked before, but is there an elegant way to check
whether an variable/argument passed to a function is a "parse tree"
for an (unevaluated) expression or not, *without* evaluating it if
not?
"Parse tree" isn't R terminology. Could you give an example of one call
that passes a parse tree, and one that doesn't?
Duncan Murdoch
Currently, I do various rather ad hoc eval()+substitute() tricks for
this that most likely only work under certain circumstances. Ideally,
I'm looking for a isParseTree() function such that I can call:
expr0 <- foo({ x <- 1 })
expr1 <- foo(expr0)
stopifnot(identical(expr1, expr0))
where foo() is:
foo <- function(expr) {
if (!isParseTree(expr))
expr <- substitute(expr)
expr
}
I also want to be able to do:
expr2 <- foo(foo(foo(foo(expr0
stopifnot(identical(expr2, expr0))
and calling foo() from within other functions that may use the same
"tricks". The alternative is of course to do:
foo <- function(expr, substitute=TRUE) {
if (substitute) expr <- substitute(expr)
expr
}
but it would be neat to do this without passing an extra argument. If
this is not possible to implement in plain R, can this be done
internally inspecting SEXP:s and so on? Even better would be if
substitute() could do this for me, e.g.
expr <- substitute(expr, unlessAlreadyDone=TRUE)
Any suggestions?
Thanks,
Henrik
__
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] Request to Replace Recordplot ,, replayplot
Hi, no need to repost and start yet another thread on the same topic as you posted yesterday (R-devel thread ''ReplayPlot, limited to single session for RecordPlot()", 2014-04-30). It just makes it hard to keep a constructive conversation in one place and it clutters up the archives. Replaying plots within the current session is still useful. I'm sure others would love to be able to replay saved R plots across sessions. However, there was (most likely) a very good reason for not using it across session, which is why R added the assertion that it's not done - it's to avoid harm/misuse. If you search the R-devel archives [http://www.rseek.org/], you'll find some discussion on this topic, e.g. R-devel threads "inconsistency/bug in recordPlot/replayPlot", 2014-09-23 [https://stat.ethz.ch/pipermail/r-devel/2013-September/067471.html]. You'll find that Paul Murrell and others have though about this a lot. Hopefully, this gives you enough to research to appreciate the problem. /Henrik On Thu, May 1, 2014 at 11:58 AM, Michael Cohen wrote: > Record plot which stores a plot to an internal R data structure and Replay > Plot which > replays the plot enables one to keep plots around and use them accross > sessions at least until version 3. If you cannot restore old plots and > treat them as data and save accross sessions, there is little reason for > recordPlot. Either R needs to dispense with internal formats entirelly, a > bad move in my opinion or revise the structure so that it can be read from > a file and then replayed and augmented. This internal facility, in some > ways equivalent to the matlab fig is good to have around. It would not be > needed if one of the data formats already stored i.e. pdf ... etc. could be > read in and used then as internal plot. Your thoughts > --mike > > -- > Michael Cohen > Work: 808 Commonwealth Avenue, Actuarial Sciences, Boston Mass > Home: 25 Stearns Road #3 Brookline, MA > Ph: 1-857-389-3432(c) 1-617-758-5509(w) 617-734-8828(h) Fax: 617-353-7755 > > [[alternative HTML version deleted]] > > __ > 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] How to test if an object/argument is "parse tree" - without evaluating it?
Henrik,
If I understand correctly, you want something along the lines of
(following your example):
foo <- function(expr) {
if (!is.language(expr)) substitute(expr)
else expr
}
## first example
expr0 <- foo({ x <- 1 })
expr1 <- foo(expr0)
stopifnot(identical(expr1, expr0))
## second
expr2 <- foo(foo(foo(foo(expr0
stopifnot(identical(expr2, expr0))
Hadley's guide on NSE + language elements in R
(http://adv-r.had.co.nz/Computing-on-the-language.html,
http://adv-r.had.co.nz/Expressions.html) may be helpful here.
Cheers,
Kevin
On Thu, May 1, 2014 at 1:54 PM, Duncan Murdoch wrote:
> On 01/05/2014, 4:39 PM, Henrik Bengtsson wrote:
>>
>> This may have been asked before, but is there an elegant way to check
>> whether an variable/argument passed to a function is a "parse tree"
>> for an (unevaluated) expression or not, *without* evaluating it if
>> not?
>
>
> "Parse tree" isn't R terminology. Could you give an example of one call
> that passes a parse tree, and one that doesn't?
>
> Duncan Murdoch
>
>
>>
>> Currently, I do various rather ad hoc eval()+substitute() tricks for
>> this that most likely only work under certain circumstances. Ideally,
>> I'm looking for a isParseTree() function such that I can call:
>>
>> expr0 <- foo({ x <- 1 })
>> expr1 <- foo(expr0)
>> stopifnot(identical(expr1, expr0))
>>
>> where foo() is:
>>
>> foo <- function(expr) {
>>if (!isParseTree(expr))
>> expr <- substitute(expr)
>>expr
>> }
>>
>> I also want to be able to do:
>>
>> expr2 <- foo(foo(foo(foo(expr0
>> stopifnot(identical(expr2, expr0))
>>
>> and calling foo() from within other functions that may use the same
>> "tricks". The alternative is of course to do:
>>
>> foo <- function(expr, substitute=TRUE) {
>>if (substitute) expr <- substitute(expr)
>>expr
>> }
>>
>> but it would be neat to do this without passing an extra argument. If
>> this is not possible to implement in plain R, can this be done
>> internally inspecting SEXP:s and so on? Even better would be if
>> substitute() could do this for me, e.g.
>>
>> expr <- substitute(expr, unlessAlreadyDone=TRUE)
>>
>> Any suggestions?
>>
>> Thanks,
>>
>> Henrik
>>
>> __
>> 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] How to test if an object/argument is "parse tree" - without evaluating it?
> This may have been asked before, but is there an elegant way to check
> whether an variable/argument passed to a function is a "parse tree"
> for an (unevaluated) expression or not, *without* evaluating it if
> not?
I doubt it.
Some packages say that if the argument is a formula then its right
hand side will be used, unevaluated. (You could issue a warning if
the formula had a left side.) This offloads the logic to the ~ or
formula function. It also has the advantage that environment(formula)
tells you where the symbols in the expression should be looked up.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, May 1, 2014 at 1:39 PM, Henrik Bengtsson wrote:
> This may have been asked before, but is there an elegant way to check
> whether an variable/argument passed to a function is a "parse tree"
> for an (unevaluated) expression or not, *without* evaluating it if
> not?
>
> Currently, I do various rather ad hoc eval()+substitute() tricks for
> this that most likely only work under certain circumstances. Ideally,
> I'm looking for a isParseTree() function such that I can call:
>
> expr0 <- foo({ x <- 1 })
> expr1 <- foo(expr0)
> stopifnot(identical(expr1, expr0))
>
> where foo() is:
>
> foo <- function(expr) {
> if (!isParseTree(expr))
> expr <- substitute(expr)
> expr
> }
>
> I also want to be able to do:
>
> expr2 <- foo(foo(foo(foo(expr0
> stopifnot(identical(expr2, expr0))
>
> and calling foo() from within other functions that may use the same
> "tricks". The alternative is of course to do:
>
> foo <- function(expr, substitute=TRUE) {
> if (substitute) expr <- substitute(expr)
> expr
> }
>
> but it would be neat to do this without passing an extra argument. If
> this is not possible to implement in plain R, can this be done
> internally inspecting SEXP:s and so on? Even better would be if
> substitute() could do this for me, e.g.
>
> expr <- substitute(expr, unlessAlreadyDone=TRUE)
>
> Any suggestions?
>
> Thanks,
>
> Henrik
>
> __
> 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] How to test if an object/argument is "parse tree" - without evaluating it?
On Thu, May 1, 2014 at 4:08 PM, Kevin Ushey wrote:
> Henrik,
>
> If I understand correctly, you want something along the lines of
> (following your example):
>
> foo <- function(expr) {
> if (!is.language(expr)) substitute(expr)
> else expr
> }
>
> ## first example
> expr0 <- foo({ x <- 1 })
> expr1 <- foo(expr0)
> stopifnot(identical(expr1, expr0))
>
> ## second
> expr2 <- foo(foo(foo(foo(expr0
> stopifnot(identical(expr2, expr0))
Unfortunately this won't work in general because is.language evaluates expr:
foo(stop("Uh oh!"))
In general, I'm with Bill Dunlap - you're better off being explicit
with formulas.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to test if an object/argument is "parse tree" - without evaluating it?
My take would be that this is barking up the wrong tree. If you want to pass
expressions in a way that a function can recognize, use formulas or expression
objects.
One problem is that pretty much every unevaluated argument is a "parse tree".
The only other thing it can be is a constant object, but that is really just
the simplest possible parse tree.
In what situation exactly were you expecting isParseTree to return FALSE?
-pd
On 01 May 2014, at 22:39 , Henrik Bengtsson wrote:
> This may have been asked before, but is there an elegant way to check
> whether an variable/argument passed to a function is a "parse tree"
> for an (unevaluated) expression or not, *without* evaluating it if
> not?
>
> Currently, I do various rather ad hoc eval()+substitute() tricks for
> this that most likely only work under certain circumstances. Ideally,
> I'm looking for a isParseTree() function such that I can call:
>
> expr0 <- foo({ x <- 1 })
> expr1 <- foo(expr0)
> stopifnot(identical(expr1, expr0))
>
> where foo() is:
>
> foo <- function(expr) {
> if (!isParseTree(expr))
> expr <- substitute(expr)
> expr
> }
>
> I also want to be able to do:
>
> expr2 <- foo(foo(foo(foo(expr0
> stopifnot(identical(expr2, expr0))
>
> and calling foo() from within other functions that may use the same
> "tricks". The alternative is of course to do:
>
> foo <- function(expr, substitute=TRUE) {
> if (substitute) expr <- substitute(expr)
> expr
> }
>
> but it would be neat to do this without passing an extra argument. If
> this is not possible to implement in plain R, can this be done
> internally inspecting SEXP:s and so on? Even better would be if
> substitute() could do this for me, e.g.
>
> expr <- substitute(expr, unlessAlreadyDone=TRUE)
>
> Any suggestions?
>
> Thanks,
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
