Re: [Rd] Runnable R packages

2019-02-01 Thread David Lindelof 
@Barry I'm not sure your proposal would work, since `R CMD INSTALL` won't
install a package's dependencies. Indeed it will fail with an error unless
all the dependencies are met before calling it.

Speaking of which, why doesn't R CMD INSTALL install a package's
dependencies? Would it make sense to submit this as a desirable feature?

Cheers,

David

On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:

>
>
> On Thu, Jan 31, 2019 at 3:14 PM David Lindelof  wrote:
>
>>
>> In summary, I'm convinced R would benefit from something similar to Java's
>> `Main-Class` header or Python's `__main__()` function. A new R CMD command
>> would take a package, install its dependencies, and run its "main"
>> function.
>
>
>
> I just created and built a very boilerplate R package called "runme". I
> can install its dependencies and run its "main" function with:
>
>  $ R CMD INSTALL runme_0.0.0.9000.tar.gz
>  $ R -e 'runme::main()'
>
> No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with
> python and java and C the entrypoint is more tightly specified (__name__ ==
> "__main__" in python, int main(..) in C and so on). But I don't think
> that's much of a problem.
>
> Does that not satisfy your requirements close enough? If you want it in
> one line then:
>
> R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()'
>
> will do the second if the first succeeds (Unix shells).
>
> You could write a script for $RHOME/bin/RUN which would be a two-liner and
> that could mandate the use of "main" as an entry point. But good luck
> getting anything into base R.
>
> Barry
>
>
>
>
>> If we have this machinery available, we could even consider
>> reaching out to Spark (and other tech stacks) developers and make it
>> easier
>> to develop R applications for those platforms.
>>
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] nlminb with constraints failing on some platforms

2019-02-01 Thread Martin Maechler 
> Kasper Kristensen via R-devel 
> on Mon, 28 Jan 2019 08:56:39 + writes:

> I've noticed unstable behavior of nlminb on some Linux
> systems. The problem can be reproduced by compiling
> R-3.5.2 using gcc-8.2 and running the following snippet:

> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> xhat <- rep(1, 10)
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

> The example works perfectly when removing the bounds. However, when 
bounds are added the snippet returns 'FALSE'.

> An older R version (3.4.4), compiled using the same gcc-8.2, did not have 
the problem. Between the two versions R has changed the flags to compile 
Fortran sources:

> < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
> ---
>> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse

> Reverting to the old SAFE_FFLAGS 'solves' the problem.

>> sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Scientific Linux release 6.4 (Carbon)

> Matrix products: default
> BLAS/LAPACK: 
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so

> locale:
> [1] C

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

> loaded via a namespace (and not attached):
> [1] compiler_3.5.2

So you us Intel's MKL library for BLAS/LAPACK ..

I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
and don't see such problems:

The code

f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)
xhat <- rep(1, 10)
all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

gives

> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par: num [1:10] 1 1 1 1 1 ...
 $ objective  : num -41.4
 $ convergence: int 0
 $ iterations : int 66
 $ evaluations: Named int [1:2] 96 830
  ..- attr(*, "names")= chr [1:2] "function" "gradient"
 $ message: chr "relative convergence (4)"
> xhat <- rep(1, 10)
> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
[1] "Mean relative difference: 5.534757e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 1.816536e-12"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] TRUE
>

for me. Maybe others can quickly run the above  7 lines and report ?

Maybe there's something else unusual with your Linux
distribution's libraries?

I'm not an expert on these compiler flags; have you seen what
the R-admin manual
https://cran.r-project.org/doc/manuals/R-admin.html#Linux
says about them?

Best,
Martin

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

Re: [Rd] nlminb with constraints failing on some platforms

2019-02-01 Thread Ralf Stubner 
On 01.02.19 10:00, Martin Maechler wrote:
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
> List of 6
>  $ par: num [1:10] 1 1 1 1 1 ...
>  $ objective  : num -41.4
>  $ convergence: int 0
>  $ iterations : int 66
>  $ evaluations: Named int [1:2] 96 830
>   ..- attr(*, "names")= chr [1:2] "function" "gradient"
>  $ message: chr "relative convergence (4)"
>> xhat <- rep(1, 10)
>> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 5.534757e-07"
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.816536e-12"
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE
>>
> 
> for me. Maybe others can quickly run the above  7 lines and report ?

