[Rd] withAutoprint({ .... }) ?
On R-help, with subject
'[R] source() does not include added code'
> Joshua Ulrich
> on Wed, 31 Aug 2016 10:35:01 -0500 writes:
> I have quantstrat installed and it works fine for me. If you're
> asking why the output of t(tradeStats('macross')) isn't being printed,
> that's because of what's described in the first paragraph in the
> *Details* section of help("source"):
> Note that running code via ‘source’ differs in a few respects from
> entering it at the R command line. Since expressions are not
> executed at the top level, auto-printing is not done. So you will
> need to include explicit ‘print’ calls for things you want to be
> printed (and remember that this includes plotting by ‘lattice’,
> FAQ Q7.22).
> So you need:
> print(t(tradeStats('macross')))
> if you want the output printed to the console.
indeed, and "of course"" ;-)
As my subject indicates, this is another case, where it would be
very convenient to have a function
withAutoprint()
so the OP could have (hopefully) have used
withAutoprint(source(..))
though that would have been equivalent to the already nicely existing
source(.., print.eval = TRUE)
which works via the withVisible(.) utility that returns for each
'expression' if it would auto print or not, and then does print (or
not) accordingly.
My own use cases for such a withAutoprint({...})
are demos and examples, sometimes even package tests which I want to print:
Assume I have a nice demo / example on a help page/ ...
foo(..)
(z <- bar(..))
summary(z)
where I carefully do print parts (and don't others),
and suddenly I find I want to run that part of the demo /
example / test only in some circumstances, e.g., only when
interactive, but not in BATCH, or only if it is me, the package maintainer,
if( identical(Sys.getenv("USER"), "maechler") ) {
foo(..)
(z <- bar(..))
summary(z)
}
Now all the auto-printing is gone, and
1) I have to find out which of these function calls do autoprint and wrap
a print(..) around these, and
2) the result is quite ugly (for an example on a help page etc.)
What I would like in a future R, is to be able to simply wrap the "{
.. } above with an 'withAutoprint(.) :
if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
foo(..)
(z <- bar(..))
summary(z)
})
Conceptually such a function could be written similar to source() with an R
level for loop, treating each expression separately, calling eval(.) etc.
That may cost too much performnace, ... still to have it would be better than
not having the possibility.
If you read so far, you'd probably agree that such a function
could be a nice asset in R,
notably if it was possible to do this on the fast C level of R's main
REPL.
Have any of you looked into how this could be provided in R ?
If you know the source a little, you will remember that there's
the global variable R_Visible which is crucial here.
The problem with that is that it *is* global, and only available
as that; that the auto-printing "concept" is so linked to "toplevel context"
and that is not easy, and AFAIK not so much centralized in one place in the
source. Consequently, all kind of (very) low level functions manipulate
R_Visible
temporarily and so a C level implementation of withAutoprint() may
need considerable more changes than just setting R_Visible to TRUE in one
place.
Have any efforts / experiments already happened towards providing such
functionality ?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] withAutoprint({ .... }) ?
On 02/09/2016 7:56 AM, Martin Maechler wrote:
On R-help, with subject
'[R] source() does not include added code'
Joshua Ulrich
on Wed, 31 Aug 2016 10:35:01 -0500 writes:
> I have quantstrat installed and it works fine for me. If you're
> asking why the output of t(tradeStats('macross')) isn't being printed,
> that's because of what's described in the first paragraph in the
> *Details* section of help("source"):
> Note that running code via ‘source’ differs in a few respects from
> entering it at the R command line. Since expressions are not
> executed at the top level, auto-printing is not done. So you will
> need to include explicit ‘print’ calls for things you want to be
> printed (and remember that this includes plotting by ‘lattice’,
> FAQ Q7.22).
> So you need:
> print(t(tradeStats('macross')))
> if you want the output printed to the console.
indeed, and "of course"" ;-)
As my subject indicates, this is another case, where it would be
very convenient to have a function
withAutoprint()
so the OP could have (hopefully) have used
withAutoprint(source(..))
though that would have been equivalent to the already nicely existing
source(.., print.eval = TRUE)
which works via the withVisible(.) utility that returns for each
'expression' if it would auto print or not, and then does print (or
not) accordingly.
My own use cases for such a withAutoprint({...})
are demos and examples, sometimes even package tests which I want to print:
Assume I have a nice demo / example on a help page/ ...
foo(..)
(z <- bar(..))
summary(z)
where I carefully do print parts (and don't others),
and suddenly I find I want to run that part of the demo /
example / test only in some circumstances, e.g., only when
interactive, but not in BATCH, or only if it is me, the package maintainer,
if( identical(Sys.getenv("USER"), "maechler") ) {
foo(..)
(z <- bar(..))
summary(z)
}
Now all the auto-printing is gone, and
1) I have to find out which of these function calls do autoprint and wrap
a print(..) around these, and
2) the result is quite ugly (for an example on a help page etc.)
What I would like in a future R, is to be able to simply wrap the "{
.. } above with an 'withAutoprint(.) :
if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
foo(..)
(z <- bar(..))
summary(z)
})
Conceptually such a function could be written similar to source() with an R
level for loop, treating each expression separately, calling eval(.) etc.
That may cost too much performnace, ... still to have it would be better than
not having the possibility.
If you read so far, you'd probably agree that such a function
could be a nice asset in R,
notably if it was possible to do this on the fast C level of R's main
REPL.
Have any of you looked into how this could be provided in R ?
If you know the source a little, you will remember that there's
the global variable R_Visible which is crucial here.
The problem with that is that it *is* global, and only available
as that; that the auto-printing "concept" is so linked to "toplevel context"
and that is not easy, and AFAIK not so much centralized in one place in the
source. Consequently, all kind of (very) low level functions manipulate
R_Visible
temporarily and so a C level implementation of withAutoprint() may
need considerable more changes than just setting R_Visible to TRUE in one
place.
Have any efforts / experiments already happened towards providing such
functionality ?
I don't think the performance cost would matter. If you're printing
something, you're already slow. So doing this at the R level would make
most sense to me --- that's how Sweave and source and knitr do it, so it
can't be that bad.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN packages maintained by you
Hi, I have the same problem and, at a first look, the issues reported by the CRAN checks seemed easy to fix. However, after checking it again locally and on http://win-builder.r-project.org it appeared that GCC 4.9.3 (Windows, Rtools 3.4), same also on win-builder reports even more issues, especially legacy Fortran (mainly Roger's #2 and #3), but also "warning: ISO C forbids conversion of object pointer to function pointer type" The latter results from using pointers returned by R_ExternalPtrAddr() for calling user-defined functions in DLLs, cf. the following thread from the very beginning: https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html What is now expected to do? 1. Is it really the intention to start a complete rewrite of all legacy Fortran code? 2. Is there now a better way for calling user functions than R_ExternalPtrAddr()? Many thanks for clarification, Thomas Am 28.08.2016 um 23:48 schrieb Roger Koenker: Hi Kurt, I have started to look into this, and I need some guidance about how to prioritize my repairs. There are basically 4 categories of warnings from gfortran’s pedantic critique of my packages: 1. Some errant tab characters it doesn’t like, 2. Too many or too few continue statements 3. Horrible (and obsolescent) arithmetic and computed gotos 4. undeclared doubles and dubious conversions The last category seems relatively easy to fix and is potentially important, but the others seem more difficult to fix and altogether less important. The goto issues are all in code that has been written long ago by others and imported, e.g. Peyton and Ng’s cholesky.f. I’m very reluctant to mess with any of those gotos. The fact that they were declared obsolete long ago doesn’t mean that gfortran has any intention of not supporting these constructs in the future, does it? Before devoting more time and energy, which is in short supply lately, I like to hear what others are thinking/doing about all this, so I’ll copy this to r-devel. All the best, Roger url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 On Aug 28, 2016, at 2:36 AM, Kurt Hornik wrote: Dear maintainers, This concerns the CRAN packages Using gfortran with options -Wall -pedantic to compile your package Fortran code finds important problems, see your package check pages for more information. Can you please fix these problems as quickly as possible? Best -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Thomas Petzoldt Technische Universitaet Dresden Faculty of Environmental Sciences Institute of Hydrobiology 01062 Dresden, Germany Tel.: +49 351 463 34954 Fax: +49 351 463 37108 E-Mail: thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt -- limnology and ecological modelling -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN packages maintained by you
On 2 September 2016 at 14:54, Thomas Petzoldt wrote: | Hi, | | I have the same problem and, at a first look, the issues reported by the | CRAN checks seemed easy to fix. However, after checking it again locally | and on http://win-builder.r-project.org it appeared that GCC 4.9.3 | (Windows, Rtools 3.4), same also on win-builder reports even more | issues, especially legacy Fortran (mainly Roger's #2 and #3), but also | | "warning: ISO C forbids conversion of object pointer to function pointer | type" | | The latter results from using pointers returned by R_ExternalPtrAddr() | for calling user-defined functions in DLLs, cf. the following thread | from the very beginning: | https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html | | What is now expected to do? | | 1. Is it really the intention to start a complete rewrite of all legacy | Fortran code? | | 2. Is there now a better way for calling user functions than | R_ExternalPtrAddr()? See this commit (where I apologize for referring to GitHub as the non-canonical source, but it presents things in pretty enough manner) by Brian Ripley just a few days ago: https://github.com/wch/r-source/commit/a528a69b98d3e763c39cfabf9b4a9e398651177c So R 3.4.0 will have R_MakeExternalPtrFn() and R_ExternalPtrAddrFn(). (Hat tip to Duncan's very useful NEWS summary robot-blog which I read daily). Dirk | Many thanks for clarification, | | Thomas | | | Am 28.08.2016 um 23:48 schrieb Roger Koenker: | > Hi Kurt, | > | > I have started to look into this, and I need some guidance about how to | > prioritize my repairs. There are basically 4 categories of warnings from | > gfortran’s pedantic critique of my packages: | > | > 1. Some errant tab characters it doesn’t like, | > 2. Too many or too few continue statements | > 3. Horrible (and obsolescent) arithmetic and computed gotos | > 4. undeclared doubles and dubious conversions | > | > The last category seems relatively easy to fix and is potentially | > important, but the others seem more difficult to fix and altogether | > less important. The goto issues are all in code that has been written | > long ago by others and imported, e.g. Peyton and Ng’s cholesky.f. | > I’m very reluctant to mess with any of those gotos. The fact that | > they were declared obsolete long ago doesn’t mean that gfortran | > has any intention of not supporting these constructs in the future, | > does it? | > | > Before devoting more time and energy, which is in short supply | > lately, I like to hear what others are thinking/doing about all this, | > so I’ll copy this to r-devel. | > | > All the best, | > Roger | > | > url:www.econ.uiuc.edu/~rogerRoger Koenker | > emailrkoen...@uiuc.eduDepartment of Economics | > vox: 217-333-4558University of Illinois | > fax: 217-244-6678Urbana, IL 61801 | > | > | >> On Aug 28, 2016, at 2:36 AM, Kurt Hornik wrote: | >> | >> | >> Dear maintainers, | >> | >> This concerns the CRAN packages | > | > | >> | >> Using gfortran with options -Wall -pedantic to compile your package | >> Fortran code finds important problems, see your package check pages for | >> more information. | >> | >> Can you please fix these problems as quickly as possible? | >> | >> Best | >> -k | > | > __ | > R-devel@r-project.org mailing list | > https://stat.ethz.ch/mailman/listinfo/r-devel | > | | | -- | Dr. Thomas Petzoldt | Technische Universitaet Dresden | Faculty of Environmental Sciences | Institute of Hydrobiology | 01062 Dresden, Germany | | Tel.: +49 351 463 34954 | Fax: +49 351 463 37108 | E-Mail: thomas.petzo...@tu-dresden.de | http://tu-dresden.de/Members/thomas.petzoldt | | -- limnology and ecological modelling -- | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] withAutoprint({ .... }) ?
On 02.09.2016 14:38, Duncan Murdoch wrote:
On 02/09/2016 7:56 AM, Martin Maechler wrote:
On R-help, with subject
'[R] source() does not include added code'
Joshua Ulrich
on Wed, 31 Aug 2016 10:35:01 -0500 writes:
> I have quantstrat installed and it works fine for me. If you're
> asking why the output of t(tradeStats('macross')) isn't being
printed,
> that's because of what's described in the first paragraph in the
> *Details* section of help("source"):
> Note that running code via ‘source’ differs in a few respects from
> entering it at the R command line. Since expressions are not
> executed at the top level, auto-printing is not done. So you will
> need to include explicit ‘print’ calls for things you want to be
> printed (and remember that this includes plotting by ‘lattice’,
> FAQ Q7.22).
> So you need:
> print(t(tradeStats('macross')))
> if you want the output printed to the console.
indeed, and "of course"" ;-)
As my subject indicates, this is another case, where it would be
very convenient to have a function
withAutoprint()
so the OP could have (hopefully) have used
withAutoprint(source(..))
though that would have been equivalent to the already nicely existing
source(.., print.eval = TRUE)
which works via the withVisible(.) utility that returns for each
'expression' if it would auto print or not, and then does print (or
not) accordingly.
My own use cases for such a withAutoprint({...})
are demos and examples, sometimes even package tests which I want to
print:
Assume I have a nice demo / example on a help page/ ...
foo(..)
(z <- bar(..))
summary(z)
where I carefully do print parts (and don't others),
and suddenly I find I want to run that part of the demo /
example / test only in some circumstances, e.g., only when
interactive, but not in BATCH, or only if it is me, the package
maintainer,
if( identical(Sys.getenv("USER"), "maechler") ) {
foo(..)
(z <- bar(..))
summary(z)
}
Now all the auto-printing is gone, and
1) I have to find out which of these function calls do autoprint and
wrap
a print(..) around these, and
2) the result is quite ugly (for an example on a help page etc.)
What I would like in a future R, is to be able to simply wrap the "{
.. } above with an 'withAutoprint(.) :
if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
foo(..)
(z <- bar(..))
summary(z)
})
Conceptually such a function could be written similar to source()
with an R
level for loop, treating each expression separately, calling eval(.)
etc.
That may cost too much performnace, ... still to have it would be
better than
not having the possibility.
If you read so far, you'd probably agree that such a function
could be a nice asset in R,
notably if it was possible to do this on the fast C level of R's main
REPL.
Have any of you looked into how this could be provided in R ?
If you know the source a little, you will remember that there's
the global variable R_Visible which is crucial here.
The problem with that is that it *is* global, and only available
as that; that the auto-printing "concept" is so linked to "toplevel
context"
and that is not easy, and AFAIK not so much centralized in one place
in the
source. Consequently, all kind of (very) low level functions
manipulate R_Visible
temporarily and so a C level implementation of withAutoprint() may
need considerable more changes than just setting R_Visible to TRUE in
one
place.
Have any efforts / experiments already happened towards providing such
functionality ?
I don't think the performance cost would matter. If you're printing
something, you're already slow. So doing this at the R level would
make most sense to me --- that's how Sweave and source and knitr do
it, so it can't be that bad.
Duncan Murdoch
A C-level implementation would bring the benefit of a lean traceback()
in case of an error. I suspect eval() could be enhanced to auto-print.
By the same token it would be extremely helpful to have a C-level
implementation of local() which wouldn't litter the stack trace.
-Kirill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN packages maintained by you
Am 02.09.2016 um 16:02 schrieb Dirk Eddelbuettel: On 2 September 2016 at 14:54, Thomas Petzoldt wrote: | Hi, | | I have the same problem and, at a first look, the issues reported by the | CRAN checks seemed easy to fix. However, after checking it again locally | and on http://win-builder.r-project.org it appeared that GCC 4.9.3 | (Windows, Rtools 3.4), same also on win-builder reports even more | issues, especially legacy Fortran (mainly Roger's #2 and #3), but also | | "warning: ISO C forbids conversion of object pointer to function pointer | type" | | The latter results from using pointers returned by R_ExternalPtrAddr() | for calling user-defined functions in DLLs, cf. the following thread | from the very beginning: | https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html | | What is now expected to do? | | 1. Is it really the intention to start a complete rewrite of all legacy | Fortran code? | | 2. Is there now a better way for calling user functions than | R_ExternalPtrAddr()? See this commit (where I apologize for referring to GitHub as the non-canonical source, but it presents things in pretty enough manner) by Brian Ripley just a few days ago: https://github.com/wch/r-source/commit/a528a69b98d3e763c39cfabf9b4a9e398651177c So R 3.4.0 will have R_MakeExternalPtrFn() and R_ExternalPtrAddrFn(). Thank you very much for this hint, sounds very promising! I was indeed looking for something like this in the R docs+sources, but didn't expect that it is that hot. Now I found it now also in the canonical svn sources ;) I am little bit concerned, how fast this should be forced by CRAN because of back-compatibility, and if compiler derivatives are worth the effort for this ... Remains issue #1 with "Obsolescent features" of legacy Fortran. While updating my Fedora test system, it seems that there are many other packages around that use this sort of old-style, and well tested (!!!) Fortran ... Thomas [...] | Am 28.08.2016 um 23:48 schrieb Roger Koenker: | > Hi Kurt, | > | > I have started to look into this, and I need some guidance about how to | > prioritize my repairs. There are basically 4 categories of warnings from | > gfortran’s pedantic critique of my packages: | > | > 1. Some errant tab characters it doesn’t like, | > 2. Too many or too few continue statements | > 3. Horrible (and obsolescent) arithmetic and computed gotos | > 4. undeclared doubles and dubious conversions | > | > The last category seems relatively easy to fix and is potentially | > important, but the others seem more difficult to fix and altogether | > less important. The goto issues are all in code that has been written | > long ago by others and imported, e.g. Peyton and Ng’s cholesky.f. | > I’m very reluctant to mess with any of those gotos. The fact that | > they were declared obsolete long ago doesn’t mean that gfortran | > has any intention of not supporting these constructs in the future, | > does it? | > | > Before devoting more time and energy, which is in short supply | > lately, I like to hear what others are thinking/doing about all this, | > so I’ll copy this to r-devel. | > | > All the best, | > Roger | > | > url:www.econ.uiuc.edu/~rogerRoger Koenker | > emailrkoen...@uiuc.eduDepartment of Economics | > vox: 217-333-4558University of Illinois | > fax: 217-244-6678Urbana, IL 61801 | > | > | >> On Aug 28, 2016, at 2:36 AM, Kurt Hornik wrote: | >> | >> | >> Dear maintainers, | >> | >> This concerns the CRAN packages | > | > | >> | >> Using gfortran with options -Wall -pedantic to compile your package | >> Fortran code finds important problems, see your package check pages for | >> more information. | >> | >> Can you please fix these problems as quickly as possible? | >> | >> Best | >> -k | > | > __ | > R-devel@r-project.org mailing list | > https://stat.ethz.ch/mailman/listinfo/r-devel | > -- Thomas Petzoldt thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] withAutoprint({ .... }) ?
Re withAutoprint(), Splus's source() function could take a expression
(literal or not) in place of a file name or text so it could support
withAutoprint-like functionality in its GUI. E.g.,
> source(auto.print=TRUE, exprs.literal= { x <- 3:7 ; sum(x) ; y <- log(x)
; x - 100}, prompt="--> ")
--> x <- 3:7
--> sum(x)
[1] 25
--> y <- log(x)
--> x - 100
[1] -97 -96 -95 -94 -93
or
> expr <- quote({ x <- 3:7 ; sum(x) ; y <- log(x) ; x - 100})
> source(auto.print=TRUE, exprs = expr, prompt="--> ")
--> x <- 3:7
--> sum(x)
[1] 25
--> y <- log(x)
--> x - 100
[1] -97 -96 -95 -94 -93
It was easy to implement, since exprs's default value is parse(file) or
parse(text=text), which source is calculating anyway.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Sep 2, 2016 at 4:56 AM, Martin Maechler
wrote:
> On R-help, with subject
>'[R] source() does not include added code'
>
> > Joshua Ulrich
> > on Wed, 31 Aug 2016 10:35:01 -0500 writes:
>
> > I have quantstrat installed and it works fine for me. If you're
> > asking why the output of t(tradeStats('macross')) isn't being
> printed,
> > that's because of what's described in the first paragraph in the
> > *Details* section of help("source"):
>
> > Note that running code via ‘source’ differs in a few respects from
> > entering it at the R command line. Since expressions are not
> > executed at the top level, auto-printing is not done. So you will
> > need to include explicit ‘print’ calls for things you want to be
> > printed (and remember that this includes plotting by ‘lattice’,
> > FAQ Q7.22).
>
>
>
> > So you need:
>
> > print(t(tradeStats('macross')))
>
> > if you want the output printed to the console.
>
> indeed, and "of course"" ;-)
>
> As my subject indicates, this is another case, where it would be
> very convenient to have a function
>
>withAutoprint()
>
> so the OP could have (hopefully) have used
>withAutoprint(source(..))
> though that would have been equivalent to the already nicely existing
>
>source(.., print.eval = TRUE)
>
> which works via the withVisible(.) utility that returns for each
> 'expression' if it would auto print or not, and then does print (or
> not) accordingly.
>
> My own use cases for such a withAutoprint({...})
> are demos and examples, sometimes even package tests which I want to print:
>
> Assume I have a nice demo / example on a help page/ ...
>
> foo(..)
> (z <- bar(..))
> summary(z)
>
>
> where I carefully do print parts (and don't others),
> and suddenly I find I want to run that part of the demo /
> example / test only in some circumstances, e.g., only when
> interactive, but not in BATCH, or only if it is me, the package maintainer,
>
> if( identical(Sys.getenv("USER"), "maechler") ) {
> foo(..)
> (z <- bar(..))
> summary(z)
>
> }
>
> Now all the auto-printing is gone, and
>
> 1) I have to find out which of these function calls do autoprint and wrap
>a print(..) around these, and
>
> 2) the result is quite ugly (for an example on a help page etc.)
>
> What I would like in a future R, is to be able to simply wrap the "{
> .. } above with an 'withAutoprint(.) :
>
> if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
> foo(..)
> (z <- bar(..))
> summary(z)
>
> })
>
> Conceptually such a function could be written similar to source() with an R
> level for loop, treating each expression separately, calling eval(.) etc.
> That may cost too much performnace, ... still to have it would be better
> than
> not having the possibility.
>
>
>
> If you read so far, you'd probably agree that such a function
> could be a nice asset in R,
> notably if it was possible to do this on the fast C level of R's main
> REPL.
>
> Have any of you looked into how this could be provided in R ?
> If you know the source a little, you will remember that there's
> the global variable R_Visible which is crucial here.
> The problem with that is that it *is* global, and only available
> as that; that the auto-printing "concept" is so linked to "toplevel
> context"
> and that is not easy, and AFAIK not so much centralized in one place in the
> source. Consequently, all kind of (very) low level functions manipulate
> R_Visible
> temporarily and so a C level implementation of withAutoprint() may
> need considerable more changes than just setting R_Visible to TRUE in one
> place.
>
> Have any efforts / experiments already happened towards providing such
> functionality ?
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Coercion of 'exclude' in function 'factor' (was 'droplevels' inappropriate change)
I am basically fine with the change.
How about using just the following?
if(!is.character(exclude))
exclude <- as.vector(exclude, typeof(x)) # may result in NA
x <- as.character(x)
It looks simpler and is, more or less, equivalent.
In factor.Rd, in description of argument 'exclude', "(when \code{x} is a
\code{factor} already)" can be removed.
A larger change that, I think, is reasonable is entirely removing the code
exclude <- as.vector(exclude, typeof(x)) # may result in NA
The explicit coercion of 'exclude' is not necessary. Function 'factor' works
without it.
The coercion of 'exclude' may leads to a surprise because it "may result in
NA". Example from https://stat.ethz.ch/pipermail/r-help/2005-April/069053.html :
factor(as.integer(c(1,2,3,3,NA)), exclude=NaN)
excludes NA.
As a bonus, without the coercion of 'exclude', 'exclude' can be a factor if 'x'
is a factor. This part of an example in
https://stat.ethz.ch/pipermail/r-help/2011-April/276274.html works.
cc <- c("x","y","NA")
ff <- factor(cc)
factor(ff,exclude=ff[3])
However, the coercion of 'exclude' has been in function 'factor' in R "forever".
On Wed, 31/8/16, Martin Maechler wrote:
Subject: Re: [Rd] 'droplevels' inappropriate change
Cc: "Martin Maechler"
Date: Wednesday, 31 August, 2016, 2:51 PM
> Martin Maechler
> on Sat, 27 Aug 2016 18:55:37 +0200 writes:
> Suharto Anggono Suharto Anggono via R-devel
> on Sat, 27 Aug 2016 03:17:32 + writes:
>> In R devel r71157, 'droplevels' documentation, in "Arguments" section,
says this about argument 'exclude'.
>> passed to factor(); factor levels which should be excluded from the
result even if present. Note that this was implicitly NA in R <= 3.3.1 which
did drop NA levels even when present in x, contrary to the documentation. The
current default is compatible with x[ , drop=FALSE].
>> The part
>> x[ , drop=FALSE]
>> should be
>> x[ , drop=TRUE]
[[elided Yahoo spam]]
> a "typo" by me. .. fixed now.
>> Saying that 'exclude' is factor levels is not quite true for NA element.
NA may be not an original level, but NA in 'exclude' affects the result.
>> For a factor 'x', factor(x, exclude = exclude) doesn't really work for
excluding in general. See, for example,
https://stat.ethz.ch/pipermail/r-help/2005-September/079336.html .
>> factor(factor(c("a","b","c")), exclude="c")
>> However, this excludes "2":
>> factor(factor(2:3), exclude=2)
>> Rather unexpectedly, this excludes NA:
>> factor(factor(c("a",NA), exclude=NULL), exclude="c")
>> For a factor 'x', factor(x, exclude = exclude) can only exclude
integer-like or NA levels. An explanation is in
https://stat.ethz.ch/pipermail/r-help/2011-April/276274.html .
> Well, Peter Dalgaard (in that R-devel e-mail, a bit more than 5
> years ago) is confirming the problem there, and suggesting (as
> you, right?) that actually `factor()` is not behaving
> correctly here.
> And your persistence is finally getting close to convince me
> that it is not just droplevels(), but factor() itself which
> needs care here.
> Interestingly, the following patch *does* pass 'make check-all'
> (after small change in tests/reg-tests-1b.R which is ok),
> and leads to behavior which is much closer to the documentation,
> notably for your two examples above would give what one would
> expect.
> (( If the R-Hub would support experiments with branches of R-devel
> from R-core members, I could just create such a branch and R Hub
> would run 'R CMD check ' for thousands of CRAN packages
> and provide a web page with the *differences* in the package
> check results ... so we could see ... ))
> I do agree that we should strongly consider such a change.
as nobody has commented, I've been liberal and have taken these
no comments as consent.
Hence I have committed
r71178 | maechler | 2016-08-31 09:45:40 +0200 (Wed, 31 Aug 2016) | 1 line
Changed paths:
M /trunk/doc/NEWS.Rd
M /trunk/src/library/base/R/factor.R
M /trunk/src/library/base/man/factor.Rd
M /trunk/tests/reg-tests-1b.R
M /trunk/tests/reg-tests-1c.R
factor(x, exclude) more "rational" when x or exclude are character
which apart from documentation, examples, and regression tests
is just the patch below.
Martin Maechler
ETH Zurich
> --- factor.R(revision 71157)
> +++ factor.R(working copy)
> @@ -28,8 +28,12 @@
> levels <- unique(y[ind])
> }
> force(ordered) # check if original x is an ordered factor
> -exclude <- as.vector(exclude, typeof(x)) # may result in NA
> -x <- as.character(x)
> +if(!is.character(x)) {
> +if(!is.character(exclude))
Re: [Rd] withAutoprint({ .... }) ?
On Fri, 2 Sep 2016, Kirill Müller wrote:
On 02.09.2016 14:38, Duncan Murdoch wrote:
On 02/09/2016 7:56 AM, Martin Maechler wrote:
On R-help, with subject
'[R] source() does not include added code'
Joshua Ulrich
on Wed, 31 Aug 2016 10:35:01 -0500 writes:
> I have quantstrat installed and it works fine for me. If you're
> asking why the output of t(tradeStats('macross')) isn't being
printed,
> that's because of what's described in the first paragraph in the
> *Details* section of help("source"):
> Note that running code via ‘source’ differs in a few respects from
> entering it at the R command line. Since expressions are not
> executed at the top level, auto-printing is not done. So you will
> need to include explicit ‘print’ calls for things you want to be
> printed (and remember that this includes plotting by ‘lattice’,
> FAQ Q7.22).
> So you need:
> print(t(tradeStats('macross')))
> if you want the output printed to the console.
indeed, and "of course"" ;-)
As my subject indicates, this is another case, where it would be
very convenient to have a function
withAutoprint()
so the OP could have (hopefully) have used
withAutoprint(source(..))
though that would have been equivalent to the already nicely existing
source(.., print.eval = TRUE)
which works via the withVisible(.) utility that returns for each
'expression' if it would auto print or not, and then does print (or
not) accordingly.
My own use cases for such a withAutoprint({...})
are demos and examples, sometimes even package tests which I want to
print:
Assume I have a nice demo / example on a help page/ ...
foo(..)
(z <- bar(..))
summary(z)
where I carefully do print parts (and don't others),
and suddenly I find I want to run that part of the demo /
example / test only in some circumstances, e.g., only when
interactive, but not in BATCH, or only if it is me, the package
maintainer,
if( identical(Sys.getenv("USER"), "maechler") ) {
foo(..)
(z <- bar(..))
summary(z)
}
Now all the auto-printing is gone, and
1) I have to find out which of these function calls do autoprint and
wrap
a print(..) around these, and
2) the result is quite ugly (for an example on a help page etc.)
What I would like in a future R, is to be able to simply wrap the "{
.. } above with an 'withAutoprint(.) :
if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
foo(..)
(z <- bar(..))
summary(z)
})
Conceptually such a function could be written similar to source()
with an R
level for loop, treating each expression separately, calling eval(.)
etc.
That may cost too much performnace, ... still to have it would be
better than
not having the possibility.
If you read so far, you'd probably agree that such a function
could be a nice asset in R,
notably if it was possible to do this on the fast C level of R's main
REPL.
Have any of you looked into how this could be provided in R ?
If you know the source a little, you will remember that there's
the global variable R_Visible which is crucial here.
The problem with that is that it *is* global, and only available
as that; that the auto-printing "concept" is so linked to "toplevel
context"
and that is not easy, and AFAIK not so much centralized in one place
in the
source. Consequently, all kind of (very) low level functions
manipulate R_Visible
temporarily and so a C level implementation of withAutoprint() may
need considerable more changes than just setting R_Visible to TRUE in
one
place.
Have any efforts / experiments already happened towards providing such
functionality ?
I don't think the performance cost would matter. If you're printing
something, you're already slow. So doing this at the R level would
make most sense to me --- that's how Sweave and source and knitr do
it, so it can't be that bad.
Duncan Murdoch
A C-level implementation would bring the benefit of a lean traceback()
in case of an error. I suspect eval() could be enhanced to auto-print.
By the same token it would be extremely helpful to have a C-level
implementation of local() which wouldn't litter the stack trace.
local() within a byte compiled function already produces a less
cluttered traceback, though perhaps not ideal. Moving the interpreted
version closer to the compiled one is in the works.
Best,
luke
-Kirill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
[Rd] WISH: Export utils:::findMatches()
WISH:
I'd like make a plea for utils:::findMatches() to be exported such
that anyone can do:
.DollarNames.MyClass <- function(x, pattern="") {
utils:::findMatches(pattern, names(x))
}
The utils:::findMatches() is agile to the "fuzzy" options, cf.
.DollarNames. It also doesn't erase what's been typed if there is not
match (see below).
ALTERNATIVE:
I'm aware of that utils:::.DollarNames.default almost do the same
thing, but, unfortunately, that does not work for all data type, e.g.
environment-based objects. An alternative to utils:::findMatches() is
to use:
.DollarNames.MyClass <- function(x, pattern="") {
grep(pattern, names(x), value=TRUE)
}
but that has the additional downside to return an empty string "" if
there's no match, which in turn erases whatever the user typed before
hitting TAB.
Thanks
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
