[Bioc-devel] svn and git-mirror not synced

[Leif Väremo]

Hi,

It seems like the svn/Bioconductor version and the git-mirrors are out of sync, 
for the piano package.

Bioconductor and svn show 1.15.2: 
http://bioconductor.org/packages/devel/bioc/html/piano.html
Git-mirror, DESCRIPTION shows version 1.15.1: 
https://github.com/Bioconductor-mirror/piano/blob/master/DESCRIPTION

Any idea why this change does not show up in git?

(it has been like this for at least 10 days)

All the best

Leif Väremo

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

[Gabriel Becker]

Well, that's embarrassing. Sorry for the noise on that front, everyone. I
misunderstood something from the aforementioned unrelated conversation I
was having, but not double checking is on me (I rarely use if else and when
I do I avoid that situation in my own code, which is why I didn't already
know this)


I'd still argue that situation should at least warn, possibly error, as it
seems indicative of a bug in the user's code.

On Mon, Nov 28, 2016 at 7:00 AM, Martin Maechler  wrote:

> > Suharto Anggono Suharto Anggono via R-devel 
> > on Sat, 26 Nov 2016 17:14:01 + writes:
>
> > Just stating, in 'ifelse', 'test' is not recycled. As I said in
> "R-intro: length of 'ifelse' result" (https://stat.ethz.ch/
> pipermail/r-devel/2016-September/073136.html), ifelse(condition, a, b)
> returns a vector of the length of 'condition', even if 'a' or 'b' is longer.
>
> yes and  ?ifelse (the help page) also does not say that test is
> recycled, rather
>
>>>  If \code{yes} or \code{no} are too short, their elements are
> recycled.
>
> (*and* the problem you wrote the above has been corrected in the
>  R-intro manual shortly after).
>
>
> > On current 'ifelse' code in R:
>
> > * The part
> > ans[nas] <- NA
> > could be omitted because NA's are already in place.
> > If the part is removed, variable 'nas' is no longer used.
>
> I agree that this seems logical.  If I apply the change, R's own
> full checks do not seem affected, and I may try to commit that
> change and "wait and see".
>
>
> > * The any(*) part actually checks the thing that is used as the
> index vector. The index vector could be stored and then repeatedly used,
> like the following.
>
> > if (any(sel <- test & ok))
> > ans[sel] <- rep(yes, length.out = length(ans))[sel]
>
> yes, I know, and have had similar thoughts in the past.
> However note  (I know you that) the current code is
>
> if (any(test[ok]))
> ans[test & ok] <- rep(yes, length.out = length(ans))[test & ok]
>
> and   any(test[ok])  may be considerably faster than
>   any(sel <- test & ok)
>
> OTOH I think the current code would only be faster (for the
> above) when any(.) returned FALSE ...
> I think it may depend on the typical use cases which of the two
> versions is more efficient.
>
>
> > * If 'test' is a factor, doing
> > storage.mode(test) <- "logical"
> > is not appropriate, but is.atomic(test) returns TRUE. Maybe use
> > if(!is.object(test))
> >instead of
> > if(is.atomic(test)) .
>
> This would be a considerable change I think...
> Note that I'm currently really proposing to introduce an *additional*
> ifelse function with different "more reasonable" semantic,  and
> your last change would do that too.
>
> My alternative should really work
> - for factors
> - for "array"s including "matrix" (as the current ifelse() does!)
> - for "Date", "POSIXct", "ts"(timeseries), "zoo",
>   "sparseVector", "sparseMatrix" (*), or "mpfr",
>   without any special code, but rather by design.
>
>  *) Currently needs the R-forge version of  Matrix, version 1.2-8.
>
> A bit less than an hour ago, I have updated the gist with an updated
> proposal ifelse2() {and the current alternatives that I know},
> modified so it *does* keep more, e.g.  dim() attributes in
> reasonable cases.
>
> https://gist.github.com/mmaechler/9cfc3219c4b89649313bfe6853d878
> 94#file-ifelse-def-r-L168
>
> Hence my ifelse2() became even a bit longer (but not slower)
> working for even more classes of  "yes" and "no".
>
>
> > On ifelse-checks.R:
> > * In function 'chkIfelse', if the fourth function argument names is
> not "NA.", the argument name is changed, but the function body still uses
> the old name. That makes error in chkIfelse(ifelseHW) .
> > A fix:
> > if(names(formals(FUN))[[4]] != "NA.") {
> > body(FUN) <- do.call(substitute, list(body(FUN),
> > setNames(list(quote(NA.)),
> names(formals(FUN))[[4]])))
> > names(formals(FUN))[[4]] <- "NA."
> > }
>
> yes, thank you!  (a bit embarrassing for me ..)
>
> > After fixing, chkIfelse(ifelseHW) just fails at identical(iflt,
> as.POSIXlt(ifct)) .
> > 'iflt' has NA as 'tzone' and 'isdst' components.
> > * Because function 'chkIfelse' continues checking after failure,
> > as.POSIXlt(ifct)
> > may give error. The error happens, for example, in
> chkIfelse(ifelseR) . Maybe place it inside try(...).
> > * If 'lt' is a "POSIXlt" object, (lt-100) is a "POSIXct" object.
> > So,
> > FUN(c(TRUE, FALSE, NA, TRUE), lt, lt-100)
> > is an example of mixed class.
>
> good; thank you for the hint.
>
> > * The part of function 'chkIfelse' in
> > for(i in seq_len(nFact))
> > uses 'NA.' function argument. That makes error when 'chkIfelse' is
> applied to function without fourth argument.
> > The 

