Re: [Rd] Redundant code in 'split.default' in R devel
> Suharto Anggono via R-devel
> on Fri, 5 Oct 2018 17:13:30 + writes:
> After r75387, function 'split.default' in R devel still has this part that no
> longer has effect.
> lf <- levels(f)
> y <- vector("list", length(lf))
> names(y) <- lf
Indeed --> removed now.
Thank you very much, Suharto!
Martin
---
"Exercise" (tongue in cheek) to the reader:
Write a "code walker" (an R function itself) that takes an
argument 'expr', which is an R expression (think of a *body* of a
function 'f') and is able to mark e.g. warn about such
"dead" code in 'expr' (and hence in function 'f' ...) --- with
the important underlying assumption that all functions that are
called inside 'f' have "no side effects".
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
Hello,
I agree the documentation of args can be improved, but the main question is
what the return should be.
I guess the reason args() returns NULL is because of the way argument-matching
works for primitives: there is a lot going on under the hood, and what
arguments are/are not acceptable for `[` can't be stated as straightforward as
we can with other functions.
Note also the difference in printing "sum" and "[": sum first prints
"function(..., na.rm=FALSE)", whereas `[` jumps straight to the body. And this
is not an artefact of printing it, as makes overwriting it makes clear:
`[` <- function(x, i, j, ..., drop=FALSE) .Primitive("[")
exhibited very strange behaviour, where you need to call it twice/nested: 1[2]
returns a primitive function, to get it to do its job you need 1[2](df, 3, 4)
instead of df[3,4].
So general advice would probably be to stay away from messing with arguments
with primitives, as ?args already hints at: " mainly used interactively (...).
For programming, consider using formals instead."
Basically, primitives are optimized and down to the core, which probably means
the concept of an argument-list may not be as clear as it is with "normal"
functions.
So working with args() on primitives comes with some risks, which probably is
the reason that formals() always return NULL in that case.
What is your use case?
If you really need a return value, I think you could catch NULL-values,
something like this:
args <- function(name) {
if(is.character(name)) name <- get(name, parent.frame(), mode='function')
if(!is.function(name)) return(NULL)
ret <- base::args(name)
if(is.null(ret) && is.primitive(name)) {
ret <- function(...) NULL
environment(ret) <- parent.frame()
}
return(ret)
}
Which would just return "function(...) NULL" for args("["), which is of the
expected class, but does not give you any real information. Would that help you?
Otherwise, to get to know the arguments there is of course "?"
And note that if there is a dispatch, it's possible to get the argument-list of
a specific method, e.g. args(`[.data.frame`) works as expected (as it is not a
primitive)
Best regards,
Emil Bode
On 07/10/2018, 16:34, "R-devel on behalf of Rui Barradas"
wrote:
Hello,
This is because args(`[`) returns NULL and class(NULL) is NULL.
So the question would be why is the return value of args(`[`) NULL?
Rui Barradas
Às 15:14 de 07/10/2018, Peter Dalgaard escreveu:
>
>
>> On 7 Oct 2018, at 16:04 , Rui Barradas wrote:
>>
>> Hello,
>>
>> I don't see why you say that the documentation seems to be wrong:
>>
>>
>> class(args(`+`))
>> #[1] "function"
>>
>>
>> args() on a primitive does return a closure. At least in this case it
does.
>
> But in this case it doesn't:
>
>> is.primitive(get("["))
> [1] TRUE
>> class(args(get("[")))
> [1] "NULL"
>
> Or, for that matter:
>
>> is.primitive(`[`)
> [1] TRUE
>> class(args(`[`))
> [1] "NULL"
>
> -pd
>
>>
>>
>> Rui Barradas
>>
>> Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
>>> There is more "fun" afoot here, but I don't recall what the point may
be:
args(get("+"))
>>> function (e1, e2)
>>> NULL
args(get("["))
>>> NULL
get("[")
>>> .Primitive("[")
get("+")
>>> function (e1, e2) .Primitive("+")
>>> The other index operators, "[[", "[<-", "[[<-" are similar
>>> The docs are pretty clear that args() on a primitive should yield a
closure, so at least the documentation seems to be wrong.
>>> -pd
On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
Hi,
A short code example showing the warning might the only thing needed
here:
```
> formals(args(`[`))
NULL
*Warning message:In formals(fun) : argument is not a function*
> is.function(`[`)
[1] TRUE
> is.primitive(`[`)
[1] TRUE
```
Now with an other primitive:
```
> formals(args(`sum`))
$...
$na.rm
[1] FALSE
> is.function(`sum`)
[1] TRUE
> is.primitive(`sum`)
[1] TRUE
> class(`[`)
[1] "function"
```
Is this a feature ?
Laurent
[[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
__
R-devel@r-project.org mailing list
https:
Re: [Rd] Rscript -e does not accept newlines under Linux?
I've checked in an experimental fix for this (75413). The newline was lost in the shell script wrapper for R, it is now being escaped similarly to space. To pass multiple commands to Rscript, one can also use "-e" multiple times. Tomas On 09/17/2018 01:09 PM, Duncan Murdoch wrote: On 16/09/2018 4:53 AM, Voeten, C.C. wrote: Hello, I have found what I believe to be a bug in the Linux version of the Rscript binary. Under Windows (official 64-bit 3.5.1 R distribution running on an up-to-date Win10), I can do the following (e.g. under powershell): PS H:\Users\Cesko> Rscript -e 'ls() ls()' character(0) character(0) which works as I expect: I am running Rscript with two arguments, namely (1) '-e', and (2) two lines of code to be run, and it indeed executes those two lines of code. This fails when attempted on a Linux build (amd64, compiled from the official 3.5.1 sources, but also reproducible with today's r-devel snapshot): $ Rscript -e 'ls() ls()' ARGUMENT 'ls()' __ignored__ character(0) This behavior is not what I expected. Have I found a bug, or am I simply using it wrong? I would not assume that shell behaviour in Windows and Unix would always be the same. A better comparison would be to list some other command on the same system that behaves differently. For example, on MacOS I see $ echo 'ls() > ls()' ls() ls() which suggests that what you wrote should be legal, but the form of that command is different: there's no equivalent of "-e". Maybe someone else who knows Unix shell behaviour better can comment on whether they'd expect your Rscript command to work. By the way, if you just want multiple commands to execute, you can separate them by semi-colons, and that does work: $ Rscript -e 'ls(); ls()' character(0) character(0) And I see this, which may explain the original problem: $ Rscript -e 'commandArgs(); ls()' [1] "/Library/Frameworks/R.framework/Resources/bin/exec/R" [2] "--slave" [3] "--no-restore" [4] "-e" [5] "commandArgs();~+~ls()" character(0) Notice that argument 5 includes both commands, whereas with the newline they are separated: $ Rscript -e 'commandArgs() > ls()' ARGUMENT 'ls()' __ignored__ [1] "/Library/Frameworks/R.framework/Resources/bin/exec/R" [2] "--slave" [3] "--no-restore" [4] "-e" [5] "commandArgs()" [6] "ls()" And finally, this also works: Rscript -e 'ls() -e ls()' 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] bug with OutDec option and deferred_string altrep object
Thanks for the report. The approach you outlines below should work -- I'll look into it. Best, luke On Mon, 8 Oct 2018, Michael Sannella wrote: > While implementing R's new 'altrep' functionality in the TERR engine, > I discovered a bug in R's 'deferred_string' altrep object: it is not > using the correct value of the 'OutDec' option when it expands a > deferred_string. See the following example: > > R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > > options(scipen=0, OutDec=".") > > as.character(123.456) > [1] "123.456" > > options(scipen=-5, OutDec=",") > > as.character(123.456) > [1] "1,23456e+02" > > xx <- as.character(123.456) > > options(scipen=0, OutDec=".") > > xx > [1] "1.23456e+02" > > > > In the example above, the variable 'xx' is set to a deferred_string > while OutDec is ','. However, when the string is actually formatted > (when xx is printed), it uses the current option value OutDec='.' to > format the string. I think that deferred_string should use the value > OutDec=',' from when as.character was called. > > Note that the behavior is different with the 'scipen' option: The > deferred_string object records the scipen=-5 value when as.character > is called, and uses this value when xx is printed. Looking at the > deferred_string object, it appears that CDR(R_altrep_data1()) is > set to a scalar integer containing the scipen value at the time the > deferred_string was created. > > Ideally, the deferred_string object would save both the scipen and > OutDec option values. I'd suggest saving these values as regular > pairlist values, say by setting the data1 field to pairlist(, > scipen=-5L, OutDec=',') for the value of xx above. To save space, you > could avoid saving these values in the common case where scipen=0L, > OutDec='.'. It would also be better if the data1 field was a > well-formed pairlist; the current value of the data1 field causes > R_inspect to segfault. > > I understand that you probably wouldn't want to change the > deferred_string structure. An alternative fix would be to avoid this > case by: > 1. Never create a deferred_string if OutDec is not '.'. > 2. When expanding an element of a deferred_string, temporarily set > OutDec to '.'. > > ~~ Michael Sannella > > > -- 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 https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug with OutDec option and deferred_string altrep object
While implementing R's new 'altrep' functionality in the TERR engine, I discovered a bug in R's 'deferred_string' altrep object: it is not using the correct value of the 'OutDec' option when it expands a deferred_string. See the following example: R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > options(scipen=0, OutDec=".") > as.character(123.456) [1] "123.456" > options(scipen=-5, OutDec=",") > as.character(123.456) [1] "1,23456e+02" > xx <- as.character(123.456) > options(scipen=0, OutDec=".") > xx [1] "1.23456e+02" > In the example above, the variable 'xx' is set to a deferred_string while OutDec is ','. However, when the string is actually formatted (when xx is printed), it uses the current option value OutDec='.' to format the string. I think that deferred_string should use the value OutDec=',' from when as.character was called. Note that the behavior is different with the 'scipen' option: The deferred_string object records the scipen=-5 value when as.character is called, and uses this value when xx is printed. Looking at the deferred_string object, it appears that CDR(R_altrep_data1()) is set to a scalar integer containing the scipen value at the time the deferred_string was created. Ideally, the deferred_string object would save both the scipen and OutDec option values. I'd suggest saving these values as regular pairlist values, say by setting the data1 field to pairlist(, scipen=-5L, OutDec=',') for the value of xx above. To save space, you could avoid saving these values in the common case where scipen=0L, OutDec='.'. It would also be better if the data1 field was a well-formed pairlist; the current value of the data1 field causes R_inspect to segfault. I understand that you probably wouldn't want to change the deferred_string structure. An alternative fix would be to avoid this case by: 1. Never create a deferred_string if OutDec is not '.'. 2. When expanding an element of a deferred_string, temporarily set OutDec to '.'. ~~ Michael Sannella [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R_ext/Altrep.h should be more C++-friendly
I am not able to #include "R_ext/Altrep.h" from a C++ file. I think
it needs two changes:
1. add the same __cplusplus check as most of the other header files:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
2. change the line
R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
to
R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
since C++ doesn't like an argument named 'class'
~~ Michael Sannella
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
