Re: [R-pkg-devel] win-builder down?

[Rolf Turner]

On 1/03/20 2:40 pm, Hugh Parsonage wrote:

Are CRAN staff located in Europe only? Is there a case to have a limited 
staff across multiple timezones with a rolling roster? Obviously if 
something is reported it’s best if it can be actioned immediately.


Just to be clear, it is winbuilder, and not CRAN, that is the subject of 
concern.  In my understanding at least, these (winbuilder and CRAN) are 
quite different entities.


Also I have the vague (quite possibly erroneous) impression that the 
staff of winbuilder consists of a unique individual, namely Uwe Ligges.


It might be a Good Thing if someone located somewhere other than Europe, 
were to volunteer to assist Uwe.   OTOH Uwe might not want any 
assistance and/or might not trust the competence of such volunteers.


cheers,

Rolf

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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

Re: [R-pkg-devel] win-builder down?

[Hugh Parsonage]

Are CRAN staff located in Europe only? Is there a case to have a limited
staff across multiple timezones with a rolling roster? Obviously if
something is reported it’s best if it can be actioned immediately.

On Sun, 1 Mar 2020 at 12:29 pm, Henrik Bengtsson 
wrote:

> FYI, in past when queues got stuck, Uwe told me it's often a package that
> launches an external process (e.g. java.exe) that doesn't terminate and
> prevents R CMD check from terminating/timing out. He got watchdogs to kill
> such stray events but there are false negatives.
>
> A couple of weeks ago I proposed to add a placeholder for the package
> currently tested and Uwe said he might look into it, e.g.
>
> $ curl ftp://win-builder.r-project.org/R-devel/
> 02-05-20  03:10PM  2359737 bayestestR_0.5.2.tar.gz
> 02-05-20  11:42AM  0
> some.pkg_0.0.1.tar.gz-PROCESSING
> 02-05-20  11:56AM  5053108 catdata_1.2.2.tar.gz
>
> Even if it doesn't solve the problem, it'll communicate to "us" that
> something is stuck and what it is.
>
> Anyway, we can help out by reporting (like this) when a queue look stuck.
> Then I think it helps to clarify which queue/builder is stuck.
>
> Henrik
>
>
> On Sat, Feb 29, 2020, 15:13 Rolf Turner  wrote:
>
> >
> > On 1/03/20 11:44 am, Max Kuhn wrote:
> >
> > > On February 29, 2020 at 5:06:35 PM, Rolf Turner (
> r.tur...@auckland.ac.nz
> > > ) wrote:
> > >>
> > >> On 1/03/20 2:23 am, Hadley Wickham wrote:
> > >>
> > >> > Is it down again? I'm seeing the same problem again.
> > >> > Hadley
> > >> >
> > >> > On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham  > > wrote:
> > >> >>
> > >> >> Hi all,
> > >> >>
> > >> >> Is win-builder down? I submitted a couple of packages >24 hours
> ago,
> > >> >> and haven't heard back.
> > >> >>
> > >> >> Hadley
> > >>
> > >> Me too. Submitted a package about 18 hours ago, and so far not a
> > >> sausage. Although it's churlish to complain, one gets used to a
> service
> > >> that has been provided and gets annoyed when the service disappears.
> > >
> > > True, but it would be unnecessary if `R CMD check —as-cran` did exactly
> > > the same thing as win-builder (as well as the extra, informal checks
> > > done on a first submission).
> >
> > Not entirely true.  The package that I am currently trying to get built
> > is for use by some consulting clients and is not (yet) for public
> > release.  So I can't/don't submit it to CRAN so as to get a Windoze
> > binary that way.
> >
> > cheers,
> >
> > Rolf
> >
> > P.S. I note that the winbuilder web site says:
> >
> > >  Please do not upload Bioconductor packages or CRAN packages.
> > >  Both Bioconductor and CRAN do have build systems 
> >
> > I presume that this exhortation is of some antiquity and is "no longer
> > operative".
> >
> > R.
> >
> > --
> > Honorary Research Fellow
> > Department of Statistics
> > University of Auckland
> > Phone: +64-9-373-7599 ext. 88276
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [FORGED] Re: win-builder down?

[Henrik Bengtsson]

FYI, in past when queues got stuck, Uwe told me it's often a package that
launches an external process (e.g. java.exe) that doesn't terminate and
prevents R CMD check from terminating/timing out. He got watchdogs to kill
such stray events but there are false negatives.

A couple of weeks ago I proposed to add a placeholder for the package
currently tested and Uwe said he might look into it, e.g.

$ curl ftp://win-builder.r-project.org/R-devel/
02-05-20  03:10PM  2359737 bayestestR_0.5.2.tar.gz
02-05-20  11:42AM  0
some.pkg_0.0.1.tar.gz-PROCESSING
02-05-20  11:56AM  5053108 catdata_1.2.2.tar.gz

Even if it doesn't solve the problem, it'll communicate to "us" that
something is stuck and what it is.

Anyway, we can help out by reporting (like this) when a queue look stuck.
Then I think it helps to clarify which queue/builder is stuck.

Henrik


On Sat, Feb 29, 2020, 15:13 Rolf Turner  wrote:

>
> On 1/03/20 11:44 am, Max Kuhn wrote:
>
> > On February 29, 2020 at 5:06:35 PM, Rolf Turner (r.tur...@auckland.ac.nz
> > ) wrote:
> >>
> >> On 1/03/20 2:23 am, Hadley Wickham wrote:
> >>
> >> > Is it down again? I'm seeing the same problem again.
> >> > Hadley
> >> >
> >> > On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham  > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> Is win-builder down? I submitted a couple of packages >24 hours ago,
> >> >> and haven't heard back.
> >> >>
> >> >> Hadley
> >>
> >> Me too. Submitted a package about 18 hours ago, and so far not a
> >> sausage. Although it's churlish to complain, one gets used to a service
> >> that has been provided and gets annoyed when the service disappears.
> >
> > True, but it would be unnecessary if `R CMD check —as-cran` did exactly
> > the same thing as win-builder (as well as the extra, informal checks
> > done on a first submission).
>
> Not entirely true.  The package that I am currently trying to get built
> is for use by some consulting clients and is not (yet) for public
> release.  So I can't/don't submit it to CRAN so as to get a Windoze
> binary that way.
>
> cheers,
>
> Rolf
>
> P.S. I note that the winbuilder web site says:
>
> >  Please do not upload Bioconductor packages or CRAN packages.
> >  Both Bioconductor and CRAN do have build systems 
>
> I presume that this exhortation is of some antiquity and is "no longer
> operative".
>
> R.
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> __
> 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] tcl problem with R-3.6.3?

