[Rd] Recent changes to as.complex(NA_real_)
Revisiting this thread from April:
https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
where the decision (not yet backported) was made for as.complex(NA_real_)
to give NA_complex_ instead of complex(r=NA_real_, i=0), to be consistent
with help("as.complex") and as.complex(NA) and as.complex(NA_integer_).
Was any consideration given to the alternative? That is, to changing
as.complex(NA) and as.complex(NA_integer_) to give complex(r=NA_real_, i=0),
consistent with as.complex(NA_real_), then amending help("as.complex")
accordingly?
The principle that Im(as.complex()) should
be zero is quite fundamental, in my view, hence the "new" behaviour seems
to really violate the principle of least surprise ...
Another (but maybe weaker) argument is that double->complex coercions happen
more often than logical->complex and integer->complex ones. Changing the
behaviour of the more frequently performed coercion is more likely to affect
code "out there".
Yet another argument is that one expects
identical(as.complex(NA_real_), NA_real_ + (0+0i))
to be TRUE, i.e., that coercing from double to complex is equivalent to
adding a complex zero. The new behaviour makes the above FALSE, since
NA_real_ + (0+0i) gives complex(r=NA_real_, i=0).
Having said that, one might also (but more naively) expect
identical(as.complex(as.double(NA_complex_)), NA_complex_)
to be TRUE. Under my proposal it continues to be FALSE. Well, I'd prefer
if it gave FALSE with a warning "imaginary parts discarded in coercion",
but it seems that as.double(complex(r=a, i=b)) never warns when either of
'a' and 'b' is NA_real_ or NaN, even where "information" {nonzero 'b'} is
clearly lost ...
Whatever decision is made about as.complex(NA_real_), maybe these points
should be weighed before it becomes part of R-release ...
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
Hi
The problem is what "supports UNICODE" means.
Graphics devices have a 'hasTextUTF8' boolean to indicate that ...
/* Some devices can plot UTF-8 text directly without converting
to the native encoding, e.g. windows(), quartz()
If this flag is true, all text *not in the symbol font* is sent
in UTF8 to the textUTF8/strWidthUTF8 entry points.
... and this is TRUE for the pdf() device for example.
It is also TRUE for Cairo devices, but the support is quite different
(as your examples demonstrate).
The Cairo devices do not alter UTF8 text at all, but the pdf() device
attempts to convert to a single-byte representation, which of course
will not always work.
The situation is only made more complex with the recent dev->glyph()
support because that offers another possible route to producing generic
UNICODE characters, including on pdf() devices.
Paul
On 21/09/23 04:12, Trevor Davis wrote:
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> > Trevor Davis
> > on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[R-pkg-devel] A simple question regarding examples
Hello,
I have a simple question about including examples. My code depends on a rarely
used Python module, so I am using the @examplesIf tag per Hadley Wickham's
advice as follows:
#' @examplesIf reticulate::py_module_available('ctef')
#' res <- my_func(input1, input2)
Unfortunately, my_func runs overtime during the CRAN check. To resolve this, do
I simply use the less elegant approach as follows?
#' \dontrun{
#' if (reticulate::py_module_available('ctef')) {
#' res <- my_func(input1, input2)
#' }
Thank you,
Hanyu
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> > Trevor Davis
> > on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
> Trevor Davis
> on Thu, 31 Aug 2023 13:49:03 -0700 writes:
> Hi,
> It would be nice if `grDevices::dev.capabilities()` could also be used to
> query whether the current graphics device supports Unicode. In such a
case
> I'd expect it to return `FALSE` if `pdf()` is the current graphics device
> and something else for the Cairo or Quartz devices.
> Thanks,
> Trevor
I agree in principle that this would be useful new feature for
dev.capabilities()
However, pdf() *does* support Unicode.
The problem is that some pdf *viewers*,
notably `evince` on Fedora Linux, for several years now,
do *not* show *some* of the UTF-8 glyphs because they do not use
the correct fonts {which *are* on the machine; good old `xpdf`
does in that case show the glyphs}.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Checking the number of cores used
20 сентября 2023 г. 8:27:31 UTC, Shu Fai Cheung пишет: >Third, the "testthat.Rout" file only shows the total time: > >> proc.time() > user system elapsed > 13.530 0.291 29.492 > >I believe the user time is not useful as we can use two processes in >testthat. How can we detect the use of more than two cores in the >tests? R could report CPU and elapsed tme for each test file in tests/*.R, but with testthat, it only sees tests/testthat.R, which isn't very useful. If you know R6, it should be possible to implement a CPUTimeReporter that would collect information about CPU and "wallclock" time taken by each individual test: https://testthat.r-lib.org/reference/Reporter.html It may be worth submitting a feature request for such a reporter. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
Thanks for the suggestion. I will use rhub and a virtual machine to check again.
I read some previous posts and I thought I need to check the times to
see if there is any unintended usage of parallel processing, e.g., CPU
time > 2 x elapsed time. May I ask a few questions on this part?
This is from the "-Ex.Rout" file:
> base::cat("Time elapsed: ", proc.time() - base::get("ptime", pos =
> 'CheckExEnv'),"\n")
Time elapsed: 14.94 0.27 15.26 NA NA
First, is this something I can ignore, unless the CPU time is
substantially larger than elapsed time? This is the total time but the
parallel process may be triggered in only one of the many examples.
Second, are the files "-Ex.timings", showing per-example timing, only
available on some platforms? I could get it locally in Windows, and
can find it in Winbuilder output. However, I could not find them in
the rhub platforms I tried, not even in the Windows platform. I
suppose adding "--as-cran" will also add "--timings"?
Third, the "testthat.Rout" file only shows the total time:
> proc.time()
user system elapsed
13.530 0.291 29.492
I believe the user time is not useful as we can use two processes in
testthat. How can we detect the use of more than two cores in the
tests?
Last, how can we detect the use of more than two cores in vignettes? I
checked and couldn't find similar timing information on vignettes.
Sorry for asking so many questions. I would like to have a reliable
way to detect hidden use of parallel processing such that I can
prevent the problem from happening. I have some ideas which package I
imported is causing the problem but I have used it before without
problem. Therefore, I would like to see if I overlooked anything.
Regards,
Shu Fai
On Tue, Sep 19, 2023 at 5:02 PM Uwe Ligges
wrote:
>
>
>
> On 18.09.2023 16:10, Shu Fai Cheung wrote:
> > Hi All,
> >
> > I know we should not use more than 2 cores in tests, vignettes, etc. I
> > encountered and solved this issue before. However, I still committed
> > this mistake in a new package and would like find out where the cause
> > is.
> >
> > I have a package that already has parallel processing disabled by
> > default and I did not enable parallel processing in the examples and
> > tests (except for one test, which is always skipped by skip()).
> > However, I was told that somewhere in the package more than 2 cores
> > are used.
> >
> > I checked several times and even added a temporary 'stop()` to "trap"
> > parallel processing but still could not find where the source of the
> > problem is.
> >
> > I checked the timing in the log in R CMD check results from winbuilder
> > but everything seems OK. The user time and elapsed time are similar
> > for all the examples.
> >
> > Is there any quick way to check where things go wrong regarding the
> > number of cores? It is not easy to find the source of the problems
> > when there are many examples and tests.
>
> If it is OK on winbuilder but not on Linux, then likely something makes
> use of multithreading.
>
> Best,
> Uwe Ligges
>
>
>
> > Regards,
> > Shu Fai
> >
> > __
> > 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: [R-pkg-devel] Checking the number of cores used
Thanks a lot. I don't have a physical linux box and so I need to use
rhub. But I don't know why there are no "-Ex.timings" files in the
check. E.g,
check(platform = "debian-gcc-release", show_status = FALSE, check_args
= "--as-cran")
I can only see these files in artifacts:
[ ]00check.log2023-09-20 08:00 3.4K
[ ]00install.out2023-09-20 08:00 702
[ ]Rdlatex.log2023-09-20 08:00 30K
[ ]modelbpp-Ex.Rout2023-09-20 08:00 28K
[ ]modelbpp-manual.log2023-09-20 08:00 19K
The case is the same for this, no "-Ex.timings" files:
check(platform = "windows-x86_64-release", show_status = FALSE,
check_args = "--as-cran")
Although I think I need to, I tried adding "--timings" but still do
not see the "-Ex.timings".
However, if I run the check locally in Windows 10 using R CMD check
with --as-cran, I can find the "-Ex.timings" files.
I can find the total time at the end of "-Ex.Rout" but I think this is
not what I need:
> base::cat("Time elapsed: ", proc.time() - base::get("ptime", pos =
> 'CheckExEnv'),"\n")
Time elapsed: 10.963 0.161 13.589 0.302 0.081
Regards,
Shu Fai
On Tue, Sep 19, 2023 at 5:59 PM Duncan Murdoch wrote:
>
> On 18/09/2023 10:10 a.m., Shu Fai Cheung wrote:
> > Hi All,
> >
> > I know we should not use more than 2 cores in tests, vignettes, etc. I
> > encountered and solved this issue before. However, I still committed
> > this mistake in a new package and would like find out where the cause
> > is.
> >
> > I have a package that already has parallel processing disabled by
> > default and I did not enable parallel processing in the examples and
> > tests (except for one test, which is always skipped by skip()).
> > However, I was told that somewhere in the package more than 2 cores
> > are used.
> >
> > I checked several times and even added a temporary 'stop()` to "trap"
> > parallel processing but still could not find where the source of the
> > problem is.
> >
> > I checked the timing in the log in R CMD check results from winbuilder
> > but everything seems OK. The user time and elapsed time are similar
> > for all the examples.
> >
> > Is there any quick way to check where things go wrong regarding the
> > number of cores? It is not easy to find the source of the problems
> > when there are many examples and tests.
>
> If you run R CMD check at the command line, it will produce a
> directory *.Rcheck containing a number of files. One of those files
> will be *-Ex.timings, which will give the individual timings of each of
> the examples in your package. Maybe you can recognize from those which
> of the examples are problematic ones, and add `proc.time()` calls to the
> example to figure out which line(s) cause the issue.
>
> I don't remember whether winbuilder keeps the timings file when it runs
> a check.
>
> Duncan Murdoch
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