Similar but not equal results for me:

> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par: num [1:10] 1 1 1 1 1 ...
 $ objective  : num -41.4
 $ convergence: int 0
 $ iterations : int 66
 $ evaluations: Named int [1:2] 96 830
  ..- attr(*, "names")= chr [1:2] "function" "gradient"
 $ message: chr "relative convergence (4)"
> xhat <- rep(1, 10)
> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
[1] "Mean relative difference: 3.266165e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 6.722005e-13"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] TRUE


Setup:

* Debian Stable with gcc 6.2
* R 3.5.2 from CRAN repository
* OpenBLAS

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nlminb with constraints failing on some platforms

2019-02-01 Thread Berend Hasselman 



> On 1 Feb 2019, at 10:00, Martin Maechler  wrote:
> 
> 
>>> sessionInfo()
>> R version 3.5.2 (2018-12-20)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Scientific Linux release 6.4 (Carbon)
> 
>> Matrix products: default
>> BLAS/LAPACK: 
>> /zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> 
>> locale:
>> [1] C
> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
> 
>> loaded via a namespace (and not attached):
>> [1] compiler_3.5.2
> 
> So you us Intel's MKL library for BLAS/LAPACK ..
> 
> I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
> and don't see such problems:
> 
> The code
> 
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
> xhat <- rep(1, 10)
> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> 
> gives
> 
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
> List of 6
> $ par: num [1:10] 1 1 1 1 1 ...
> $ objective  : num -41.4
> $ convergence: int 0
> $ iterations : int 66
> $ evaluations: Named int [1:2] 96 830
>  ..- attr(*, "names")= chr [1:2] "function" "gradient"
> $ message: chr "relative convergence (4)"
>> xhat <- rep(1, 10)
>> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 5.534757e-07"
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.816536e-12"
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE
>> 
> 
> for me. Maybe others can quickly run the above  7 lines and report ?
> 

Identical result on R 3.5.2 on macOS 10.14.3 with the CRAN version of R.


Berend Hasselman

> Maybe there's something else unusual with your Linux
> distribution's libraries?
> 
> I'm not an expert on these compiler flags; have you seen what
> the R-admin manual
>https://cran.r-project.org/doc/manuals/R-admin.html#Linux
> says about them?
> 
> Best,
> Martin
> 
> __
> 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] nlminb with constraints failing on some platforms

2019-02-01 Thread Martin Maechler 
> Berend Hasselman 
> on Fri, 1 Feb 2019 15:59:58 +0100 writes:

>> On 1 Feb 2019, at 10:00, Martin Maechler  
wrote:
>> 
>> 
 sessionInfo()
>>> R version 3.5.2 (2018-12-20)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Scientific Linux release 6.4 (Carbon)
>> 
>>> Matrix products: default
>>> BLAS/LAPACK: 
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
>> 
>>> locale:
>>> [1] C
>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.5.2
>> 
>> So you us Intel's MKL library for BLAS/LAPACK ..
>> 
>> I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
>> and don't see such problems:
>> 
>> The code
>> 
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
>> xhat <- rep(1, 10)
>> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
>> 
>> gives
>> 
>>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>>> str(opt)
>> List of 6
>> $ par: num [1:10] 1 1 1 1 1 ...
>> $ objective  : num -41.4
>> $ convergence: int 0
>> $ iterations : int 66
>> $ evaluations: Named int [1:2] 96 830
>> ..- attr(*, "names")= chr [1:2] "function" "gradient"
>> $ message: chr "relative convergence (4)"
>>> xhat <- rep(1, 10)
>>> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
>> [1] "Mean relative difference: 5.534757e-07"
>>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
>> [1] "Mean relative difference: 1.816536e-12"
>>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
>> [1] TRUE
>>> 
>> 
>> for me. Maybe others can quickly run the above  7 lines and report ?
>> 

> Identical result on R 3.5.2 on macOS 10.14.3 with the CRAN version of R.

> Berend Hasselman

Thank you, Berend, and Ralf (with gcc 6.2 and OpenBLAS),
for your reports.