[Charles Geyer]

I realized I don't have to do those checks.  It was not working again (same
error) message when I got home, but after a reboot it worked fine.  Of
course it has tcl/tk because when it works, it brings up a gui chooser
thingy that allows me to choose a CRAN mirror.

On Sat, Feb 29, 2020 at 3:33 PM Charles Geyer  wrote:

> No. I didn't do any of that and am now at a hockey game.  But since I
> can't reproduce the problem after an Ubuntu online update and reboot, I
> assume the issue is moot.  But I will check these things in an hour or so.
>
> On Sat, Feb 29, 2020, 3:24 PM Dirk Eddelbuettel  wrote:
>
>>
>> Charles,
>>
>> Did you try a build of the provided alpha, beta and rc releases made
>> available to allow you to ensure that the released version would build and
>> perform as expected?
>>
>> FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian,
>> built for the Ubuntu backports at CRAN (thanks to Michael) and also in the
>> base Rocker container behaves as expected (and as the one RC build did):
>>
>> edd@rob:~$ docker run --rm -ti rocker/r-base
>>
>> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
>> 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.
>>
>> > capabilities()
>>jpeg pngtiff   tcltk X11aqua
>>TRUETRUETRUETRUE   FALSE   FALSE
>>http/ftp sockets  libxmlfifo  cledit   iconv
>>TRUETRUETRUETRUETRUETRUE
>> NLS profmem   cairo ICU long.double libcurl
>>TRUETRUETRUETRUETRUETRUE
>> >
>>
>>
>> And (to echo Martin Maechler) tcltk comes up as TRUE as it should.
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>
>

-- 
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of Minnesota
char...@stat.umn.edu

[[alternative HTML version deleted]]

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

Re: [Rd] dput()

[Steven Dirkse]

Ben,

I'll edit and split your question just a little.
  1) "Is there a way to get an *exact* ASCII representation of a
double-precision value?"
  2) "Is there a way to get round-trip behavior, i.e. to make sure that the
value, when converted back to double, is identical() to the original"

The hexNumeric idea mentioned by Duncan is a positive answer to the first
question.  It's a little hard to grok at first, but it is fully precise and
represents exactly a 64-bit double.  And since it is exact it converts back
identically.

But there is another way to get round-trip behavior.  There is a set of
routines called dtoa that, when given an IEEE double, produce the shortest
sequence of base 10 digits that will map back to the double.  There may be
some rounding when producing these digits, but of all the digit sequences
that would map back to the input x, these routines produce the shortest
such.

A link to the original routines is here:

http://www.netlib.org/fp/dtoa.c

and some searching will turn up variants of this code in newer guises.

A good question to ask: for all finite doubles, what is the length of the
longest digit sequence required?  I believe 17 digits is the max digits
required.  It may be 18, but I doubt it.  I don't have an example at hand
and I spent some time looking when working with these routines.   Oh, BTW,
trailing or leading zeros do not count toward the length of the digit
sequence.

-Steve

On Sat, Feb 29, 2020 at 4:21 AM Ben Bolker  wrote:

>
>  I think Robin knows about FAQ 7.31/floating point (author of
> 'Brobdingnag', among other numerical packages).  I agree that this is
> surprising (to me).
>
>   To reframe this question: is there way to get an *exact* ASCII
> representation of a numeric value (i.e., guaranteeing the restored value
> is identical() to the original) ?
>
>  .deparseOpts has
>
> ‘"digits17"’: Real and finite complex numbers are output using
>   format ‘"%.17g"’ which may give more precision than the
>   default (but the output will depend on the platform and there
>   may be loss of precision when read back).
>
>   ... but this still doesn't guarantee that all precision is kept.
>
>   Maybe
>
>  saveRDS(x,textConnection("out","w"),ascii=TRUE)
> identical(x,as.numeric(out[length(out)]))   ## TRUE
>
> ?
>
>
>
>
> On 2020-02-29 2:42 a.m., Rui Barradas wrote:
> > Hello,
> >
> > FAQ 7.31
> >
> > See also this StackOverflow post:
> >
> >
> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
> >
> > Hope this helps,
> >
> > Rui Barradas
> >
> > Às 00:08 de 29/02/20, robin hankin escreveu:
> >> My interpretation of dput.Rd is that dput() gives an exact ASCII form
> >> of the internal representation of an R object.  But:
> >>
> >>   rhankin@cuttlefish:~ $ R --version
> >> R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
> >> Copyright (C) 2019 The R Foundation for Statistical Computing
> >> Platform: x86_64-pc-linux-gnu (64-bit)
> >>
> >> [snip]
> >>
> >> rhankin@cuttlefish:~ $ R --vanilla --quiet
> >>> x <- sum(dbinom(0:20,20,0.35))
> >>> dput(x)
> >> 1
> >>> x-1
> >> [1] -4.440892e-16
> >>>
> >>> x==1
> >> [1] FALSE
> >>>
> >>
> >> So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?
> >>
> >> __
> >> 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
>


-- 
Steven Dirkse, Ph.D.
GAMS Development Corp.
office: 202.342.0180

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [FORGED] Re: win-builder down?

[Rolf Turner]

On 1/03/20 11:44 am, Max Kuhn wrote:

On February 29, 2020 at 5:06:35 PM, Rolf Turner (r.tur...@auckland.ac.nz 
) wrote:


On 1/03/20 2:23 am, Hadley Wickham wrote:

> Is it down again? I'm seeing the same problem again.
> Hadley
>
> On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham mailto:h.wick...@gmail.com>> wrote:
>>
>> Hi all,
>>
>> Is win-builder down? I submitted a couple of packages >24 hours ago,
>> and haven't heard back.
>>
>> Hadley

Me too. Submitted a package about 18 hours ago, and so far not a
sausage. Although it's churlish to complain, one gets used to a service
that has been provided and gets annoyed when the service disappears.


True, but it would be unnecessary if `R CMD check —as-cran` did exactly 
the same thing as win-builder (as well as the extra, informal checks 
done on a first submission).


Not entirely true.  The package that I am currently trying to get built 
is for use by some consulting clients and is not (yet) for public 
release.  So I can't/don't submit it to CRAN so as to get a Windoze 
binary that way.


cheers,

Rolf

P.S. I note that the winbuilder web site says:


 Please do not upload Bioconductor packages or CRAN packages.
 Both Bioconductor and CRAN do have build systems 


