Re: [Bioc-devel] package named spdeq causes error

[Levi Waldron]

Looking further up the list of error messages, there is a long dependency
chain ending with a missing system dependency (see below):
   * anamiR -> agricolae -> spdep -> sf -> system dependency libgdal-dev

You should be able to fix it with `apt install libgdal-dev` if you're on
Debian/Ubuntu. BTW, I figured this out on a Docker+Singularity container
and scripts I've been working on to try to make almost all of Bioconductor
installable, to make it easier to run release+devel side by side, and to
smooth the edges for people who don't feel like learning the million flags
Docker has or where their package and home directories go every time they
restart :). I'll add libgal-dev. It's early but see
https://github.com/waldronlab/bioconductor_devel if you want to try, and I
really welcome feedback on documentation or functionality.

Dependency error chain:

* installing *source* package ‘sf’ ...

** package ‘sf’ successfully unpacked and MD5 sums checked

configure: CC: gcc

configure: CXX: g++ -std=gnu++11

*checking for gdal-config... no*

*no*

*configure: error: gdal-config not found or not executable.*

*ERROR: configuration failed for package ‘sf’*

* removing ‘/usr/local/lib/R/host-site-library/sf’

* installing *source* package ‘minfi’ ...

** R

** inst

** byte-compile and prepare package for lazy loading

** help

*** installing help indices

** building package indices

** installing vignettes

** testing if installed package can be loaded

* DONE (minfi)

* installing *source* package ‘klaR’ ...

** package ‘klaR’ successfully unpacked and MD5 sums checked

** R

** data

** inst

** byte-compile and prepare package for lazy loading

** help

*** installing help indices

** building package indices

** testing if installed package can be loaded

* DONE (klaR)

*ERROR: dependency ‘sf’ is not available for package ‘spdep’*

** removing ‘/usr/local/lib/R/host-site-library/spdep’*

* installing *source* package ‘methylumi’ ...

** R

** data

** inst

** byte-compile and prepare package for lazy loading

** help

*** installing help indices

** building package indices

** installing vignettes

** testing if installed package can be loaded

* DONE (methylumi)

*ERROR: dependency ‘spdep’ is not available for package ‘agricolae’*

* removing ‘/usr/local/lib/R/host-site-library/agricolae’

* installing *source* package ‘lumi’ ...

** R

** data

** inst

** byte-compile and prepare package for lazy loading

** help

*** installing help indices

** building package indices

** installing vignettes

** testing if installed package can be loaded

* DONE (lumi)

ERROR: dependency ‘agricolae’ is not available for package ‘anamiR’

* removing ‘/usr/local/lib/R/host-site-library/anamiR’


The downloaded source packages are in

‘/tmp/RtmpOjPTFv/downloaded_packages’

Warning messages:

1: In install.packages(pkgs = doing, lib = lib, repos = repos, ...) :

  installation of package ‘sf’ had non-zero exit status

2: In install.packages(pkgs = doing, lib = lib, repos = repos, ...) :

  installation of package ‘spdep’ had non-zero exit status

3: In install.packages(pkgs = doing, lib = lib, repos = repos, ...) :

  installation of package ‘agricolae’ had non-zero exit status

4: In install.packages(pkgs = doing, lib = lib, repos = repos, ...) :

  installation of package ‘anamiR’ had non-zero exit status

> *


On Thu, Feb 21, 2019 at 11:00 PM Dario Strbenac 
wrote:

> Good day,
>
> I don't, but your software package imports agricolae which imports spdep.
> spdep is available from CRAN, so it's strange that the Bioconductor build
> server running Linux has not been able to install it.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Levi Waldron
http://www.waldronlab.io
Associate Professor of BiostatisticsCUNY School of Public Health
US: +1 646-364-9616   Skype:
levi.waldron

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] package named spdeq causes error

[Dario Strbenac]

Good day,

I don't, but your software package imports agricolae which imports spdep. spdep 
is available from CRAN, so it's strange that the Bioconductor build server 
running Linux has not been able to install it.

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

[Bioc-devel] package named spdeq causes error

[r04945002]

Hi all,

I got an error about this...