[R-pkg-devel] Conflicting S3 imports?

[Thierry Onkelinx]

Dear all,

When building my package "A" I get following warning.

class "inla" is defined (with package slot ‘B’) but no metadata object
found to revise superClass information---not exported?  Making a copy in
package ‘A’

- Both packages "A" and "B" use setOldClass("inla") to import the S3 class
"inla".
- Both package define S4 methods for the "inla" class.
- Package "B" defines two S4 classes, none of them have a slot of class
"inla".
- Package "A" defines several S4 classes. One of them ("cA") has a slot of
class "maybeInla", which is defined as setClassUnion("maybeInla", c("inla",
"NULL"))
- The "cA" class uses a slot of class "cB". "cB" is imported from package
"B".

Can someone explain me the warning. And give me a hint on how to avoid it?

Best regards,

Thierry


ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Sat, 26 Nov 2016 17:14:01 + writes:

> Just stating, in 'ifelse', 'test' is not recycled. As I said in "R-intro: 
length of 'ifelse' result" 
(https://stat.ethz.ch/pipermail/r-devel/2016-September/073136.html), 
ifelse(condition, a, b) returns a vector of the length of 'condition', even if 
'a' or 'b' is longer.

yes and  ?ifelse (the help page) also does not say that test is
recycled, rather

   >>  If \code{yes} or \code{no} are too short, their elements are recycled.

(*and* the problem you wrote the above has been corrected in the
 R-intro manual shortly after).


> On current 'ifelse' code in R:

> * The part
> ans[nas] <- NA
> could be omitted because NA's are already in place.
> If the part is removed, variable 'nas' is no longer used.

I agree that this seems logical.  If I apply the change, R's own
full checks do not seem affected, and I may try to commit that
change and "wait and see".


> * The any(*) part actually checks the thing that is used as the index 
vector. The index vector could be stored and then repeatedly used, like the 
following.

>     if (any(sel <- test & ok))
>     ans[sel] <- rep(yes, length.out = length(ans))[sel]

yes, I know, and have had similar thoughts in the past.
However note  (I know you that) the current code is

if (any(test[ok]))
ans[test & ok] <- rep(yes, length.out = length(ans))[test & ok]

and   any(test[ok])  may be considerably faster than
  any(sel <- test & ok)
  
OTOH I think the current code would only be faster (for the
above) when any(.) returned FALSE ...
I think it may depend on the typical use cases which of the two
versions is more efficient.


> * If 'test' is a factor, doing
> storage.mode(test) <- "logical"
> is not appropriate, but is.atomic(test) returns TRUE. Maybe use
> if(!is.object(test))
>instead of
> if(is.atomic(test)) .

This would be a considerable change I think...
Note that I'm currently really proposing to introduce an *additional*
ifelse function with different "more reasonable" semantic,  and
your last change would do that too.

My alternative should really work
- for factors
- for "array"s including "matrix" (as the current ifelse() does!)
- for "Date", "POSIXct", "ts"(timeseries), "zoo",
  "sparseVector", "sparseMatrix" (*), or "mpfr",
  without any special code, but rather by design.

 *) Currently needs the R-forge version of  Matrix, version 1.2-8.

