Re: [Rd] 1954 from NA

2021-05-23 Thread brodie gaslam via R-devel
I should add, I don't know that you can rely on this particular encoding of R's NA.  If I were trying to restore an NA from some external format, I would just generate an R NA via e.g NA_real_ in the R session I'm restoring the external data into, and not try to hand assemble one. Best, B. On

Re: [Rd] 1954 from NA

2021-05-23 Thread Mark van der Loo
I wrote about this once over here: http://www.markvanderloo.eu/yaRb/2012/07/08/representation-of-numerical-nas-in-r-and-the-1954-enigma/ -M Op zo 23 mei 2021 15:33 schreef brodie gaslam via R-devel < r-devel@r-project.org>: > I should add, I don't know that you can rely on this > particular

Re: [Rd] 1954 from NA

2021-05-23 Thread Adrian Dușa
Dear Tomas, I understand that perfectly, but that is fine. The payload is not going to be used in any computations anyways, it is strictly an information carrier that differentiates between different types of (tagged) NA values. Having only one NA value in R is extremely limiting for the social

Re: [Rd] 1954 from NA

2021-05-23 Thread Adrian Dușa
On Sun, May 23, 2021 at 4:33 PM brodie gaslam via R-devel < r-devel@r-project.org> wrote: > I should add, I don't know that you can rely on this > particular encoding of R's NA. If I were trying to restore > an NA from some external format, I would just generate an > R NA via e.g NA_real_ in the

Re: [Rd] 1954 from NA

2021-05-23 Thread brodie gaslam via R-devel
> On Sunday, May 23, 2021, 10:45:22 AM EDT, Adrian Dușa > wrote: > > On Sun, May 23, 2021 at 4:33 PM brodie gaslam via R-devel > wrote: > > I should add, I don't know that you can rely on this > > particular encoding of R's NA.  If I were trying to restore > > an NA from some external format,

Re: [Rd] 1954 from NA

2021-05-23 Thread Tomas Kalibera
TLDR: tagging R NAs is not possible. External software should not depend on how R currently implements NA, this may change at any time. Tagging of NA is not supported in R (if it were, it would have been documented). It would not be possible to implement such tagging reliably with the current

[Rd] 1954 from NA

2021-05-23 Thread Adrian Dușa
Dear R devs, I am probably missing something obvious, but still trying to understand why the 1954 from the definition of an NA has to fill 32 bits when it normally doesn't need more than 16. Wouldn't the code below achieve exactly the same thing? typedef union { double value; unsigned

Re: [Rd] 1954 from NA

2021-05-23 Thread brodie gaslam via R-devel
This is because the NA in question is NA_real_, which is encoded in double precision IEEE-754, which uses 64 bits.  The "1954" is just part of the NA.  The NA must also conform to the NaN encoding for double precision numbers, which requires that the "beginning" portion of the number be "0x7ff0"

Re: [Rd] 1954 from NA

2021-05-23 Thread Tomas Kalibera
On 5/23/21 8:04 PM, Adrian Dușa wrote: > Dear Tomas, > > I understand that perfectly, but that is fine. > The payload is not going to be used in any computations anyways, it is > strictly an information carrier that differentiates between different > types of (tagged) NA values. Good, but

Re: [Rd] 1954 from NA

2021-05-23 Thread Greg Minshall
+1 Avi Gross via R-devel wrote: > Arguably, R was not developed to satisfy some needs in the way intended. > > When I have had to work with datasets from some of the social sciences I have > had to adapt to subtleties in how they did things with software like SPSS in > which an NA was done

Re: [Rd] 1954 from NA

2021-05-23 Thread Avi Gross via R-devel
Arguably, R was not developed to satisfy some needs in the way intended. When I have had to work with datasets from some of the social sciences I have had to adapt to subtleties in how they did things with software like SPSS in which an NA was done using an out of bounds marker like 999 or "."

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Duncan Murdoch
This page https://bookdown.org/yihui/rmarkdown-cookbook/install-latex-pkgs.html suggests that executing this in R should fix the tikz issue: tinytex::parse_install( text = "! LaTeX Error: File `tikz.sty' not found." ) The "ks" message looks like a missing R package rather than a missing

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Spencer Graves
Hi, Duncan et al.: Thanks very much to Duncan for his suggestion. I did added the line Duncan suggested in three slightly different places. That fixed the problems with missing tex and pdflatex, but exposed two new problems: On Windows and ubuntu (both release and devel) I

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Duncan Murdoch
On 22/05/2021 10:05 p.m., Spencer Graves wrote: Hello: What do you suggest I do to enable GitHub Action to process "sos.Rnw" properly? The development version of my "sos" package passes "R CMD check" on my Mac but fails in all four platforms under GitHub Action on

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Spencer Graves
Hi, Duncan et al.: I inserted "the lines from the rgl workflow to work around the XQuartz issues" that Duncan provided after "env" in TWO places in R-CMD-check.yaml with the same result: GitHub Action worked fine on Windows and ubuntu (both release and devel) but failed on macOS

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Spencer Graves
Hi, Duncan et al.: Thanks again to Duncan. Your suggestions worked for the LaTeX problem, though it required multiple iterations, adding a total of 7 different "tinytex::parse_install" clauses to overcome other LaTeX and pdfTeX errors. However, macOS still says, "there is no

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Duncan Murdoch
I don't see where the connection is, but it's almost certainly coming in through your unconditional use of "fda::CRAN()". Since "fda" is not a hard requirement, this should be conditional on having it installed. Duncan Murdoch On 23/05/2021 5:25 p.m., Spencer Graves wrote: Hi, Duncan et

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Duncan Murdoch
Okay, I just worked out the chain: The fda package depends on fds. fds depends on rainbow. rainbow imports ks. ks imports plot3D. plot3D imports misc3d. misc3d imports tcltk. tcltk on macOS needs XQuartz. I saw this item online: https://github.com/actions/virtual-environments/issues/771 .

[R-pkg-devel] Troubleshoot unknown macro '\backslashemph' warning

2021-05-23 Thread Aravind J.
Hi, While checking two of my packages (https://github.com/aravind-j/EvaluateCore and https://github.com/aravind-j/augmentedRCBD)with winbuilder while preparing for submitting an updated version, I am getting the following warning. * checking Rd files ... [4s] WARNING prepare_Rd: :2: unknown

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Duncan Murdoch
For ks, if you look here: https://github.com/sbgraves237/sos/runs/2650960959?check_suite_focus=true in the "Install Dependencies" section, you'll see these errors: trying URL 'https://cloud.r-project.org/src/contrib/ks_1.13.0.tar.gz' Content type 'application/x-gzip' length 1076044 bytes (1.0

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

2021-05-23 Thread Spencer Graves
Hi, Duncan et al.: Thanks again. I removed fda from "suggests" and added it to "imports" in DESCRIPTION. I also added "importFrom('fda', 'CRAN')" to NAMESPACE. Sadly, the result was the same: It passed "R CMD check" on Windows, ubuntu, and my local Mac but not macOS on GitHub Action.

[Bioc-devel] VariantAnnotation Installation Compile Error

2021-05-23 Thread Dario Strbenac
Good day, I apparently have a valid Bioconductor package library but VariantAnnotation won't install successfully. > valid() [1] TRUE > install("VariantAnnotation") Bioconductor version 3.13 (BiocManager 1.30.15), R 4.1.0 (2021-05-18) Installing package(s) 'VariantAnnotation' trying URL