Re: [R-pkg-devel] Regarding maGUI package error

2019-02-19 Thread dhamma pal
Hi.
Following is the check results from CRAN server, though I didn't get any
warning on my PC.

package maGUI_2.3.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/Windows/00check.log
>
Status: 1 WARNING, 1 NOTE
Debian: <
https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/Debian/00check.log
>
Status: 1 NOTE

Last released version's CRAN status: ERROR: 2
See: >

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on
the R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please
reply-all to this message and explain.

More details are given in the directory:
<
https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/
>
The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
  Maintainer: 'Dhammapal Bharne '

  New submission

  Package was archived on CRAN

  CRAN repository db overrides:
X-CRAN-Comment: Archived on 2018-11-01 as check warnings were not
  corrected despite a month's notice.

Needed change for BioC 3.8

Flavor: r-devel-windows-ix86+x86_64
Check: whether package can be installed, Result: WARNING
  Found the following significant warnings:
Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the
'BiocManager' CRAN
  See 'd:/RCompile/CRANincoming/R-devel/maGUI.Rcheck/00install.out' for
details.

Flavor: r-devel-windows-ix86+x86_64
Check: Overall checktime, Result: NOTE
  Overall checktime 11 min > 10 min


On Wed, 20 Feb 2019, 2:36 am Duncan Murdoch  On 19/02/2019 11:47 a.m., dhamma pal wrote:
> > Dear all.
> > The current version of the maGUI package is 2.2 which got errors after
> the
> > upgradation of R version.
> >
> > Therefore I was trying to submit new version 2.3 of the package but
> getting
> > warnings of the previous version of 2.2 at the CRAN incoming Precheck
> > server.
> >
> > To resolve this, Do I need to upload the corrected package with the 2.2
> > version?
> > or How to rectify the errors of the previous version the packages at the
> > CRAN repository?
> >
> > Note: The error message is that "BiocInstaller and biocLite packages are
> > depreciated. Use BiocManager instead." Therefore I have replaced these
> > packages with BiocManager package. But now It couldn't upload at CRAN
> > because of the errors in the previous version.
>
> I suspect your interpretation of the messages you've received could be
> incorrect.  Could you post a copy of it if it came by email, or a link
> if it's on a web page?
>
> One reason you may have trouble uploading a revision is that you were
> unresponsive to requests for fixes in the previous one, and your package
> has been archived:  see
>
> https://cran.r-project.org/web/packages/maGUI/index.html
>
> and
>
>
> https://cran-archive.r-project.org/web/checks/2018-11-01_check_results_maGUI.html
>
> The stuff about the Bioconductor packages is shown as warnings, but you
> also have errors.  Did you fix everything?
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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


Re: [Rd] bias issue in sample() (PR 17494)

2019-02-19 Thread Gabriel Becker
Luke,

I'm happy to help with this. Its great to see this get tackled (I've cc'ed
Kelli Ottoboni who helped flag this issue).

I can prepare a patch for the RNGkind related stuff and the doc update.

As for ???, what are your (and others') thoughts about the possibility of
a) a reproducibility API which takes either an R version (or maybe
alternatively a date) and sets the RNGkind to the default for that
version/date, and/or b) that sessionInfo be modified to capture (and
display) the RNGkind in effect.

Best,
~G


On Tue, Feb 19, 2019 at 11:52 AM Tierney, Luke 
wrote:

>
> Before the next release we really should to sort out the bias issue in
> sample() reported by Ottoboni and Stark in
> https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and
> filed aa a bug report by Duncan Murdoch at
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494.
>
> Here are two examples of bad behavior through current R-devel:
>
>  set.seed(123)
>  m <- (2/5) * 2^32
>  x <- sample(m, 100, replace = TRUE)
>  table(x %% 2, x > m / 2)
>  ##
>  ##FALSE   TRUE
>  ## 0 300620 198792
>  ## 1 200196 300392
>
>  table(sample(2/7 * 2^32, 100, replace = TRUE) %% 2)
>  ##
>  ##  0  1
>  ## 429054 570946
>
> I committed a modification to R_unif_index to address this by
> generating random bits (blocks of 16) and rejection sampling, but for
> now this is only enabled if the environment variable R_NEW_SAMPLE is
> set before the first call.
>
> Some things still needed:
>
> - someone to look over the change and see if there are any issues
> - adjustment of RNGkind to allowing the old behavior to be selected
> - make the new behavior the default
> - adjust documentation
> - ???
>
> Unfortunately I don't have enough free cycles to do this, but I can
> help if someone else can take the lead.
>
> There are two other places I found that might suffer from the same
> issue, in walker_ProbSampleReplace (pointed out bu O & S) and in
> src/nmath/wilcox.c.  Both can be addressed by using R_unif_index. I
> have done that for walker_ProbSampleReplace, but the wilcox change
> might need adjusting to support the standalone math library and I
> don't feel confident enough I'd get that right.
>
> Best,
>
> luke
>
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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