I presume that this exhortation is of some antiquity and is "no longer 
operative".


R.

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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

Re: [R-pkg-devel] [FORGED] Re: win-builder down?

[Max Kuhn]

On February 29, 2020 at 5:06:35 PM, Rolf Turner (r.tur...@auckland.ac.nz)
wrote:


On 1/03/20 2:23 am, Hadley Wickham wrote:

> Is it down again? I'm seeing the same problem again.
> Hadley
>
> On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham 
wrote:
>>
>> Hi all,
>>
>> Is win-builder down? I submitted a couple of packages >24 hours ago,
>> and haven't heard back.
>>
>> Hadley

Me too. Submitted a package about 18 hours ago, and so far not a
sausage. Although it's churlish to complain, one gets used to a service
that has been provided and gets annoyed when the service disappears.

True, but it would be unnecessary if `R CMD check —as-cran` did exactly the
same thing as win-builder (as well as the extra, informal checks done on a
first submission).

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [FORGED] Re: win-builder down?

[Rolf Turner]

On 1/03/20 2:23 am, Hadley Wickham wrote:


Is it down again? I'm seeing the same problem again.
Hadley

On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham  wrote:


Hi all,

Is win-builder down? I submitted a couple of packages >24 hours ago,
and haven't heard back.

Hadley


Me too.  Submitted a package about 18 hours ago, and so far not a 
sausage.  Although it's churlish to complain, one gets used to a service 
that has been provided and gets annoyed when the service disappears.


cheers,

Rolf Turner

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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

Re: [Rd] tcl problem with R-3.6.3?

[Charles Geyer]

No. I didn't do any of that and am now at a hockey game.  But since I can't
reproduce the problem after an Ubuntu online update and reboot, I assume
the issue is moot.  But I will check these things in an hour or so.

On Sat, Feb 29, 2020, 3:24 PM Dirk Eddelbuettel  wrote:

>
> Charles,
>
> Did you try a build of the provided alpha, beta and rc releases made
> available to allow you to ensure that the released version would build and
> perform as expected?
>
> FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian,
> built for the Ubuntu backports at CRAN (thanks to Michael) and also in the
> base Rocker container behaves as expected (and as the one RC build did):
>
> edd@rob:~$ docker run --rm -ti rocker/r-base
>
> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> 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.
>
> > capabilities()
>jpeg pngtiff   tcltk X11aqua
>TRUETRUETRUETRUE   FALSE   FALSE
>http/ftp sockets  libxmlfifo  cledit   iconv
>TRUETRUETRUETRUETRUETRUE
> NLS profmem   cairo ICU long.double libcurl
>TRUETRUETRUETRUETRUETRUE
> >
>
>
> And (to echo Martin Maechler) tcltk comes up as TRUE as it should.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [Rd] tcl problem with R-3.6.3?

[Dirk Eddelbuettel]

Charles,

Did you try a build of the provided alpha, beta and rc releases made
available to allow you to ensure that the released version would build and
perform as expected?

FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian,
built for the Ubuntu backports at CRAN (thanks to Michael) and also in the
base Rocker container behaves as expected (and as the one RC build did):

edd@rob:~$ docker run --rm -ti rocker/r-base

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
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.

> capabilities()
   jpeg pngtiff   tcltk X11aqua 
   TRUETRUETRUETRUE   FALSE   FALSE 
   http/ftp sockets  libxmlfifo  cledit   iconv 
   TRUETRUETRUETRUETRUETRUE 
NLS profmem   cairo ICU long.double libcurl 
   TRUETRUETRUETRUETRUETRUE 
>


And (to echo Martin Maechler) tcltk comes up as TRUE as it should.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] dput()

[robin hankin]

 Thanks guys, I guess I should have referred to FAQ 7.31 (which I am
indeed very familiar with) to avoid misunderstanding.  I have always
used dput() to clarify 7.31-type issues.

The description in ?dput implies [to me at any rate] that there will
be no floating-point roundoff in its output.  I hadn't realised that
'deparsing' as discussed in dput.Rd includes precision roundoff
issues.

I guess the question I should have asked is close to Ben's: "How to
force dput() to return an exact representation of a floating point
number?".  Duncan's reply is the insight I was missing: exact decimal
representation of a double might not be possible (this had not
occurred to me).  Also, Duncan's suggestion of control = c("all",
"hexNumeric") looks good and I will experiment with this.

Best wishes

Robin




On Sun, Mar 1, 2020 at 6:22 AM Duncan Murdoch  wrote:
>
> On 29/02/2020 4:19 a.m., Ben Bolker wrote:
> >
> >   I think Robin knows about FAQ 7.31/floating point (author of
> > 'Brobdingnag', among other numerical packages).  I agree that this is
> > surprising (to me).
> >
> >To reframe this question: is there way to get an *exact* ASCII
> > representation of a numeric value (i.e., guaranteeing the restored value
> > is identical() to the original) ?
> >
> >   .deparseOpts has
> >
> > ‘"digits17"’: Real and finite complex numbers are output using
> >format ‘"%.17g"’ which may give more precision than the
> >default (but the output will depend on the platform and there
> >may be loss of precision when read back).
> >
> >... but this still doesn't guarantee that all precision is kept.
>
> "Using control = c("all", "hexNumeric") comes closest to making
> deparse() an inverse of parse(), as representing double and complex
> numbers as decimals may well not be exact. However, not all objects are
> deparse-able even with this option. A warning will be issued if the
> function recognizes that it is being asked to do the impossible."
>
> >
> >Maybe
> >
> >   saveRDS(x,textConnection("out","w"),ascii=TRUE)
> > identical(x,as.numeric(out[length(out)]))   ## TRUE
> >
> > ?
> >
> >
> >
> >
> > On 2020-02-29 2:42 a.m., Rui Barradas wrote:
> >> Hello,
> >>
> >> FAQ 7.31
> >>
> >> See also this StackOverflow post:
> >>
> >> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
> >>
> >> Hope this helps,
> >>
> >> Rui Barradas
> >>
> >> Às 00:08 de 29/02/20, robin hankin escreveu:
> >>> My interpretation of dput.Rd is that dput() gives an exact ASCII form
> >>> of the internal representation of an R object.  But:
> >>>
> >>>rhankin@cuttlefish:~ $ R --version
> >>> R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
> >>> Copyright (C) 2019 The R Foundation for Statistical Computing
> >>> Platform: x86_64-pc-linux-gnu (64-bit)
> >>>
> >>> [snip]
> >>>
> >>> rhankin@cuttlefish:~ $ R --vanilla --quiet
>  x <- sum(dbinom(0:20,20,0.35))
>  dput(x)
> >>> 1
>  x-1
> >>> [1] -4.440892e-16
> 
>  x==1
> >>> [1] FALSE
> 
> >>>
> >>> So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?
> >>>
> >>> __
> >>> 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
> >
>
> __
> 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] R 3.6.3 is released

