date:20161201

Re: [R-pkg-devel] Error in dyn.load(dllfile) : unable to load shared object

2016-12-01 Thread Dirk Eddelbuettel


On 1 December 2016 at 17:15, Aarti Singh wrote:
| Hello,
| 
| I am new to R package development. I am working on a package that has in
| its src folder  one (prime) cpp file and some helper cpp (X.Cpp, Y.Cpp) and
| one c file (Z.C) and their header files (X.h, Y.h and Z.h)
| 
| I am getting the following error when I do 'Build & Reload' in Rstudio.
| 
| "
| Error in dyn.load(dllfile) :
|   unable to load shared object '/Users/abcd/BART/bart_pkg1/src/bartpkg.so':
|   dlopen(/Users/abcd/BART/bart_pkg1/src/bartpkg.so, 6): Symbol not found:
| __ZN3RNG4nfixElm
|   Referenced from: /Users/abcd/BART/bart_pkg1/src/bartpkg.so
|   Expected in: flat namespace
|  in /Users/abcd/BART/bart_pkg1/src/bartpkg.so
| Calls: suppressPackageStartupMessages ...  -> load_all ->
| load_dll -> library.dynam2 -> dyn.load
| Execution halted
| 
| Exited with status 1.
| 
| "
| 
| I have followed the basic guidelines to build the package.
| 
| The .R file has directive #' @useDynLib bartpkg in the right place.
| 
| Also, the prime cpp file has the following tags in the right place.
| 1. #include 
|   using namespace Rcpp;
| 2.  //' @param x A single integer.
|  //' @export
|  // [[Rcpp::export]]
| 
| 
| And my NAMESPACE file shows 'useDynLib(bartpkg)' correctly.
| 
| I am able to see the 'bartpkg.so' shared object file in the src directory.
| 
| 
| I tried in the terminal this command "c++filt -n _ZN3RNG4nfixElm" and was
| able to see that the symbol in the error ' Symbol not found:
| __ZN3RNG4nfixElm' is coming from the .C file RNG.C and is because of a
| function 'nfix'.
| 
| But even if I remove the function 'nfix' or remove the RNG.C file
| altogether, the same error ' Symbol not found: __ZN3RNG4nfixElm' comes.
| 
| can it  be a flag issue that my compiler is not able to compile the 'C'
| file?
| I am able to see that all the cpp files generate respective object files,
| but I dont see anything like that for the C file.
| 
| I am using RStudio is the session info is
| > sessionInfo()
| R version 3.3.1 (2016-06-21)
| Platform: x86_64-apple-darwin13.4.0 (64-bit)
| Running under: OS X 10.11.6 (El Capitan)
| 
| locale:
| [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
| 
| attached base packages:
| [1] stats graphics  grDevices utils datasets  methods   base
| 
| other attached packages:
| [1] bartpkg_0.1.0packrat_0.4.8-1  Rcpp_0.12.8
| msm_1.6.4LaplacesDemon_16.0.1
| 
| loaded via a namespace (and not attached):
|  [1] roxygen2_5.0.1  lattice_0.20-34 mvtnorm_1.0-5   digest_0.6.10
| grid_3.3.1  magrittr_1.5
|  [7] stringi_1.1.2   Matrix_1.2-7.1  splines_3.3.1   tools_3.3.1
| stringr_1.1.0   survival_2.39-5
| [13] parallel_3.3.1  rsconnect_0.5   inline_0.3.14   expm_0.999-0
| 
| I am stuck at this problem for weeks now.
| Any help would be highly appreciated.

Please don't cross post, but I just gave you a hint at your identical
StackOverflow question:
http://stackoverflow.com/questions/40922814/error-in-dyn-loaddllfile-unable-to-load-shared-object-expected-in-flat-na#comment69060886_40922814

Dirk 
 
| Thank you.
| 
| -Aarti
| 
|   [[alternative HTML version deleted]]
| 
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

Re: [Bioc-devel] package vignette error : external data can't be captured when compiling package vignette

2016-12-01 Thread Hervé Pagès


Hi,

Make sure you understand the difference between the *package source
tree*, which you control and where you must create the inst/ folder,
and the *package installation folder*, which gets created and
populated by 'R CMD INSTALL'. The exact location of the *package
installation folder* doesn't really matter but if you are curious
you can use the .libPaths() command to see it. The *package installation
folder* is the subfolder of .libPaths() that has the name of the
package. You can also see it with find.package("mypackage").

During installation, everything that is under the inst/ folder will
get installed *directly* under the *package installation folder*.
So if you created the extdata/ folder under inst/ (as it should be),
extdata/ will end up being installed at .libPaths()/mypackage/extdata/
The code in your examples can get the path to the *installed* extdata/
folder with

  system.file(package="mypackage", "extdata")

or get the path to any file under extdata/ with e.g.

  system.file(package="mypackage", "extdata", "data1.bed")

Don't do

  system.file(package="mypackage", "extdata/data1.bed")

even if it works for you because it's not portable (the use of / as
a separator is a platform-dependent thing).

Finally note that you should never try to modify anything that is under
.libPaths() by hand. Furthermore, and that's a mistake we see sometimes
with contributed packages, the code in your package should always
treat the *package installation folder* as a read-only folder.

Hope this helps,

H.


On 12/01/2016 04:34 PM, Jurat Shayidin wrote:

Hi BiocDevel :

I am getting vignette error when I building my packages, and external data
can't be captured by system.file() . I did unit test all function of my
packages, it works fine. When I am going to compile package vignette, test
input bed file can't be detected. However, I used devtools::install()command
to install my packages, but installation directory inst/ was not created
automatically. By R package convention, all external data must be located
in inst/, so I manually created this folder  inst/extdata and paste my
data, but vignette compilation still failed. According to convention of R
package, my package structure will be:

myPackage
`- inst
`- extdata
`- data1.bed
`- data2.bed
`- R
`- ...
`- NAMESPACE
`- DESCRIPTION



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

[Bioc-devel] package vignette error : external data can't be captured when compiling package vignette

2016-12-01 Thread Jurat Shayidin

Hi BiocDevel :

I am getting vignette error when I building my packages, and external data
can't be captured by system.file() . I did unit test all function of my
packages, it works fine. When I am going to compile package vignette, test
input bed file can't be detected. However, I used devtools::install()command
to install my packages, but installation directory inst/ was not created
automatically. By R package convention, all external data must be located
in inst/, so I manually created this folder  inst/extdata and paste my
data, but vignette compilation still failed. According to convention of R
package, my package structure will be:

myPackage
`- inst
`- extdata
`- data1.bed
`- data2.bed
`- R
`- ...
`- NAMESPACE
`- DESCRIPTION

-- 

Note that readPeakFile take list of bed file as an input. Here is the toy
function I am going to use in vignette file .

readPeakFile<- function(mydat, ...) {
  files <- list.files(mydat, full.names = TRUE, "\\.bed$")
  readMe <- lapply(files, import.bed)
  return(readMe)}

I got error from this code chunk :

```{r}
library(MSPC)
inputBed <- list.files(system.file("extdata", package = "MSPC"), full.names
= TRUE)
inputData <- readPeakFile(peakFolder = inputBed)

inputData
```

Error: object 'inputData' not found

I tried another way which discussed in mailing list long time ago, but I
got empty list instead :

```{r}
library(MSPC)
extdata.dir <- system.file("extdata", package = "MSPC")
bedfiles <- dir(extdata.dir, pattern="\\.bed$", full.names=TRUE)
myData <- readPeakFiles(peakFolder = bedfiles)

myData
```
named list()

can't figure out why got these issue very often. why installation directory
inst not created automatically ? why test data can't be captured by
system.file() when compiling the package vignette ? I think inst must be
created automatically when I install my packages, but it didn't happen to
me, why is that ? How can I fix this compilation error for package vignette
? Any idea please ?

Here is what I got :

==> devtools::check()

Updating MSPC documentation
Loading MSPC
Writing NAMESPACE
Writing FDR_stats.Rd
Writing Fisher_stats.Rd
Writing MSPC-package.Rd
Writing info.Rd
Writing create_output.Rd
Writing denoise_ERs.Rd
Writing filterByFisherMethod.Rd
Writing filterByOverlapHit.Rd
Writing peakOverlapping.Rd
Writing pvalueConversion.Rd
Writing readPeakFiles.Rd
Setting env vars
---
CFLAGS  : -Wall -pedantic
CXXFLAGS: -Wall -pedantic
Building MSPC
--
"C:/PROGRA~1/R/R-devel/bin/x64/R" --no-site-file --no-environ --no-save  \
  --no-restore --quiet CMD build "C:\Users\jvrat\Documents\MSPC"  \
  --no-resave-data --no-manual

* checking for file 'C:\Users\jvrat\Documents\MSPC/DESCRIPTION' ... OK
* preparing 'MSPC':
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
Quitting from lines 46-52 (vignette.Rmd)
Error: processing vignette 'vignette.Rmd' failed with diagnostics:
length(peakFolder) > 0 is not TRUE
Execution halted
Warning: running command '"C:/PROGRA~1/R/R-devel/bin/x64/Rscript" --vanilla
--default-packages= -e "tools::buildVignettes(dir = '.', tangle = TRUE)"'
had status 1
Error: Command failed (1)
In addition: Warning message:
@importfrom [peakOverlapping.R#23]: unknown tag
Execution halted

Exited with status 1.




Jurat Shahidin

Dipartimento di Elettronica, Informazione e Bioingegneria
Politecnico di Milano
Piazza Leonardo da Vinci 32 - 20133 Milano, Italy
Mobile : +39 3279366608 <+39%20327%20936%206608>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Error in dyn.load(dllfile) : unable to load shared object

2016-12-01 Thread Aarti Singh

Hello,

I am new to R package development. I am working on a package that has in
its src folder  one (prime) cpp file and some helper cpp (X.Cpp, Y.Cpp) and
one c file (Z.C) and their header files (X.h, Y.h and Z.h)

I am getting the following error when I do 'Build & Reload' in Rstudio.

"
Error in dyn.load(dllfile) :
  unable to load shared object '/Users/abcd/BART/bart_pkg1/src/bartpkg.so':
  dlopen(/Users/abcd/BART/bart_pkg1/src/bartpkg.so, 6): Symbol not found:
__ZN3RNG4nfixElm
  Referenced from: /Users/abcd/BART/bart_pkg1/src/bartpkg.so
  Expected in: flat namespace
 in /Users/abcd/BART/bart_pkg1/src/bartpkg.so
Calls: suppressPackageStartupMessages ...  -> load_all ->
load_dll -> library.dynam2 -> dyn.load
Execution halted

Exited with status 1.

"

I have followed the basic guidelines to build the package.

The .R file has directive #' @useDynLib bartpkg in the right place.

Also, the prime cpp file has the following tags in the right place.
1. #include 
  using namespace Rcpp;
2.  //' @param x A single integer.
 //' @export
 // [[Rcpp::export]]


And my NAMESPACE file shows 'useDynLib(bartpkg)' correctly.

I am able to see the 'bartpkg.so' shared object file in the src directory.


I tried in the terminal this command "c++filt -n _ZN3RNG4nfixElm" and was
able to see that the symbol in the error ' Symbol not found:
__ZN3RNG4nfixElm' is coming from the .C file RNG.C and is because of a
function 'nfix'.

But even if I remove the function 'nfix' or remove the RNG.C file
altogether, the same error ' Symbol not found: __ZN3RNG4nfixElm' comes.

can it  be a flag issue that my compiler is not able to compile the 'C'
file?
I am able to see that all the cpp files generate respective object files,
but I dont see anything like that for the C file.

I am using RStudio is the session info is
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.6 (El Capitan)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] bartpkg_0.1.0packrat_0.4.8-1  Rcpp_0.12.8
msm_1.6.4LaplacesDemon_16.0.1

loaded via a namespace (and not attached):
 [1] roxygen2_5.0.1  lattice_0.20-34 mvtnorm_1.0-5   digest_0.6.10
grid_3.3.1  magrittr_1.5
 [7] stringi_1.1.2   Matrix_1.2-7.1  splines_3.3.1   tools_3.3.1
stringr_1.1.0   survival_2.39-5
[13] parallel_3.3.1  rsconnect_0.5   inline_0.3.14   expm_0.999-0

I am stuck at this problem for weeks now.
Any help would be highly appreciated.


Thank you.

-Aarti

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] [Bioc-degel] AnnotationHub needed in the description of the ExperimentHubData

2016-12-01 Thread Marcin Kosiński

Hi Valerie,

Thanks for the responce. Yes I have ExperimentHub in Depends.

In the following code results I present the `query` NOTE that comes out
after devtools::check().
Then I present the content of my DESCRIPTION file and NAMESPACE.
After I added AnnotationHub to Imports and importFrom(AnnotationHub, query)
to NAMESPACE, the NOTE disappeared



> devtools::check()
Updating RTCGA.clinical.20160128 documentation
Loading RTCGA.clinical.20160128
Setting env vars
--
CFLAGS  : -Wall -pedantic
CXXFLAGS: -Wall -pedantic
Building RTCGA.clinical.20160128
--
'/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
--quiet CMD build  \
  '/home/mkosinski/RTCGA.clinical.20160128' --no-resave-data --no-manual

* checking for file ‘/home/mkosinski/RTCGA.clinical.20160128/DESCRIPTION’
... OK
* preparing ‘RTCGA.clinical.20160128’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* looking to see if a ‘data/datalist’ file should be added
* building ‘RTCGA.clinical.20160128_0.99.0.tar.gz’

Setting env vars
--
_R_CHECK_CRAN_INCOMING_USE_ASPELL_: TRUE
_R_CHECK_CRAN_INCOMING_   : FALSE
_R_CHECK_FORCE_SUGGESTS_  : FALSE
Checking RTCGA.clinical.20160128
--
'/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
--quiet CMD check  \
  '/tmp/RtmpWLIOjs/RTCGA.clinical.20160128_0.99.0.tar.gz' --as-cran
--timings  \
  --no-manual

* using log directory ‘/tmp/RtmpWLIOjs/RTCGA.clinical.20160128.Rcheck’
* using R version 3.3.1 (2016-06-21)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using options ‘--no-manual --as-cran’
* checking for file ‘RTCGA.clinical.20160128/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘RTCGA.clinical.20160128’ version ‘0.99.0’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘RTCGA.clinical.20160128’ can be installed ... OK
* checking installed package size ... NOTE
  installed size is 18.2Mb
  sub-directories of 1Mb or more:
data  18.0Mb
* checking package directory ... OK
* checking ‘build’ directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... NOTE
Non-standard file/directory found at top level:
  ‘createTCGA.R’
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ...
OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
.onLoad :  : func: no visible global function definition for
  ‘query’
ACC.clinical.20160128: no visible global function definition for
  ‘query’
BLCA.clinical.20160128: no visible global function definition for
  ‘query’
BRCA.clinical.20160128: no visible global function definition for
  ‘query’
CESC.clinical.20160128: no visible global function definition for
  ‘query’
CHOL.clinical.20160128: no visible global function definition for
  ‘query’
COADREAD.clinical.20160128: no visible global function definition for
  ‘query’
DLBC.clinical.20160128: no visible global function definition for
  ‘query’
ESCA.clinical.20160128: no visible global function definition for
  ‘query’
FPPP.clinical.20160128: no visible global function definition for
  ‘query’
GBMLGG.clinical.20160128: no visible global function definition for
  ‘query’
HNSC.clinical.20160128: no visible global function definition for
  ‘query’
KICH.clinical.20160128: no visible global function definition for
  ‘query’
KIPAN.clinical.20160128: no visible global function definition for
  ‘query’
KIRC.clinical.20160128: no visible global function definition for
  ‘query’
KIRP.clinical.20160128: no visible global function

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

2016-12-01 Thread Ei-ji Nakama

hi,

my environment...
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

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

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

It's not a very good example...

f0<-function(x,y)exp(complex(real=x,imag=y))
f1<-function(x,y)complex(real=exp(1)^x*cos(y),imag=exp(1)^x*sin(y))
f2<-function(x,y)complex(real=exp(1)^x*cospi(y/pi),imag=exp(1)^x*sinpi(y/pi))

f0(700,1.23)
f1(700,1.23)
f2(700,1.23)

f0(700,1.23e23)
f1(700,1.23e23)
f2(700,1.23e23)

Garbage number is required.

Thank you!

2016-12-01 18:31 GMT+09:00 Prof Brian Ripley :
> Please note that you need to report your platforms (as per the posting
> guide), as the C function starts
>
> #ifdef HAVE_COSPI
> #elif defined HAVE___COSPI
> double cospi(double x) {
> return __cospi(x);
> }
>
> And AFAICS the system versions on Solaris and OS X behave the same way as
> R's substitute.
>
>
>
>
> On 01/12/2016 09:12, Martin Maechler wrote:
>>>
>>> Martin Maechler 
>>> on Thu, 1 Dec 2016 09:36:10 +0100 writes:
>>
>>
>>> Ei-ji Nakama 
>>> on Thu, 1 Dec 2016 14:39:55 +0900 writes:
>>
>>
>> >> Hi,
>> >> i try sin, cos, and tan.
>>
>> >>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> >> [1] 0.5444181 0.8388140 1.5407532
>>
>> >> However, *pi results the following
>>
>> >>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> >> [1] 1 0 0
>>
>> >> Please try whether the following becomes all right.
>>
>> > [..]
>>
>> > Yes, it does  -- the fix will be in all future versions of R.
>>
>> oops not so quickly, Martin!
>>
>> Of course, the results then coincide,  by sheer implementation.
>>
>> *BUT* it is not at all clear which of the two results is better;
>> e.g., if you replace '1.23' by '1' in the above examples, the
>> result of the unchnaged  *pi() functions is 100% accurate,
>> whereas
>>
>>  R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
>>  [1] -0.8847035 -0.4661541  0.5269043
>>
>> is "garbage".  After all,  1e45 is an even integer and so, the
>> (2pi)-periodic functions should give the same as for 0  which
>> *is*  (1, 0, 0).
>>
>> For such very large arguments, the results of all of sin() ,
>> cos() and tan()  are in some sense "random garbage" by
>> necessity:
>> Such large numbers have zero information about the resolution modulo
>> [0, 2pi)  or (-pi, pi]  and hence any (non-trivial) periodic
>> function with such a "small" period can only return "random noise".
>>
>>
>> > Thank you very much Ei-ji Nakama, for this valuable contribution
>> > to make R better!
>>
>> That is still true!  It raises the issue to all of us and will
>> improve the documentation at least!
>>
>> At the moment, I'm not sure where we should go.
>> Of course, I could start experiments using my own 'Rmpfr'
>> package where I can (with increasing computational effort!) get
>> correct values (for increasingly larger arguments) but at the
>> moment, I don't see how this would help.
>>
>> Martin
>
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford



-- 
Best Regards,
--
Eiji NAKAMA 
"\u4e2d\u9593\u6804\u6cbb"  

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

Re: [Rd] problem with normalizePath()

2016-12-01 Thread Martin Maechler

> Evan Cortens 
> on Wed, 30 Nov 2016 09:58:59 -0700 writes:

> I found this as well. At our institution, our home directories are on
> network shares that are mapped to local drives. The default, it appears, 
is
> to set the location for libraries (etc) to the network share name
> (//computer//share/director/a/b/user) rather than the local drive mapping
> (H:/). Given the issue with dir.create(), this means it's impossible to
> install packages (since it tries to "create" the share, not the highest
> directory). This can be fixed in the same way Michael found, namely, set
> the environment variables to use the local mapping rather than the network
> share. But ideally, the fix would be to treat Windows network paths
> correctly.

Yes, and why shouldn't Microsoft be the institution who can best
judge how to do that,  now that they sell a "Microsoft R"  ?? 
!??!?!??!?!??!?
(trying again with BCC;  next time, I'll use CC).

(a slowly increasingly frustrated)
Martin Maechler
ETH Zurich

> Best,
> Evan

> On Wed, Nov 30, 2016 at 7:16 AM, Laviolette, Michael <
> michael.laviole...@dhhs.nh.gov> wrote:

>> In researching another issue, I discovered a workaround: the network 
drive
>> folder needs to be mapped to the local PC.
>> 
>> setwd("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/Michael Laviolette/Stat
>> tools")
>> df1 <- readxl::read_excel("addrlist-4-MikeL.xls", 2)
>> # fails, throws same error
>> df2 <- readxl::read_excel("Z:/Stat tools/addrlist-4-MikeL.xls", 2)  #
>> works
>> 
>> -Original Message-
>> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>> Sent: Friday, November 18, 2016 3:37 PM
>> To: Evan Cortens
>> Cc: Laviolette, Michael; r-devel@r-project.org
>> Subject: Re: [Rd] problem with normalizePath()
>> 
>> > Evan Cortens 
>> > on Thu, 17 Nov 2016 15:51:03 -0700 writes:
>> 
>> > I wonder if this could be related to the issue that I
>> > submitted to bugzilla about two months ago? (
>> > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159)
>> 
>> > That is to say, could it be that it's treating the first
>> > path after the single backslash as an actual directory,
>> > rather than as the name of the share?
>> 
>> > --
>> > Evan Cortens, PhD Institutional Analyst - Office of
>> > Institutional Analysis Mount Royal University 403-440-6529
>> 
>> Could well be.  Thank you, Evan, also for your bug report including patch
>> proposal.
>> 
>> In such situations we (R core) would be really happy if Microsoft showed
>> another facet of their investment into R:
>> Ideally there should be enough staff who can judge and test such bugs and
>> bug fixes?
>> 
--> I'm BCC'ing this to one place at least.
>> 
>> Best,
>> Martin Maechler  ETH Zurich
>> 
>> > On Thu, Nov 17, 2016 at 2:28 PM, Laviolette, Michael <
>> > michael.laviole...@dhhs.nh.gov> wrote:
>> 
>> >> The packages "readxl" and "haven" (and possibly others)
>> >> no longer access files on shared network drives. The
>> >> problem appears to be in the normalizePath()
>> >> function. The file can be read from a local drive or by
>> >> functions that don't call normalizePath(). The error
>> >> thrown is
>> >>
>> >> Error:
>> >> path[1]="\\Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls":
>> >> The system cannot find the file specified
>> >>
>> >> Here's my session:
>> >>
>> >> library(readxl) library(XLConnect)
>> >>
>> >> # attempting to read file from network drive df1 <-
>> >> read_excel("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls")
>> >> # pathname is fully qualified, but error thrown as above
>> >>
>> >> cat(normalizePath("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls"))
>> >> # throws same error
>> >>
>> >> # reading same file with different function df2 <-
>> >> readWorksheetFromFile("//Hzndhhsvf2/data/OCPH/EPI/
>> BHSDM/Group/17.xls",
>> >> 1) # completes successfully
>> >>
>> >> # reading same file from local drive df3 <-
>> >> read_excel("C:/17.xls") # completes successfully
>> >>
>> >> sessionInfo() R version 3.3.2 (2016-10-31) Platform:
>> >> x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7
>> >> x64 (build 7601) Service Pack 1
>> >>
>> >> locale: [1] LC_COLLATE=English_United States.1252
>> >> LC_CTYPE=English_United States.1252 [3]
>> >> LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5]
>> >> LC_TIME=English_United States.1252
>> >>
>> >> attached base packages: [1] stats graphics grDevices
>> >> utils datasets methods base
>> >>
>> >> other attached packages: [1] readxl_0.1.1 dplyr_0.5.0
>> >> XLConnect_0.2-12 [4]

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

2016-12-01 Thread Prof Brian Ripley

Please note that you need to report your platforms (as per the posting 
guide), as the C function starts

#ifdef HAVE_COSPI
#elif defined HAVE___COSPI
double cospi(double x) {
return __cospi(x);
}

And AFAICS the system versions on Solaris and OS X behave the same way 
as R's substitute.

On 01/12/2016 09:12, Martin Maechler wrote:

Martin Maechler 
on Thu, 1 Dec 2016 09:36:10 +0100 writes:

Ei-ji Nakama 
on Thu, 1 Dec 2016 14:39:55 +0900 writes:

>> Hi,
>> i try sin, cos, and tan.

>>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> [1] 0.5444181 0.8388140 1.5407532

>> However, *pi results the following

>>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> [1] 1 0 0

>> Please try whether the following becomes all right.

> [..]

> Yes, it does  -- the fix will be in all future versions of R.

oops not so quickly, Martin!

Of course, the results then coincide,  by sheer implementation.

*BUT* it is not at all clear which of the two results is better;
e.g., if you replace '1.23' by '1' in the above examples, the
result of the unchnaged  *pi() functions is 100% accurate,
whereas

 R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
 [1] -0.8847035 -0.4661541  0.5269043

is "garbage".  After all,  1e45 is an even integer and so, the
(2pi)-periodic functions should give the same as for 0  which
*is*  (1, 0, 0).

For such very large arguments, the results of all of sin() ,
cos() and tan()  are in some sense "random garbage" by
necessity:
Such large numbers have zero information about the resolution modulo
[0, 2pi)  or (-pi, pi]  and hence any (non-trivial) periodic
function with such a "small" period can only return "random noise".

> Thank you very much Ei-ji Nakama, for this valuable contribution
> to make R better!

That is still true!  It raises the issue to all of us and will
improve the documentation at least!

At the moment, I'm not sure where we should go.
Of course, I could start experiments using my own 'Rmpfr'
package where I can (with increasing computational effort!) get
correct values (for increasingly larger arguments) but at the
moment, I don't see how this would help.

Martin

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

2016-12-01 Thread Martin Maechler

> Martin Maechler 
> on Thu, 1 Dec 2016 09:36:10 +0100 writes:

> Ei-ji Nakama 
> on Thu, 1 Dec 2016 14:39:55 +0900 writes:

>> Hi,
>> i try sin, cos, and tan.

>>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> [1] 0.5444181 0.8388140 1.5407532

>> However, *pi results the following

>>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> [1] 1 0 0

>> Please try whether the following becomes all right.

> [..]

> Yes, it does  -- the fix will be in all future versions of R.

oops not so quickly, Martin!

Of course, the results then coincide,  by sheer implementation.

*BUT* it is not at all clear which of the two results is better;
e.g., if you replace '1.23' by '1' in the above examples, the
result of the unchnaged  *pi() functions is 100% accurate,
whereas

 R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
 [1] -0.8847035 -0.4661541  0.5269043

is "garbage".  After all,  1e45 is an even integer and so, the
(2pi)-periodic functions should give the same as for 0  which
*is*  (1, 0, 0).

For such very large arguments, the results of all of sin() ,
cos() and tan()  are in some sense "random garbage" by
necessity:
Such large numbers have zero information about the resolution modulo
[0, 2pi)  or (-pi, pi]  and hence any (non-trivial) periodic
function with such a "small" period can only return "random noise".

> Thank you very much Ei-ji Nakama, for this valuable contribution
> to make R better!

That is still true!  It raises the issue to all of us and will
improve the documentation at least!

At the moment, I'm not sure where we should go.
Of course, I could start experiments using my own 'Rmpfr'
package where I can (with increasing computational effort!) get
correct values (for increasingly larger arguments) but at the
moment, I don't see how this would help.

Martin

> Martin Maechler,
> ETH Zurich

>> -- 
>> Best Regards,
>> --
>> Eiji NAKAMA 
>> "\u4e2d\u9593\u6804\u6cbb"  

> __
> 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] Different results for cos,sin,tan and cospi,sinpi,tanpi

2016-12-01 Thread Martin Maechler

> Ei-ji Nakama 
> on Thu, 1 Dec 2016 14:39:55 +0900 writes:

> Hi,
> i try sin, cos, and tan.

>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
> [1] 0.5444181 0.8388140 1.5407532

> However, *pi results the following

>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
> [1] 1 0 0

> Please try whether the following becomes all right.

[..]

Yes, it does  -- the fix will be in all future versions of R.

Thank you very much Ei-ji Nakama, for this valuable contribution
to make R better!

Martin Maechler,
ETH Zurich


> -- 
> Best Regards,
> --
> Eiji NAKAMA 
> "\u4e2d\u9593\u6804\u6cbb"  

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

Re: [R-pkg-devel] Error in dyn.load(dllfile) : unable to load shared object

Re: [Bioc-devel] package vignette error : external data can't be captured when compiling package vignette

[Bioc-devel] package vignette error : external data can't be captured when compiling package vignette

[R-pkg-devel] Error in dyn.load(dllfile) : unable to load shared object

Re: [Bioc-devel] [Bioc-degel] AnnotationHub needed in the description of the ExperimentHubData

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

Re: [Rd] problem with normalizePath()

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

10 matches

Site Navigation

Mail list logo

Footer information