Re: [Bioc-devel] Question regarding the error from build report

[Hervé Pagès]

What is the question?

On 3/26/20 17:36, 유도영 wrote:


___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=yOswU0969aOLHa3jBIrzVj8fAiukIOoj9_7XnCcbRqI=zbtkDPRVf5duX0qU9xSZy3MqdeBSIo3Bpl7L6zEdNBE=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] core dump in MotifDb build

[Hervé Pagès]

Hi Paul,

I can reproduce this on my laptop. See full output below (it's big!). 
Make sure to use a recent version of R devel (I updated mine 3 days 
ago). The error seems to occur in MotIV's C/C++ code (in 
/home/hpages/R/R-4.0.r78037/library/MotIV/libs/MotIV.so on my machine).


2 unrelated things:
- Please add MotIV and seqLogo to your Suggests field (they're used in 
the vignette and/or the unit tests).

- Make sure to remove vignettes/MotifDb.tex

Best,
H.

--

hpages@spectre:~/MotifDb/vignettes$ R-4.0 CMD Stangle MotifDb.Rnw
Output file:  MotifDb.R

hpages@spectre:~/MotifDb/vignettes$ R-4.0

R Under development (unstable) (2020-03-23 r78037) -- "Unsuffered 
Consequences"

Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> source("MotifDb.R", echo=TRUE)

> ### R code from vignette source 
'/home/hpages/git.bioconductor.org/software/MotifDb/vignettes/MotifDb.Rnw'

>
>   [TRUNCATED]
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following objects are masked from ‘package:parallel’:

clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
clusterExport, clusterMap, parApply, parCapply, parLapply,
parLapplyLB, parRapply, parSapply, parSapplyLB

The following objects are masked from ‘package:stats’:

IQR, mad, sd, var, xtabs

The following objects are masked from ‘package:base’:

anyDuplicated, append, as.data.frame, basename, cbind, colnames,
dirname, do.call, duplicated, eval, evalq, Filter, Find, get, grep,
grepl, intersect, is.unsorted, lapply, Map, mapply, match, mget,
order, paste, pmax, pmax.int, pmin, pmin.int, Position, rank,
rbind, Reduce, rownames, sapply, setdiff, sort, table, tapply,
union, unique, unsplit, which, which.max, which.min

Loading required package: S4Vectors
Loading required package: stats4

Attaching package: ‘S4Vectors’

The following object is masked from ‘package:base’:

expand.grid

Loading required package: IRanges
Loading required package: GenomicRanges
Loading required package: GenomeInfoDb
Loading required package: Biostrings
Loading required package: XVector

Attaching package: ‘Biostrings’

The following object is masked from ‘package:base’:

strsplit


Registered S3 method overwritten by 'treeio':
  method from
  root.phylo ape
See system.file("LICENSE", package="MotifDb") for use restrictions.

> library (MotIV)

Attaching package: ‘MotIV’

The following object is masked from ‘package:stats’:

filter


> library (seqLogo)
Loading required package: grid

Attaching package: ‘seqLogo’

The following object is masked from ‘package:MotIV’:

makePWM


> ###
> ### code chunk number 2: MotifDb.Rnw:71-90
> #  [TRUNCATED]

> ###
> ### code chunk number 3: sources
> ###
> lengt  [TRUNCATED]
[1] 10701

> sort (table (values (MotifDb)$dataSource), decreasing=TRUE)

 jaspar2018  jaspar2016 HOCOMOCOv10
   156412091066
 cisbp_1.02   jolma2013SwissRegulon
874 843 684
stamlab FlyFactorSurvey JASPAR_2014
683 614 592
JASPAR_COREhPDIUniPROBE
459 437 380
  HOMER HOCOMOCOv11-secondary-D  ScerTF
332 290 196
 HOCOMOCOv11-core-A  HOCOMOCOv11-core-C  HOCOMOCOv11-core-B
181 135  84
HOCOMOCOv11-secondary-A HOCOMOCOv11-secondary-B HOCOMOCOv11-secondary-C
 46  19  13

> ###
> ### code chunk number 4: organisms
> ###
> sor  [TRUNCATED]


Hsapiens

 5384

Mmusculus

 1411

Dmelanogaster

 

[Rd] Expressions from boxplot() passed to bxp()

[Marius Hofert]

Hi,

Is this expected behavior (R-3.6.0)?

dat <- cbind(x = 1:10, y = 10:1)
ylab <- substitute(X[t], list(t = 2))
plot(dat, ylab = ylab) # works (correctly displays ylab)
boxplot(dat, ylab = ylab) # fails
boxplot(dat, ylab = as.expression(ylab)) # works

Thanks & cheers,
M

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

Re: [Rd] unstable corner of parameter space for qbeta?

[Ben Bolker]