[dmedri]

Or use the Roaster:https://github.com/dmedri/roaster/(feedback is welcome)
 Messaggio originale Da: Peter Dalgaard via R-devel 
 Data: 29/02/20  10:19  (GMT+01:00) A: 
r-annou...@r-project.org Cc: r-devel  Oggetto: [Rd] R 
3.6.3 is released The build system rolled up R-3.6.3.tar.gz (codename "Holding 
the Windsock") this morning.The list below details the changes in this 
release.You can get the source code 
fromhttp://cran.r-project.org/src/base/R-3/R-3.6.3.tar.gzor wait for it to be 
mirrored at a CRAN site nearer to you.Binaries for various platforms will 
appear in due course.For the R Core Team,Peter DalgaardThese are the checksums 
(md5 and SHA-256) for the freshly created files, in case you wishto check that 
they are uncorrupted:MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4MD5 
(COPYING) = eb723b61539feef013de476e68b5c50aMD5 (COPYING.LIB) = 
a6f89e2100d9b6cdffcea4f398e37343MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052MD5 
(INSTALL) = 7893f754308ca31f1ccf62055090ad7bMD5 (NEWS) = 
2b364f6eaef28e069ab8ed779ee5859dMD5 (NEWS.0) = 
bfcd7c147251b5474d96848c6f57e5a8MD5 (NEWS.1) = 
eb78c4d053ec9c32b815cf0c2ebea801MD5 (NEWS.2) = 
591dcf615162127f904e4e461f330ce9MD5 (R-latest.tar.gz) = 
506c9576ba33e1262ad5b5624db9d96aMD5 (README) = 
f468f281c919665e276a1b691decbbe6MD5 (RESOURCES) = 
529223fd3ffef95731d0a87353108435MD5 (THANKS) = 
bb45f89c01d509721c47fd41f147da60MD5 (VERSION-INFO.dcf) = 
d97d382dc5583f9385461d8a4b0ff091MD5 (R-3/R-3.6.3.tar.gz) = 
506c9576ba33e1262ad5b5624db9d96a2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09
  AUTHORSe6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4  
COPYING6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3  
COPYING.LIB38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d  
FAQf87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31  
INSTALL50381062bad9aeb4b0c8c4695cb6955c5ff70699fcc821a8e1b340229100278c  
NEWS4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62  
NEWS.012b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01  
NEWS.1ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc  
NEWS.289302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f  
R-latest.tar.gz2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc 
 README408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9  
RESOURCES2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a  
THANKS20f8bfdfc6302bb2cf9b0fc5424c9a10ac0953096b6c32768ffd106a3fdd4589  
VERSION-INFO.dcf89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f
  R-3/R-3.6.3.tar.gzThis is the relevant part of the NEWS fileCHANGES IN R 
3.6.3:  NEW FEATURES:    * The included LAPACK has been updated to version 
3.9.0 (for the  included routines, just bug fixes).  BUG FIXES:    * Fixed 
a C level integer overflow in rhyper(); reported by  Benjamin Tyner in 
PR#17694.    * Uses of url(gzcon(.)) needing to extend buffer size have failed  
    (with HTTP/2 servers), reported by G'abor Cs'ardi.    * predict(loess(..), 
se=TRUE) now errors out (instead of  seg.faulting etc) for large sample 
sizes, thanks to a report and  patch by Benjamin Tyner in PR#17121.    * 
tools:assertCondition(., "error") and hence assertError() no  longer return 
errors twice (invisibly).    * update(form, new) in the case of a long new 
formula sometimes  wrongly eliminated the intercept from form, or (more 
rarely)  added a garbage term (or seg.faulted !); the fix happened by  
simplifying the C-level logic of terms.formula().  Reported by  Mathias 
Amb"uhl in PR#16326.    * The error message from stopifnot(.., )  again contains the full "stopifnot(...)" call: Its attempted
  suppression did not work consistently.    * On Windows, download.file(., , 
"wininet", headers=character())  would fail; reported with patch proposal 
by Kevin Ushey in  PR#17710.-- Peter Dalgaard, Professor,Center for 
Statistics, Copenhagen Business SchoolSolbjerg Plads 3, 2000 Frederiksberg, 
DenmarkPhone: (+45)38153501Office: A 4.23Email: pd@cbs.dk  Priv: 
PDalgd@gmail.com__r-de...@r-project.org
 mailing listhttps://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] tcl problem with R-3.6.3?

[Martin Maechler]

> Charles Geyer 
> on Sat, 29 Feb 2020 12:19:08 -0600 writes:

> I knew I could work around.  But this shouldn't happen.

I assume   capabilities()does show a   FALSE   for "tcltk" ?
In such cases, sessionInfo()  may be extended:

> sfsmisc :: sessionInfoX() # returns even more; has a "nice" print() method

Extended  sessionInfo():
---
Capabilities:
   jpeg pngtiff   tcltk X11aqua 
  X   X   X   X   X   - 
   http/ftp sockets  libxmlfifo  cledit   iconv 
  X   X   X   X   -   X 
NLS profmem   cairo ICU long.double libcurl 
  X   -   X   X   X   X 
Sys.info:
nodenamev-lynne
usermaechler

LAPACK version: 3.9.0 
External software (versions):
zlib1.2.11
bzlib   1.0.6, 6-Sept-2010
xz  5.2.4
PCRE8.43 2019-02-23
ICU 63.2
TRE TRE 0.8.0 R_fixes (BSD)
iconv   glibc 2.29
readline8.0
BLAS/u/maechler/R/D/r-patched/F30-64-inst/lib/libRblas.so

PCRE (regex) config.: ("UTF-8" = TRUE, "Unicode properties" = TRUE, JIT = TRUE, 
stack = TRUE) 
R executable linked against libR.* ['is R shared']: FALSE 

R_LIBS:
libPath [.libPaths()] contents in addition to R_LIBS and .Library:
[1] "/usr/local64.sfs/app/R/Bioconductor/library_3.10_F30"
[2] "/usr/local64.sfs/app/R/R_local/library_F30-3.6"  
[3] "/u/maechler/R/x86_64-pc-linux-gnu-library/3.6"   
Main R env. variables (for more, inspect the 'xR.env' component):
[,1]   
R_ENVIRON   "/u/maechler/R/Renviron64" 
R_PROFILE   "/u/maechler/R/Rprofile"   
R_CHECK_ENVIRON "/u/maechler/.R/check.Renviron"
 standard sessionInfo():
R version 3.6.3 Patched (2020-02-29 r77878)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Fedora 30 (Thirty)

Matrix products: default
BLAS:   /u/maechler/R/D/r-patched/F30-64-inst/lib/libRblas.so
LAPACK: /u/maechler/R/D/r-patched/F30-64-inst/lib/libRlapack.so

locale:
 [1] LC_CTYPE=de_CH.UTF-8   LC_NUMERIC=C  
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=de_CH.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=de_CH.UTF-8   
 [7] LC_PAPER=de_CH.UTF-8   LC_NAME=C 
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=de_CH.UTF-8 LC_IDENTIFICATION=C   

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

other attached packages:
[1] fortunes_1.5-4 sfsmisc_1.1-5 

loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3tcltk_3.6.3   
> 

I'm not seeing any problems on my Linux platforms (all Fedora 30).

Martin

> And yes.  Same problem with your example.

> blurfle$ R --vanilla

> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> 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.

>> ans <- utils::select.list(c("hello", "world", "again"),
>> graphics=TRUE)
> Error in structure(.External(.C_dotTclObjv, objv), class =
> "tclObj") : [tcl] grab failed: window not viewable.
>> q()

> I didn't bother with sessionInfo() this time.  I presume
> it would be the same as before.


> AFAIK this is a fully up to date Ubuntu 18.04 box.

> On Sat, Feb 29, 2020 at 12:13 PM Henrik Bengtsson <
> henrik.bengts...@gmail.com> wrote:

>> Here's a simpler example that should reproduce that error
>> for you:
>> 
>> ans <- utils::select.list(c("hello", "world", "again"),
>> graphics=TRUE)
>> 
>> Does it?
>> 
>> FYI, I installed R 3.6.3 from source on CentOS 7 a few
>> hours ago, and for me the above works just fine.
>> 
>> For your immediate needs of selecting a CRAN mirror, you
>> can set:
>> 
>> options(menu.graphics = FALSE)
>> 
>> as a workaround to skip Tcl-based menus.
>> 
>> /Henrik
>> 
>> On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer
>>  wrote:
>> >
>> > Just built 3.6.3 from source 

Re: [Rd] tcl problem with R-3.6.3?

[Charles Geyer]

I knew I could work around.  But this shouldn't happen.

And yes.  Same problem with your example.

blurfle$ R --vanilla

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
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.

> ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
  [tcl] grab failed: window not viewable.
> q()

I didn't bother with sessionInfo() this time.  I presume it would be the
same as before.


AFAIK this is a fully up to date Ubuntu 18.04 box.

On Sat, Feb 29, 2020 at 12:13 PM Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:

> Here's a simpler example that should reproduce that error for you:
>
>   ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)
>
> Does it?
>
> FYI, I installed R 3.6.3 from source on CentOS 7 a few hours ago, and
> for me the above works just fine.
>
> For your immediate needs of selecting a CRAN mirror, you can set:
>
> options(menu.graphics = FALSE)
>
> as a workaround to skip Tcl-based menus.
>
> /Henrik
>
> On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer 
> wrote:
> >
> > Just built 3.6.3 from source and tcl doesn't work.  Worked fine with the
> > same laptop in 3.6.2.  Here's the exact error.
> >
> > blurfle$ R --vanilla
> >
> > R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> > 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.
> >
> > > sessionInfo()
> > R version 3.6.3 (2020-02-29)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.4 LTS
> >
> > Matrix products: default
> > BLAS:   /home/geyer/local/current/lib/R/lib/libRblas.so
> > LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so
> >
> > locale:
> >  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.6.3
> > > install.packages("aster")
> > --- Please select a CRAN mirror for use in this session ---
> > Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
> >   [tcl] grab failed: window not viewable.
> > > q()
> >
> > What's up with that?
> >
> > --
> > Charles Geyer
> > Professor, School of Statistics
> > Resident Fellow, Minnesota Center for Philosophy of Science
> > University of Minnesota
> > char...@stat.umn.edu
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of Minnesota
char...@stat.umn.edu

[[alternative HTML version deleted]]

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

Re: [Rd] tcl problem with R-3.6.3?

[Henrik Bengtsson]

Here's a simpler example that should reproduce that error for you:

  ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)

Does it?

FYI, I installed R 3.6.3 from source on CentOS 7 a few hours ago, and
for me the above works just fine.

For your immediate needs of selecting a CRAN mirror, you can set:

options(menu.graphics = FALSE)

as a workaround to skip Tcl-based menus.

/Henrik

On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer  wrote:
>
> Just built 3.6.3 from source and tcl doesn't work.  Worked fine with the
> same laptop in 3.6.2.  Here's the exact error.
>
> blurfle$ R --vanilla
>
> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> 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.
>
> > sessionInfo()
> R version 3.6.3 (2020-02-29)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.4 LTS
>
> Matrix products: default
> BLAS:   /home/geyer/local/current/lib/R/lib/libRblas.so
> LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.3
> > install.packages("aster")
> --- Please select a CRAN mirror for use in this session ---
> Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
>   [tcl] grab failed: window not viewable.
> > q()
>
> What's up with that?
>
> --
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
>
> [[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] tcl problem with R-3.6.3?

[Charles Geyer]

Just built 3.6.3 from source and tcl doesn't work.  Worked fine with the
same laptop in 3.6.2.  Here's the exact error.

blurfle$ R --vanilla

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
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.

> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS

Matrix products: default
BLAS:   /home/geyer/local/current/lib/R/lib/libRblas.so
LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] compiler_3.6.3
> install.packages("aster")
--- Please select a CRAN mirror for use in this session ---
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
  [tcl] grab failed: window not viewable.
> q()

What's up with that?

-- 
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of Minnesota
char...@stat.umn.edu

[[alternative HTML version deleted]]

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

Re: [Rd] dput()

[Duncan Murdoch]

On 29/02/2020 4:19 a.m., Ben Bolker wrote:


  I think Robin knows about FAQ 7.31/floating point (author of
'Brobdingnag', among other numerical packages).  I agree that this is
surprising (to me).

   To reframe this question: is there way to get an *exact* ASCII