* installing to library ‘/home/biocbuild/bbs-3.8-bioc/R/library’
* installing *source* package ‘anamiR’ ...
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘spdep’
ERROR: lazy loading failed for package ‘anamiR’
* removing ‘/home/biocbuild/bbs-3.8-bioc/R/library/anamiR’
* restoring previous ‘/home/biocbuild/bbs-3.8-bioc/R/library/anamiR’

which I don't include package named 'spdeq' in my package...
Anyone got this as well?


Thanks,
Ti-Tai

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

Re: [Rd] Return/print standard error in t.test()

[Thomas J. Leeper]

Hi John,

Thanks for your reply. Of course I could write a package and of course I
would find that trivial to do. The point is this is a main entry point to R
for probably (at this point) hundreds of thousands of students. I’d like
them to be able to get a basic quantity of interest from a t-test without
four subsequent function calls.

I also don’t really see the point about the object class, given we’re
talking S3. print() doesn’t have to print everything in the object (see
e.g., print.lm() ), so there should be little harm in returning additional
information when relevant. Leaving the print() method unchanged and simply
returning the SE as an additional element should affect almost nothing.

I’m all for continuity and conservative development, but we also should aim
to make R as useful and usable as possible. This seems like a nice simple
way to do that.

Best,
Thomas


On Thu, 21 Feb 2019 at 21:51 Fox, John  wrote:

> Dear Thomas,
>
> it is, unfortunately, not that simple. t.test() returns an object of class
> "htest" and not all such objects have standard errors. I'm not entirely
> sure what the point is since it's easy to compute the standard error of the
> difference from the information in the object (adapting an example from
> ?t.test):
>
> > (res <- t.test(1:10, y = c(7:20)))
>
> Welch Two Sample t-test
>
> data:  1:10 and c(7:20)
> t = -5.4349, df = 21.982, p-value = 1.855e-05
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
>  -11.052802  -4.947198
> sample estimates:
> mean of x mean of y
>   5.5  13.5
>
> > as.vector(abs(diff(res$estimate)/res$statistic)) # SE
> [1] 1.47196
> > class(res)
> [1] "htest"
>
> and if you really want to print the SE as a matter of course, you could
> always write your own wrapper for t.test() that returns an object of class,
> say, "t.test" for which you can provide a print() method. Much of the
> advantage of working in a statistical computing environment like R (or
> Stata, for that matter) is that you can make things work the way you like.
>
> Best,
>  John
>
>   -
>   John Fox, Professor Emeritus
>   McMaster University
>   Hamilton, Ontario, Canada
>   Web: http::/socserv.mcmaster.ca/jfox
>
> > On Feb 21, 2019, at 3:57 PM, Thomas J. Leeper 
> wrote:
> >
> > A recent thread on Twitter [1] by a Stata user highlighted that t.test()
> > does not return or print the standard error of the mean difference,
> despite
> > it being calculated by the function.
> >
> > I know this isn’t the kind of change that’s likely to be made but could
> we
> > at least return the SE even if the print() method isn’t updated? Or,
> > better, update the print() method to display this as well?
> >
> > Best,
> > Thomas
> >
> > [1]
> > https://twitter.com/amandayagan/status/1098314654470819840?s=21
> > --
> >
> > Thomas J. Leeper
> > http://www.thomasleeper.com
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --

Thomas J. Leeper
http://www.thomasleeper.com

[[alternative HTML version deleted]]

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

Re: [Rd] Return/print standard error in t.test()

[Rui Barradas]

Hello,

Something like this?



t.test2 <- function(...) {
  ht <- t.test(...)
  class(ht) <- c("htest_tjl", class(ht))
  ht
}
print.htest_tjl <- function(x, ...) {
  NextMethod(x, ...)
  se <- as.vector(abs(diff(x$estimate)/x$statistic))
  cat("Standard error of the difference:", se, "\n\n")
  invisible(x)
}

t.test2(1:10, y = c(7:20))
t.test2(extra ~ group, data = sleep)  # last example from ?t.test



