[Rd] Strange "no-echo" in place of "slave"
SVN revision replaces "slave" with "no-echo" in R devel. In each of the following, "no-echo" is rather strange to me. - src/gnuwin32/README.Rterm 3) As a no-echo process for ESS mode in NTEmacs with flag --ess. - src/library/grDevices/src/qdCocoa.m /* the no-echo thread work until this is NO */ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wrong explanation on 'ylab' in hist.Rd
Description of arguments main, xlab, ylab in hist.Rd in current R devel and R
patched ends with this.
the default \code{ylab} is \code{"Frequency"} iff \code{probability} is true
In fact, if 'probability' is true, the histogram doesn't represent frequencies.
It should be
the default \code{ylab} is \code{"Frequency"} iff \code{freq} is true
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inappropriate class(o)[!inherits(o,"AsIs")] in get_all_vars
SVN revision 77401 changes x[isM] <- lapply(x[isM], function(o) `class<-`(o, class(o)[class(o) != "AsIs"])) to x[isM] <- lapply(x[isM], function(o) `class<-`(o, class(o)[!inherits(o,"AsIs")])) in function 'get_all_vars' in src/library/stats/R/models.R in R devel. The change is inappropriate. class(o)[class(o) != "AsIs"] removes "AsIs" from class(o), giving class(o) without "AsIs". On the other hand, inherits(o,"AsIs") is just a single logical value. If "AsIs" is in class(o), inherits(o,"AsIs") is TRUE. In that case, by recycling of logical index, class(o)[!inherits(o,"AsIs")] removes all elements of class(o), giving character(0). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inappropriate class(o)[!inherits(o,"AsIs")] in get_all_vars
class(o)[!inherits(o,"AsIs")] is still in function 'get_all_vars' in R patched
(in
https://svn.r-project.org/R/branches/R-3-6-branch/src/library/stats/R/models.R).
It was ported to R patched by r77402. On Monday, 18 November 2019, 8:12:10
PM GMT+7, Martin Maechler wrote:
> Martin Maechler
> on Mon, 18 Nov 2019 12:15:38 +0100 writes:
> suharto anggono--- via R-devel
> on Sun, 17 Nov 2019 10:34:31 + writes:
>> SVN revision 77401 changes
>> x[isM] <- lapply(x[isM], function(o) `class<-`(o, class(o)[class(o) !=
"AsIs"]))
>> to
>> x[isM] <- lapply(x[isM], function(o) `class<-`(o,
class(o)[!inherits(o,"AsIs")]))
>> in function 'get_all_vars' in src/library/stats/R/models.R in R devel.
>> The change is inappropriate.
>> class(o)[class(o) != "AsIs"] removes "AsIs" from class(o), giving
class(o) without "AsIs".
>> On the other hand, inherits(o,"AsIs") is just a single logical value. If
"AsIs" is in class(o), inherits(o,"AsIs") is TRUE. In that case, by recycling
of logical index, class(o)[!inherits(o,"AsIs")] removes all elements of
class(o), giving character(0).
> Thank you, Suharto !
> You are obviously right, and I'm a bit embarrassed by my
> overzealousness to follow my own recommendations in the R Blog
> http://bit.ly/R_blog_class_think_2x
> {*wrongly*: The recommendation was to "think again" ...}
> It's a "shame" that the wrong code did not trigger any checks,
> so if anybody has time... I'd be grateful for such a regression
> check.
Once I started thinking, it was easy to modify the previous
reg.check to trigger in the case of the erronous r77401.
Fixed now in 77435.
Martin
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round(x, dig) [was "Development version of R fails tests .."]
I disagree with what is assessed as "correct" in vignette of package 'round'.
With
x <- 9.18665
, what is actually stored in 'x' is a number that is slightly larger than
9.18665. So, as said in the vignette, it is closer to 9.1867 than 9.1866.
sprintf("%.4f", x)
giving
"9.1867"
is correct, as it is a string representing the _exact_ number 9.1867.
For round(x, 4) , that gives number and cannot return 9.1867 exactly, I still
think that a binary double precision number closest to 9.1867 should be
returned. My principles:
- Input number should be read as is, should be treated as exact.
- What counts is what the exact result should be.
> Hugh Parsonage
> on Sat, 8 Feb 2020 21:12:43 +1100 writes:
> The only observation I can make is that the change to
> round() was made in r77727 whereas your R-devel appears to
> be r77715 (so would not exhibit the fixed behaviour). My
> guess is that there was a perpetual installation failure
> after r77715 but that the test folder was still retrieved
> and used.
> On Sat, 8 Feb 2020 at 19:27, Berwin A Turlach wrote:
>>
>> G'day all,
>>
>> I have daily scripts running to install the patched version of the
>> current R version and the development version of R on my linux box
>> (Ubuntu 18.04.4 LTS).
>>
>> The last development version that was successfully compiled and
>> installed was "R Under development (unstable) (2020-01-25 r77715)" on
>> 27 January. Since then the script always fails as a regression test
>> seems to fail. Specifically, in the tests/ subdirectory of my build
>> directory I have a file reg-tests-1d.Rout.fail which ends with:
>>
>> > ## more than half of the above were rounded *down* in R <= 3.6.x
>> > ## Some "wrong" test cases from CRAN packages (partly relying on wrong
R <= 3.6.x behavior)
>> > stopifnot(exprs = {
>> + all.equal(round(10.7775, digits=3), 10.778, tolerance = 1e-12) #
even tol=0, was 10.777
>> + all.equal(round(12345 / 1000, 2), 12.35 , tolerance = 1e-12) #
even tol=0, was 12.34 in Rd
>> + all.equal(round(9.18665, 4),9.1866, tolerance = 1e-12) #
even tol=0, was 9.1867
>> + })
>> Error: round(10.7775, digits = 3) and 10.778 are not equal:
>> Mean relative difference: 9.27902e-05
>> Execution halted
>>
>> This happens while the 32bit architecture is installed, which is a bit
>> surprising as I get the following results for the last installed
>> version of R's development version:
>>
>> R Under development (unstable) (2020-01-25 r77715) -- "Unsuffered
Consequences"
>> Copyright (C) 2020 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu/32 (32-bit)
>> [...]
>> > round(10.7775, digits=3)
>> [1] 10.778
>>
>> and
>>
>> R Under development (unstable) (2020-01-25 r77715) -- "Unsuffered
Consequences"
>> Copyright (C) 2020 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu/64 (64-bit)
>> [...]
>> > round(10.7775, digits=3)
>> [1] 10.778
>>
>>
>> On the other hand, the R 3.6.2 version, that I mainly use at the moment,
>> gives the following results:
>>
>> 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/32 (32-bit)
>> [...]
>> > round(10.7775, digits=3)
>> [1] 10.777
>>
>> and
>>
>> 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 (64-bit)
>> [...]
>> > round(10.7775, digits=3)
>> [1] 10.777
>>
>>
>> So it seems as if the behaviour of round() has changed between R 3.6.2
>> and the development version. But I do not understand why this test all
>> of a sudden failed if the results from the last successfully installed
>> development version of R suggest that the test should be passed.
>>
>> Thanks in advance for any insight and tips.
>>
>> Cheers,
>> Berwin
Note that r77727 was the last of a few commits I made related to
dealing with R's bug report PR#17668:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17668
which itself triggered an involved dialogue, mostly online,
visible at the PR's URL above.
It lead me to also write an R package 'round' (in order to
compare R 3.6.x and later's round() versions, comparing them etc)
with a (not entirely polished) package vignette
that explains how rounding to decimal digits is not at all
trivial and why and how I ended (*) improving R's
round(x, digits) algorithm in R-devel.
The CRAN version of the package
https://cran.r-project.org/package=round
install.packages("round")
is not quite current, notably its vignette isn't and so I have
mentioned in the
[Rd] tryCatch without handler in QC.R
The following is among those added by r77792 to src/library/tools/R/QC.R in R devel. bad <- tryCatch(check_url_db(udb)) The 'tryCatch' has no handler. It does nothing. Error would still stop execution. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tryCatch without handler in QC.R
Sorry, it is already fixed. Currently, it is as follows. bad <- tryCatch(check_url_db(udb), error = identity) On Tuesday, 10 March 2020, 11:53:16 pm GMT+7, wrote: The following is among those added by r77792 to src/library/tools/R/QC.R in R devel. bad <- tryCatch(check_url_db(udb)) The 'tryCatch' has no handler. It does nothing. Error would still stop execution. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Without 'collapse', 'paste' pastes (concatenates) its arguments elementwise
(separated by 'sep', " " by default). New in R devel and R patched, specifying
recycle0 = FALSE makes mixing zero-length and nonzero-length arguments results
in length zero. The result of paste(n, "th", sep = "", recycle0 = FALSE) always
have the same length as 'n'. Previously, the result is still as long as the
longest argument, with the zero-length argument like "". If all og the
arguments have length zero, 'recycle0' doesn't matter.
As far as I understand, 'paste' with 'collapse' as a character string is
supposed to put together elements of a vector into a single character string. I
think 'recycle0' shouldn't change it.
In current R devel and R patched, paste(character(0), collapse = "", recycle0 =
FALSE) is character(0). I think it should be "", like paste(character(0),
collapse="").
paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th, 5th".
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
is
"4th".
I think
paste(c(), "th", sep = "", collapse = ", ", recycle0 = FALSE)
should be
"",
not character(0).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
I was wrong, as I didn't actually try and didn't read the documentation
carefully. I thought that ' zero-length arguments being recycled to "" '
happens when recycle0 = TRUE. It is actually the opposite.
Everywhere in my previous message, recycle0 = FALSE should be recycle0 = TRUE.
I really think that 'paste' with 'collapse' specified (as a character string)
should always result in a single character string, no matter what value of
'recycle0'.
paste(character(0), collapse = "", recycle0 = TRUE) # character(0), but should
be ""
paste(character(0), recycle0 = FALSE)
is the same as
paste(character(0), recycle0 = TRUE) .
'recycle0' doesn't matter there.
Why should
paste(character(0), collapse = "", recycle0 = FALSE)
be different from
paste(character(0), collapse = "", recycle0 = TRUE) ?
paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = TRUE) # "4th,
5th"
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = TRUE) # "4th"
paste(c( ), "th", sep = "", collapse = ", ", recycle0 = TRUE) #
character(0), but should be ""
On Saturday, 2 May 2020, 10:09:21 pm GMT+7, Martin Maechler
wrote:
> suharto anggono--- via R-devel
> on Fri, 1 May 2020 03:05:37 + (UTC) writes:
> Without 'collapse', 'paste' pastes (concatenates) its arguments
elementwise (separated by 'sep', " " by default). New in R devel and R patched,
specifying recycle0 = FALSE makes mixing zero-length and nonzero-length
arguments results in length zero.
That's not intended.
(It's what should only happen with the new (non-default) recycle0=TRUE )
> The result of paste(n, "th", sep = "", recycle0 = FALSE) always have the same
> length as 'n'. Previously, the result is still as long as the longest
> argument, with the zero-length argument like "". If all og the arguments have
> length zero, 'recycle0' doesn't matter.
> As far as I understand, 'paste' with 'collapse' as a character string is
supposed to put together elements of a vector into a single character string. I
think 'recycle0' shouldn't change it.
Well, not quite: only 'recycle0=FALSE' shouldn't change it
.. maybe this is what you meant anyway.
> In current R devel and R patched, paste(character(0), collapse = "",
recycle0 = FALSE) is character(0). I think it should be "", like
paste(character(0), collapse="").
Definitely: The intent of the new 'recycle0' argument is to
provide a non-default possibility for paste(, recycle0=TRUE) to behave more
like "arithmetic" functions where the recycling rules ensure that
if one argument has length 0 then the result has length 0:
i.e., paste(a,b,c,d, recycle0=TRUE) should recycle the same as
a+b+c+d does recycle
Indeed, the default 'recycle0=FALSE' should correspond to previous (R <= 4.0.0)
behavior entirely.
BUT from all I see, R-devel and R-patched's version of paste()
do behave as they should. Also what you clim here is not true :
> paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> is
> "4th, 5th".
> paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> is
> "4th".
> I think
> paste(c( ), "th", sep = "", collapse = ", ", recycle0 = FALSE)
> should be
> "",
> not character(0).
Rather, what I see is what the comments of the following code
lines claim (according to the intention of 'recycle0', contrary
some of your claims above) :
paste(character(0), collapse = "", recycle0 = FALSE) # is "", like
paste(character(0), collapse = "")
paste(character(0), collapse = "", recycle0 = TRUE) # is character(0)
paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = FALSE) # is
"4th, 5th"
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = FALSE) # is "4th"
paste(c( ), "th", sep = "", collapse = ", ", recycle0 = FALSE) # is "th"
##
paste(c("4", "5"), "th", sep = "", collapse = ", ", recycle0 = TRUE) # is
"4th, 5th"
paste(c("4" ), "th", sep = "", collapse = ", ", recycle0 = TRUE) # is "4th"
paste(c( ), "th", sep = "", collapse = ", ", recycle0 = TRUE) # is
character(0)
There must be a lapsus / misunderstanding somewhere.
I don't see any problem in the new behavior for now.
Best regards,
Martin
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