On 2020-03-26 4:02 a.m., Martin Maechler wrote:
>> Ben Bolker 
>> on Wed, 25 Mar 2020 21:09:16 -0400 writes:
> 
> > I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
> > since there's a clear warning about lack of convergence of the numerical
> > algorithm ("full precision may not have been achieved").  I can work
> > around this, but I'm curious why it happens and whether there's a better
> > workaround -- it doesn't seem to be in a particularly extreme corner of
> > parameter space. It happens, e.g., for  these parameters:
> 
> > phi <- 1.1
> > i <- 0.01
> > t <- 0.001
> > shape1 = i/phi  ##  0.009090909
> > shape2 = (1-i)/phi  ## 0.9
> > qbeta(t,shape1,shape2)  ##  5.562685e-309
> > ##  brute-force uniroot() version, see below
> > Qbeta0(t,shape1,shape2)  ## 0.9262824
> 
> > The qbeta code is pretty scary to read: the warning "full precision
> > may not have been achieved" is triggered here:
> 
> > 
> https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530
> 
> > Any thoughts?
> 
> Well,  qbeta() is mostly based on inverting pbeta()  and pbeta()
> has *several* "dangerous" corners in its parameter spaces
> {in some cases, it makes sense to look at the 4 different cases
>  log.p = TRUE/FALSE  //  lower.tail = TRUE/FALSE  separately ..}
> 
> pbeta() itself is based on the most complex numerical code in
> all of base R, i.e., src/nmath/toms708.c  and that algorithm
> (TOMS 708) had been sophisticated already when it was published,
> and it has been improved and tweaked several times since being
> part of R, notably for the log.p=TRUE case which had not been in
> the focus of the publication and its algorithm.
> [[ NB: part of this you can read when reading  help(pbeta)  to the end ! ]]
> 
> I've spent many "man weeks", or even "man months" on pbeta() and
> qbeta(), already and have dreamed to get a good student do a
> master's thesis about the problem and potential solutions I've
> looked into in the mean time.
> 
> My current gut feeling is that in some cases, new approximations
> are necessary (i.e. tweaking of current approximations is not
> going to help sufficiently).
> 
> Also not (in the R sources)  tests/p-qbeta-strict-tst.R
> a whole file of "regression tests" about  pbeta() and qbeta()
> {where part of the true values have been computed with my CRAN
> package Rmpfr (for high precision computation) with the
> Rmpfr::pbetaI() function which gives arbitrarily precise pbeta()
> values but only when  (a,b) are integers -- that's the "I" in pbetaI().
> 
> Yes, it's intriguing ... and I'll look into your special
> findings a bit later today.
> 
> 
>   > Should I report this on the bug list?
> 
> Yes, please.  Not all problem of pbeta() / qbeta() are part yet,
> of R's bugzilla data base,  and maybe this will help to draw
> more good applied mathematicians look into it.

  Will report.

  I'm not at all surprised that this is a super-tough problem.  The only
part that was surprising to me was that my naive uniroot-based solution
worked (for this particular corner of parameter space where qbeta() has
trouble: it was terrible elsewhere, so now I'm using a hybrid solution
where I use my brute-force uniroot thing if I get a warning from qbeta().

I hesitated to even bring it up because I know you're really busy, but I
figured it was better to tag it now and let you deal with it some time
later.

Bugzilla report at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17746

  cheers
   Ben Bolker


> 
> 
> 
> Martin Maechler
> ETH Zurich and R Core team
> (I'd call myself the "dpq-hacker" within R core -- related to
>  my CRAN package 'DPQ')
> 
> 
> > A more general illustration:
> > http://www.math.mcmaster.ca/bolker/misc/qbeta.png
> 
> > ===
> > fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
> > f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
> > }
> > ## brute-force beta quantile function
> > Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
> > fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
> > uniroot(fn,interval=c(0,1))$root
> > }
> > Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
> > curve(fun,from=1,to=4)
> > curve(fun(x,f=Qbeta),add=TRUE,col=2)
> 
> > __
> > 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

[Bioc-devel] Question regarding the error from build report

[유도영]

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

[Bioc-devel] core dump in MotifDb build

[Paul Shannon]

Dear Bioc,

I have added the lasted HOCOMOCO motifs to MotifDb but changed no code.   The 
package 1.29.6 dumps core during in the bioc devel linux build, and fails 
perhaps similarly on windows.

   
http://bioconductor.org/checkResults/devel/bioc-LATEST/MotifDb/malbec2-buildsrc.html

Any suggestions on how I can track this down?   The package builds and checks 
clean on my macOS and linux systems.

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

Re: [Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

[Winston Chang]

Simon,

The link I provided to the httpuv issue has detailed information about
the error:
  https://github.com/rstudio/httpuv/issues/260

The error occurs when I run the following (although note, depending on
which mirror you use, the recent CRAN server issues may result in
problems downloading the packages):
  install.packages("Rcpp")
  install.packages("httpuv", type = "source")

Here's the full output:
  https://gist.github.com/wch/c70b438381c9d2a8b1f917b054e0ba7e

Here's an example of the errors:

In file included from staticpath.cpp:1:
In file included from ./staticpath.h:7:
In file included from /Users/winston/R/3.6/BH/include/boost/optional.hpp:15:
In file included from
/Users/winston/R/3.6/BH/include/boost/optional/optional.hpp:28:
In file included from
/Users/winston/R/3.6/BH/include/boost/core/addressof.hpp:17:
In file included from /Users/winston/R/3.6/BH/include/boost/config.hpp:57:
In file included from
/Users/winston/R/3.6/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/winston/R/3.6/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:664:27:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int  getwgroups_np(int *, uuid_t);
  ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31:
note: 'uid_t' declared here
typedef __darwin_uid_tuid_t;
  ^

This issue describes the same problem:
  https://github.com/RcppCore/Rcpp/issues/1046

And it has been fixed in the development version of Rcpp by:
   https://github.com/RcppCore/Rcpp/pull/1047

I know that Kevin Ushey has tried building with the CRAN-recommended
clang 7 toolchain and encountered the same errors. I haven't done that
yet myself, though.

-Winston

On Thu, Mar 26, 2020 at 4:00 PM Simon Urbanek
 wrote:
>
> Winston,
>
> the Mac CRAN build builds a package only if either is true:
> 1) the package has not passed checks
> 2) there is a new version of the package since last successful build+check
>
> The old build machine doesn't have the capacity to do full re-builds (it 
> would take over 24h - currently the nightly build of packages takes 16-22 
> hours), but we're currently building a new setup for R 4.0.0 on new hardware 
> and as a part of it we are planning to setup a "mac-builder" similar to what 
> is currently available for Windows.
>
> That said, I have run httpuv by hand on the CRAN build machine (against Rcpp 
> 1.0.4) and I saw no issues. I have seen the discussion on Rcpp, but so far no 
> one actually posted details of what is breaking (nor do your links include 
> any actual details on this). I'd love to help, but the lack fo a useful 
> report makes this impossible. If you have any actual leads, please post them. 
> The CRAN machine uses the tools that are available on CRAN: 
> https://cran.r-project.org/bin/macosx/tools/ (clang-7 and gfortran-6.1 for 
> 3.6.x)
>
> Cheers,
> Simon
>
>
> > On 27/03/2020, at 7:38 AM, Winston Chang  wrote:
> >
> > I have two questions about the CRAN machines that build binary
> > packages for Mac. When a new version of a package is released,
> >  (A) Do the downstream dependencies get re-checked?
> >  (B) Do the downstream dependencies get re-built?
> >
> > I have heard (but do not know for sure) that the answer to (A) is no,
> > the downstream dependencies do not get rechecked.
> >
> > From publicly available information on the CRAN web server, it looks
> > like the answer to (B) is also no, the downstream dependencies do not
> > get rebuilt. Looking at
> > https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/, I see
> > the following dates for these binary packages:
> >
> > - Rcpp_1.0.4.tgz: 2020-03-18
> > - httpuv_1.5.2.tgz: 2019-09-12
> > - dplyr_0.8.5.tgz: 2020-03-08
> >
> > Rcpp was released recently, and httpuv and dplyr (which are downstream
> > dependencies of Rcpp) have older dates, which indicates that these
> > binary packages were not rebuilt when Rcpp was released.
> >
> > In my particular case, I'm interested in the httpuv package (which I
> > maintain). I and several others have not been able to get the CRAN
> > version of httpuv to compile using the CRAN version of Rcpp on Mac.
> > (It seems to compile fine on other platforms.) I have heard from
> > maintainers of other Rcpp-dependent packages that they also can't get
> > their packages to compile on Mac, using both the default Mac compiler
> > toolchain and the CRAN-recommended toolchain, which uses clang 7.
> >
> > For more technical details about the cause of breakage, see:
> > https://github.com/RcppCore/Rcpp/issues/1060
> > https://github.com/rstudio/httpuv/issues/260
> >
> > If the CRAN Mac build machine is indeed able to build httpuv against
> > the current version of Rcpp, it would be really helpful to have more
> > information about the system configuration. If it is not able to
> > rebuild httpuv and 

Re: [Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

[Hadley Wickham]

If I do install.packages("dplyr", type = "source"), I see:

Installing package into ‘/Users/hadley/R’
(as ‘lib’ is unspecified)
trying URL 'https://cran.rstudio.com/src/contrib/dplyr_0.8.5.tar.gz'
Content type 'application/x-gzip' length 1378766 bytes (1.3 MB)
==
downloaded 1.3 MB

* installing *source* package ‘dplyr’ ...
** package ‘dplyr’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
ccache clang++ -Qunused-arguments
 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I../inst/include -DRCPP_DEFAULT_INCLUDE_CALL=false -DCOMPILING_DPLYR
-DRCPP_USING_UTF8_ERROR_STRING -DRCPP_USE_UNWIND_PROTECT
-DBOOST_NO_AUTO_PTR  -I"/Users/hadley/R/BH/include"
-I"/Users/hadley/R/plogr/include" -I"/Users/hadley/R/Rcpp/include"
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
-I/usr/local/include  -fPIC  -Wall -g -O2  -c RcppExports.cpp -o
RcppExports.o
In file included from RcppExports.cpp:4:
In file included from ./../inst/include/dplyr.h:4:
In file included from ../inst/include/dplyr/main.h:6:
In file included from ../inst/include/dplyr/workarounds/static_assert.h:17:
In file included from /Users/hadley/R/BH/include/boost/config.hpp:57:
In file included from
/Users/hadley/R/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/hadley/R/BH/include/boost/config/detail/posix_features.hpp:18:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:655:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/gethostuuid.h:39:17:
error: unknown type name 'uuid_t'
int gethostuuid(uuid_t, const struct timespec *)
__OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_NA);
^
In file included from RcppExports.cpp:4:
In file included from ./../inst/include/dplyr.h:4:
In file included from ../inst/include/dplyr/main.h:6:
In file included from ../inst/include/dplyr/workarounds/static_assert.h:17:
In file included from /Users/hadley/R/BH/include/boost/config.hpp:57:
In file included from
/Users/hadley/R/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/hadley/R/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:662:27:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int  getsgroups_np(int *, uuid_t);
  ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31:
note: 'uid_t' declared here
typedef __darwin_uid_tuid_t;
  ^
In file included from RcppExports.cpp:4:
In file included from ./../inst/include/dplyr.h:4:
In file included from ../inst/include/dplyr/main.h:6:
In file included from ../inst/include/dplyr/workarounds/static_assert.h:17:
In file included from /Users/hadley/R/BH/include/boost/config.hpp:57:
In file included from
/Users/hadley/R/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/hadley/R/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:664:27:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int  getwgroups_np(int *, uuid_t);
  ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31:
note: 'uid_t' declared here
typedef __darwin_uid_tuid_t;
  ^
In file included from RcppExports.cpp:4:
In file included from ./../inst/include/dplyr.h:4:
In file included from ../inst/include/dplyr/main.h:6:
In file included from ../inst/include/dplyr/workarounds/static_assert.h:17:
In file included from /Users/hadley/R/BH/include/boost/config.hpp:57:
In file included from
/Users/hadley/R/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/hadley/R/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:727:31:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int  setsgroups_np(int, const uuid_t);
  ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31:
note: 'uid_t' declared here
typedef __darwin_uid_tuid_t;
  ^
In file included from RcppExports.cpp:4:
In file included from ./../inst/include/dplyr.h:4:
In file included from ../inst/include/dplyr/main.h:6:
In file included from ../inst/include/dplyr/workarounds/static_assert.h:17:
In file included from /Users/hadley/R/BH/include/boost/config.hpp:57:
In file included from
/Users/hadley/R/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/hadley/R/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:729:31:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int  

Re: [Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

[Simon Urbanek]

Winston,

the Mac CRAN build builds a package only if either is true:
1) the package has not passed checks
2) there is a new version of the package since last successful build+check

The old build machine doesn't have the capacity to do full re-builds (it would 
take over 24h - currently the nightly build of packages takes 16-22 hours), but 
we're currently building a new setup for R 4.0.0 on new hardware and as a part 
of it we are planning to setup a "mac-builder" similar to what is currently 
available for Windows.