(The suffix tjl commes from the OP's initials.)


Hope this helps,

Rui Barradas

Às 21:51 de 21/02/2019, Fox, John escreveu:

Dear Thomas,

it is, unfortunately, not that simple. t.test() returns an object of class 
"htest" and not all such objects have standard errors. I'm not entirely sure 
what the point is since it's easy to compute the standard error of the difference from 
the information in the object (adapting an example from ?t.test):


(res <- t.test(1:10, y = c(7:20)))


Welch Two Sample t-test

data:  1:10 and c(7:20)
t = -5.4349, df = 21.982, p-value = 1.855e-05
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
  -11.052802  -4.947198
sample estimates:
mean of x mean of y
   5.5  13.5


as.vector(abs(diff(res$estimate)/res$statistic)) # SE

[1] 1.47196

class(res)

[1] "htest"

and if you really want to print the SE as a matter of course, you could always write your 
own wrapper for t.test() that returns an object of class, say, "t.test" for 
which you can provide a print() method. Much of the advantage of working in a statistical 
computing environment like R (or Stata, for that matter) is that you can make things work 
the way you like.

Best,
  John

   -
   John Fox, Professor Emeritus
   McMaster University
   Hamilton, Ontario, Canada
   Web: http::/socserv.mcmaster.ca/jfox


On Feb 21, 2019, at 3:57 PM, Thomas J. Leeper  wrote:

A recent thread on Twitter [1] by a Stata user highlighted that t.test()
does not return or print the standard error of the mean difference, despite
it being calculated by the function.

I know this isn’t the kind of change that’s likely to be made but could we
at least return the SE even if the print() method isn’t updated? Or,
better, update the print() method to display this as well?

Best,
Thomas

[1]
https://twitter.com/amandayagan/status/1098314654470819840?s=21
--

Thomas J. Leeper
http://www.thomasleeper.com

[[alternative HTML version deleted]]

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


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



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

Re: [Rd] Return/print standard error in t.test()

[Fox, John]

Dear Thomas,

it is, unfortunately, not that simple. t.test() returns an object of class 
"htest" and not all such objects have standard errors. I'm not entirely sure 
what the point is since it's easy to compute the standard error of the 
difference from the information in the object (adapting an example from 
?t.test):

> (res <- t.test(1:10, y = c(7:20)))

Welch Two Sample t-test

data:  1:10 and c(7:20)
t = -5.4349, df = 21.982, p-value = 1.855e-05
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 -11.052802  -4.947198
sample estimates:
mean of x mean of y 
  5.5  13.5 

> as.vector(abs(diff(res$estimate)/res$statistic)) # SE
[1] 1.47196
> class(res)
[1] "htest"

and if you really want to print the SE as a matter of course, you could always 
write your own wrapper for t.test() that returns an object of class, say, 
"t.test" for which you can provide a print() method. Much of the advantage of 
working in a statistical computing environment like R (or Stata, for that 
matter) is that you can make things work the way you like.

Best,
 John

  -
  John Fox, Professor Emeritus
  McMaster University
  Hamilton, Ontario, Canada
  Web: http::/socserv.mcmaster.ca/jfox

> On Feb 21, 2019, at 3:57 PM, Thomas J. Leeper  wrote:
> 
> A recent thread on Twitter [1] by a Stata user highlighted that t.test()
> does not return or print the standard error of the mean difference, despite
> it being calculated by the function.
> 
> I know this isn’t the kind of change that’s likely to be made but could we
> at least return the SE even if the print() method isn’t updated? Or,
> better, update the print() method to display this as well?
> 
> Best,
> Thomas
> 
> [1]
> https://twitter.com/amandayagan/status/1098314654470819840?s=21
> -- 
> 
> Thomas J. Leeper
> http://www.thomasleeper.com
> 
>   [[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] Return/print standard error in t.test()

[Thomas J. Leeper]

A recent thread on Twitter [1] by a Stata user highlighted that t.test()
does not return or print the standard error of the mean difference, despite
it being calculated by the function.

I know this isn’t the kind of change that’s likely to be made but could we
at least return the SE even if the print() method isn’t updated? Or,
better, update the print() method to display this as well?

Best,
Thomas

[1]
https://twitter.com/amandayagan/status/1098314654470819840?s=21
-- 

Thomas J. Leeper
http://www.thomasleeper.com

[[alternative HTML version deleted]]

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

Re: [Rd] code for sum function

[Gabriel Becker]

Hi all,

>From what I can see from my checkout of the Rsources (in src/main/summary.c
as pointed out by others) sums are calculated the "naive" way (see rsum  c
function) but  means are actually calculated something akin to the Neumaier
way (see real_mean c function).

Just an fyi.
~G

On Thu, Feb 21, 2019 at 9:03 AM Ben Bolker  wrote:

> Specifically: https://svn.r-project.org/R/trunk/src/main/summary.c
>
> And if you don't want to deal with Subversion, you can look at the
> read-only github mirror:
>
>
> https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/main/summary.c#L115-L131
>
> On Thu, Feb 21, 2019 at 11:57 AM David Winsemius 
> wrote:
> >
> >
> > On 2/20/19 2:55 PM, Rampal Etienne wrote:
> > > Dear Tomas,
> > >
> > > Where do I find these files? Do they contain the code for the sum
> function?
> >
> > Yes.
> >
> > https://svn.r-project.org/R/trunk/
> >
> >
> > David
> >
> > >
> > > What do you mean exactly with your point on long doubles? Where can I
> find
> > > documentation on this?
> > >
> > > Cheers, Rampal
> > >
> > > On Mon, Feb 18, 2019, 15:38 Tomas Kalibera  wrote:
> > >
> > >> See do_summary() in summary.c, rsum() for doubles. R uses long double
> > >> type as accumulator on systems where available.
> > >>
> > >> Best,
> > >> Tomas
> > >>
> > >> 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
> > >>
> > >>
> > >   [[alternative HTML version deleted]]
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://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] code for sum function

[Ben Bolker]

Specifically: https://svn.r-project.org/R/trunk/src/main/summary.c

And if you don't want to deal with Subversion, you can look at the
read-only github mirror:

https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/main/summary.c#L115-L131

On Thu, Feb 21, 2019 at 11:57 AM David Winsemius  wrote:
>
>
> On 2/20/19 2:55 PM, Rampal Etienne wrote:
> > Dear Tomas,
> >
> > Where do I find these files? Do they contain the code for the sum function?
>
> Yes.
>
> https://svn.r-project.org/R/trunk/
>
>
> David
>
> >
> > What do you mean exactly with your point on long doubles? Where can I find
> > documentation on this?
> >
> > Cheers, Rampal
> >
> > On Mon, Feb 18, 2019, 15:38 Tomas Kalibera  >
> >> See do_summary() in summary.c, rsum() for doubles. R uses long double
> >> type as accumulator on systems where available.
> >>
> >> Best,
> >> Tomas
> >>
> >> 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
> >>
> >>
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] code for sum function

[David Winsemius]

On 2/20/19 2:55 PM, Rampal Etienne wrote:

Dear Tomas,

Where do I find these files? Do they contain the code for the sum function?


Yes.

https://svn.r-project.org/R/trunk/


David



What do you mean exactly with your point on long doubles? Where can I find
documentation on this?

Cheers, Rampal

On Mon, Feb 18, 2019, 15:38 Tomas Kalibera 
See do_summary() in summary.c, rsum() for doubles. R uses long double
type as accumulator on systems where available.

Best,
Tomas

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




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

Re: [Rd] Bug in print.default: dispatches to global show instead of methods::show

[Martin Maechler]

> Lionel Henry 
> on Thu, 21 Feb 2019 12:27:11 +0100 writes:

> Hello,
> This is already fixed in r-devel, I think by this commit:

> 
https://github.com/wch/r-source/commit/b59a1526085d1b4375b184d35118c6fd6f003912#diff-12de104c9320556f0e99da345c6fb259
 


> Best,
> Lionel

Yes, indeed... part of patches that Lionel had proposed himself!

Best,
Martin

>> On 21 Feb 2019, at 00:07, Dean Attali  wrote:
>> 
>> This is related to a problem that was fixed in 2015
>> 
https://github.com/wch/r-source/commit/38ea40dcd0353af16d35296ee621338c49ae48c9
>> The problem then was that auto-printing by typing an object to the 
console
>> would search for show() in the globalenv instead of in the methods
>> namespace.
>> 
>> The problem I would like to report is that it seems that when an S4 
object
>> is printed with print(), a similar issue happens. I do realize that S4
>> objects should be printed with show() rather than print(), which would
>> solve the issue, but this still seems like a bug to me.
>> 
>> Example:
>> 
>> library(methods)
>> show <- function(...) message("hijacked!")
>> setClass("Test", representation(test = "character"))
>> test <- new("Test")
>> print(test)
>> # hijacked!
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> 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] Proposed patch for ?Extract