A bit less than an hour ago, I have updated the gist with an updated
proposal ifelse2() {and the current alternatives that I know},
modified so it *does* keep more, e.g.  dim() attributes in
reasonable cases.

https://gist.github.com/mmaechler/9cfc3219c4b89649313bfe6853d87894#file-ifelse-def-r-L168

Hence my ifelse2() became even a bit longer (but not slower)
working for even more classes of  "yes" and "no".


> On ifelse-checks.R:
> * In function 'chkIfelse', if the fourth function argument names is not 
"NA.", the argument name is changed, but the function body still uses the old 
name. That makes error in chkIfelse(ifelseHW) .
> A fix:
>         if(names(formals(FUN))[[4]] != "NA.") {
>             body(FUN) <- do.call(substitute, list(body(FUN),
>                 setNames(list(quote(NA.)), names(formals(FUN))[[4]])))
>             names(formals(FUN))[[4]] <- "NA."
>         }

yes, thank you!  (a bit embarrassing for me ..)

> After fixing, chkIfelse(ifelseHW) just fails at identical(iflt, 
as.POSIXlt(ifct)) .
> 'iflt' has NA as 'tzone' and 'isdst' components.
> * Because function 'chkIfelse' continues checking after failure,
> as.POSIXlt(ifct)
> may give error. The error happens, for example, in chkIfelse(ifelseR) . 
Maybe place it inside try(...).
> * If 'lt' is a "POSIXlt" object, (lt-100) is a "POSIXct" object.
> So,
> FUN(c(TRUE, FALSE, NA, TRUE), lt, lt-100)
> is an example of mixed class.

good; thank you for the hint.

> * The part of function 'chkIfelse' in
> for(i in seq_len(nFact))
> uses 'NA.' function argument. That makes error when 'chkIfelse' is 
applied to function without fourth argument.
> The part should be wrapped in
> if(has.4th) .
yes of course

> * Function 'ifelseJH' has fourth argument, but the argument is not for 
value if NA. So, instead of
> chkIfelse(ifelseJH) ,
> maybe call
> chkIfelse(function(test, yes, no) ifelseJH(test, yes, no)) .
You are right;
I've decided to solve this differently.

I'm looking at these suggestions now, notably also your proposals below;
thank you, Suharto!

(I wanted to put my improved 'ifelse2' out first, quickly).
Martin


> A concrete version of 'ifelse2' that starts the result from 'yes':
> function(test, yes, no, NA. = NA) {
>     if(!is.logical(test))
>         test <- if(isS4(test)) methods::as(test, "logical") 

[Rd] Two typos in manuals

[Mikko Korpela]

I think that in doc/manual/R-intro.texi, "used a part of an even larger 
expression" should be "used as part of an even larger expression".


Another suspected typo is in doc/manual/R-ints.texi, where "dialects of 
TeX and used for different purposes" should probably be "dialects of TeX 
are used for different purposes".


A patch file against R-devel revision 71696 is included.

--
Mikko Korpela
Department of Geosciences and Geography
University of Helsinki
Index: doc/manual/R-intro.texi
===
--- doc/manual/R-intro.texi	(revision 71696)
+++ doc/manual/R-intro.texi	(working copy)
@@ -3377,7 +3377,7 @@
 @var{@dots{}}; @var{expr_m}@}}, in which case the value of the group
 is the result of the last expression in the group evaluated.  Since such
 a group is also an expression it may, for example, be itself included in