Re: [Rd] Documentation for sd (stats) + suggestion

2019-02-19 Thread Dario Strbenac
Good day,

It is implemented by the CRAN package multicon. The function is named popsd. 
But it does seem like something R should provide without creating a package 
dependency.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Bioc-devel] BioC2019 talk/workshop/scholarship submission deadline MARCH 15

2019-02-19 Thread Levi Waldron
The deadline to submit a syllabus proposing a workshop, an abstract for a
talk or poster, or a travel scholarship application to BioC2019 in New York
City is fast approaching on March 15. Will be again producing a workshop
booklet from accepted workshops (see the BioC2018 workshop booklet
 for example).
https://bioc2019.bioconductor.org/call-for-abstracts

Registration  is open, and
we've identified nearby hotels to recommend at a range of affordable prices
(see travel and accommodations
). This year is
also associated with an added one-day symposium in honor of Robert
Gentleman's 60th birthday
, providing a
chance to meet and hear from founders of R and Bioconductor.
Apologies for cross-posting (https://support.bioconductor.org/p/118159/)
but I want to make sure no one misses this deadline accidentally.

-- 
Levi Waldron
https://www.waldronlab.io
Associate Professor of BiostatisticsCUNY School of Public Health

[[alternative HTML version deleted]]

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


Re: [Rd] mle (stat4) crashing due to singular Hessian in covariance matrix calculation

2019-02-19 Thread Ben Bolker


  I don't know if this will get much response from the R developers;
they might just recommend that you protect your mle() call in a try() or
tryCatch() to stop it from breaking your loop.  Alternatively, you could
try mle2() function in the bbmle package, which started out long ago as
a slightly more flexible and robust version of stats4::mle(); I don't
remember/can't promise that it handles fits with singular Hessians, but
I'm guessing it does ...

  cheers
   Ben Bolker


On 2019-02-19 12:02 p.m., Francisco Matorras wrote:
> Hi, R developers.
> when running mle inside a loop I found a nasty behavior. From time to
> time, my model had a degenerate minimum and the loop just crashed. I
> tracked it down to "vcov <- if (length(coef)) solve(oout$hessian)" line,
> being the hessian singular.
> Note that the minimum reached was good, it just did not make sense to
> calculate the covariance matrix as the inverse of a singular Hessian. In
> my case i am just interested on the value of the log-likelihood. For my
> application, I patched it easily in a local version of mle just removing
> this call since I am not using vcov at all, but i wonder if it can be
> improved in the official release. I can imagine of two simple solutions,
> either including vcov calculation as an option or avoiding the call to
> solve if the hessian is singular (setting vcov to NA). I am willing to
> write a few lines of coded if you think it is worth.
> 
> regards
> 
> Francisco Matorras
> Instituto de Física de Cantabria
> Universidad de Cantabria
> 
> 
> __
> 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: [R-pkg-devel] Regarding maGUI package error

2019-02-19 Thread Duncan Murdoch

On 19/02/2019 11:47 a.m., dhamma pal wrote:

Dear all.
The current version of the maGUI package is 2.2 which got errors after the
upgradation of R version.

Therefore I was trying to submit new version 2.3 of the package but getting
warnings of the previous version of 2.2 at the CRAN incoming Precheck
server.

To resolve this, Do I need to upload the corrected package with the 2.2
version?
or How to rectify the errors of the previous version the packages at the
CRAN repository?

Note: The error message is that "BiocInstaller and biocLite packages are
depreciated. Use BiocManager instead." Therefore I have replaced these
packages with BiocManager package. But now It couldn't upload at CRAN
because of the errors in the previous version.


I suspect your interpretation of the messages you've received could be 
incorrect.  Could you post a copy of it if it came by email, or a link 
if it's on a web page?


One reason you may have trouble uploading a revision is that you were 
unresponsive to requests for fixes in the previous one, and your package 
has been archived:  see


https://cran.r-project.org/web/packages/maGUI/index.html

and

https://cran-archive.r-project.org/web/checks/2018-11-01_check_results_maGUI.html

The stuff about the Bioconductor packages is shown as warnings, but you 
also have errors.  Did you fix everything?


Duncan Murdoch

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


Re: [Rd] code for sum function

2019-02-19 Thread Ben Bolker


This SO question may be of interest:

https://stackoverflow.com/questions/38589705/difference-between-rs-sum-and-armadillos-accu/

  which points out that sum() isn't doing anything fancy *except* using
extended-precision registers when available.  (Using Kahan's algorithm
does come at a computational cost ...)

On 2019-02-19 2:08 p.m., William Dunlap via R-devel wrote:
> The algorithm does make a differece.  You can use Kahan's summation
> algorithm (https://en.wikipedia.org/wiki/Kahan_summation_algorithm) to
> reduce the error compared to the naive summation algorithm.  E.g., in R
> code:
> 
> naiveSum <-
> function(x) {
>s <- 0.0
>for(xi in x) s <- s + xi
>s
> }
> kahanSum <- function (x)
> {
>s <- 0.0
>c <- 0.0 # running compensation for lost low-order bits
>for(xi in x) {
>   y <- xi - c
>   t <- s + y # low-order bits of y may be lost here
>   c <- (t - s) - y
>   s <- t
>}
>s
> }
> 
>> rSum <- vapply(c(1:20,10^(2:7)), function(n) sum(rep(1/7,n)), 0)
>> rNaiveSum <- vapply(c(1:20,10^(2:7)), function(n) naiveSum(rep(1/7,n)), 0)
>> rKahanSum <- vapply(c(1:20,10^(2:7)), function(n) kahanSum(rep(1/7,n)), 0)
>>
>> table(rSum == rNaiveSum)
> 
> FALSE  TRUE
>21 5
>> table(rSum == rKahanSum)
> 
> FALSE  TRUE
> 323
> 
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> 
> 
> On Tue, Feb 19, 2019 at 10:36 AM Paul Gilbert  wrote:
> 
>> (I didn't see anyone else answer this, so ...)
>>
>> You can probably find the R code in src/main/ but I'm not sure. You are
>> talking about a very simple calculation, so it seems unlike that the
>> algorithm is the cause of the difference. I have done much more
>> complicated things and usually get machine precision comparisons. There
>> are four possibilities I can think of that could cause (small) differences.
>>
>> 0/ Your code is wrong, but that seems unlikely on such a simple
>> calculations.
>>
>> 1/ You are summing a very large number of numbers, in which case the sum
>> can become very large compared to numbers being added, then things can
>> get a bit funny.
>>
>> 2/ You are using single precision in fortran rather than double. Double
>> is needed for all floating point numbers you use!
>>
>> 3/ You have not zeroed the double precision numbers in fortran. (Some
>> compilers do not do this automatically and you have to specify it.) Then
>> if you accidentally put singles, like a constant 0.0 rather than a
>> constant 0.0D+0, into a double you will have small junk in the lower
>> precision part.
>>
>> (I am assuming you are talking about a sum of reals, not integer or
>> complex.)
>>
>> HTH,
>> Paul Gilbert
>>
>> On 2/14/19 2:08 PM, Rampal Etienne wrote:
>>> Hello,
>>>
>>> I am trying to write FORTRAN code to do the same as some R code I have.
>>> I get (small) differences when using the sum function in R. I know there
>>> are numerical routines to improve precision, but I have not been able to
>>> figure out what algorithm R is using. Does anyone know this? Or where
>>> can I find the code for the sum function?
>>>
>>> Regards,
>>>
>>> Rampal Etienne
>>>
>>> __
>>> 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
>>
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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


[Rd] patch for gregexpr(perl=TRUE)

2019-02-19 Thread Toby Hocking
Hi all,

Several people have noticed that gregexpr is very slow for large subject
strings when perl=TRUE is specified.
-
https://stackoverflow.com/questions/31216299/r-faster-gregexpr-for-very-large-strings
-
http://r.789695.n4.nabble.com/strsplit-perl-TRUE-gregexpr-perl-TRUE-very-slow-for-long-strings-td4727902.html
- https://stat.ethz.ch/pipermail/r-help/2008-October/178451.html

I figured out the issue, which is fixed by changing 1 line of code in
src/main/grep.c -- there is a strlen function call which is currently
inside of the while loop over matches, and the patch moves it before the
loop.
https://github.com/tdhock/namedCapture-article/blob/master/linear-time-gregexpr-perl.patch

I made some figures that show the quadratic time complexity before applying
the patch, and the linear time complexity after applying the patch
https://github.com/tdhock/namedCapture-article#19-feb-2019

I would have posted a bug report on bugs.r-project.org but I do not have an
account. So can an R-devel person please either (1) accept this patch, or
(2) give me an account so I can post the patch on the bug tracker?

Finally I would like to mention that Bill Dunlap noticed a similar problem
(time complexity which is quadratic in subject size) for strsplit with
perl=TRUE. My patch does NOT fix that, but I suspect that a similar fix
could be accomplished (because I see that strlen is being called in a while
loop in do_strsplit as well).

Thanks
Toby Dylan Hocking

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] mailing list sign up

2019-02-19 Thread Martin Morgan
These users have been added manually. If others have similar problems please do 
let us know (a common problem is that the confirmation email gets classified as 
'spam', but that seems not to be the case here). Martin

On 2/19/19, 2:45 PM, "Bioc-devel on behalf of Lily Wang" 
 wrote:

Dear BioC team,

Two members of my group are having problems signing up the bioc-devel
mailing list. They have received and confirmed in the confirmation email,
but still are not receiving emails.

As "Maintainer must register at the support site" is part of the
requirement for submitting new R packages to bioconductor, could you please
help us to check their status?

Their emails are
Odom, Gabriel J 
Liu, Lizhong 

Thank you!

- Lily

Lily Wang
Associate Professor
Department of Public Health Sciences
Dr. John T. Macdonald Foundation
Department of Human Genetics
Miller School of Medicine
University of Miami
-

[[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


[Rd] bias issue in sample() (PR 17494)

2019-02-19 Thread Tierney, Luke


Before the next release we really should to sort out the bias issue in
sample() reported by Ottoboni and Stark in
https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and
filed aa a bug report by Duncan Murdoch at
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494.

Here are two examples of bad behavior through current R-devel:

 set.seed(123)
 m <- (2/5) * 2^32
 x <- sample(m, 100, replace = TRUE)
 table(x %% 2, x > m / 2)
 ##
 ##FALSE   TRUE
 ## 0 300620 198792
 ## 1 200196 300392

 table(sample(2/7 * 2^32, 100, replace = TRUE) %% 2)
 ##
 ##  0  1
 ## 429054 570946

I committed a modification to R_unif_index to address this by
generating random bits (blocks of 16) and rejection sampling, but for
now this is only enabled if the environment variable R_NEW_SAMPLE is
set before the first call.

Some things still needed:

- someone to look over the change and see if there are any issues
- adjustment of RNGkind to allowing the old behavior to be selected
- make the new behavior the default
- adjust documentation
- ???

Unfortunately I don't have enough free cycles to do this, but I can
help if someone else can take the lead.

There are two other places I found that might suffer from the same
issue, in walker_ProbSampleReplace (pointed out bu O & S) and in
src/nmath/wilcox.c.  Both can be addressed by using R_unif_index. I
have done that for walker_ProbSampleReplace, but the wilcox change
might need adjusting to support the standalone math library and I
don't feel confident enough I'd get that right.

Best,

luke


-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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


[Bioc-devel] mailing list sign up

2019-02-19 Thread Lily Wang
Dear BioC team,

Two members of my group are having problems signing up the bioc-devel
mailing list. They have received and confirmed in the confirmation email,
but still are not receiving emails.

As "Maintainer must register at the support site" is part of the
requirement for submitting new R packages to bioconductor, could you please
help us to check their status?

Their emails are
Odom, Gabriel J 
Liu, Lizhong 

Thank you!

- Lily

Lily Wang
Associate Professor
Department of Public Health Sciences
Dr. John T. Macdonald Foundation
Department of Human Genetics
Miller School of Medicine
University of Miami
-

[[alternative HTML version deleted]]

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


Re: [Rd] code for sum function

2019-02-19 Thread William Dunlap via R-devel
The algorithm does make a differece.  You can use Kahan's summation
algorithm (https://en.wikipedia.org/wiki/Kahan_summation_algorithm) to
reduce the error compared to the naive summation algorithm.  E.g., in R
code:

naiveSum <-
function(x) {
   s <- 0.0
   for(xi in x) s <- s + xi
   s
}
kahanSum <- function (x)
{
   s <- 0.0
   c <- 0.0 # running compensation for lost low-order bits
   for(xi in x) {
  y <- xi - c
  t <- s + y # low-order bits of y may be lost here
  c <- (t - s) - y
  s <- t
   }
   s
}

> rSum <- vapply(c(1:20,10^(2:7)), function(n) sum(rep(1/7,n)), 0)
> rNaiveSum <- vapply(c(1:20,10^(2:7)), function(n) naiveSum(rep(1/7,n)), 0)
> rKahanSum <- vapply(c(1:20,10^(2:7)), function(n) kahanSum(rep(1/7,n)), 0)
>
> table(rSum == rNaiveSum)

FALSE  TRUE
   21 5
> table(rSum == rKahanSum)

FALSE  TRUE
323


Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Feb 19, 2019 at 10:36 AM Paul Gilbert  wrote:

> (I didn't see anyone else answer this, so ...)
>
> You can probably find the R code in src/main/ but I'm not sure. You are
> talking about a very simple calculation, so it seems unlike that the
> algorithm is the cause of the difference. I have done much more
> complicated things and usually get machine precision comparisons. There
> are four possibilities I can think of that could cause (small) differences.
>
> 0/ Your code is wrong, but that seems unlikely on such a simple
> calculations.
>
> 1/ You are summing a very large number of numbers, in which case the sum
> can become very large compared to numbers being added, then things can
> get a bit funny.
>
> 2/ You are using single precision in fortran rather than double. Double
> is needed for all floating point numbers you use!
>
> 3/ You have not zeroed the double precision numbers in fortran. (Some
> compilers do not do this automatically and you have to specify it.) Then
> if you accidentally put singles, like a constant 0.0 rather than a
> constant 0.0D+0, into a double you will have small junk in the lower
> precision part.
>
> (I am assuming you are talking about a sum of reals, not integer or
> complex.)
>
> HTH,
> Paul Gilbert
>
> On 2/14/19 2:08 PM, Rampal Etienne wrote:
> > Hello,
> >
> > I am trying to write FORTRAN code to do the same as some R code I have.
> > I get (small) differences when using the sum function in R. I know there
> > are numerical routines to improve precision, but I have not been able to
> > figure out what algorithm R is using. Does anyone know this? Or where
> > can I find the code for the sum function?
> >
> > Regards,
> >
> > Rampal Etienne
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Regarding maGUI package error

2019-02-19 Thread Yonghui Dong
Hi DHAMMAPAL,

I have asked the same question in Bioconductor support forum. 

Here is the link and the answers 
https://support.bioconductor.org/p/117793/#117796 


If your package is dependent on packages from Bioconductor, it is quite 
possible that you will encounter this warning. 
Unfortunately, until now I haven’t found a way to eliminate this warning. 

Hope people here could help.

Dong

> On 19 Feb 2019, at 18:47, dhamma pal  wrote:
> 
> Dear all.
> The current version of the maGUI package is 2.2 which got errors after the
> upgradation of R version.
> 
> Therefore I was trying to submit new version 2.3 of the package but getting
> warnings of the previous version of 2.2 at the CRAN incoming Precheck
> server.
> 
> To resolve this, Do I need to upload the corrected package with the 2.2
> version?
> or How to rectify the errors of the previous version the packages at the
> CRAN repository?
> 
> Note: The error message is that "BiocInstaller and biocLite packages are
> depreciated. Use BiocManager instead." Therefore I have replaced these
> packages with BiocManager package. But now It couldn't upload at CRAN
> because of the errors in the previous version.
> 
> 
> 
> -- 
> Best,
> 
> *DHAMMAPAL BHARNE,*
> PhD Research Scholar,
> 
> *University of Hyderabad,*
> Mobile: 91 9492274285
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel


[[alternative HTML version deleted]]

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


Re: [Rd] code for sum function

2019-02-19 Thread Paul Gilbert

(I didn't see anyone else answer this, so ...)

You can probably find the R code in src/main/ but I'm not sure. You are 
talking about a very simple calculation, so it seems unlike that the 
algorithm is the cause of the difference. I have done much more 
complicated things and usually get machine precision comparisons. There 
are four possibilities I can think of that could cause (small) differences.


0/ Your code is wrong, but that seems unlikely on such a simple 
calculations.


1/ You are summing a very large number of numbers, in which case the sum 
can become very large compared to numbers being added, then things can 
get a bit funny.


2/ You are using single precision in fortran rather than double. Double 
is needed for all floating point numbers you use!


3/ You have not zeroed the double precision numbers in fortran. (Some 
compilers do not do this automatically and you have to specify it.) Then 
if you accidentally put singles, like a constant 0.0 rather than a 
constant 0.0D+0, into a double you will have small junk in the lower 
precision part.


(I am assuming you are talking about a sum of reals, not integer or 
complex.)


HTH,
Paul Gilbert

On 2/14/19 2:08 PM, Rampal Etienne wrote:

Hello,

I am trying to write FORTRAN code to do the same as some R code I have. 
I get (small) differences when using the sum function in R. I know there 
are numerical routines to improve precision, but I have not been able to 
figure out what algorithm R is using. Does anyone know this? Or where 
can I find the code for the sum function?


Regards,

Rampal Etienne

__
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


[Rd] mle (stat4) crashing due to singular Hessian in covariance matrix calculation

2019-02-19 Thread Francisco Matorras

Hi, R developers.
when running mle inside a loop I found a nasty behavior. From time to 
time, my model had a degenerate minimum and the loop just crashed. I 
tracked it down to "vcov <- if (length(coef)) solve(oout$hessian)" line, 
being the hessian singular.
Note that the minimum reached was good, it just did not make sense to 
calculate the covariance matrix as the inverse of a singular Hessian. In 
my case i am just interested on the value of the log-likelihood. For my 
application, I patched it easily in a local version of mle just removing 
this call since I am not using vcov at all, but i wonder if it can be 
improved in the official release. I can imagine of two simple solutions, 
either including vcov calculation as an option or avoiding the call to 
solve if the hessian is singular (setting vcov to NA). I am willing to 
write a few lines of coded if you think it is worth.


regards

Francisco Matorras
Instituto de Física de Cantabria
Universidad de Cantabria

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


Re: [Bioc-devel] Merging GInteraction/GenomicInteractions ranges

2019-02-19 Thread Luke Klein
Thank you for the tip, Aaron!  I’m working on the sorting step right now.

One thing I’m not clear on is how to expand the ranges from one step to the 
next.  The way GenomicInteractions are structured, there is a Granges object 
with all possible ranges, and the GInteractions object is populated by 
reference to said interactions.

What I am going to need is a new GRanges object with the new set of (expanded) 
ranges, and a way to map the prior ranges to the new, wider range.

For your edification, I’ve included the images in this email (which is 
addressed directly to you) so that you can see what I’d written in my first 
question.

Best,

— Luke Klein
PhD Student
Department of Statistics
University of California, Riverside
lklei...@ucr.edu







> On Feb 13, 2019, at 3:34 AM, Aaron Lun 
>  wrote:
> 
> Note that your visual won't show up for many (all?) of us. Nonetheless,
> I think I know what you want to do.
> 
> Your task does not lend itself to vectorization, which makes it
> difficult to write efficient R code. It's not impossible, but it would
> be quite hard to read and debug, and your maintenance programmer will
> be cursing you somewhere down the line.
> 
> If speed is truly a concern, I would write this code in C++. This would
> probably be several lines' worth of code:
> 
> 1. Compute a pair of bin IDs for each interaction by dividing each
> anchor coordinate by the bin width and truncating the result. (You'll
> need to decide if you want to use the midpoint/start/end, etc.)
> 2. Sort the interactions by the paired bin IDs, e.g., with std::sort.
> 3. Identify each "run" of interactions with the same paired IDs.
> 4. Repeat step 1 within each run (you'll need to offset the anchor
> coordinate before dividing this time). Append the current quadrant to
> the quadrant sequence for return to R at the end of recursion.
> 
> Clear, concise, and can be slapped together in less than half an hour
> with Rcpp and C++11, if you know what you're doing.
> 
> -A
> 
> On Tue, 2019-02-12 at 11:34 -0800, Luke Klein wrote:
>> Hello.  I am planning to develop a new package which extends the
>> GenomicInteractions package.  I would like some help/advice on
>> implementing the following functionality.
>> 
>> Consider the follow GenomicInteractions object
>> 
>> GenomicInteractions object with 10 interactions and 1 metadata
>> column:
>>seqnames1   ranges1 seqnames2   ranges2 |counts
>>| 
>>[1]  chrA   1-2 ---  chrA  9-10 | 1
>>[2]  chrA   1-2 ---  chrA 15-16 | 1
>>[3]  chrA   3-4 ---  chrA   3-4 | 1
>>[4]  chrA   5-6 ---  chrA   7-8 | 1
>>[5]  chrA   5-6 ---  chrA  9-10 | 1
>>[6]  chrA   7-8 ---  chrA   7-8 | 1
>>[7]  chrA   7-8 ---  chrA 11-12 | 1
>>[8]  chrA   7-8 ---  chrA 17-18 | 1
>>[9]  chrA  9-10 ---  chrA  9-10 | 1
>>   [10]  chrA  9-10 ---  chrA 15-16 | 1
>>   ---
>>   regions: 8 ranges and 0 metadata columns
>>   seqinfo: 1 sequence from an unspecified genome; no seqlengths
>> 
>> 
>> Which is visually represented thusly
>> 
>> 
>> 
>> I would like to do the following:
>> 
>> 1) I want to group the regions into bins of WxW (in this case, W will
>> be 3), as in a quad-tree structure > 
>> dtree> with the final group being WxW (instead of 2x2).  This will
>> involve 
>>  - iteratively dividing the matrix into quadrants {upper-left
>> (0), upper-right (1), lower-left (2), lower-right(3)} .
>>  - labeling each subdivision in a new column until the final WxW
>> resolution is reached.
>>  - sorting by the columns
>> 
>> 
>> 
>> 
>> GenomicInteractions object with 10 interactions and 1 metadata
>> column:
>>seqnames1   ranges1 seqnames2   ranges2
>> |counts quad1 quad2
>>| 
>>  
>>[1]  chrA   1-2 ---  chrA  9-10 | 1   
>>0  1
>>[2]  chrA   1-2 ---  chrA 15-16 | 1   
>>1  0
>>[3]  chrA   3-4 ---  chrA   3-4 | 1   
>>0  0
>>[4]  chrA   5-6 ---  chrA   7-8 | 1   
>>0  1
>>[5]  chrA   5-6 ---  chrA  9-10 | 1   
>>0  1
>>[6]  chrA   7-8 ---  chrA   7-8 | 1   
>>0  3   
>>[7]  chrA   7-8 ---  chrA 11-12 | 1   
>>0  3
>>[8]  chrA   7-8 ---  chrA 17-18 | 1   
>>1  2
>>[9]  chrA  9-10 ---  chrA  9-10 | 1   
>>0  3
>>   [10]  chrA  9-10 ---  chrA 15-16 

[R-pkg-devel] Regarding maGUI package error

2019-02-19 Thread dhamma pal
Dear all.
The current version of the maGUI package is 2.2 which got errors after the
upgradation of R version.

Therefore I was trying to submit new version 2.3 of the package but getting
warnings of the previous version of 2.2 at the CRAN incoming Precheck
server.

To resolve this, Do I need to upload the corrected package with the 2.2
version?
or How to rectify the errors of the previous version the packages at the
CRAN repository?

Note: The error message is that "BiocInstaller and biocLite packages are
depreciated. Use BiocManager instead." Therefore I have replaced these
packages with BiocManager package. But now It couldn't upload at CRAN
because of the errors in the previous version.



-- 
Best,

*DHAMMAPAL BHARNE,*
PhD Research Scholar,

*University of Hyderabad,*
Mobile: 91 9492274285

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] How to suppress startup messages

2019-02-19 Thread Martin Morgan
I think the best / only way to do this is to convince the author that this type 
of self-promotion is not helpful in the long run --- if all maintainers did 
this then a typical R session would start with 10's of these, and each would 
have no impact.

Martin

On 2/16/19, 2:35 PM, "Bioc-devel on behalf of David Jimenez-Morales" 
 wrote:

Hi there,
Loading the bioconductor package artMS gets the following startup message:

library(artMS)

Package PerformanceAnalytics (1.5.2) loaded.
Copyright (c) 2004-2018 Peter Carl and Brian G. Peterson, GPL-2 |
GPL-3https://github.com/braverock/PerformanceAnalytics

I know that the user has the option of doing…

suppressPackageStartupMessages(library(PerformanceAnalytics))
or
suppressPackageStartupMessages(library(artMS))

But how can these messages from these dependencies (imported packages) be
suppressed? i.e., how to load artMS and prevent that message from happening
automatically?

Thanks!
David

[[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


Re: [Bioc-devel] Question about package dependency

2019-02-19 Thread Vincent Carey
put ggplot2 in Suggests:

see 1.1.3 of https://cran.r-project.org/doc/manuals/r-release/R-exts.html

The ‘Suggests’ field uses the same syntax as ‘Depends’ and lists packages
that are not necessarily needed. This includes packages used only in
examples, tests or vignettes (see Writing package vignettes
),
and packages loaded in the body of functions. E.g., suppose an example11
 from
package *foo* uses a dataset from package *bar*. Then it is not necessary
to have *bar* use *foo* unless one wants to execute all the
examples/tests/vignettes: it is useful to have *bar*, but not necessary.
Version requirements can be specified but should be checked by the code
which uses the package.

On Tue, Feb 19, 2019 at 10:02 AM Xu Ren  wrote:

> Hi everyone,
>
> I'm developing a Bioconductor package and I have a question about package
> dependency. The functions in my package do not depend on ggplot2 but I used
> ggplot2 to do some visualization in the package vignette. I'm wondering if
> I should import ggplot2 in the DESCRIPTION file. If ggplot2 is not
> imported, R CMD check will produce a note:
>
>
> * checking tests ...
>
>   Running ‘testthat.R’
>
>  OK
>
> * checking for unstated dependencies in vignettes ... NOTE
>
> 'library' or 'require' call not declared from: ‘ggplot2’
>
> * checking package vignettes in ‘inst/doc’ ... OK
>
> * checking running R code from vignettes ...
>
> If ggplot2 is imported, since it is used only in the vignette, and none of
> the function in my package depend on ggplot2, R CMD check generates another
> note:
>
> * checking loading without being on the library search path ... OK
>
> * checking dependencies in R code ... NOTE
>
> Namespace in Imports field not imported from: ‘ggplot2’
>
>   All declared Imports should be used.
>
> * checking S3 generic/method consistency ... OK
>
> * checking replacement functions ... OK
>
>
>
> So I'm wondering if ggplot2 should be imported in this case. Thank you!
>
> Sincerely,
> Xu Ren
>
> [[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 ...{{dropped:18}}

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


Re: [Bioc-devel] Question about package dependency

2019-02-19 Thread Shepherd, Lori
I believe this type of dependency belongs in the Suggests:  field of the 
DESCRIPTION file.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Xu Ren 

Sent: Tuesday, February 19, 2019 10:01:54 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Question about package dependency

Hi everyone,

I'm developing a Bioconductor package and I have a question about package
dependency. The functions in my package do not depend on ggplot2 but I used
ggplot2 to do some visualization in the package vignette. I'm wondering if
I should import ggplot2 in the DESCRIPTION file. If ggplot2 is not
imported, R CMD check will produce a note:


* checking tests ...

  Running �testthat.R�

 OK

* checking for unstated dependencies in vignettes ... NOTE

'library' or 'require' call not declared from: �ggplot2�

* checking package vignettes in �inst/doc� ... OK

* checking running R code from vignettes ...

If ggplot2 is imported, since it is used only in the vignette, and none of
the function in my package depend on ggplot2, R CMD check generates another
note:

* checking loading without being on the library search path ... OK

* checking dependencies in R code ... NOTE

Namespace in Imports field not imported from: �ggplot2�

  All declared Imports should be used.

* checking S3 generic/method consistency ... OK

* checking replacement functions ... OK



So I'm wondering if ggplot2 should be imported in this case. Thank you!

Sincerely,
Xu Ren

[[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


[Bioc-devel] Question about package dependency

2019-02-19 Thread Xu Ren
Hi everyone,

I'm developing a Bioconductor package and I have a question about package
dependency. The functions in my package do not depend on ggplot2 but I used
ggplot2 to do some visualization in the package vignette. I'm wondering if
I should import ggplot2 in the DESCRIPTION file. If ggplot2 is not
imported, R CMD check will produce a note:


* checking tests ...

  Running ‘testthat.R’

 OK

* checking for unstated dependencies in vignettes ... NOTE

'library' or 'require' call not declared from: ‘ggplot2’

* checking package vignettes in ‘inst/doc’ ... OK

* checking running R code from vignettes ...

If ggplot2 is imported, since it is used only in the vignette, and none of
the function in my package depend on ggplot2, R CMD check generates another
note:

* checking loading without being on the library search path ... OK

* checking dependencies in R code ... NOTE

Namespace in Imports field not imported from: ‘ggplot2’

  All declared Imports should be used.

* checking S3 generic/method consistency ... OK

* checking replacement functions ... OK



So I'm wondering if ggplot2 should be imported in this case. Thank you!

Sincerely,
Xu Ren

[[alternative HTML version deleted]]

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


Re: [Bioc-devel] Single Package Builder

2019-02-19 Thread Shepherd, Lori
Sorry for the inconvenience.  The Single Package Builder should be up and 
running as normal now.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin Morgan 

Sent: Monday, February 18, 2019 12:30:37 PM
To: Felix Ernst; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Single Package Builder

Issues with the SPB may persist until Tuesday morning. Martin

On 2/18/19, 5:29 AM, "Bioc-devel on behalf of Felix Ernst" 
 wrote:

Hi,



I just wanted to ask, whether the SPB is under maintenance.



After a push, the bot reports the start of a build, but the build is not
started or at least the result is not reported back to the issue on GitHub.



I hope I didn�t miss something or is the info from the 29th of January still
valid?



Best regards,

Felix



---



Felix Ernst, PhD

Universit� Libre de Bruxelles

RNA MOLECULAR BIOLOGY

BIOPARK Charleroi Brussels-South CAMPUS

Rue Profs Jeener & Brachet, 12

B-6041 Charleroi - Gosselies

BELGIUM

+32(2)650 9774 (office phone)

  felix.er...@ulb.ac.be






 [[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: [Rd] Documentation for sd (stats) + suggestion

2019-02-19 Thread S Ellison
> As far as I can tell, the manual help page for ``sd``
> 
> ?sd
> 
> does not explicitly mention that the formula for the standard deviation is
> the so-called "Bessel-corrected" formula (divide by n-1 rather than n).

See Details, where it says 
"Details:

 Like 'var' this uses denominator n - 1.
"



***
This email and any attachments are confidential. Any use...{{dropped:8}}

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


[Rd] Documentation for sd (stats) + suggestion

2019-02-19 Thread PatrickT
I cannot file suggestions on bugzilla, so writing here.

As far as I can tell, the manual help page for ``sd``

?sd

does not explicitly mention that the formula for the standard deviation is
the so-called "Bessel-corrected" formula (divide by n-1 rather than n).

I suggest it should be stated near the top.

I would also suggest (feature request!) that either

 - a population standard deviation formula, e.g. ``sdp`` or ``sd.p`` be
made available (that would be my preference)

or

 - the current ``sd`` be extended to accept a ``population=FALSE`` or
``sample=TRUE`` argument.

Same for the variance. Excel, Calc, etc. offer these.

Motivation: I encourage my students to use R rather than Python (which has
picked up big time in recent years) on the grounds that it is easier to get
started with and is specialized in statistics. But then there is no
"population" formula for the standard deviation. And ``mode`` is not the
mode they expect... (btw I suggest adding a ``modes`` function to the
core)  All things a beginner will look for in a stats software.

Thanks for listening. And thanks for the great work!

[[alternative HTML version deleted]]

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