representation of a numeric value (i.e., guaranteeing the restored value
is identical() to the original) ?

  .deparseOpts has

‘"digits17"’: Real and finite complex numbers are output using
   format ‘"%.17g"’ which may give more precision than the
   default (but the output will depend on the platform and there
   may be loss of precision when read back).

   ... but this still doesn't guarantee that all precision is kept.


"Using control = c("all", "hexNumeric") comes closest to making 
deparse() an inverse of parse(), as representing double and complex 
numbers as decimals may well not be exact. However, not all objects are 
deparse-able even with this option. A warning will be issued if the 
function recognizes that it is being asked to do the impossible."




   Maybe

  saveRDS(x,textConnection("out","w"),ascii=TRUE)
identical(x,as.numeric(out[length(out)]))   ## TRUE

?




On 2020-02-29 2:42 a.m., Rui Barradas wrote:

Hello,

FAQ 7.31

See also this StackOverflow post:

https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal

Hope this helps,

Rui Barradas

Às 00:08 de 29/02/20, robin hankin escreveu:

My interpretation of dput.Rd is that dput() gives an exact ASCII form
of the internal representation of an R object.  But:

   rhankin@cuttlefish:~ $ R --version
R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

[snip]

rhankin@cuttlefish:~ $ R --vanilla --quiet

x <- sum(dbinom(0:20,20,0.35))
dput(x)

1

x-1

[1] -4.440892e-16


x==1

[1] FALSE




So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?

__
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



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

Re: [R-pkg-devel] Internet security software?

[Bob Rudis]

As someone who is in cybersecurity as their $DAYJOB and who runs macOS as their 
primary OS (tho I pretty much run them all in one way, shape or form), I'd 
suggest:

- relying heavily on Gatekeeper/Xprotect (the built-in anti-malware solution 
that comes with macOS, provided you keep updating the OS)
- review the free tools at  and 
consider installing them for "monitoring". Specifically, I'd suggest using:
  - LuLu 
  - KnockKnowk 
  - ReiKey 
  - BlockBlock 
  - RansomWhere? 
  - OverSight 
  - Lockdown  (if you're 
stuck on seriously old macOS)
- use MalwareBytes free edition for periodic scans
- use Google Chrome Beta channel with uBlock Origin and the Disconnect 
extensions (and very few other extensions). 
  Go into uBlock Origin and enable all of the non-regional blocklists and then 
ones for your specific region.
  We're seeing regular increases in malicious advertisements across all ad 
networks.

The vast majority (if not all) of commercial or freemium macOS anti-malware 
solutions are mind-numbingly trivial to bypass. Unless you're in a regulatory 
environment that requires commercial, always-on anti-malware, I'd just run (as 
noted) the free version of Malwarebytes. If you are regulated, then it's one of 
the better ones from a commercial standpoint.

-boB