-parentheses and used a part of an even larger expression, and so on.
+parentheses and used as part of an even larger expression, and so on.
 
 @node Control statements,  , Grouped expressions, Loops and conditional execution
 @section Control statements
Index: doc/manual/R-ints.texi
===
--- doc/manual/R-ints.texi	(revision 71696)
+++ doc/manual/R-ints.texi	(working copy)
@@ -4295,7 +4295,7 @@
 @node Use of TeX dialects, Current and future directions, Testing R code, Top
 @chapter Use of TeX dialects
 
-Various dialects of TeX and used for different purposes in @R{}.  The
+Various dialects of TeX are used for different purposes in @R{}.  The
 policy is that manuals be written in @samp{texinfo}, and for convenience
 the main and Windows FAQs are also.  This has the advantage that is is
 easy to produce @HTML{} and plain text versions as well as typeset manuals.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Strange behavior when using progress bar (Fwd: Re: [R] The code itself disappears after starting to execute the for loop)

[Jon Skoien]

I first answered to the email below in r-help, but as I did not see any 
response, and it looks like a bug/unwanted behavior, I am also posting 
here. I have observed this in RGui, whereas it seems not to happen in 
RStudio.


Similar to OP, I sometimes have a problem with functions using the 
progress bar. Frequently, the console is cleared after x iterations when 
the progress bar is called in a function which is wrapped in a loop. In 
the example below, this happened for me every ~44th iteration. 
Interestingly, it seems that reduction of the sleep times in this 
function increases the number of iterations before clearing. In my real 
application, where the progress bar is used in a much slower function, 
the console is cleared every 2-3 iteration, which means that I cannot 
scroll back to check the output.



testit <- function(x = sort(runif(20)), ...)
{
  pb <- txtProgressBar(...)
  for(i in c(0, x, 1)) {Sys.sleep(0.2); setTxtProgressBar(pb, i)}
  Sys.sleep(1)
  close(pb)
}

iter = 0
while (TRUE) {testit(style = 3); iter = iter + 1; print(paste("done", 
iter))}


Is this only a problem for a few, or is it reproducible? Any hints to
what the problem could be, or if it can be fixed? I have seen this in 
some versions of R, and could also reproduce in 3.3.2.


Best wishes,
Jon

R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8.1 x64 (build 9600)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base




On 11/23/2016 5:22 PM, Maram SAlem wrote:

Thanks a lot Bert , will check out your suggestions.

I've unchecked the buffer output option in GUI but still have the same problem.

Thanks for your time and concern.

Maram Salem

Sent from my iPhone


On Nov 23, 2016, at 5:55 PM, Bert Gunter  wrote:

In addition to Jim's comments, which you have not yet satisfactorily
addressed (buffering in GUI??),

1. Show your code!

2. Show ouput of sessionInfo()

3. Upgrade to the latest R version maybe

4. Perhaps write to package maintainer (see ?maintainer) if nothing or
no one helps.

Cheers,
Bert


Bert Gunter

"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )



On Tue, Nov 22, 2016 at 10:05 AM, Maram SAlem  wrote:
Thanks for helping Jim.

I'm actually using the pbapply function together with the print function within 
a loop. In earlier versions, the progress bar and the output of the print 
function used to appear after each iteration of the loop. But with the 3.3.1. 
Version nothing appears, instead the console turns white and thecursor turns 
blue ( busy) and I know nothing about the progress of the running code.

I just want to see the bar and the output of the print function as I used to, 
any help?

Thanks in advance.
Maram Salem



Sent from my iPhone


On Nov 3, 2016, at 8:30 PM, jim holtman  wrote:

A little more information would help.  How exactly are out creating the output 
to the console?  Are you using 'print', 'cat' or something else?  Do you have 
buffered output checked on the GUI (you probably don't want it checked or you 
output will be delayed till the buffer is full -- this mightbe the cause of 
your problem.


Jim Holtman
Data Munger Guru

What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.


On Thu, Nov 3, 2016 at 1:55 PM, Maram SAlem  wrote:
Hi all,

I've a question concerning the R 3.3.1 version. I have a long code that I used 
to run on versions earlier to the 3.3.1 version, and when I copied the code to 
the R console, I can still see the code while the loop is executing , along 
with the output printed after each iteration of the loop.

Now, on the 3.3.1 version, after I copy the code to the console, it disappears 
and I only see the printed output of only one iteration at a time, that is, 
after the first iteration the printed output disappears ( thoughit's only 6 
lines, just giving me some guidance, not a long output).
This is causing me some problems, so I don't know if there is a general option 
for R that enables me to still see the code and the output of allthe iterations 
till the loop is over, as was the case with earlier R versions.

I didn't include the code as it's a long one.

Thanks a lot in advance,

Maram


Sent from my iPhone
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?

[Martin Maechler]

> Related to the length of 'ifelse' result, I want to say that "example of 
> different return modes" in ?ifelse led me to perceive a wrong thing in the 
> past.
>  ## example of different return modes:
>  yes <- 1:3
>  no <- pi^(0:3)
>  typeof(ifelse(NA,yes, no)) # logical
>  typeof(ifelse(TRUE,  yes, no)) # integer
>  typeof(ifelse(FALSE, yes, no)) # double
> 
> As the result of each 'ifelse' call is not printed, I thought that the length 
> of the result is 3. In fact, the length of the result is 1.

"of course"... (;-)

But this indeed proves that the example is too sophisticated and
not helpful/clear enough.
Is this better?

## example of different return modes (and 'test' alone determining length):
yes <- 1:3
no  <- pi^(1:4)
utils::str( ifelse(NA,yes, no) ) # logical, length 1
utils::str( ifelse(TRUE,  yes, no) ) # integer, length 1
utils::str( ifelse(FALSE, yes, no) ) # double,  length 1



> I realize just now that the length of 'no' is different from 'yes'. The 
> length of 'yes' is 3, the length of 'no' is 4.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Missing objects using dump.frames for post-mortem debugging of crashed batch jobs. Bug or gap in documentation?

[Andreas Kersting]

Martin, thanks for the good news and sorry for wasting your (and others
time) by not doing my homework and query bugzilla first (lesson learned!
).

I have tested the new implementation from R-devel and observe a semantic
difference when playing with the parameters:

  # Test script 1
  g <- "global"
  f <- function(p) {
l <- "local"
dump.frames()
  }
  f("parameter")

results in
  # > debugger()
  # Message:  object 'server' not foundAvailable environments had calls:
  # 1: source("~/.active-rstudio-document", echo = TRUE)
  # 2: withVisible(eval(ei, envir))
  # 3: eval(ei, envir)
  # 4: eval(expr, envir, enclos)
  # 5: .active-rstudio-document#9: f("parameter")
  #
  # Enter an environment number, or 0 to exit
  # Selection: 5
  # Browsing in the environment with call:
  #   .active-rstudio-document#9: f("parameter")
  # Called from: debugger.look(ind)
  # Browse[1]> g
  # [1] "global"
  # Browse[1]>

while dumping to a file

  # Test script 2
  g <- "global"
  f <- function(p) {
l <- "local"
dump.frames(to.file = TRUE, include.GlobalEnv = TRUE)
  }
  f("parameter")

results in
  # > load("last.dump.rda")
  # > debugger()



  # Message:  object 'server' not foundAvailable environments had calls:
  # 1: .GlobalEnv
  # 2: source("~/.active-rstudio-document", echo = TRUE)
  # 3: withVisible(eval(ei, envir))
  # 4: eval(ei, envir)
  # 5: eval(expr, envir, enclos)
  # 6: .active-rstudio-document#11: f("parameter")
  #
  # Enter an environment number, or 0 to exit
  # Selection: 6
  # Browsing in the environment with call:
  #   .active-rstudio-document#11: f("parameter")
  # Called from: debugger.look(ind)
  # Browse[1]> g
  # Error: object 'g' not found
  # Browse[1]>


Your call to f() and the corresponding dump is heavily
obfuscated by all the wrap paper that Rstudio seems to wrap around a
simple function call (or just around using debugger() ?).

All this was to get the correct environments when things are run
in a batch job... and there's no Rstudio gift wrapping in that case.

In my simple use of the above, "g" is clearly available in the .GlobalEnv
component of last.dump :


exists("g", last.dump$.GlobalEnv)

[1] TRUE

get("g", last.dump$.GlobalEnv)

[1] "global"




and that's all what's promised, right?
In such a post mortem debugging, notably from a batch job (!),
you don't want your .GlobalEnv to be *replaced* by the
.GlobalEnv from 'last.dump', do you?

I think in the end, I think you are indirectly asking for new features to be
added to  debugger(), namely that it works more seemlessly with
a last.dump object that has been created via 'include.GlobalEnv = TRUE'.

This wish for a new feature may be a very sensible wish.
I think it's fine if you add it as wish (for a new feature to
debugger()) to the R bugzilla site
( https://bugs.r-project.org/ -- after asking one of R core to
  add you to the list of "registered ones" there, see the
  boldface note in https://www.r-project.org/bugs.html )

Personally, I would only look into this issue if we also get a patch
proposal (see also https://www.r-project.org/bugs.html), because
already now you can easily get to "g" in your example.

Martin



Hi,

how about changing debugger() to something along the lines:

debugger <- function(dump = last.dump)
{
# debugger.look <- function(.selection)
# {
# ## allow e.g. '...' to fail
# for(.obj in ls(envir=dump[[.selection]], all.names=TRUE))
# tryCatch(assign(.obj, get(.obj,envir=dump[[.selection]])),
#  error=function(e) {})
# cat(gettext("Browsing in the environment with call:\n   "),
# calls[.selection], "\n", sep = "")
# rm(.obj, .selection)
# browser()
# }
if (!inherits(dump, "dump.frames")) {
cat(gettextf("'dump' is not an object of class %s\n",
 dQuote("dump.frames")))
return(invisible())
}
err.action <- getOption("error")
on.exit(options(error=err.action))
if (length(msg <- attr(dump, "error.message")))
cat(gettext("Message: "), msg)
n <- length(dump)
if (!n) {
cat(gettextf("'dump' is empty\n"))
return(invisible())
}
calls <- names(dump)

if (calls[1] == ".GlobalEnv") {
parent.env(dump[[1]]) <- parent.env(.GlobalEnv)
for (i in seq_along(dump)[-1]) {
if (identical(parent.env(dump[[i]]), .GlobalEnv)) {
parent.env(dump[[i]]) <- dump[[1]]
}
}
}

repeat {
cat(gettext("Available environments had calls:\n"))
cat(paste0(1L:n, ": ", calls), sep = "\n")
cat(gettext("\nEnter an environment number, or 0 to exit  "))
repeat {
ind <- .Call(C_menu, as.character(calls))
if(ind <= n) break
}
if(ind == 0L) return(invisible())
# debugger.look(ind)
cat(gettext("Browsing in the environment with call:\n   "),
calls[ind], "\n", sep = "")

[Rd] methods:::.selectSuperClasses and byte compilation

[François Rousset]

Dear R-devel list,

Running the following example on a recent R-devel (here, 2016-11-22 
r71672) shows that the byte compiler can cause some significant 
performance drops (here, computation time increasing from 0.01s to 0.31s 
...)

=
library(Matrix)
someMatrix <- new("dtCMatrix", i= c(1L, 0:3), p=c(0L,0L,0:2, 5L), Dim = 
c(5L, 5L),

  x = rep(1, 5), diag = "U")
compiler::enableJIT(3) ## R-devel default
system.time(replicate(100,Matrix::crossprod(someMatrix))) ## slow !
compiler::enableJIT(0)
system.time(replicate(100,Matrix::crossprod(someMatrix))) ## fast
==
By tracing compiler::cmpfun, I found that the reason may be that 
invoking Matrix::crossprod calls methods:::.selectSuperClasses which 
creates and runs the following function

function (exti) {!isVirtualExt(exti) && length(exti@by) == 0 && exti@simple}
and thus that this function is byte-compiled each time Matrix::crossprod 
is called.


Is there a straightforward way for users / R package writers to avoid 
such problems, or shouldn't it be fixed in the R sources ?


Thanks,

F.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel