Re: [Rd] head.matrix can return 1000s of columns -- limit to n or add new argument?
Finally read in detail your response Gabe. Looks great, and I agree it's
quite intuitive, as well as agree against non-recycling.
Once the length(n) == length(dim(x)) behavior is enabled, I don't think
there's any need/desire to have head() do x[1:6,1:6] anymore. head(x, c(6,
6)) is quite clear for those familiar with head(x, 6), it would seem to me.
Mike C
On Sat, Jul 13, 2019 at 8:35 AM Gabriel Becker
wrote:
> Hi Michael and Abby,
>
> So one thing that could happen that would be backwards compatible (with
> the exception of something that was an error no longer being an error) is
> head and tail could take vectors of length (dim(x)) rather than integers of
> length for n, with the default being n=6 being equivalent to n = c(6,
> dim(x)[2], <...>, dim(x)[k]), at least for the deprecation cycle, if not
> permanently. It not recycling would be unexpected based on the behavior of
> many R functions but would preserve the current behavior while granting
> more fine-grained control to users that feel they need it.
>
> A rapidly thrown-together prototype of such a method for the head of a
> matrix case is as follows:
>
> head2 = function(x, n = 6L, ...) {
> indvecs = lapply(seq_along(dim(x)), function(i) {
> if(length(n) >= i) {
> ni = n[i]
> } else {
> ni = dim(x)[i]
> }
> if(ni < 0L)
> ni = max(nrow(x) + ni, 0L)
> else
> ni = min(ni, dim(x)[i])
> seq_len(ni)
> })
> lstargs = c(list(x),indvecs, drop = FALSE)
> do.call("[", lstargs)
> }
>
>
> > mat = matrix(1:100, 10, 10)
>
> > *head(mat)*
>
> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>
> [1,]1 11 21 31 41 51 61 71 8191
>
> [2,]2 12 22 32 42 52 62 72 8292
>
> [3,]3 13 23 33 43 53 63 73 8393
>
> [4,]4 14 24 34 44 54 64 74 8494
>
> [5,]5 15 25 35 45 55 65 75 8595
>
> [6,]6 16 26 36 46 56 66 76 8696
>
> > *head2(mat)*
>
> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>
> [1,]1 11 21 31 41 51 61 71 8191
>
> [2,]2 12 22 32 42 52 62 72 8292
>
> [3,]3 13 23 33 43 53 63 73 8393
>
> [4,]4 14 24 34 44 54 64 74 8494
>
> [5,]5 15 25 35 45 55 65 75 8595
>
> [6,]6 16 26 36 46 56 66 76 8696
>
> > *head2(mat, c(2, 3))*
>
> [,1] [,2] [,3]
>
> [1,]1 11 21
>
> [2,]2 12 22
>
> > *head2(mat, c(2, -9))*
>
> [,1]
>
> [1,]1
>
> [2,]2
>
>
> Now one thing to keep in mind here, is that I think we'd either a) have
> to make the non-recycling behavior permanent, or b) have head treat
> data.frames and matrices different with respect to the subsets they grab
> (which strikes me as a *Bad Plan *(tm)).
>
> So I don't think the default behavior would ever be mat[1:6, 1:6], not
> because of backwards compatibility, but because at least in my intuition
> that is just not what head on a data.frame should do by default, and I
> think the behaviors for the basic rectangular datatypes should "stick
> together". I mean, also because of backwards compatibility, but that could
> *in
> theory* change across a long enough deprecation cycle, but the
> conceptually right thing to do with a data.frame probably won't.
>
> All of that said, is head(mat, c(6, 6)) really that much easier to
> type/better than just mat[1:6, 1:6, drop=FALSE] (I know this will behave
> differently if any of the dims of mat are less than 6, but if so why are
> you heading it in the first place ;) )? I don't really have a strong
> feeling on the answer to that.
>
> I'm happy to put a patch for head.matrix, head.data.frame, tail.matrix and
> tail.data.frame, plus documentation, if people on R-core are interested in
> this.
>
> Note, as most here probably know, and as alluded to above, length(n) > 1
> for head or tail currently give an error, so this would be an extension
> of the existing functionality in the mathematical extension sense, where
> all existing behavior would remain identical, but the support/valid
> parameter space would grow.
>
> Best,
> ~G
>
>
> On Fri, Jul 12, 2019 at 4:03 PM Abby Spurdle wrote:
>
>> > I assume there are lots of backwards-compatibility issues as well as
>> valid
>> > use cases for this behavior, so I guess defaulting to M[1:6, 1:6] is out
>> of
>> > the question.
>>
>> Agree.
>>
>> > Is there any scope for adding a new argument to head.matrix that would
>> > allow this flexibility?
>>
>> I agree with what you're trying to achieve.
>> However, I'm not sure this is as simple as you're suggesting.
>>
>> What if the user wants "head" in rows but "tail" in columns.
>> Or "head" in rows, and both "head" and "tail" in columns.
>> With head and tail alone, there's a combinatorial explosion.
>>
>> Also, when using tail on an unnamed matrix,
[Rd] REprintf could be caught by tryCatch(message)
Dear R-devel community,
There appears to be an inconsistency in R C API about the exceptions
that can be raised from C code.
Mapping of R C funs to corresponding R functions is as follows.
error-> stop
warning -> warning
REprintf -> message
Rprintf -> cat
Rprint/cat is of course not an exception, I listed it just for completeness.
The inconsistency I would like to report is about REprintf. It cannot
be caught by tryCatch(message). Warnings are errors are being caught
as expected.
Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
can catch it?
So in the example below catch(Cmessage()) would behave consistently to
R's catch(message("a"))?
Regards,
Jan Gorecki
catch = function(expr) {
tryCatch(expr,
message=function(m) cat("caught message\n"),
warning=function(w) cat("caught warning\n"),
error=function(e) cat("caught error\n")
)
}
library(inline)
Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
catch(stop("a"))
#caught error
catch(warning("a"))
#caught warning
catch(message("a"))
#caught message
catch(Cstop())
#caught error
catch(Cwarning())
#caught warning
catch(Cmessage())
#a
#NULL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] REprintf could be caught by tryCatch(message)
On Sun, 15 Sep 2019, Jan Gorecki wrote:
> Dear R-devel community,
>
> There appears to be an inconsistency in R C API about the exceptions
> that can be raised from C code.
> Mapping of R C funs to corresponding R functions is as follows.
>
> error-> stop
> warning -> warning
> REprintf -> message
This is wrong: REpintf is like cat with file = stderr(). If this claim
is made somewhere in R documentation please report it a a bug.
> Rprintf -> cat
>
> Rprint/cat is of course not an exception, I listed it just for completeness.
> The inconsistency I would like to report is about REprintf. It cannot
> be caught by tryCatch(message). Warnings are errors are being caught
> as expected.
>
> Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
> can catch it?
No: this is behaving as intended.
Best,
luke
> So in the example below catch(Cmessage()) would behave consistently to
> R's catch(message("a"))?
>
> Regards,
> Jan Gorecki
>
> catch = function(expr) {
> tryCatch(expr,
>message=function(m) cat("caught message\n"),
>warning=function(w) cat("caught warning\n"),
>error=function(e) cat("caught error\n")
> )
> }
> library(inline)
> Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
> Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
> Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
>
> catch(stop("a"))
> #caught error
> catch(warning("a"))
> #caught warning
> catch(message("a"))
> #caught message
>
> catch(Cstop())
> #caught error
> catch(Cwarning())
> #caught warning
> catch(Cmessage())
> #a
> #NULL
>
> __
> 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
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] REprintf could be caught by tryCatch(message)
Thank you Luke for prompt reply.
Is it possible then to request a new function to R C API "message"
that would equivalent to R "message" function? Similarly as we now
have C "warning" and C "error" functions.
Best,
Jan
On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke wrote:
>
> On Sun, 15 Sep 2019, Jan Gorecki wrote:
>
> > Dear R-devel community,
> >
> > There appears to be an inconsistency in R C API about the exceptions
> > that can be raised from C code.
> > Mapping of R C funs to corresponding R functions is as follows.
> >
> > error-> stop
> > warning -> warning
> > REprintf -> message
>
> This is wrong: REpintf is like cat with file = stderr(). If this claim
> is made somewhere in R documentation please report it a a bug.
>
> > Rprintf -> cat
> >
> > Rprint/cat is of course not an exception, I listed it just for completeness.
> > The inconsistency I would like to report is about REprintf. It cannot
> > be caught by tryCatch(message). Warnings are errors are being caught
> > as expected.
> >
> > Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
> > can catch it?
>
> No: this is behaving as intended.
>
> Best,
>
> luke
>
> > So in the example below catch(Cmessage()) would behave consistently to
> > R's catch(message("a"))?
> >
> > Regards,
> > Jan Gorecki
> >
> > catch = function(expr) {
> > tryCatch(expr,
> >message=function(m) cat("caught message\n"),
> >warning=function(w) cat("caught warning\n"),
> >error=function(e) cat("caught error\n")
> > )
> > }
> > library(inline)
> > Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
> > Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
> > Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
> >
> > catch(stop("a"))
> > #caught error
> > catch(warning("a"))
> > #caught warning
> > catch(message("a"))
> > #caught message
> >
> > catch(Cstop())
> > #caught error
> > catch(Cwarning())
> > #caught warning
> > catch(Cmessage())
> > #a
> > #NULL
> >
> > __
> > 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
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: package or namespace load failed for ‘utils
In case a search engine leads someone with the same issue here, I am
documenting the point I reached:
I can reproduce the issue with a small example when forcing R to not load
any package at startup time (using an Renviron file):
```
package <- "utils"
lib.loc <- ""
ns <- loadNamespace(package, lib.loc)
```
The code path goes through `registerS3methods(nsInfo$S3methods, package,
env)` and there to:
```
if (methods::is(genfun, "genericFunction"))
```
The evaluation of `methods::is` reaches the line triggering the error as
`.identC(class1, class2)` and `.identC(class2, "ANY")` both return `NA` and
`NA || NA` is not defined:
```
> if (NA || NA) { cat("here\n") }
Error in if (NA || NA) { : missing value where TRUE/FALSE needed
```
As I understand it `.identC()` should never return `NA`, and if the case
this would mean that R itself is an unstable state (something at the C
level that should not have happened has happened) but this was not caught
earlier.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] REprintf could be caught by tryCatch(message)
You can file it as a wishlist item in the bug trackign system. Without
a compelling case or a complete and well tested patch or both I doubt
it will rise to the top of anyone's priority list.
Best,
luke
On Sun, 15 Sep 2019, Jan Gorecki wrote:
> Thank you Luke for prompt reply.
> Is it possible then to request a new function to R C API "message"
> that would equivalent to R "message" function? Similarly as we now
> have C "warning" and C "error" functions.
>
> Best,
> Jan
>
> On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke wrote:
>>
>> On Sun, 15 Sep 2019, Jan Gorecki wrote:
>>
>>> Dear R-devel community,
>>>
>>> There appears to be an inconsistency in R C API about the exceptions
>>> that can be raised from C code.
>>> Mapping of R C funs to corresponding R functions is as follows.
>>>
>>> error-> stop
>>> warning -> warning
>>> REprintf -> message
>>
>> This is wrong: REpintf is like cat with file = stderr(). If this claim
>> is made somewhere in R documentation please report it a a bug.
>>
>>> Rprintf -> cat
>>>
>>> Rprint/cat is of course not an exception, I listed it just for completeness.
>>> The inconsistency I would like to report is about REprintf. It cannot
>>> be caught by tryCatch(message). Warnings are errors are being caught
>>> as expected.
>>>
>>> Is there any chance to "fix"/"improve" REprintf so tryCatch(message)
>>> can catch it?
>>
>> No: this is behaving as intended.
>>
>> Best,
>>
>> luke
>>
>>> So in the example below catch(Cmessage()) would behave consistently to
>>> R's catch(message("a"))?
>>>
>>> Regards,
>>> Jan Gorecki
>>>
>>> catch = function(expr) {
>>> tryCatch(expr,
>>>message=function(m) cat("caught message\n"),
>>>warning=function(w) cat("caught warning\n"),
>>>error=function(e) cat("caught error\n")
>>> )
>>> }
>>> library(inline)
>>> Cstop = cfunction(c(), 'error("%s\\n","a"); return R_NilValue;')
>>> Cwarning = cfunction(c(), 'warning("%s\\n","a"); return R_NilValue;')
>>> Cmessage = cfunction(c(), 'REprintf("%s\\n","a"); return R_NilValue;')
>>>
>>> catch(stop("a"))
>>> #caught error
>>> catch(warning("a"))
>>> #caught warning
>>> catch(message("a"))
>>> #caught message
>>>
>>> catch(Cstop())
>>> #caught error
>>> catch(Cwarning())
>>> #caught warning
>>> catch(Cmessage())
>>> #a
>>> #NULL
>>>
>>> __
>>> 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
>
--
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
Re: [Rd] Error: package or namespace load failed for‘utils
> Laurent Gautier writes:
> In case a search engine leads someone with the same issue here, I am
> documenting the point I reached:
> I can reproduce the issue with a small example when forcing R to not load
> any package at startup time (using an Renviron file):
> ```
> package <- "utils"
> lib.loc <- ""
> ns <- loadNamespace(package, lib.loc)
> ```
I cannot reproduce this using current R-devel or R-patched. After
starting with R_DEFAULT_PACKAGES=NULL,
R> search()
[1] ".GlobalEnv" "Autoloads""package:base"
R> loadedNamespaces()
[1] "compiler" "tools""base"
R> package <- "utils"
R> lib.loc <- file.path(R.home(), "library")
R> ns <- loadNamespace(package, lib.loc)
R> loadedNamespaces()
[1] "compiler" "tools""utils""base"
-k
> The code path goes through `registerS3methods(nsInfo$S3methods, package,
> env)` and there to:
> ```
> if (methods::is(genfun, "genericFunction"))
> ```
> The evaluation of `methods::is` reaches the line triggering the error as
> `.identC(class1, class2)` and `.identC(class2, "ANY")` both return `NA` and
> `NA || NA` is not defined:
> ```
>> if (NA || NA) { cat("here\n") }
> Error in if (NA || NA) { : missing value where TRUE/FALSE needed
> ```
> As I understand it `.identC()` should never return `NA`, and if the case
> this would mean that R itself is an unstable state (something at the C
> level that should not have happened has happened) but this was not caught
> earlier.
> [[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
