[Rd] reg-tests-1d.R fails in r72721
Hi,
I am failing make check in r72721 at the end of reg-tests-1d.R. The
relevant block of code is
## path.expand shouldn't translate to local encoding PR#17120
filename <- "\U9b3c.R"
print(Encoding(filename))
x1 <- path.expand(paste0("~/", filename))
print(Encoding(x1))
x2 <- paste0(path.expand("~/"), filename)
print(Encoding(x2))
stopifnot(identical( path.expand(paste0("~/", filename)),
paste0(path.expand("~/"), filename)))
## Chinese character was changed to hex code
Encoding(x1) is "unknown" while Encoding(x2) is "UTF-8". If I run
this code with R --vanilla, both are UTF-8 and the assertion
passes. What is make check doing differently? Or is there something
wrong with my setting/environment? Thanks,
h.
--
+---
| Hiroyuki Kawakatsu
| Business School, Dublin City University
| Dublin 9, Ireland. Tel +353 (0)1 700 7496
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] precision of do_arith() in arithmetic.c
To the R development team: First of all, thank you so much for maintaining wonderful R software. Perhaps, Dr. Ahn has just reported an error on the wilcox.test() function, and suggesting that an error may arise from abs() and rank(). I just had a quick check that the problem may come from the precision of the results of arithmetic functions. 87.7-89.1+1.4 # > 87.7-89.1+1.4 # [1] 8.437695e-15 I checked that do_arith() in arithmetic.c is using double type (8 byte) for PLUSOP, MINUSOP, TIMESOP, DIVOP etc. https://github.com/wch/r-source/blob/f68b30e3b5479d84adbff516d48d4722a574dc82/src/main/arithmetic.c I have two thoughts: (1) in the rank() function, we may round at less than 14 decimal places by default? (2) using long double type (10 byte) instead of double type (8 byte) by default in the arithmetic function could be helpful for preventing embarassment? Perhaps, R may provide the arithmetic function with various variable types, if some application needs. Thanks. Min-hyung [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reg-tests-1d.R fails in r72721
On 24/05/2017 5:47 AM, Hiroyuki Kawakatsu wrote:
Hi,
I am failing make check in r72721 at the end of reg-tests-1d.R. The
relevant block of code is
## path.expand shouldn't translate to local encoding PR#17120
filename <- "\U9b3c.R"
print(Encoding(filename))
x1 <- path.expand(paste0("~/", filename))
print(Encoding(x1))
x2 <- paste0(path.expand("~/"), filename)
print(Encoding(x2))
stopifnot(identical( path.expand(paste0("~/", filename)),
paste0(path.expand("~/"), filename)))
## Chinese character was changed to hex code
Encoding(x1) is "unknown" while Encoding(x2) is "UTF-8". If I run
this code with R --vanilla, both are UTF-8 and the assertion
passes. What is make check doing differently? Or is there something
wrong with my setting/environment? Thanks,
I think the test is wrong because in the first case you are working in a
locale where that character is representable. In my locale it is not,
so x1 is converted to UTF-8, and everything compares equal.
An explicit conversion of x1 to UTF-8 should fix this, i.e. replace
x1 <- path.expand(paste0("~/", filename))
with
x1 <- enc2utf8(path.expand(paste0("~/", filename)))
Could you try this and see if it helps?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reg-tests-1d.R fails in r72721
On 2017-05-24, Duncan Murdoch wrote:
>
> I think the test is wrong because in the first case you are working in a
> locale where that character is representable. In my locale it is not, so x1
> is converted to UTF-8, and everything compares equal.
>
> An explicit conversion of x1 to UTF-8 should fix this, i.e. replace
>
> x1 <- path.expand(paste0("~/", filename))
>
> with
>
> x1 <- enc2utf8(path.expand(paste0("~/", filename)))
>
> Could you try this and see if it helps?
Nope:
> ## path.expand shouldn't translate to local encoding PR#17120
> filename <- "\U9b3c.R"
>
> x11 <- path.expand(paste0("~/", filename))
> print(Encoding(x11))
[1] "unknown"
> x12 <- enc2utf8( path.expand(paste0("~/", filename)) )
> print(Encoding(x12))
[1] "unknown"
> x2 <- paste0(path.expand("~/"), filename)
> print(Encoding(x2))
[1] "UTF-8"
>
> #stopifnot(identical(path.expand(paste0("~/", filename)),
> stopifnot(identical(enc2utf8( path.expand(paste0("~/", filename)) ),
+ paste0(path.expand("~/"), filename)))
Error: identical(enc2utf8(path.expand(paste0("~/", filename))),
paste0(path.expand("~/"), is not TRUE
Execution halted
I forgot to report:
> sessionInfo()
R Under development (unstable) (2017-05-23 r72721)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)
Matrix products: default
BLAS: /usr/local/share/R-devel/lib/libRblas.so
LAPACK: /usr/local/share/R-devel/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.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.5.0
h.
--
+---
| Hiroyuki Kawakatsu
| Business School, Dublin City University
| Dublin 9, Ireland. Tel +353 (0)1 700 7496
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] precision of do_arith() in arithmetic.c
> On 24 May 2017, at 04:24, M Kim wrote: > > To the R development team: > > First of all, thank you so much for maintaining wonderful R software. > > Perhaps, Dr. Ahn has just reported an error on the wilcox.test() function, > and suggesting that an error may arise from abs() and rank(). > > > I just had a quick check that the problem may come from the precision of > the results of arithmetic functions. > > > 87.7-89.1+1.4 > # > 87.7-89.1+1.4 > # [1] 8.437695e-15 > R FAQ 7.31. See https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f Berend > I checked that do_arith() in arithmetic.c is using double type (8 byte) for > PLUSOP, MINUSOP, TIMESOP, DIVOP etc. > > https://github.com/wch/r-source/blob/f68b30e3b5479d84adbff516d48d4722a574dc82/src/main/arithmetic.c > > > I have two thoughts: > > (1) in the rank() function, we may round at less than 14 decimal places by > default? > > (2) using long double type (10 byte) instead of double type (8 byte) by > default in the arithmetic function could be helpful for preventing > embarassment? > > Perhaps, R may provide the arithmetic function with various variable types, > if some application needs. > > > Thanks. > > Min-hyung > > [[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] reg-tests-1d.R fails in r72721
On 24/05/2017 7:59 AM, Hiroyuki Kawakatsu wrote:
On 2017-05-24, Duncan Murdoch wrote:
I think the test is wrong because in the first case you are working in a
locale where that character is representable. In my locale it is not, so x1
is converted to UTF-8, and everything compares equal.
An explicit conversion of x1 to UTF-8 should fix this, i.e. replace
x1 <- path.expand(paste0("~/", filename))
with
x1 <- enc2utf8(path.expand(paste0("~/", filename)))
Could you try this and see if it helps?
Nope:
Okay, how about if we weaken the test? Instead of
stopifnot(identical(path.expand(paste0("~/", filename)),
paste0(path.expand("~/"), filename)))
try
stopifnot(path.expand(paste0("~/", filename)) ==
paste0(path.expand("~/"), filename))
Duncan Murdoch
## path.expand shouldn't translate to local encoding PR#17120
filename <- "\U9b3c.R"
x11 <- path.expand(paste0("~/", filename))
print(Encoding(x11))
[1] "unknown"
x12 <- enc2utf8( path.expand(paste0("~/", filename)) )
print(Encoding(x12))
[1] "unknown"
x2 <- paste0(path.expand("~/"), filename)
print(Encoding(x2))
[1] "UTF-8"
#stopifnot(identical(path.expand(paste0("~/", filename)),
stopifnot(identical(enc2utf8( path.expand(paste0("~/", filename)) ),
+ paste0(path.expand("~/"), filename)))
Error: identical(enc2utf8(path.expand(paste0("~/", filename))),
paste0(path.expand("~/"), is not TRUE
Execution halted
I forgot to report:
sessionInfo()
R Under development (unstable) (2017-05-23 r72721)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)
Matrix products: default
BLAS: /usr/local/share/R-devel/lib/libRblas.so
LAPACK: /usr/local/share/R-devel/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.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.5.0
h.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reg-tests-1d.R fails in r72721
On 2017-05-24, Duncan Murdoch wrote:
[...]
> Okay, how about if we weaken the test?
[...]
> try
>
> stopifnot(path.expand(paste0("~/", filename)) ==
> paste0(path.expand("~/"), filename))
>
Nope:
> ## path.expand shouldn't translate to local encoding PR#17120
> filename <- "\U9b3c.R"
>
> #stopifnot(identical(path.expand(paste0("~/", filename)),
> stopifnot(path.expand(paste0("~/", filename)) ==
+ paste0(path.expand("~/"), filename))
Error: path.expand(paste0("~/", filename)) == paste0(path.expand("~/"),
is not TRUE
Execution halted
The problem is that path.expand(), or do_pathexpand() for
non-windoze calls translateChar() which in turn calls
translateToNative() which is unknown to make check (but not to R
--vanilla) under my setup. Once it is unknown, there seems to be no
way to force an encoding:
> ## path.expand shouldn't translate to local encoding PR#17120
> filename <- "\U9b3c.R"
> print(Encoding(filename))
[1] "UTF-8"
>
> y1 <- paste0("~/", filename)
> print(Encoding(y1))
[1] "UTF-8"
>
> y2 <- path.expand(y1)
> print(Encoding(y2))
[1] "unknown"
>
> y3a <- iconv(y2, to="UTF-8")
> print(Encoding(y3a))
[1] "unknown"
>
> y3b <- enc2utf8(y2)
> print(Encoding(y3b))
[1] "unknown"
>
> Encoding(y2) <- "UTF-8"
> print(Encoding(y2))
[1] "unknown"
>
h.
--
+---
| Hiroyuki Kawakatsu
| Business School, Dublin City University
| Dublin 9, Ireland. Tel +353 (0)1 700 7496
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reg-tests-1d.R fails in r72721
On 24/05/2017 9:59 AM, Hiroyuki Kawakatsu wrote:
On 2017-05-24, Duncan Murdoch wrote:
[...]
Okay, how about if we weaken the test?
[...]
try
stopifnot(path.expand(paste0("~/", filename)) ==
paste0(path.expand("~/"), filename))
Nope:
## path.expand shouldn't translate to local encoding PR#17120
filename <- "\U9b3c.R"
#stopifnot(identical(path.expand(paste0("~/", filename)),
stopifnot(path.expand(paste0("~/", filename)) ==
+ paste0(path.expand("~/"), filename))
Error: path.expand(paste0("~/", filename)) == paste0(path.expand("~/"),
is not TRUE
Execution halted
Thanks. I've made that test conditional on running on Windows, and
re-opened bug 17120. I indicated that it's now a Unix-only bug.
This may be a first: a case where R handles non-native characters
better in Windows than it does in Unix. I'm sure this will show up in a
Microsoft ad soon :-).
Duncan Murdoch
The problem is that path.expand(), or do_pathexpand() for
non-windoze calls translateChar() which in turn calls
translateToNative() which is unknown to make check (but not to R
--vanilla) under my setup. Once it is unknown, there seems to be no
way to force an encoding:
## path.expand shouldn't translate to local encoding PR#17120
filename <- "\U9b3c.R"
print(Encoding(filename))
[1] "UTF-8"
y1 <- paste0("~/", filename)
print(Encoding(y1))
[1] "UTF-8"
y2 <- path.expand(y1)
print(Encoding(y2))
[1] "unknown"
y3a <- iconv(y2, to="UTF-8")
print(Encoding(y3a))
[1] "unknown"
y3b <- enc2utf8(y2)
print(Encoding(y3b))
[1] "unknown"
Encoding(y2) <- "UTF-8"
print(Encoding(y2))
[1] "unknown"
h.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting an R bugzilla account
Thank you for creating this! I'll go ahead and start working on bugs as I have time. I have a patch for the bug I linked below so you should see that soon. :) Nathan -Original Message- From: Martyn Plummer [mailto:plumm...@iarc.fr] Sent: Tuesday, May 23, 2017 11:16 PM To: r-devel@r-project.org; Nathan Sosnovske Subject: Re: [Rd] Getting an R bugzilla account Thanks for your help Nathan. I have added a bugzilla account for you. Martyn On Tue, 2017-05-23 at 21:02 +, Nathan Sosnovske via R-devel wrote: > Hi All, > > I have a fix to this bug ( > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs. > r-project.org%2Fbugzilla3%2Fshow_&data=02%7C01%7Cnsosnov%40microsoft.c > om%7Ce0541136ceb6429d9d0f08d4a26c1926%7C72f988bf86f141af91ab2d7cd011db > 47%7C1%7C0%7C636312032542968195&sdata=oNadqT%2B%2Fm0pj86k8Z854lVSWWHUu > t60YOaYmiaZfPZk%3D&reserved=0 > bug.cgi?id=16454) and would like to submit a patch to the bug report > on Bugzilla. I'd also like to start going through some of the other > Windows-specific issues and start fixing those. The bug submission > instructions indicate that I should ask here for a Bugzilla account. > Is that still the correct procedure? > > Thanks! > > Nathan > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7Cnsosnov%40microsoft.com%7Ce0541136ceb6429d9d0f08d4a26c1926%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636312032542968195&sdata=nDdVG5QFWYItWdoKPq9XvYOGiwqq51ODtd53wuES5JY%3D&reserved=0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] Ensure correct order of evaluation in macro
Hi Martin, Would you feel comfortable merging my small patch in? I'd like to send additional patches that will improve these types of function macros so I'm hoping to start with this small change. Thanks, Sahil __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