[Marc Schwartz via R-devel]

Hi,

In follow up to the thread on R-Help yesterday:

  https://stat.ethz.ch/pipermail/r-help/2019-February/461725.html

I am attaching a proposed patch against the trunk version of Extract.Rd, with 
wording added to the "Matrices and arrays" section, to note that indexing these 
object by factors behaves in a manner consistent with vectors.

Regards,

Marc Schwartz

--- ExtractORIG.Rd  2019-02-21 08:17:47.0 -0500
+++ ExtractMOD.Rd   2019-02-21 08:23:35.0 -0500
@@ -151,6 +151,9 @@
   indices can be numeric, logical, character, empty or even factor.
   An empty index (a comma separated blank) indicates that all entries in
   that dimension are selected.
+  As with vectors, indexing by factors is equivalent to indexing by the
+  numeric codes (see \code{\link{factor}}) and not by the character
+  values which are printed (for which use \code{[as.character(i)]}).
   The argument \code{drop} applies to this form of indexing.
 
   A third form of indexing is via a numeric matrix with the one column


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

Re: [Rd] model.matrix.default() silently ignores bad contrasts.arg

[Ben Bolker]

On Thu, Feb 21, 2019 at 7:49 AM Fox, John  wrote:
>
> Dear Ben,
>
> Perhaps I'm missing the point, but contrasts.arg is documented to be a list. 
> From ?model.matrix: "contrasts.arg: A list, whose entries are values (numeric 
> matrices or character strings naming functions) to be used as replacement 
> values for the contrasts replacement function and whose names are the names 
> of columns of data containing factors."

  I absolutely agree that this is not a bug/behaves as documented (I
could have said that more clearly).  It's just that (for reasons I
attempted to explain) this is a really easy mistake to make.

> This isn't entirely accurate because a function also works as a named element 
> of the list (in addition to a character string naming a function and a 
> contrast matrix), as your example demonstrates, but nowhere that I'm aware of 
> is it suggested that a non-list should work.
>
> It certainly would be an improvement if specifying contrast.arg as a non-list 
> generated an error or warning message, and it at least arguably would be 
> convenient to allow a general contrast specification such as 
> contrasts.arg-"contr.sum", but I don't see a bug here.

  I agree.  That's what my patch does (throws a warning message if
contrasts.arg is non-NULL and not a list).

  cheers
   Ben Bolker



>
> Best,
>  John
>
>   -
>   John Fox, Professor Emeritus
>   McMaster University
>   Hamilton, Ontario, Canada
>   Web: http::/socserv.mcmaster.ca/jfox
>
> > On Feb 20, 2019, at 7:14 PM, Ben Bolker  wrote:
> >
> > An lme4 user pointed out  that
> > passing contrasts as a string or symbol to [g]lmer (which would work if
> > we were using `contrasts<-` to set contrasts on a factor variable) is
> > *silently ignored*. This goes back to model.matrix(), and seems bad
> > (this is a very easy mistake to make, because of the multitude of ways
> > to specify contrasts for factors in R  - e.g. options(contrasts=...);
> > setting contrasts on the specific factors; passing contrasts as a list
> > to the model function ... )
> >
> > The relevant code is here:
> >
> > https://github.com/wch/r-source/blob/trunk/src/library/stats/R/models.R#L578-L603
> >
> > The following code shows the problem: a plain-vanilla model.matrix()
> > call with no contrasts argument, followed by two wrong contrasts
> > arguments, followed by a correct contrasts argument.
> >
> > data(cbpp, package="lme4")
> > mf1 <- model.matrix(~period, data=cbpp)
> > mf2 <- model.matrix(~period, contrasts.arg="contr.sum", data=cbpp)
> > all.equal(mf1,mf2) ## TRUE
> > mf3 <- model.matrix(~period, contrasts.arg=contr.sum, data=cbpp)
> > all.equal(mf1,mf3)  ## TRUE
> > mf4 <- model.matrix(~period, contrasts.arg=list(period=contr.sum),
> > data=cbpp)
> > isTRUE(all.equal(mf1,mf4))  ## FALSE
> >
> >
> >  I've attached a potential patch for this, which is IMO the mildest
> > possible case (if contrasts.arg is non-NULL and not a list, it produces
> > a warning).  I haven't been able to test it because of some mysterious
> > issues I'm having with re-making R properly ...
> >
> >  Thoughts?  Should I submit this as a bug report/patch?
> >
> >  cheers
> >   Ben Bolker
> >
> >
> > __
> > 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] code for sum function

[Rampal Etienne]

Dear Will,

This is exactly what I find.
My point is thus that the sum function in R is not a naive sum nor a
Kahansum (in all cases), but what algorithm is it using then?

Cheers, Rampal


On Tue, Feb 19, 2019, 19:08 William Dunlap  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: [Rd] code for sum function

[Rampal Etienne]

Dear Paul,

Thank you for thinking with me. I will respond to your options:

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

It's really just a comparison of the sum function in Fortran with that of
R. If instead I use the naive summation with a for loop in both languages I
get the same answer.

>
> 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.
>
Yes, this is what's happening and why I need to know what algorithm R uses
to overcome or reduce these precision issues.

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

>
> 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.
>
It doesn't matter if I double them in this way or not (they are declared as
doubles and I think the compiler treats then as doubles).

So my question remains what algorithm R uses.

Cheers, Rampal

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

[[alternative HTML version deleted]]

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

Re: [Rd] code for sum function

[Rampal Etienne]

Dear Tomas,

Where do I find these files? Do they contain the code for the sum function?

What do you mean exactly with your point on long doubles? Where can I find
documentation on this?

Cheers, Rampal

On Mon, Feb 18, 2019, 15:38 Tomas Kalibera  See do_summary() in summary.c, rsum() for doubles. R uses long double
> type as accumulator on systems where available.
>
> Best,
> Tomas
>
> 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
>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] model.matrix.default() silently ignores bad contrasts.arg

[Fox, John]

Dear Ben,

Perhaps I'm missing the point, but contrasts.arg is documented to be a list. 
From ?model.matrix: "contrasts.arg: A list, whose entries are values (numeric 
matrices or character strings naming functions) to be used as replacement 
values for the contrasts replacement function and whose names are the names of 
columns of data containing factors." 

This isn't entirely accurate because a function also works as a named element 
of the list (in addition to a character string naming a function and a contrast 
matrix), as your example demonstrates, but nowhere that I'm aware of is it 
suggested that a non-list should work.

It certainly would be an improvement if specifying contrast.arg as a non-list 
generated an error or warning message, and it at least arguably would be 
convenient to allow a general contrast specification such as 
contrasts.arg-"contr.sum", but I don't see a bug here.

Best,
 John

  -
  John Fox, Professor Emeritus
  McMaster University
  Hamilton, Ontario, Canada
  Web: http::/socserv.mcmaster.ca/jfox

> On Feb 20, 2019, at 7:14 PM, Ben Bolker  wrote:
> 
> An lme4 user pointed out  that
> passing contrasts as a string or symbol to [g]lmer (which would work if
> we were using `contrasts<-` to set contrasts on a factor variable) is
> *silently ignored*. This goes back to model.matrix(), and seems bad
> (this is a very easy mistake to make, because of the multitude of ways
> to specify contrasts for factors in R  - e.g. options(contrasts=...);
> setting contrasts on the specific factors; passing contrasts as a list
> to the model function ... )
> 
> The relevant code is here:
> 
> https://github.com/wch/r-source/blob/trunk/src/library/stats/R/models.R#L578-L603
> 
> The following code shows the problem: a plain-vanilla model.matrix()
> call with no contrasts argument, followed by two wrong contrasts
> arguments, followed by a correct contrasts argument.
> 
> data(cbpp, package="lme4")
> mf1 <- model.matrix(~period, data=cbpp)
> mf2 <- model.matrix(~period, contrasts.arg="contr.sum", data=cbpp)
> all.equal(mf1,mf2) ## TRUE
> mf3 <- model.matrix(~period, contrasts.arg=contr.sum, data=cbpp)
> all.equal(mf1,mf3)  ## TRUE
> mf4 <- model.matrix(~period, contrasts.arg=list(period=contr.sum),
> data=cbpp)
> isTRUE(all.equal(mf1,mf4))  ## FALSE
> 
> 
>  I've attached a potential patch for this, which is IMO the mildest
> possible case (if contrasts.arg is non-NULL and not a list, it produces
> a warning).  I haven't been able to test it because of some mysterious
> issues I'm having with re-making R properly ...
> 
>  Thoughts?  Should I submit this as a bug report/patch?
> 
>  cheers
>   Ben Bolker
> 
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Bug in print.default: dispatches to global show instead of methods::show