In the mean time I also had tried Windows 32bit and 64bit, today's
R-devel version from CRAN (on a Terminal server) and also got
identical results for 64 bit and astonishingly even a bit more
accuracy for the 32 bit version.

So far, Kasper's platform is the only one where there's been a
problem, but I think it would be good to see/hear more here,
notably for people with optimized non-default BLAS/LAPACK or
system libraries...

>> Maybe there's something else unusual with your Linux
>> distribution's libraries?
>> 
>> I'm not an expert on these compiler flags; have you seen what
>> the R-admin manual
>> https://cran.r-project.org/doc/manuals/R-admin.html#Linux
>> says about them?
>> 
>> Best,
>> Martin
>> 
>> __
>> 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] Runnable R packages

2019-02-01 Thread Barry Rowlingson 
Ummm oops. Magic pixies? It assumed all of CRAN was installed?

Maybe I'll write something that could go in /usr/lib/R/bin/RUN that
checks and gets deps, installs the package, and runs package::main,
which I think is what the OP wants - you could do R CMD RUN
foo_1.0.0.tar.gz and away it goes...

B


On Thu, Jan 31, 2019 at 3:56 PM David Lindelof  wrote:
>
> Would you care to share how your package installs its own dependencies? I 
> assume this is done during the call to `main()`? (Last time I checked, R CMD 
> INSTALL would not install a package's dependencies...)
>
>
> On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson 
>  wrote:
>>
>>
>>
>> On Thu, Jan 31, 2019 at 3:14 PM David Lindelof  wrote:
>>>
>>>
>>> In summary, I'm convinced R would benefit from something similar to Java's
>>> `Main-Class` header or Python's `__main__()` function. A new R CMD command
>>> would take a package, install its dependencies, and run its "main"
>>> function.
>>
>>
>>
>> I just created and built a very boilerplate R package called "runme". I can 
>> install its dependencies and run its "main" function with:
>>
>>  $ R CMD INSTALL runme_0.0.0.9000.tar.gz
>>  $ R -e 'runme::main()'
>>
>> No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with 
>> python and java and C the entrypoint is more tightly specified (__name__ == 
>> "__main__" in python, int main(..) in C and so on). But I don't think that's 
>> much of a problem.
>>
>> Does that not satisfy your requirements close enough? If you want it in one 
>> line then:
>>
>> R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()'
>>
>> will do the second if the first succeeds (Unix shells).
>>
>> You could write a script for $RHOME/bin/RUN which would be a two-liner and 
>> that could mandate the use of "main" as an entry point. But good luck 
>> getting anything into base R.
>>
>> Barry
>>
>>
>>
>>>
>>> If we have this machinery available, we could even consider
>>> reaching out to Spark (and other tech stacks) developers and make it easier
>>> to develop R applications for those platforms.
>>>
>>
>>

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

Re: [Rd] nlminb with constraints failing on some platforms

2019-02-01 Thread Rui Barradas 

Hello,

R 3.5.2 on ubuntu 18.04. sessionInfo() at the end.
Works with me, same results, cannot reproduce the error.


f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)

xhat <- rep(1, 10)
all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
#[1] "Mean relative difference: 5.534757e-07"
all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
#[1] "Mean relative difference: 1.816536e-12"
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
#[1] TRUE


Hope this helps,

Rui Barradas


sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1

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

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

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.0   rstudioapi_0.8   bindr_0.1.1  magrittr_1.5
 [5] tidyselect_0.2.5 munsell_0.5.0colorspace_1.3-2 lattice_0.20-38
 [9] R6_2.3.0 rlang_0.3.0.1stringr_1.3.1plyr_1.8.4
[13] dplyr_0.7.8  tools_3.5.2  grid_3.5.2   yaml_2.2.0
[17] assertthat_0.2.0 tibble_1.4.2 crayon_1.3.4 bindrcpp_0.2.2
[21] purrr_0.2.5  reshape2_1.4.3   glue_1.3.0   stringi_1.2.4
[25] compiler_3.5.2   pillar_1.3.1 scales_1.0.0 lubridate_1.7.4
[29] pkgconfig_2.0.2  zoo_1.8-4




Às 09:00 de 01/02/2019, Martin Maechler escreveu:

Kasper Kristensen via R-devel
 on Mon, 28 Jan 2019 08:56:39 + writes:


 > I've noticed unstable behavior of nlminb on some Linux
 > systems. The problem can be reproduced by compiling
 > R-3.5.2 using gcc-8.2 and running the following snippet:

 > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
 > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
 > xhat <- rep(1, 10)
 > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

 > The example works perfectly when removing the bounds. However, when 
bounds are added the snippet returns 'FALSE'.

 > An older R version (3.4.4), compiled using the same gcc-8.2, did not 
have the problem. Between the two versions R has changed the flags to compile 
Fortran sources:

 > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
 > ---
 >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse

 > Reverting to the old SAFE_FFLAGS 'solves' the problem.

 >> sessionInfo()
 > R version 3.5.2 (2018-12-20)
 > Platform: x86_64-pc-linux-gnu (64-bit)
 > Running under: Scientific Linux release 6.4 (Carbon)

 > Matrix products: default
 > BLAS/LAPACK: 
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so

 > locale:
 > [1] C

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

 > loaded via a namespace (and not attached):
 > [1] compiler_3.5.2

So you us Intel's MKL library for BLAS/LAPACK ..

I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
and don't see such problems:

The code

f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)
xhat <- rep(1, 10)
all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

gives


f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)

List of 6
  $ par: num [1:10] 1 1 1 1 1 ...
  $ objective  : num -41.4
  $ convergence: int 0
  $ iterations : int 66
  $ evaluations: Named int [1:2] 96 830
   ..- attr(*, "names")= chr [1:2] "function" "gradient"
  $ message: chr "relative convergence (4)"

xhat <- rep(1, 10)
all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7

[1] "Mean relative difference: 5.534757e-07"

all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12

[1] "Mean relative difference: 1.816536e-12"

abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

[1] TRUE




for me. Maybe others can quickly run the above  7 lines and report ?

Maybe there's something else unusual with your Linux
distribution's libraries?

I'm not an expert on these compiler flags; have you seen what
the R-admin manual
 https://cran.r-project.org/doc/manuals/R-admin.html#Linux
says about them?

Best,
Martin

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

Re: [Rd] nlminb with constraints failing on some platforms

2019-02-01 Thread Avraham Adler 
No error on Windows 10, R.3.5.2 patched, Rblas compiled with OpenBLAS
0.20, Rlapack is base.

> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par: num [1:10] 1 1 1 1 1 ...
 $ objective  : num -41.4
 $ convergence: int 0
 $ iterations : int 66
 $ evaluations: Named int [1:2] 96 830
  ..- attr(*, "names")= chr [1:2] "function" "gradient"
 $ message: chr "relative convergence (4)"
> xhat <- rep(1, 10)
> all.equal(opt$par, xhat,  tol=0)
[1] "Mean relative difference: 3.266165e-07"
> all.equal(opt$objective, f(xhat), tol=0)
[1] "Mean relative difference: 6.722005e-13"
> abs( opt$objective - f(xhat) ) < 1e-4
[1] TRUE

> sessionInfo()
R version 3.5.2 Patched (2018-12-26 r75909)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

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

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2yaml_2.2.0

On Fri, Feb 1, 2019 at 3:24 PM Rui Barradas  wrote:
>
> Hello,
>
> R 3.5.2 on ubuntu 18.04. sessionInfo() at the end.
> Works with me, same results, cannot reproduce the error.
>
>
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
>
> xhat <- rep(1, 10)
> all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
> #[1] "Mean relative difference: 5.534757e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> #[1] "Mean relative difference: 1.816536e-12"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> #[1] TRUE
>
>
> Hope this helps,
>
> Rui Barradas
>
>
> sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.1 LTS
>
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
>
> locale:
>   [1] LC_CTYPE=pt_PT.UTF-8   LC_NUMERIC=C
>   [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
>   [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
>   [7] LC_PAPER=pt_PT.UTF-8   LC_NAME=C
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
>   [1] Rcpp_1.0.0   rstudioapi_0.8   bindr_0.1.1  magrittr_1.5
>   [5] tidyselect_0.2.5 munsell_0.5.0colorspace_1.3-2 lattice_0.20-38
>   [9] R6_2.3.0 rlang_0.3.0.1stringr_1.3.1plyr_1.8.4
> [13] dplyr_0.7.8  tools_3.5.2  grid_3.5.2   yaml_2.2.0
> [17] assertthat_0.2.0 tibble_1.4.2 crayon_1.3.4 bindrcpp_0.2.2
> [21] purrr_0.2.5  reshape2_1.4.3   glue_1.3.0   stringi_1.2.4
> [25] compiler_3.5.2   pillar_1.3.1 scales_1.0.0 lubridate_1.7.4
> [29] pkgconfig_2.0.2  zoo_1.8-4
>
>
>
>
> Às 09:00 de 01/02/2019, Martin Maechler escreveu:
> >> Kasper Kristensen via R-devel
> >>  on Mon, 28 Jan 2019 08:56:39 + writes:
> >
> >  > I've noticed unstable behavior of nlminb on some Linux
> >  > systems. The problem can be reproduced by compiling
> >  > R-3.5.2 using gcc-8.2 and running the following snippet:
> >
> >  > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> >  > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> >  > xhat <- rep(1, 10)
> >  > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> >
> >  > The example works perfectly when removing the bounds. However, when 
> > bounds are added the snippet returns 'FALSE'.
> >
> >  > An older R version (3.4.4), compiled using the same gcc-8.2, did not 
> > have the problem. Between the two versions R has changed the flags to 
> > compile Fortran sources:
> >
> >  > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
> >  > ---
> >  >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
> >
> >  > Reverting to the old SAFE_FFLAGS 'solves' the problem.
> >
> >  >> sessionInfo()
> >  > R version 3.5.2 (2018-12-20)
> >  > Platform: x86_64-pc-linux-gnu (64-bit)
> >  > Running under: Scientific Linux release 6.4 (Carbon)
> >
> >  > Matrix products: default
> >  > BLAS/LAPACK: 
> > /zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> >
> >  > locale:
> >  > [1] C
> >
> >  > attached base packages:
> >  > [1] stats graphics  grDevices utils datasets  methods   base
> >
> >  > loaded via a namespace (and not attached):
> >  > [1] compiler_3.5.2
> >
> > So you us Intel's MKL library for BLAS/LAPA

Re: [Rd] Runnable R packages

2019-02-01 Thread William Dunlap via R-devel 
To download a package with all its dependencies and install it, use the
install.packages() functions instead of 'R CMD INSTALL'.  E.g., in bash:

mkdir /tmp/libJunk
env R_LIBS_SITE=libJunk R --quiet -e 'if
(!requireNamespace("purrr",quietly=TRUE)) install.packages("purrr")'

For corporate "production use" you probably want to set up your own
repository containing
fixed versions of packages instead of using CRAN.  Then edd repos="..." to
the install.packages()
call.  Of course you can put this into a package and somehow deal with the
bootstrapping issue.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Jan 31, 2019 at 8:04 AM David Lindelof  wrote:

> Would you care to share how your package installs its own dependencies? I
> assume this is done during the call to `main()`? (Last time I checked, R
> CMD INSTALL would not install a package's dependencies...)
>
>
> On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson <
> b.rowling...@lancaster.ac.uk> wrote:
>
> >
> >
> > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 
> wrote:
> >
> >>
> >> In summary, I'm convinced R would benefit from something similar to
> Java's
> >> `Main-Class` header or Python's `__main__()` function. A new R CMD
> command
> >> would take a package, install its dependencies, and run its "main"
> >> function.
> >
> >
> >
> > I just created and built a very boilerplate R package called "runme". I
> > can install its dependencies and run its "main" function with:
> >
> >  $ R CMD INSTALL runme_0.0.0.9000.tar.gz
> >  $ R -e 'runme::main()'
> >
> > No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with
> > python and java and C the entrypoint is more tightly specified (__name__
> ==
> > "__main__" in python, int main(..) in C and so on). But I don't think
> > that's much of a problem.
> >
> > Does that not satisfy your requirements close enough? If you want it in
> > one line then:
> >
> > R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()'
> >
> > will do the second if the first succeeds (Unix shells).
> >
> > You could write a script for $RHOME/bin/RUN which would be a two-liner
> and
> > that could mandate the use of "main" as an entry point. But good luck
> > getting anything into base R.
> >
> > Barry
> >
> >
> >
> >
> >> If we have this machinery available, we could even consider
> >> reaching out to Spark (and other tech stacks) developers and make it
> >> easier
> >> to develop R applications for those platforms.
> >>
> >>
> >
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Runnable R packages

2019-02-01 Thread Dirk Eddelbuettel 


On 1 February 2019 at 13:31, William Dunlap via R-devel wrote:
| To download a package with all its dependencies and install it, use the
| install.packages() functions instead of 'R CMD INSTALL'.  E.g., in bash:
| 
| mkdir /tmp/libJunk
| env R_LIBS_SITE=libJunk R --quiet -e 'if
| (!requireNamespace("purrr",quietly=TRUE)) install.packages("purrr")'

Or one could use 'littler' and install some of its examples in the $PATH path
(which I tend to do via softlinks to get updates easily).

Then it is simply

   $ install.r purrr

and there is also install2.r with docopt goodness and more options.

These have been my preferred tools for many years at home and work, and they
found their way through Rocker dockerfiles as well as install2.r was started
by Carl for added features.
 
| For corporate "production use" you probably want to set up your own
| repository containing
| fixed versions of packages instead of using CRAN.  Then edd repos="..." to
| the install.packages()
| call.  Of course you can put this into a package and somehow deal with the
| bootstrapping issue.

Absolutely. But what repo to source packages from is somewhat orthogonal to
how to install from there. Also, thanks to Gergely, repos is now an argument
to install2.r

Dirk

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

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

[Rd] Set the number of threads using openmp with .Fortran?

2019-02-01 Thread Ignacio Martinez 
Hi everybody,

I'm trying to develop an R package with Fortran and OpenMP. I wrote a
simple hello world but I'm not able to set the number of threads. I found this
old email chain

and
I tried to set my compile instructions accordingly but i had no luck.

*This is my makevars:*

PKG_FCFLAGS="-fno-stack-protector"
F90FLAGS =  "-fopenmp"
LDFLAGS = "-fopenmp"

*This is my Fortran module:*

module hello_openmp
   use omp_lib
   implicit none
   contains

subroutine hello(ncores) bind(C, name="hello_")
  use, intrinsic :: iso_c_binding,
only : c_double, c_int
  integer(c_int), intent(in) :: ncores
  integer:: iam
  ! Specify number of threads to use:
  !$call omp_set_num_threads(ncores)
  !$omp parallel private(iam)
  iam=omp_get_thread_num()
  !$omp critical
  write(*,*) 'Hello from', iam
  !$omp end critical
  !$omp end parallel
end subroutine hello

end module hello_openmp


*and this is my R function:*

#'@export
#'@useDynLib helloOpenMP, .registration = TRUE

hello <- function(ncores=4) {
  .Fortran("hello", ncores = as.integer(ncores))
}


*Alas, when I call hello things only run with one thread:*

> hello(ncores = 2)$ncores
 Hello from   0
[1] 2


Could you point me in the right direction? What am I missing?


Thanks,


Ignacio

[[alternative HTML version deleted]]

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

Re: [Rd] Runnable R packages

2019-02-01 Thread Abs Spurdle 
This is possibly the most redundant discussion I've ever seen on the R
mailing lists.

In the original post:

> 2) It provides no way to deal with dependencies on other packages
> 3) It provides no way to "run" an application provided as an R package

Both completely false statements.

> recently been a growing interest in developing full applications

R was originally designed for interpreted use, with statistics and graphics.
However, GUI, web and other applications are possible.
And it's been around for a while.
(So, not "recently").

Maybe your organization could/should pay a programmer to do it?

[[alternative HTML version deleted]]

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

Re: [Rd] Runnable R packages

2019-02-01 Thread Abs Spurdle 
Further to my previous post,
it would be possible to create an .exe file, say:

my_r_application.exe

That starts R, loads your R package(s), calls the R function of your choice
and does whatever else you want.

However, I don't think that it would add much value.
But feel free to correct me if you think that I'm wrong.

[[alternative HTML version deleted]]

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