> On Feb 25, 2020, at 04:16, Joris Meys  wrote:
> 
> Hi Spencer,
> 
> I've abandoned Bitdefender for the reason you give: it gave me too much 
> trouble with false positives and seemingly random blocking of all kinds of 
> tools at one point. But the reason is not Bitdefender in itself. It worked 
> perfectly fine until the updates came for the Spectre and Meltdown 
> vulnerabilities. Somehow these patches messed with the workings of 
> Bitdefender, leading to the problems you describe. As Windows 7 is no longer 
> maintained, these problems won't be solved.
> 
> So first of all, you should abandon Windows 7. Even if it would work fine, 
> it's a huge security risk. No point in having an antivirus if you run an OS 
> that's no longer maintained. Either move to Windows 10 or change for a Linux 
> distro (Ubuntu is imho the one Windows users find most easy to adapt to. Your 
> mileage may vary).
> 
> As for antivirus, I'm now using Kaspersky and am liking it so far (2 years 
> now). I find it less intrusive than Bitdefender as well, even though I had no 
> complaints in the past. 
> 
> Kind regards
> Joris
> 
> --
> Joris Meys
> Statistical consultant
> 
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> --
> 
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 
> 
> From: R-package-devel  on behalf of 
> Spencer Graves 
> Sent: Monday, February 24, 2020 10:49 PM
> To: List r-package-devel
> Subject: [R-pkg-devel] Internet security software?
> 
> Hello, All:
> 
> 
>   What antivirus / internet security software do you use and
> recommend?
> 
> 
>   I've used Bitdefender for years.  However, I've been encountering
> an increasing number of problems with software I've used for years.
> Some of my problems disappear when I turn off parts of Bitdefender.
> However, I've been unable to use RStudio on my Windows 7 computer since
> early last November.  Also, when I turn off certain features of
> Bitdefender, "R CMD build sos" (with sos cloned from
> "https://github.com/sbgraves237/sos;) completes in a few minutes.  With
> Bitdefender configured normally, "R CMD build sos" stops without warning
> on "* creating vignettes".  I've left it for days like that without it
> moving beyond that point.  No error message but also no progress.
> 
> 
>   Rather than doing a web search for alternative internet security
> software, I thought I'd ask you all:  If some of you have had similar
> problems with other antivirus / internet security software, I think I'd
> be more likely to hear it from you than from a web search.  Some of my
> problems may not be due to Bitdefender, but I know that some are, and
> Bitdefender tech support answers the phone but fails to fix these problems.
> 
> 
>   Thanks,
>   Spencer Graves
> 
> __
> 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

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

Re: [R-pkg-devel] win-builder down?

[Henrik Bengtsson]

Could be.  FYI, I think the different win-builder queues are
independent, i.e. when one get stuck it does not affect the others.
For example, I just verified that R-devel_gcc8 works.


$ date --iso-8601=seconds
2020-02-29T07:41:53-08:00


$ curl -s ftp://win-builder.r-project.org/R-oldrel/ | sed -E
's/(AM|PM)/\t\1/g' | sort -k 1 -k 3 -k 2
[empty]


$ curl -s ftp://win-builder.r-project.org/R-release/ | sed -E
's/(AM|PM)/\t\1/g' | sort -k 1 -k 3 -k 2
02-28-20  06:35 PM   129480 miraculix_0.9.19.1.tar.gz
02-28-20  06:41 PM   964211 wbstats_1.0.0.tar.gz
02-28-20  07:16 PM  2805713 SWMPrExtension_1.1.3.tar.gz
...
02-29-20  12:25 PM  2256595 lidR_2.2.3.tar.gz


$ curl -s ftp://win-builder.r-project.org/R-devel/ | sed -E
's/(AM|PM)/\t\1/g' | sort -k 1 -k 3 -k 2
02-28-20  07:59 PM   861233 tune_0.1.0.tar.gz
02-28-20  08:02 PM  4259662 qtl_1.46-2.tar.gz
02-28-20  08:07 PM   259716 forcats_0.4.0.9000.tar.gz
...
02-29-20  12:44 PM32053 PostcodesioR_0.2.0.tar.gz


$ curl -s ftp://win-builder.r-project.org/R-devel_gcc8/ | sed -E
's/(AM|PM)/\t\1/g' | sort -k 1 -k 3 -k 2
[empty]

/Henrik

On Sat, Feb 29, 2020 at 5:23 AM Hadley Wickham  wrote:
>
> Is it down again? I'm seeing the same problem again.
> Hadley
>
> On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham  wrote:
> >
> > Hi all,
> >
> > Is win-builder down? I submitted a couple of packages >24 hours ago,
> > and haven't heard back.
> >
> > Hadley
> >
> > --
> > http://hadley.nz
>
>
>
> --
> http://hadley.nz
>
> __
> 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

Re: [Bioc-devel] Duplicated commits in BioC git repository

[Mingxiang Teng]

Thank you, Nitesh. The github repo is here:
https://github.com/tengmx/rnaseqcomp
Best,
Mingxiang

On Sat, Feb 29, 2020 at 7:52 AM Turaga, Nitesh <
nitesh.tur...@roswellpark.org> wrote:

> Hi,
>
> If you send me your GitHub repo where you have the cleaned repo. I will
> compare it to the repo on the bioconductor git server. I'll do a quick
> check and sync them once I think they are correctly done.
>
> Thank you for taking time to read the documentation and fixing the
> duplicate commits.
>
> Best regards,
>
> Nitesh
>
> --
> Nitesh Turaga
> Senior Programmer Analyst
> Bioconductor core team
> Roswell Park
>
> --
> *From:* Bioc-devel  on behalf of
> Mingxiang Teng 
> *Sent:* Friday, February 28, 2020 7:33:57 PM
> *To:* bioc-devel@r-project.org 
> *Subject:* [Bioc-devel] Duplicated commits in BioC git repository
>
> Hi,
> I cannot push commits back to rnaseqcomp package in BioC git repository due
> to the duplicated commits.I have cleaned the commits with cherry-pick
> following
> https://bioconductor.org/developers/how-to/git/resolve-duplicate-commits/.
> It seems that I have to contact Bioconductor core team to sync my local
> repository with the version on Bioconductor. Please help.
> Thank you,
> Mingxiang
>
> [[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

[R-pkg-devel] Possible gcc-10.0.1 Bug in gcc-10 Test Server

[brodie gaslam via R-package-devel]

At the risk of getting laughed out of the room I wanted to share with you some 
interesting findings that arose from trying to figure out why my package vetr 
is segfaulting on the gcc-10 test machine:

https://www.stats.ox.ac.uk/pub/bdr/gcc10/vetr.out

Thanks to Dirk Eddelbuettel who pointed me to rocker/r-base that builds on the 
testing debian repo I was able to reproduce the error, and figure just enough 
to post a semi-cogent question on SO:

https://stackoverflow.com/q/60406042/2725969

And some folks that know more than me about compilers rendered judgment that it 
likely is a compiler error.  I realize "random dudes on SO rendered judgment" 
is not exactly the most ringing endorsement, but the logic they present is 
sound and matches my reading of the C standard (not that that is worth much).

It is unlikely for others to run into this issue as it requires an extremely 
particular set of circumstances.  If you too segfault on Professor Ripley's 
machine please don't just point to this as the reason without actually 
confirming that's what's happening.

Best,

Brodie.

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

Re: [Bioc-devel] Duplicated commits in BioC git repository

[Turaga, Nitesh]

Hi,

If you send me your GitHub repo where you have the cleaned repo. I will compare 
it to the repo on the bioconductor git server. I'll do a quick check and sync 
them once I think they are correctly done.

Thank you for taking time to read the documentation and fixing the duplicate 
commits.

Best regards,

Nitesh

--
Nitesh Turaga
Senior Programmer Analyst
Bioconductor core team
Roswell Park


From: Bioc-devel  on behalf of Mingxiang Teng 

Sent: Friday, February 28, 2020 7:33:57 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Duplicated commits in BioC git repository

Hi,
I cannot push commits back to rnaseqcomp package in BioC git repository due
to the duplicated commits.I have cleaned the commits with cherry-pick
following
https://bioconductor.org/developers/how-to/git/resolve-duplicate-commits/.
It seems that I have to contact Bioconductor core team to sync my local
repository with the version on Bioconductor. Please help.
Thank you,
Mingxiang

[[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] issue: maintainer of a Bioconductor package

[OLIVIER FRANCOIS]

Dear bioc team, 


I am an author of the bioconductor package LEA [ 
https://bioconductor.org/packages/devel/bioc/html/LEA.html | 
https://bioconductor.org/packages/devel/bioc/html/LEA.html ] , mainly 
contributing to its GitHub repository [ https://github.com/bcm-uga/LEA | 
https://github.com/bcm-uga/LEA ] . I would like to sync my changes with the 
bioc-devel repository. 

The issue is that my email (olivier.francois at grenoble-inp.fr) does not seem 
to be associated with a maintainer of the Bioconductor package, and it fails 
when i try to create an account in the credentials database. 

Could you please help with this issue 

best wishes 
Olivier 

[[alternative HTML version deleted]]

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

Re: [Rd] dput()

[Ben Bolker]

 I think Robin knows about FAQ 7.31/floating point (author of
'Brobdingnag', among other numerical packages).  I agree that this is
surprising (to me).

  To reframe this question: is there way to get an *exact* ASCII
representation of a numeric value (i.e., guaranteeing the restored value
is identical() to the original) ?

 .deparseOpts has

‘"digits17"’: Real and finite complex numbers are output using
  format ‘"%.17g"’ which may give more precision than the
  default (but the output will depend on the platform and there
  may be loss of precision when read back).

  ... but this still doesn't guarantee that all precision is kept.

  Maybe

 saveRDS(x,textConnection("out","w"),ascii=TRUE)
identical(x,as.numeric(out[length(out)]))   ## TRUE

?




On 2020-02-29 2:42 a.m., Rui Barradas wrote:
> Hello,
> 
> FAQ 7.31
> 
> See also this StackOverflow post:
> 
> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
> 
> Hope this helps,
> 
> Rui Barradas
> 
> Às 00:08 de 29/02/20, robin hankin escreveu:
>> My interpretation of dput.Rd is that dput() gives an exact ASCII form
>> of the internal representation of an R object.  But:
>>
>>   rhankin@cuttlefish:~ $ R --version
>> R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
>> Copyright (C) 2019 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> [snip]
>>
>> rhankin@cuttlefish:~ $ R --vanilla --quiet
>>> x <- sum(dbinom(0:20,20,0.35))
>>> dput(x)
>> 1
>>> x-1
>> [1] -4.440892e-16
>>>
>>> x==1
>> [1] FALSE
>>>
>>
>> So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?
>>
>> __
>> 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

[Rd] R 3.6.3 is released

[Peter Dalgaard via R-devel]

The build system rolled up R-3.6.3.tar.gz (codename "Holding the Windsock") 
this morning.

The list below details the changes in this release.

You can get the source code from

http://cran.r-project.org/src/base/R-3/R-3.6.3.tar.gz

or wait for it to be mirrored at a CRAN site nearer to you.

Binaries for various platforms will appear in due course.


For the R Core Team,

Peter Dalgaard

These are the checksums (md5 and SHA-256) for the freshly created files, in 
case you wish
to check that they are uncorrupted:

MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 2b364f6eaef28e069ab8ed779ee5859d
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9
MD5 (R-latest.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
MD5 (VERSION-INFO.dcf) = d97d382dc5583f9385461d8a4b0ff091
MD5 (R-3/R-3.6.3.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a


2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09  AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4  COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3  COPYING.LIB
38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d  FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31  INSTALL
50381062bad9aeb4b0c8c4695cb6955c5ff70699fcc821a8e1b340229100278c  NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62  NEWS.0
12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01  NEWS.1
ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc  NEWS.2
89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f  
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc  README
408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9  RESOURCES
2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a  THANKS
20f8bfdfc6302bb2cf9b0fc5424c9a10ac0953096b6c32768ffd106a3fdd4589  
VERSION-INFO.dcf
89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f  
R-3/R-3.6.3.tar.gz


This is the relevant part of the NEWS file

CHANGES IN R 3.6.3:

  NEW FEATURES:

* The included LAPACK has been updated to version 3.9.0 (for the
  included routines, just bug fixes).

  BUG FIXES:

* Fixed a C level integer overflow in rhyper(); reported by
  Benjamin Tyner in PR#17694.

* Uses of url(gzcon(.)) needing to extend buffer size have failed
  (with HTTP/2 servers), reported by G'abor Cs'ardi.

* predict(loess(..), se=TRUE) now errors out (instead of
  seg.faulting etc) for large sample sizes, thanks to a report and
  patch by Benjamin Tyner in PR#17121.

* tools:assertCondition(., "error") and hence assertError() no
  longer return errors twice (invisibly).

* update(form, new) in the case of a long new formula sometimes
  wrongly eliminated the intercept from form, or (more rarely)
  added a garbage term (or seg.faulted !); the fix happened by
  simplifying the C-level logic of terms.formula().  Reported by
  Mathias Amb"uhl in PR#16326.

* The error message from stopifnot(.., )
  again contains the full "stopifnot(...)" call: Its attempted
  suppression did not work consistently.

* On Windows, download.file(., , "wininet", headers=character())
  would fail; reported with patch proposal by Kevin Ushey in
  PR#17710.

-- 
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] dput()

[Gabriel Becker]

Hi Robin,

In the future, questions like this belong on R-help, not R-devel as it is a
basic usage question not a discussion about development of the R language
itself or similar.

That said, ?dput states a number of times that exact deparsing is not
always possible and that dput is not appropriate for what I'm inferring you
may be trying to do with it.  I would not have expected this in particular
to be one of those cases, to be honest, but its within spec. dput is NOT
guaranteed to give back an identical object, in fact according to the docs
in some cases it should be expected not to. As for why dput is doing this ,
I'm not sure if its that some amount off formatting is going on inside
dput, or if its a finite precision issue as suggested by Rui. I think the
former is more consistent with the behavior you're seeing but I don't have
time to dig into the guts of dput right this second.

Either way, If you want exact recreation of the object you have you need to
either run the actual code you used to generate it (on the same data  in
the same environment, etc etc) or serialize it out via saveRDS (or just
save if you must) and then readRDS/load it back in.

I hope that helps.
~G


On Fri, Feb 28, 2020 at 11:43 PM Rui Barradas  wrote:

> Hello,
>
> FAQ 7.31
>
> See also this StackOverflow post:
>
> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
>
> Hope this helps,
>
> Rui Barradas
>
> Às 00:08 de 29/02/20, robin hankin escreveu:
> > My interpretation of dput.Rd is that dput() gives an exact ASCII form
> > of the internal representation of an R object.  But:
> >
> >   rhankin@cuttlefish:~ $ R --version
> > R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
> > Copyright (C) 2019 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > [snip]
> >
> > rhankin@cuttlefish:~ $ R --vanilla --quiet
> >> x <- sum(dbinom(0:20,20,0.35))
> >> dput(x)
> > 1
> >> x-1
> > [1] -4.440892e-16
> >>
> >> x==1
> > [1] FALSE
> >>
> >
> > So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?
> >
> > __
> > 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] dput()

[David Winsemius]

On 2/28/20 11:42 PM, Rui Barradas wrote:

Hello,

FAQ 7.31

See also this StackOverflow post:

https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal 




That was going to be my initial response, but then I realized that the 
question might be why the dput representation of the x variable didn't 
display the detail of the decimal fraction out at the 16th or 
seventeenth place. So here's some further results to chew on:



1 (rather than 0.99955591) is what would get if `dput` were 
used to send it to a file:



 dput(x, file="temp.txt")

 x <- scan(file="temp.txt")
#Read 1 item

 x==1
#[1] TRUE

And if you wanted more precision with the value before it got rectified 
by output/input  you could use the control parameter:



dput(x, control="digits17")
#0.99956


HTH;

David.



Hope this helps,

Rui Barradas

Às 00:08 de 29/02/20, robin hankin escreveu:

My interpretation of dput.Rd is that dput() gives an exact ASCII form
of the internal representation of an R object.  But:

  rhankin@cuttlefish:~ $ R --version
R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

[snip]

rhankin@cuttlefish:~ $ R --vanilla --quiet

x <- sum(dbinom(0:20,20,0.35))
dput(x)

1

x-1

[1] -4.440892e-16


x==1

[1] FALSE




So, dput(x) gives 1, but x is not equal to 1.  Can anyone advise?

__
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