[Lionel Henry]

Hello,

This is already fixed in r-devel, I think by this commit:

https://github.com/wch/r-source/commit/b59a1526085d1b4375b184d35118c6fd6f003912#diff-12de104c9320556f0e99da345c6fb259
 


Best,
Lionel

> On 21 Feb 2019, at 00:07, Dean Attali  wrote:
> 
> This is related to a problem that was fixed in 2015
> https://github.com/wch/r-source/commit/38ea40dcd0353af16d35296ee621338c49ae48c9
> The problem then was that auto-printing by typing an object to the console
> would search for show() in the globalenv instead of in the methods
> namespace.
> 
> The problem I would like to report is that it seems that when an S4 object
> is printed with print(), a similar issue happens. I do realize that S4
> objects should be printed with show() rather than print(), which would
> solve the issue, but this still seems like a bug to me.
> 
> Example:
> 
> library(methods)
> show <- function(...) message("hijacked!")
> setClass("Test", representation(test = "character"))
> test <- new("Test")
> print(test)
> # hijacked!
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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

[Rd] Bug in print.default: dispatches to global show instead of methods::show

[Dean Attali]

This is related to a problem that was fixed in 2015
https://github.com/wch/r-source/commit/38ea40dcd0353af16d35296ee621338c49ae48c9
The problem then was that auto-printing by typing an object to the console
would search for show() in the globalenv instead of in the methods
namespace.

The problem I would like to report is that it seems that when an S4 object
is printed with print(), a similar issue happens. I do realize that S4
objects should be printed with show() rather than print(), which would
solve the issue, but this still seems like a bug to me.

Example:

library(methods)
show <- function(...) message("hijacked!")
setClass("Test", representation(test = "character"))
test <- new("Test")
print(test)
# hijacked!

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Problem on rand() in packaging

[Ralf Stubner]

On 21.02.19 09:16, Uwe Ligges wrote:
> Use R's RNG, see Writing R Extensions.

Which can be conveniently used with R::runif and Rcpp::runif etc. when
using Rcpp.

cheerio
ralf

> Best,
> Uwe Ligges
> 
> 
> On 21.02.2019 07:52, Chu-Lan Kao wrote:
>> Dear Sir,
>>
>> I've got a Rcpp code in the form like the following in my uploaded
>> package:
>>
>> inline double runiforminline(){
>>    std::default_random_engine generator(rand());
>>    std::uniform_real_distribution distribution (0.0, 1.0);
>>    return (distribution(generator));
>> }
>>
>> But as I uploaded, the system ask me to remove rand(). Various attempt
>> has
>> been tried, but all of them result in no randomness at all. Not sure
>> how to
>> fix it. Kindly appreciate all helps.
>>
>> Sincerely,
>>
>> Chu-Lan Kao ( 高竹嵐 Michael )
>> *http://chulankao.blogspot.com / *
>> chulan...@gmail.com
>>  / 0956242509
>>
>> Assist. Prof. in Statistics, National Chiao-Tung University
>> Music Director for dramAcappella Theater
>> 
>> Composer, Taipei Philaharmonic Chorus 
>> Gamer Consultant and Designer
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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

Re: [R-pkg-devel] Problem on rand() in packaging

[Uwe Ligges]

Use R's RNG, see Writing R Extensions.

Best,
Uwe Ligges


On 21.02.2019 07:52, Chu-Lan Kao wrote:

Dear Sir,

I've got a Rcpp code in the form like the following in my uploaded package:

inline double runiforminline(){
   std::default_random_engine generator(rand());
   std::uniform_real_distribution distribution (0.0, 1.0);
   return (distribution(generator));
}

But as I uploaded, the system ask me to remove rand(). Various attempt has
been tried, but all of them result in no randomness at all. Not sure how to
fix it. Kindly appreciate all helps.

Sincerely,

Chu-Lan Kao ( 高竹嵐 Michael )
*http://chulankao.blogspot.com / *
chulan...@gmail.com
 / 0956242509

Assist. Prof. in Statistics, National Chiao-Tung University
Music Director for dramAcappella Theater

Composer, Taipei Philaharmonic Chorus 
Gamer Consultant and Designer

[[alternative HTML version deleted]]

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



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