That said, I have run httpuv by hand on the CRAN build machine (against Rcpp 
1.0.4) and I saw no issues. I have seen the discussion on Rcpp, but so far no 
one actually posted details of what is breaking (nor do your links include any 
actual details on this). I'd love to help, but the lack fo a useful report 
makes this impossible. If you have any actual leads, please post them. The CRAN 
machine uses the tools that are available on CRAN: 
https://cran.r-project.org/bin/macosx/tools/ (clang-7 and gfortran-6.1 for 
3.6.x)

Cheers,
Simon


> On 27/03/2020, at 7:38 AM, Winston Chang  wrote:
> 
> I have two questions about the CRAN machines that build binary
> packages for Mac. When a new version of a package is released,
>  (A) Do the downstream dependencies get re-checked?
>  (B) Do the downstream dependencies get re-built?
> 
> I have heard (but do not know for sure) that the answer to (A) is no,
> the downstream dependencies do not get rechecked.
> 
> From publicly available information on the CRAN web server, it looks
> like the answer to (B) is also no, the downstream dependencies do not
> get rebuilt. Looking at
> https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/, I see
> the following dates for these binary packages:
> 
> - Rcpp_1.0.4.tgz: 2020-03-18
> - httpuv_1.5.2.tgz: 2019-09-12
> - dplyr_0.8.5.tgz: 2020-03-08
> 
> Rcpp was released recently, and httpuv and dplyr (which are downstream
> dependencies of Rcpp) have older dates, which indicates that these
> binary packages were not rebuilt when Rcpp was released.
> 
> In my particular case, I'm interested in the httpuv package (which I
> maintain). I and several others have not been able to get the CRAN
> version of httpuv to compile using the CRAN version of Rcpp on Mac.
> (It seems to compile fine on other platforms.) I have heard from
> maintainers of other Rcpp-dependent packages that they also can't get
> their packages to compile on Mac, using both the default Mac compiler
> toolchain and the CRAN-recommended toolchain, which uses clang 7.
> 
> For more technical details about the cause of breakage, see:
> https://github.com/RcppCore/Rcpp/issues/1060
> https://github.com/rstudio/httpuv/issues/260
> 
> If the CRAN Mac build machine is indeed able to build httpuv against
> the current version of Rcpp, it would be really helpful to have more
> information about the system configuration. If it is not able to
> rebuild httpuv and other packages against Rcpp, then this is a
> problem. Among other things, it prevents people from building their
> packages from source using CRAN versions of packages, and it also
> means that none of these packages can release a new version, because
> the binaries can't be built on Mac.
> 
> -Winston
> 
> __
> 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] unstable corner of parameter space for qbeta?

[Martin Maechler]

> Ravi Varadhan 
> on Thu, 26 Mar 2020 18:33:43 + writes:

> This is also strange:
> qbeta <- function (p, shape1, shape2, ncp = 0, lower.tail = TRUE, log.p = 
FALSE)
> {
> if (missing(ncp))
> .Call(C_qbeta, p, shape1, shape2, lower.tail, log.p)
> else .Call(C_qnbeta, p, shape1, shape2, ncp, lower.tail,
> log.p)
> }




> Since the default value is 0 for non-centrality, it seems like the logic 
above is wrong. When ncp=0, C_qnbeta would be called rather than C_qbeta.

> Am I missing something?

Yes.  This has been on purpose (forever) and I think the help
page mentions that - though probably a bit subtly.

The way it is now, one can use both algorithms to compute what
in principle should be the main thing.


> Ravi



> 
> From: R-devel  on behalf of J C Nash 

> Sent: Thursday, March 26, 2020 10:40:05 AM
> To: Martin Maechler
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] unstable corner of parameter space for qbeta?


> Despite the need to focus on pbeta, I'm still willing to put in some 
effort.
> But I find it really helps to have 2-3 others involved, since the 
questions back
> and forth keep matters moving forward. Volunteers?

> Thanks to Martin for detailed comments.

> JN


> On 2020-03-26 10:34 a.m., Martin Maechler wrote:
>>> J C Nash
>>> on Thu, 26 Mar 2020 09:29:53 -0400 writes:
>> 
>> > Given that a number of us are housebound, it might be a good time to 
try to
>> > improve the approximation. It's not an area where I have much 
expertise, but in
>> > looking at the qbeta.c code I see a lot of root-finding, where I do 
have some
>> > background. However, I'm very reluctant to work alone on this, and 
will ask
>> > interested others to email off-list. If there are others, I'll report 
back.
>> 
>> Hi John.
>> Yes, qbeta() {in its "main branches"}  does zero finding, but
>> zero finding of   pbeta(...) - p*   and I tried to explain in my
>> last e-mail that the real problem is that already pbeta() is not
>> accurate enough in some unstable corners ...
>> The order fixing should typically be
>> 1) fix pbeta()
>> 2) look at qbeta() which now may not even need a fix because its
>> problems may have been entirely a consequence of pbeta()'s inaccuracies.
>> And if there are cases where the qbeta() problems are not
>> only pbeta's "fault", it is still true that the fixes that
>> would still be needed crucially depend on the detailed
>> working of the function whose zero(s) are sought, i.e.,  pbeta()
>> 
>> > Ben: Do you have an idea of parameter region where approximation is 
poor?
>> > I think that it would be smart to focus on that to start with.
>> 
>> 
>> 
>> Rmpfr  matrix-/vector - products:
>> 
>> > Martin: On a separate precision matter, did you get my query early in 
year about double
>> > length accumulation of inner products of vectors in Rmpfr? R-help more 
or
>> > less implied that Rmpfr does NOT use extra length. I've been using 
David
>> > Smith's FM Fortran where the DOT_PRODUCT does use double length, but it
>> > would be nice to have that in R. My attempts to find "easy" 
workarounds have
>> > not been successful, but I'll admit that other things took precedence.
>> 
>> Well, the current development version of 'Rmpfr' on R-forge now
>> contains facilities to enlarge the precision of the computations
>> by a factor 'fPrec' with default 'fPrec = 1';
>> notably, instead of  x %*% y   (where the `%*%` cannot have more
>> than two arguments) does have a counterpart  matmult(x,y, )
>> which allows more arguments, namely 'fPrec', or directly 'precBits';
>> and of course there are  crossprod() and tcrossprod() one should
>> use when applicable and they also got the  'fPrec' and
>> 'precBits' arguments.
>> 
>> {The %*% etc precision increase still does not work optimally
>> efficiency wise, as it simply increases the precision of all
>> computations by just increasing the precision of x and y (the inputs)}.
>> 
>> The whole  Matrix and Matrix-vector arithmetic is still
>> comparibly slow in Rmpfr .. mostly because I valued human time
>> (mine!) much higher than computer time in its implementation.
>> That's one reason I would never want to double the precision
>> everywhere as it decreases speed even more, and often times
>> unnecessarily: doubling the accuracy is basically "worst-case
>> scenario" precaution
>> 
>> Martin
>> 

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

__
R-devel@r-project.org mailing list

Re: [Bioc-devel] Fwd: 'MBQN' Bioconductor package

[Shepherd, Lori]

I see changes pushed to the RELEASE_3_10 branch from today.   Please see the 
top section of this documentation that describes timing and expected changes.
http://bioconductor.org/developers/how-to/troubleshoot-build-report/

It will take 24-48 hours to appear on the build report and landing pages.  It 
was not included in todays build but should be on tomorrows.



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Eva Brombacher 

Sent: Thursday, March 26, 2020 2:35 PM
To: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Fwd: 'MBQN' Bioconductor package

Dear Sir or Madam,

Ariane Schad forwarded the e-mail below from Kayla E. Interdonato to me
regarding the MBQN Bioconductor package.

I tried to push the newest version to the release branch using the
following commands:
**

git fetch upstream
git checkout -b RELEASE_3_10 upstream/RELEASE_3_10
git fetch --all
git merge master
git push upstream RELEASE_3_10

When I checked, however, on
https://bioconductor.org/checkResults/3.10/bioc-LATEST/ I still only see
the old "1.0.0" package version.

Could you please let me know if I'm missing something and how to fix this.

Many thanks for your help in advance.

Best wishes,

Eva Brombacher


Am 26.03.20 um 09:04 schrieb ariane.schad:
>
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>  Urspr�ngliche Nachricht 
> Von: "Interdonato, Kayla" 
> Datum: 25.03.20 00:02 (GMT+01:00)
> An: ariane.sc...@fdm.uni-freiburg.de
> Betreff: 'MBQN' Bioconductor package
>
> The next Bioconductor release 3.11 is scheduled for April 28th.
> Commits should
>
> be made to the current 3.10 release by April 10th and the last day to
> commit
>
> to the devel branch is April 24th.
>
> We like to make an effort to have all Bioconductor packages building and
>
> checking without ERROR or TIMEOUT in both release and devel versions.
> Currently
>
> your package is producing an ERROR for all three builders in the both the
>
> release and devel version of Bioconductor. I see changes are being
> made to the
>
> devel version of the package but could you please investigate the
> release errors
>
> as soon as possible.
>
> Release version -
> https://bioconductor.org/checkResults/3.10/bioc-LATEST/MBQN/
>
> If you need any assistance please feel free to ask questions at
>
> bioc-devel@r-project.org.
>
> *Kayla E. Interdonato, MS*
>
> Programmer/Analyst
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> (716)845-1300 x4621
>

[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Fwd: 'MBQN' Bioconductor package

[Eva Brombacher]

Dear Sir or Madam,

Ariane Schad forwarded the e-mail below from Kayla E. Interdonato to me 
regarding the MBQN Bioconductor package.

I tried to push the newest version to the release branch using the 
following commands:
**

git fetch upstream
git checkout -b RELEASE_3_10 upstream/RELEASE_3_10
git fetch --all
git merge master
git push upstream RELEASE_3_10

When I checked, however, on 
https://bioconductor.org/checkResults/3.10/bioc-LATEST/ I still only see 
the old "1.0.0" package version.

Could you please let me know if I'm missing something and how to fix this.

Many thanks for your help in advance.

Best wishes,

Eva Brombacher


Am 26.03.20 um 09:04 schrieb ariane.schad:
>
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>  Ursprüngliche Nachricht 
> Von: "Interdonato, Kayla" 
> Datum: 25.03.20 00:02 (GMT+01:00)
> An: ariane.sc...@fdm.uni-freiburg.de
> Betreff: 'MBQN' Bioconductor package
>
> The next Bioconductor release 3.11 is scheduled for April 28th. 
> Commits should
>
> be made to the current 3.10 release by April 10th and the last day to 
> commit
>
> to the devel branch is April 24th.
>
> We like to make an effort to have all Bioconductor packages building and
>
> checking without ERROR or TIMEOUT in both release and devel versions. 
> Currently
>
> your package is producing an ERROR for all three builders in the both the
>
> release and devel version of Bioconductor. I see changes are being 
> made to the
>
> devel version of the package but could you please investigate the 
> release errors
>
> as soon as possible.
>
> Release version - 
> https://bioconductor.org/checkResults/3.10/bioc-LATEST/MBQN/
>
> If you need any assistance please feel free to ask questions at
>
> bioc-devel@r-project.org.
>
> *Kayla E. Interdonato, MS*
>
> Programmer/Analyst
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> (716)845-1300 x4621
>

[[alternative HTML version deleted]]

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

[Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

[Winston Chang]

I have two questions about the CRAN machines that build binary
packages for Mac. When a new version of a package is released,
  (A) Do the downstream dependencies get re-checked?
  (B) Do the downstream dependencies get re-built?

I have heard (but do not know for sure) that the answer to (A) is no,
the downstream dependencies do not get rechecked.

>From publicly available information on the CRAN web server, it looks
like the answer to (B) is also no, the downstream dependencies do not
get rebuilt. Looking at
https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/, I see
the following dates for these binary packages:

- Rcpp_1.0.4.tgz: 2020-03-18
- httpuv_1.5.2.tgz: 2019-09-12
- dplyr_0.8.5.tgz: 2020-03-08

Rcpp was released recently, and httpuv and dplyr (which are downstream
dependencies of Rcpp) have older dates, which indicates that these
binary packages were not rebuilt when Rcpp was released.

In my particular case, I'm interested in the httpuv package (which I
maintain). I and several others have not been able to get the CRAN
version of httpuv to compile using the CRAN version of Rcpp on Mac.
(It seems to compile fine on other platforms.) I have heard from
maintainers of other Rcpp-dependent packages that they also can't get
their packages to compile on Mac, using both the default Mac compiler
toolchain and the CRAN-recommended toolchain, which uses clang 7.

For more technical details about the cause of breakage, see:
https://github.com/RcppCore/Rcpp/issues/1060
https://github.com/rstudio/httpuv/issues/260

If the CRAN Mac build machine is indeed able to build httpuv against
the current version of Rcpp, it would be really helpful to have more
information about the system configuration. If it is not able to
rebuild httpuv and other packages against Rcpp, then this is a
problem. Among other things, it prevents people from building their
packages from source using CRAN versions of packages, and it also
means that none of these packages can release a new version, because
the binaries can't be built on Mac.

-Winston

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

Re: [Rd] unstable corner of parameter space for qbeta?

[Ravi Varadhan]

This is also strange:


qbeta <- function (p, shape1, shape2, ncp = 0, lower.tail = TRUE, log.p = FALSE)
{
if (missing(ncp))
.Call(C_qbeta, p, shape1, shape2, lower.tail, log.p)
else .Call(C_qnbeta, p, shape1, shape2, ncp, lower.tail,
log.p)
}




Since the default value is 0 for non-centrality, it seems like the logic above 
is wrong. When ncp=0, C_qnbeta would be called rather than C_qbeta.

Am I missing something?



Ravi




From: R-devel  on behalf of J C Nash 

Sent: Thursday, March 26, 2020 10:40:05 AM
To: Martin Maechler
Cc: r-devel@r-project.org
Subject: Re: [Rd] unstable corner of parameter space for qbeta?


Despite the need to focus on pbeta, I'm still willing to put in some effort.
But I find it really helps to have 2-3 others involved, since the questions back
and forth keep matters moving forward. Volunteers?

Thanks to Martin for detailed comments.

JN


On 2020-03-26 10:34 a.m., Martin Maechler wrote:
>> J C Nash
>> on Thu, 26 Mar 2020 09:29:53 -0400 writes:
>
> > Given that a number of us are housebound, it might be a good time to 
> try to
> > improve the approximation. It's not an area where I have much 
> expertise, but in
> > looking at the qbeta.c code I see a lot of root-finding, where I do 
> have some
> > background. However, I'm very reluctant to work alone on this, and will 
> ask
> > interested others to email off-list. If there are others, I'll report 
> back.
>
> Hi John.
> Yes, qbeta() {in its "main branches"}  does zero finding, but
> zero finding of   pbeta(...) - p*   and I tried to explain in my
> last e-mail that the real problem is that already pbeta() is not
> accurate enough in some unstable corners ...
> The order fixing should typically be
> 1) fix pbeta()
> 2) look at qbeta() which now may not even need a fix because its
>problems may have been entirely a consequence of pbeta()'s inaccuracies.
>And if there are cases where the qbeta() problems are not
>only pbeta's "fault", it is still true that the fixes that
>would still be needed crucially depend on the detailed
>working of the function whose zero(s) are sought, i.e.,  pbeta()
>
> > Ben: Do you have an idea of parameter region where approximation is 
> poor?
> > I think that it would be smart to focus on that to start with.
>
> 
>
> Rmpfr  matrix-/vector - products:
>
> > Martin: On a separate precision matter, did you get my query early in 
> year about double
> > length accumulation of inner products of vectors in Rmpfr? R-help more 
> or
> > less implied that Rmpfr does NOT use extra length. I've been using David
> > Smith's FM Fortran where the DOT_PRODUCT does use double length, but it
> > would be nice to have that in R. My attempts to find "easy" workarounds 
> have
> > not been successful, but I'll admit that other things took precedence.
>
> Well, the current development version of 'Rmpfr' on R-forge now
> contains facilities to enlarge the precision of the computations
> by a factor 'fPrec' with default 'fPrec = 1';
> notably, instead of  x %*% y   (where the `%*%` cannot have more
> than two arguments) does have a counterpart  matmult(x,y, )
> which allows more arguments, namely 'fPrec', or directly 'precBits';
> and of course there are  crossprod() and tcrossprod() one should
> use when applicable and they also got the  'fPrec' and
> 'precBits' arguments.
>
> {The %*% etc precision increase still does not work optimally
>  efficiency wise, as it simply increases the precision of all
>  computations by just increasing the precision of x and y (the inputs)}.
>
> The whole  Matrix and Matrix-vector arithmetic is still
> comparibly slow in Rmpfr .. mostly because I valued human time
> (mine!) much higher than computer time in its implementation.
> That's one reason I would never want to double the precision
> everywhere as it decreases speed even more, and often times
> unnecessarily: doubling the accuracy is basically "worst-case
> scenario" precaution
>
> Martin
>

__
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

Re: [Rd] unstable corner of parameter space for qbeta?

[J C Nash]

Despite the need to focus on pbeta, I'm still willing to put in some effort.
But I find it really helps to have 2-3 others involved, since the questions back
and forth keep matters moving forward. Volunteers?

Thanks to Martin for detailed comments.

JN


On 2020-03-26 10:34 a.m., Martin Maechler wrote:
>> J C Nash 
>> on Thu, 26 Mar 2020 09:29:53 -0400 writes:
> 
> > Given that a number of us are housebound, it might be a good time to 
> try to
> > improve the approximation. It's not an area where I have much 
> expertise, but in
> > looking at the qbeta.c code I see a lot of root-finding, where I do 
> have some
> > background. However, I'm very reluctant to work alone on this, and will 
> ask
> > interested others to email off-list. If there are others, I'll report 
> back.
> 
> Hi John.
> Yes, qbeta() {in its "main branches"}  does zero finding, but
> zero finding of   pbeta(...) - p*   and I tried to explain in my
> last e-mail that the real problem is that already pbeta() is not
> accurate enough in some unstable corners ...
> The order fixing should typically be
> 1) fix pbeta()
> 2) look at qbeta() which now may not even need a fix because its
>problems may have been entirely a consequence of pbeta()'s inaccuracies.
>And if there are cases where the qbeta() problems are not
>only pbeta's "fault", it is still true that the fixes that
>would still be needed crucially depend on the detailed
>working of the function whose zero(s) are sought, i.e.,  pbeta()
> 
> > Ben: Do you have an idea of parameter region where approximation is 
> poor?
> > I think that it would be smart to focus on that to start with.
> 
> 
> 
> Rmpfr  matrix-/vector - products:
> 
> > Martin: On a separate precision matter, did you get my query early in 
> year about double
> > length accumulation of inner products of vectors in Rmpfr? R-help more 
> or
> > less implied that Rmpfr does NOT use extra length. I've been using David
> > Smith's FM Fortran where the DOT_PRODUCT does use double length, but it
> > would be nice to have that in R. My attempts to find "easy" workarounds 
> have
> > not been successful, but I'll admit that other things took precedence.
> 
> Well, the current development version of 'Rmpfr' on R-forge now
> contains facilities to enlarge the precision of the computations
> by a factor 'fPrec' with default 'fPrec = 1';
> notably, instead of  x %*% y   (where the `%*%` cannot have more
> than two arguments) does have a counterpart  matmult(x,y, )
> which allows more arguments, namely 'fPrec', or directly 'precBits';
> and of course there are  crossprod() and tcrossprod() one should
> use when applicable and they also got the  'fPrec' and
> 'precBits' arguments.
> 
> {The %*% etc precision increase still does not work optimally
>  efficiency wise, as it simply increases the precision of all
>  computations by just increasing the precision of x and y (the inputs)}.
> 
> The whole  Matrix and Matrix-vector arithmetic is still
> comparibly slow in Rmpfr .. mostly because I valued human time
> (mine!) much higher than computer time in its implementation.
> That's one reason I would never want to double the precision
> everywhere as it decreases speed even more, and often times
> unnecessarily: doubling the accuracy is basically "worst-case
> scenario" precaution
> 
> Martin
>

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

Re: [Rd] unstable corner of parameter space for qbeta?

[Martin Maechler]

> J C Nash 
> on Thu, 26 Mar 2020 09:29:53 -0400 writes:

> Given that a number of us are housebound, it might be a good time to try 
to
> improve the approximation. It's not an area where I have much expertise, 
but in
> looking at the qbeta.c code I see a lot of root-finding, where I do have 
some
> background. However, I'm very reluctant to work alone on this, and will 
ask
> interested others to email off-list. If there are others, I'll report 
back.

Hi John.
Yes, qbeta() {in its "main branches"}  does zero finding, but
zero finding of   pbeta(...) - p*   and I tried to explain in my
last e-mail that the real problem is that already pbeta() is not
accurate enough in some unstable corners ...
The order fixing should typically be
1) fix pbeta()
2) look at qbeta() which now may not even need a fix because its
   problems may have been entirely a consequence of pbeta()'s inaccuracies.
   And if there are cases where the qbeta() problems are not
   only pbeta's "fault", it is still true that the fixes that
   would still be needed crucially depend on the detailed
   working of the function whose zero(s) are sought, i.e.,  pbeta()

> Ben: Do you have an idea of parameter region where approximation is poor?
> I think that it would be smart to focus on that to start with.



Rmpfr  matrix-/vector - products:

> Martin: On a separate precision matter, did you get my query early in 
year about double
> length accumulation of inner products of vectors in Rmpfr? R-help more or
> less implied that Rmpfr does NOT use extra length. I've been using David
> Smith's FM Fortran where the DOT_PRODUCT does use double length, but it
> would be nice to have that in R. My attempts to find "easy" workarounds 
have
> not been successful, but I'll admit that other things took precedence.

Well, the current development version of 'Rmpfr' on R-forge now
contains facilities to enlarge the precision of the computations
by a factor 'fPrec' with default 'fPrec = 1';
notably, instead of  x %*% y   (where the `%*%` cannot have more
than two arguments) does have a counterpart  matmult(x,y, )
which allows more arguments, namely 'fPrec', or directly 'precBits';
and of course there are  crossprod() and tcrossprod() one should
use when applicable and they also got the  'fPrec' and
'precBits' arguments.

{The %*% etc precision increase still does not work optimally
 efficiency wise, as it simply increases the precision of all
 computations by just increasing the precision of x and y (the inputs)}.

The whole  Matrix and Matrix-vector arithmetic is still
comparibly slow in Rmpfr .. mostly because I valued human time
(mine!) much higher than computer time in its implementation.
That's one reason I would never want to double the precision
everywhere as it decreases speed even more, and often times
unnecessarily: doubling the accuracy is basically "worst-case
scenario" precaution

Martin

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

Re: [Bioc-devel] New package function question

[Martin Morgan]

usually it is considered very bad practice to simply copy code between packages 
-- any bug-fixes or changes in behavior in the up-stream package are not 
reflected in the copied code, and 'bit rot' eventually settles in, where the 
copied code is no longer functioning correctly.

It is much better to adapt your code to use the _public_ functionality exposed 
by the original package.

I know this doesn't answer your question the way you were wanting...

Martin

On 3/26/20, 10:08 AM, "Bioc-devel on behalf of ELENI ADAM" 
 wrote:

Hello,

I am creating a new package that I would like to submit to Bioconductor.
It's essentially a C code, which is called by R (using Rcpp).

One of the C functions within my package, is the C code of the R optimize
function (obtained from a C file of the folder:
R-3.6.1\src\library\stats\src\optimize.c), but slightly modified.

At the top of the R-3.6.1\src\library\stats\src\optimize.c file it states
that:
"This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version."

I am just not entirely certain if my package is allowed to contain this
slightly modified C code of the R function?
And if yes, should I place the aforementioned phrase "This program is free
software..." in comments above the specific function?

Thank you in advance,
Eleni

[[alternative HTML version deleted]]

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

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

[Bioc-devel] Drosophila virilis BioPackage forthcoming?

[Ilkka Havukkala]

Hello there
Is it possible to get Drosophila virilis genome as a BSGenome data package?
e.g. this one
https://metazoa.ensembl.org/Drosophila_virilis/Info/Annotation/

Like to do genome analysis/comparison in BioConductor to another species
which is closely related, but further from Drosophila melanogaster etc.

Kind regards
Ilkka Havukkala
New Zealand

[[alternative HTML version deleted]]

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

[Bioc-devel] New package function question

[ELENI ADAM]

Hello,

I am creating a new package that I would like to submit to Bioconductor.
It's essentially a C code, which is called by R (using Rcpp).

One of the C functions within my package, is the C code of the R optimize
function (obtained from a C file of the folder:
R-3.6.1\src\library\stats\src\optimize.c), but slightly modified.

At the top of the R-3.6.1\src\library\stats\src\optimize.c file it states
that:
"This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version."

I am just not entirely certain if my package is allowed to contain this
slightly modified C code of the R function?
And if yes, should I place the aforementioned phrase "This program is free
software..." in comments above the specific function?

Thank you in advance,
Eleni

[[alternative HTML version deleted]]

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

Re: [Rd] unstable corner of parameter space for qbeta?

[J C Nash]

Given that a number of us are housebound, it might be a good time to try to
improve the approximation. It's not an area where I have much expertise, but in
looking at the qbeta.c code I see a lot of root-finding, where I do have some
background. However, I'm very reluctant to work alone on this, and will ask
interested others to email off-list. If there are others, I'll report back.

Ben: Do you have an idea of parameter region where approximation is poor?
I think that it would be smart to focus on that to start with.

Martin: On a separate precision matter, did you get my query early in year 
about double
length accumulation of inner products of vectors in Rmpfr? R-help more or
less implied that Rmpfr does NOT use extra length. I've been using David
Smith's FM Fortran where the DOT_PRODUCT does use double length, but it
would be nice to have that in R. My attempts to find "easy" workarounds have
not been successful, but I'll admit that other things took precedence.

Best,

John Nash



On 2020-03-26 4:02 a.m., Martin Maechler wrote:
>> Ben Bolker 
>> on Wed, 25 Mar 2020 21:09:16 -0400 writes:
> 
> > I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
> > since there's a clear warning about lack of convergence of the numerical
> > algorithm ("full precision may not have been achieved").  I can work
> > around this, but I'm curious why it happens and whether there's a better
> > workaround -- it doesn't seem to be in a particularly extreme corner of
> > parameter space. It happens, e.g., for  these parameters:
> 
> > phi <- 1.1
> > i <- 0.01
> > t <- 0.001
> > shape1 = i/phi  ##  0.009090909
> > shape2 = (1-i)/phi  ## 0.9
> > qbeta(t,shape1,shape2)  ##  5.562685e-309
> > ##  brute-force uniroot() version, see below
> > Qbeta0(t,shape1,shape2)  ## 0.9262824
> 
> > The qbeta code is pretty scary to read: the warning "full precision
> > may not have been achieved" is triggered here:
> 
> > 
> https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530
> 
> > Any thoughts?
> 
> Well,  qbeta() is mostly based on inverting pbeta()  and pbeta()
> has *several* "dangerous" corners in its parameter spaces
> {in some cases, it makes sense to look at the 4 different cases
>  log.p = TRUE/FALSE  //  lower.tail = TRUE/FALSE  separately ..}
> 
> pbeta() itself is based on the most complex numerical code in
> all of base R, i.e., src/nmath/toms708.c  and that algorithm
> (TOMS 708) had been sophisticated already when it was published,
> and it has been improved and tweaked several times since being
> part of R, notably for the log.p=TRUE case which had not been in
> the focus of the publication and its algorithm.
> [[ NB: part of this you can read when reading  help(pbeta)  to the end ! ]]
> 
> I've spent many "man weeks", or even "man months" on pbeta() and
> qbeta(), already and have dreamed to get a good student do a
> master's thesis about the problem and potential solutions I've
> looked into in the mean time.
> 
> My current gut feeling is that in some cases, new approximations
> are necessary (i.e. tweaking of current approximations is not
> going to help sufficiently).
> 
> Also not (in the R sources)  tests/p-qbeta-strict-tst.R
> a whole file of "regression tests" about  pbeta() and qbeta()
> {where part of the true values have been computed with my CRAN
> package Rmpfr (for high precision computation) with the
> Rmpfr::pbetaI() function which gives arbitrarily precise pbeta()
> values but only when  (a,b) are integers -- that's the "I" in pbetaI().
> 
> Yes, it's intriguing ... and I'll look into your special
> findings a bit later today.
> 
> 
>   > Should I report this on the bug list?
> 
> Yes, please.  Not all problem of pbeta() / qbeta() are part yet,
> of R's bugzilla data base,  and maybe this will help to draw
> more good applied mathematicians look into it.
> 
> 
> 
> Martin Maechler
> ETH Zurich and R Core team
> (I'd call myself the "dpq-hacker" within R core -- related to
>  my CRAN package 'DPQ')
> 
> 
> > A more general illustration:
> > http://www.math.mcmaster.ca/bolker/misc/qbeta.png
> 
> > ===
> > fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
> > f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
> > }
> > ## brute-force beta quantile function
> > Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
> > fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
> > uniroot(fn,interval=c(0,1))$root
> > }
> > Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
> > curve(fun,from=1,to=4)
> > curve(fun(x,f=Qbeta),add=TRUE,col=2)
> 
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> 

Re: [Bioc-devel] Bioconductor package IMMAN

[Shepherd, Lori]

I do see changes on our git server from today March 26 th so maybe this has 
been resolved?


But generally that means you need to do a
fetch --all   # gets all branches from remotes
and do a
git pull upstream master   # this gets any changes from the upstream remote 
master branch

It is always recommended to do a git pull upstream master  (and a git pull 
origin master # from your repo)  before making any code changes to ensure that 
the code you are working on is the most recent.
Occasionally the core team may make changes to the upstream repository and 
these changes would need to be included (and example is at release time when we 
bump the version number of all packages).

So a general workflow for the devel branch:

git fetch --all
git pull
git pull upstream master

# make code changes
# including a version bump

git commit -a
git push
git push upstream master

Hope this helps
Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: minoo ashtiani 
Sent: Thursday, March 26, 2020 5:27 AM
To: Shepherd, Lori ; bioc-devel@r-project.org 

Subject: Re: Bioconductor package IMMAN

Dear Lori,

Thanks for your help. I went according to your advice but I permanently get 
error in the upstream mode, here is the output:

mintty screen dump

Minoo@DESKTOP-PGH7233 MINGW64 ~/Desktop/IMMAN (master)
$ git push origin master
git Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 417 bytes | 139.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0)
To git.bioconductor.org:packages/IMMAN.git
   01a56eb..57f5adc  master -> master

Minoo@DESKTOP-PGH7233 MINGW64 ~/Desktop/IMMAN (master)
$ git push upstream master
To https://github.com/Minoo-ASTY/IMMAN.git
 ! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/Minoo-ASTY/IMMAN.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

and this is the output of pull command:
mintty screen dump

$ git pull upstream master
>From https://github.com/Minoo-ASTY/IMMAN
 * branchmaster -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Fix Version number in IMMAN pre-release
Using index info to reconstruct a base tree...
M   DESCRIPTION
Falling back to patching base and 3-way merge...
Auto-merging DESCRIPTION
CONFLICT (content): Merge conflict in DESCRIPTION
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 Fix Version number in IMMAN pre-release
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort"
.

Minoo@DESKTOP-PGH7233 MINGW64 ~/Desktop/IMMAN (master|REBASE 1/11)
$ git am --show-current-patch
commit 02b172ed888e9b4f6f827a791d4bd5ca8f3ed0f6
Author: Nitesh Turaga
Date:   Wed May 1 15:19:21 2019 -0400

Fix Version number in IMMAN pre-release

1.3.02 to 1.3.2

diff --git a/DESCRIPTION b/DESCRIPTION
index ece16fe..a2bfc10 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -1,6 +1,6 @@
 Package: IMMAN
 Title: Interlog protein network reconstruction by Mapping and Mining ANalysis
-Version: 1.3.02
+Version: 1.3.2
 Description: Reconstructing Interlog Protein Network (IPN) integrated from seve
ral
  Protein protein Interaction Networks (PPINs). Using this package,
  overlaying different PPINs to mine conserved common networks betwe
en diverse


I am unable to fix it. I tried everything. I don't know what else should I do. 
Any help would be appreciated.

Thanks a lot,
Minoo

On Mon, Mar 23, 2020 at 1:30 PM Shepherd, Lori 
mailto:lori.sheph...@roswellpark.org>> wrote:
I would do a

git fetch --all   # get all branches
git pull upstream master   # pulls changes from Bioconductor git server

# resolve any merge conflicts that arise.

It is good practice to always pull from origin and upstream before making any 
changes to code to make sure the code base is updated.

Let us know if you have any further trouble.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: minoo ashtiani mailto:ashtiani.mi...@gmail.com>>
Sent: Monday, March 23, 2020 6:26 AM
To: Shepherd, Lori ; 
bioc-devel@r-project.org 

Re: [Bioc-devel] Python dependency [EXT]

[Daniele Muraro]

Thank you very much for your feedback, Martin and Hervé

Our goal is to make the package available in R as well for users who are more 
familiar with this programming language. Python would run behind the scenes, as 
kindly suggested by Hervé; basilisk seems a very good option.

Thanks again for your availability.

All the best,

Daniele


From: Martin Morgan 
Sent: 24 March 2020 19:00
To: Daniele Muraro; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Python dependency [EXT]

It's important to ask 'why Bioconductor?' with the answer partly involving 
interoperability with other Bioconductor packages and data representations 
(e.g., 
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_developers_how-2Dto_commonMethodsAndClasses_=DwIGaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=yCpxU9kUOSglCjD0f9I0mbtqYoQIuEdTmkr8GDGomoU=VIVgIcRwU_qiSw0x5ds06-YxaDcd7AlBe9fzHb4AsMA=mSXRlT-HCK_hPxX85NvYX68PuTna-LKiTo6sc-Ak9-g=
 ). There wouldn't be much value in making something that is essentially a 
python package without connection to Bioconductor available in Bioconductor.

Martin

On 3/24/20, 11:59 AM, "Bioc-devel on behalf of Daniele Muraro" 
 wrote:

To whom it may concern,

I would like to upload onto Bioconductor a package which is currently 
developed in python.
I was wondering if Bioconductor supports python dependencies or if I should 
re-program the package in R exclusively. Is calling python from R using the 
package "reticulate" acceptable for a package submission onto Bioconductor?
Thank you for your attention.

All the best,

Daniele Muraro




--
Daniele Muraro

Computational Biologist - Staff Scientist

Wellcome Sanger Institute

Wellcome Genome Campus

Hinxton, Cambridgeshire

CB10 1SA, UK

Phone (direct) +44 (0)1223 494766

Phone (reception) +44 (0)1223 834244

e-mail: daniele.mur...@sanger.ac.uk


Sanger profile:

https://www.sanger.ac.uk/people/directory/muraro-daniele


LinkedIn profile:


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_daniele-2Dmuraro-2Da3557630_=DwIGaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=yCpxU9kUOSglCjD0f9I0mbtqYoQIuEdTmkr8GDGomoU=VIVgIcRwU_qiSw0x5ds06-YxaDcd7AlBe9fzHb4AsMA=_aj1ROic3SOfNY6CEgG2qOxyELDBtHATsLlVtH1TPK0=




--
 The Wellcome Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.



 [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=yCpxU9kUOSglCjD0f9I0mbtqYoQIuEdTmkr8GDGomoU=VIVgIcRwU_qiSw0x5ds06-YxaDcd7AlBe9fzHb4AsMA=Gs8rgYxWqJXnICuy-R6HDxnU4ENO4YsfG7NhxjPXwBQ=




-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Bioconductor package IMMAN

[minoo ashtiani]

Dear Lori,

Thanks for your help. I went according to your advice but I permanently get
error in the upstream mode, here is the output:

mintty screen dump

Minoo@DESKTOP-PGH7233 MINGW64 ~/Desktop/IMMAN (master)
 $ git push origin master
  git Enumerating objects: 9, done.
   Counting objects: 100% (9/9), done.
Delta compression using up to 4
threads Compressing objects:
100% (4/4), done.  Writing
objects: 100% (5/5), 417 bytes | 139.00 KiB/s, done.
 Total 5 (delta 3), reused 0 (delta 0)
  To git.bioconductor.org:packages/IMMAN.git
  01a56eb..57f5adc  master -> master

 Minoo@DESKTOP-PGH7233 MINGW64
~/Desktop/IMMAN (master)  $ git push upstream
master  To
https://github.com/Minoo-ASTY/IMMAN.git
   ! [rejected]master -> master (non-fast-forward)
   error: failed to push some refs to
'https://github.com/Minoo-ASTY/IMMAN.git'hint: Updates were
rejected because the tip of your current branch is behindhint: its
remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
 hint: See the 'Note about fast-forwards' in 'git push --help'
for details.


and this is the output of pull command:
mintty screen dump

$ git pull upstream master
 From https://github.com/Minoo-ASTY/IMMAN
   * branchmaster -> FETCH_HEAD
   First, rewinding head to replay your work
on top of it...   Applying: Fix Version number in
IMMAN pre-release   Using index info to
reconstruct a base tree...  M
DESCRIPTION
 Falling back to patching base and 3-way merge...
  Auto-merging DESCRIPTION
   CONFLICT (content): Merge conflict in DESCRIPTION
error: Failed to merge in the changes.
 hint: Use 'git am
--show-current-patch' to see the failed patch Patch
failed at 0001 Fix Version number in IMMAN pre-release
   Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
   You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase",
run "git rebase --abort".

  Minoo@DESKTOP-PGH7233
MINGW64 ~/Desktop/IMMAN (master|REBASE 1/11)  $ git am
--show-current-patch
commit 02b172ed888e9b4f6f827a791d4bd5ca8f3ed0f6
 Author: Nitesh Turaga  Date:
 Wed May 1 15:19:21 2019 -0400

   Fix Version number in IMMAN pre-release

 1.3.02 to 1.3.2

   diff --git
a/DESCRIPTION b/DESCRIPTION
index ece16fe..a2bfc10 100644
 --- a/DESCRIPTION
  +++ b/DESCRIPTION
   @@ -1,6 +1,6 @@
 Package: IMMAN
  Title: Interlog protein
network reconstruction by Mapping and Mining ANalysis  -Version:
1.3.02
+Version: 1.3.2
  Description: Reconstructing Interlog Protein Network (IPN)
integrated from several
   Protein protein Interaction
Networks (PPINs). Using this package,   overlaying
different PPINs to mine conserved common networks between diverse


I am unable to fix it. I tried everything. I don't know what else should I
do. Any help would be appreciated.

Thanks a lot,
Minoo

On Mon, Mar 23, 2020 at 1:30 PM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> I would do a
>
> git fetch --all   # get all branches
> git pull upstream master   # pulls changes from Bioconductor git server
>
> # resolve any merge conflicts that arise.
>
> It is good practice to always pull from origin and upstream before making
> any changes to code to make sure the code base is updated.
>
> Let us know if you have any further trouble.
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* minoo ashtiani 
> *Sent:* Monday, March 23, 2020 6:26 AM
> *To:* Shepherd, Lori ;
> bioc-devel@r-project.org 
> *Subject:* Re: Bioconductor package IMMAN
>
> Hi Lori,
>
> Thanks for the update. I edited the vignette in which the platform error
> comes from that. I updated the by using
>
>1.
>
> git push origin master
>
>2.
>
> command and it was OK, however when I wanted to run the second command
> line
>
>1.
>
>git 

Re: [Rd] unstable corner of parameter space for qbeta?

[peter dalgaard]

It's a pretty extreme case, try e.g. curve(pbeta(x, shape1, shape2), n=10001), 
and (probably -- I can't be bothered to work out the relation between beta 
shapes and F df parameters this morning...) outside what is normally 
encountered in statistical analyses. Notice though, that you have lower=FALSE 
in your Qbeta0, so you should have it in qbeta as well:

> qbeta(t,shape1,shape2, lower=FALSE)  
[1] 0.949
Warning message:
In qbeta(t, shape1, shape2, lower = FALSE) :
  full precision may not have been achieved in 'qbeta'

which of course is still wrong (I dont't think there is a problem in the other 
tail, Qbeta0(t,, lower=TRUE) returns zero. 

You can see the effect also with

curve(qbeta(x, shape1, shape2), n=10001, from=.99, to=1)

which kind of suggests one of those regime-switching bugs, where different 
methods are used for various parts of the domain, and the cross-over is not 
done quite right. 

At any rate, qbeta is one of R's very basic workhorses, so we do want it to 
work right, so by all means file a report.

-pd

> On 26 Mar 2020, at 02:09 , Ben Bolker  wrote:
> 
> 
>  I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
> since there's a clear warning about lack of convergence of the numerical
> algorithm ("full precision may not have been achieved").  I can work
> around this, but I'm curious why it happens and whether there's a better
> workaround -- it doesn't seem to be in a particularly extreme corner of
> parameter space. It happens, e.g., forthese parameters:
> 
> phi <- 1.1
> i <- 0.01
> t <- 0.001
> shape1 = i/phi  ##  0.009090909
> shape2 = (1-i)/phi  ## 0.9
> qbeta(t,shape1,shape2)  ##  5.562685e-309
> ##  brute-force uniroot() version, see below
> Qbeta0(t,shape1,shape2)  ## 0.9262824
> 
>  The qbeta code is pretty scary to read: the warning "full precision
> may not have been achieved" is triggered here:
> 
> https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530
> 
>  Any thoughts?  Should I report this on the bug list?
> 
> 
> A more general illustration:
> http://www.math.mcmaster.ca/bolker/misc/qbeta.png
> 
> ===
> fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
>  f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
> }
> ## brute-force beta quantile function
> Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
>  fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
>  uniroot(fn,interval=c(0,1))$root
> }
> Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
> curve(fun,from=1,to=4)
> curve(fun(x,f=Qbeta),add=TRUE,col=2)
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] unstable corner of parameter space for qbeta?

[Martin Maechler]

> Ben Bolker 
> on Wed, 25 Mar 2020 21:09:16 -0400 writes:

> I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
> since there's a clear warning about lack of convergence of the numerical
> algorithm ("full precision may not have been achieved").  I can work
> around this, but I'm curious why it happens and whether there's a better
> workaround -- it doesn't seem to be in a particularly extreme corner of
> parameter space. It happens, e.g., forthese parameters:

> phi <- 1.1
> i <- 0.01
> t <- 0.001
> shape1 = i/phi  ##  0.009090909
> shape2 = (1-i)/phi  ## 0.9
> qbeta(t,shape1,shape2)  ##  5.562685e-309
> ##  brute-force uniroot() version, see below
> Qbeta0(t,shape1,shape2)  ## 0.9262824

> The qbeta code is pretty scary to read: the warning "full precision
> may not have been achieved" is triggered here:

> 
https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530

> Any thoughts?

Well,  qbeta() is mostly based on inverting pbeta()  and pbeta()
has *several* "dangerous" corners in its parameter spaces
{in some cases, it makes sense to look at the 4 different cases
 log.p = TRUE/FALSE  //  lower.tail = TRUE/FALSE  separately ..}

pbeta() itself is based on the most complex numerical code in
all of base R, i.e., src/nmath/toms708.c  and that algorithm
(TOMS 708) had been sophisticated already when it was published,
and it has been improved and tweaked several times since being
part of R, notably for the log.p=TRUE case which had not been in
the focus of the publication and its algorithm.
[[ NB: part of this you can read when reading  help(pbeta)  to the end ! ]]

I've spent many "man weeks", or even "man months" on pbeta() and
qbeta(), already and have dreamed to get a good student do a
master's thesis about the problem and potential solutions I've
looked into in the mean time.

My current gut feeling is that in some cases, new approximations
are necessary (i.e. tweaking of current approximations is not
going to help sufficiently).

Also not (in the R sources)  tests/p-qbeta-strict-tst.R
a whole file of "regression tests" about  pbeta() and qbeta()
{where part of the true values have been computed with my CRAN
package Rmpfr (for high precision computation) with the
Rmpfr::pbetaI() function which gives arbitrarily precise pbeta()
values but only when  (a,b) are integers -- that's the "I" in pbetaI().

Yes, it's intriguing ... and I'll look into your special
findings a bit later today.


  > Should I report this on the bug list?

Yes, please.  Not all problem of pbeta() / qbeta() are part yet,
of R's bugzilla data base,  and maybe this will help to draw
more good applied mathematicians look into it.



Martin Maechler
ETH Zurich and R Core team
(I'd call myself the "dpq-hacker" within R core -- related to
 my CRAN package 'DPQ')


> A more general illustration:
> http://www.math.mcmaster.ca/bolker/misc/qbeta.png

> ===
> fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
> f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
> }
> ## brute-force beta quantile function
> Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
> fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
> uniroot(fn,interval=c(0,1))$root
> }
> Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
> curve(fun,from=1,to=4)
> curve(fun(x,f=Qbeta),add=TRUE,col=2)

> __
> 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: [Bioc-devel] news on tidybulk?

[stefano]

OK couple of "=" were missing.

I think I completed the upload.


Thanks a lot.

Best wishes.

*Stefano *



Stefano Mangiola | Postdoctoral fellow

Papenfuss Laboratory

The Walter Eliza Hall Institute of Medical Research

+61 (0)466452544


Il giorno gio 26 mar 2020 alle ore 18:15 stefano 
ha scritto:

> Thanks a lot for the acceptance, and the time spent on review.
>
> Although my Bioconductor and github accounts share an ssh key I still get
>
> _
>
> rstudio-2 251 % git remote add upstream g...@git.bioconductor.org:
> packages/tidybulk.git
> rstudio-2 254 % git fetch upstream
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> 
>
> Thanks for the assistance.
>
> Best wishes.
>
> *Stefano *
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
>
> Il giorno mer 25 mar 2020 alle ore 14:11 stefano <
> mangiolastef...@gmail.com> ha scritto:
>
>> Hello,
>>
>> tidybulk passed all checks now. Sorry I was waiting for a response to my
>> answer to a reviewer's question before sending updated versions, it was the
>> wrong strategy.
>>
>> Please let me know if anything else is needed.
>>
>> Best wishes.
>>
>> *Stefano *
>>
>>
>>
>> Stefano Mangiola | Postdoctoral fellow
>>
>> Papenfuss Laboratory
>>
>> The Walter Eliza Hall Institute of Medical Research
>>
>> +61 (0)466452544
>>
>>
>> Il giorno mer 25 mar 2020 alle ore 12:28 stefano <
>> mangiolastef...@gmail.com> ha scritto:
>>
>>> Hello,
>>>
>>> I have asked advise for a quite mysterious error in Windows and I have
>>> been told to wait, and I did not receive further reply. And I received a
>>> positive feedback
>>>
>>> dvantwisk  commented 13 days ago
>>> 
>>>
>>> I apologize for the wait. I've reviewed your package and found that it
>>> is excellently written. I really don't have much to add. My only question
>>> is as follows:
>>>
>>>
>>> And after replying I did not receive a reply. I have pushed an updated
>>> version. Please don't neglect this package. It is important that it will be
>>> included in this release of Bioconductor.
>>>
>>> Best wishes.
>>>
>>> *Stefano *
>>>
>>>
>>>
>>> Stefano Mangiola | Postdoctoral fellow
>>>
>>> Papenfuss Laboratory
>>>
>>> The Walter Eliza Hall Institute of Medical Research
>>>
>>> +61 (0)466452544
>>>
>>>
>>>
>>> Il giorno mar 24 mar 2020 alle ore 23:24 Vincent Carey <
>>> st...@channing.harvard.edu> ha scritto:
>>>
 I think "header says it all" may be intended ... the question is whether
 it is accepted.   since the package seems to be in error state I am not
 sure
 it can move forward at this time

 On Tue, Mar 24, 2020 at 8:22 AM Shepherd, Lori <
 lori.sheph...@roswellpark.org> wrote:

> Is there a question here? Nothing came through in the body of the
> email?
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of
> Stefano Mangiola 
> Sent: Tuesday, March 24, 2020 7:28 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] news on tidybulk?
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

 The information in this e-mail is intended only for the person to whom
 it is
 addressed. If you believe this e-mail was sent to you in error and the
 e-mail
 contains patient information, please contact the Partners Compliance 
 HelpLine
 at
 http://www.partners.org/complianceline . If the e-mail was sent to you
 in error
 but does not contain patient information, please contact the sender and
 properly
 dispose of the 

Re: [Bioc-devel] news on tidybulk?

[stefano]

Thanks a lot for the acceptance, and the time spent on review.

Although my Bioconductor and github accounts share an ssh key I still get

_

rstudio-2 251 % git remote add upstream g...@git.bioconductor.org:
packages/tidybulk.git
rstudio-2 254 % git fetch upstream
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Thanks for the assistance.

Best wishes.

*Stefano *



Stefano Mangiola | Postdoctoral fellow

Papenfuss Laboratory

The Walter Eliza Hall Institute of Medical Research

+61 (0)466452544


Il giorno mer 25 mar 2020 alle ore 14:11 stefano 
ha scritto:

> Hello,
>
> tidybulk passed all checks now. Sorry I was waiting for a response to my
> answer to a reviewer's question before sending updated versions, it was the
> wrong strategy.
>
> Please let me know if anything else is needed.
>
> Best wishes.
>
> *Stefano *
>
>
>
> Stefano Mangiola | Postdoctoral fellow
>
> Papenfuss Laboratory
>
> The Walter Eliza Hall Institute of Medical Research
>
> +61 (0)466452544
>
>
> Il giorno mer 25 mar 2020 alle ore 12:28 stefano <
> mangiolastef...@gmail.com> ha scritto:
>
>> Hello,
>>
>> I have asked advise for a quite mysterious error in Windows and I have
>> been told to wait, and I did not receive further reply. And I received a
>> positive feedback
>>
>> dvantwisk  commented 13 days ago
>> 
>>
>> I apologize for the wait. I've reviewed your package and found that it is
>> excellently written. I really don't have much to add. My only question is
>> as follows:
>>
>>
>> And after replying I did not receive a reply. I have pushed an updated
>> version. Please don't neglect this package. It is important that it will be
>> included in this release of Bioconductor.
>>
>> Best wishes.
>>
>> *Stefano *
>>
>>
>>
>> Stefano Mangiola | Postdoctoral fellow
>>
>> Papenfuss Laboratory
>>
>> The Walter Eliza Hall Institute of Medical Research
>>
>> +61 (0)466452544
>>
>>
>>
>> Il giorno mar 24 mar 2020 alle ore 23:24 Vincent Carey <
>> st...@channing.harvard.edu> ha scritto:
>>
>>> I think "header says it all" may be intended ... the question is whether
>>> it is accepted.   since the package seems to be in error state I am not
>>> sure
>>> it can move forward at this time
>>>
>>> On Tue, Mar 24, 2020 at 8:22 AM Shepherd, Lori <
>>> lori.sheph...@roswellpark.org> wrote:
>>>
 Is there a question here? Nothing came through in the body of the email?


 Lori Shepherd

 Bioconductor Core Team

 Roswell Park Comprehensive Cancer Center

 Department of Biostatistics & Bioinformatics

 Elm & Carlton Streets

 Buffalo, New York 14263

 
 From: Bioc-devel  on behalf of
 Stefano Mangiola 
 Sent: Tuesday, March 24, 2020 7:28 AM
 To: bioc-devel@r-project.org 
 Subject: [Bioc-devel] news on tidybulk?


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


 This email message may contain legally privileged and/or confidential
 information.  If you are not the intended recipient(s), or the employee or
 agent responsible for the delivery of this message to the intended
 recipient(s), you are hereby notified that any disclosure, copying,
 distribution, or use of this email message is prohibited.  If you have
 received this message in error, please notify the sender immediately by
 e-mail and delete this email message from your computer. Thank you.
 [[alternative HTML version deleted]]

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

>>>
>>> The information in this e-mail is intended only for the person to whom
>>> it is
>>> addressed. If you believe this e-mail was sent to you in error and the
>>> e-mail
>>> contains patient information, please contact the Partners Compliance 
>>> HelpLine
>>> at
>>> http://www.partners.org/complianceline . If the e-mail was sent to you
>>> in error
>>> but does not contain patient information, please contact the sender and
>>> properly
>>> dispose of the e-mail.
>>
>>

[[alternative HTML version deleted]]

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