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

[Stefan Evert]

Also no error on MacOS 10.13.6, R 3.5.1 with system-supplied VecLib BLAS.

> > 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 65
>  $ evaluations: Named int [1:2] 92 773
>   ..- 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.368798e-06"
> > all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.09683e-11"
> > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE

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

Re: [Rd] Runnable R packages

[Barry Rowlingson]

I don't think anyone denies that you *could* make an EXE to do all
that. The discussion is on *how easy* it should be to create a single
file that contains an initial "main" function plus a set of bundled
code (potentially as a package) and which when run will install its
package code (which is contained in itself, its not in a repo),
install dependencies, and run the main() function.

Now, I could build a self-executable shar file that bundled a package
together with a script to do all the above. But if there was a "RUN"
command in R, and a convention that a function called "foo::main"
would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
easier to develop and test.

If people think this adds value, then if they want to offer that value
to me as $ or £, I'd consider writing it if their total value was more
than my cost

Barry


On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle  wrote:
>
> 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

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

Re: [Rd] Runnable R packages

[Duncan Murdoch]

On 02/02/2019 8:27 a.m., Barry Rowlingson wrote:

I don't think anyone denies that you *could* make an EXE to do all
that. The discussion is on *how easy* it should be to create a single
file that contains an initial "main" function plus a set of bundled
code (potentially as a package) and which when run will install its
package code (which is contained in itself, its not in a repo),
install dependencies, and run the main() function.

Now, I could build a self-executable shar file that bundled a package
together with a script to do all the above. But if there was a "RUN"
command in R, and a convention that a function called "foo::main"
would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
easier to develop and test.


I don't believe the "so much easier" argument that this requires a 
change to base R.  If you put that functionality into a package, then 
the only extra effort the user would require is to install that other 
package.  After that, they could run


Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')"

as I suggested before.  This is no harder than running

R CMD RUN foo_1.1.1.tar.gz

The advantage of this from R Core's perspective is that you would be 
developing and maintaining "yourpackage", you wouldn't be passing the 
burden on to them.  The advantage from your perspective is that you 
could work with whatever packages you liked.  The "remotes" package has 
almost everything you need so that "yourpackage" could be nearly 
trivial.  You wouldn't need to duplicate it within base R.


Duncan Murdoch



If people think this adds value, then if they want to offer that value
to me as $ or £, I'd consider writing it if their total value was more
than my cost

Barry


On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle  wrote:


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


__
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

[David Lindelof]

I see some value in Duncan’s proposal to implement this as an extra package
instead of a change to base R, if only to see if the idea has legs. I’m
minded to do so myself using your suggestion, but is there a particular
reason why you recommend using the remotes package instead of devtools? The
latter seems to have the same functions I would need, and I believe it is
more widely installed that remotes?

Kind regards,

From: Duncan Murdoch  
Reply: Duncan Murdoch  
Date: 2 February 2019 at 15:37:16
To: Barry Rowlingson 
, Abs Spurdle 

Cc: r-devel  
Subject:  Re: [Rd] Runnable R packages

On 02/02/2019 8:27 a.m., Barry Rowlingson wrote:
> I don't think anyone denies that you *could* make an EXE to do all
> that. The discussion is on *how easy* it should be to create a single
> file that contains an initial "main" function plus a set of bundled
> code (potentially as a package) and which when run will install its
> package code (which is contained in itself, its not in a repo),
> install dependencies, and run the main() function.
>
> Now, I could build a self-executable shar file that bundled a package
> together with a script to do all the above. But if there was a "RUN"
> command in R, and a convention that a function called "foo::main"
> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
> easier to develop and test.

I don't believe the "so much easier" argument that this requires a
change to base R. If you put that functionality into a package, then
the only extra effort the user would require is to install that other
package. After that, they could run

Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')"

as I suggested before. This is no harder than running

R CMD RUN foo_1.1.1.tar.gz

The advantage of this from R Core's perspective is that you would be
developing and maintaining "yourpackage", you wouldn't be passing the
burden on to them. The advantage from your perspective is that you
could work with whatever packages you liked. The "remotes" package has
almost everything you need so that "yourpackage" could be nearly
trivial. You wouldn't need to duplicate it within base R.

Duncan Murdoch

>
> If people think this adds value, then if they want to offer that value
> to me as $ or £, I'd consider writing it if their total value was more
> than my cost
>
> Barry
>
>
> On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle  wrote:
>>
>> 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
>
> __
> 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


David Lindelöf, Ph.D.
+41 (0)79 415 66 41  or skype:david.lindelof
http://computersandbuildings.com
Follow me on Twitter:
http://twitter.com/dlindelof

[[alternative HTML version deleted]]

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

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

[Ignacio Martinez]

I was able to make some progress by using this
 as a
reference. Now:

*This is my makevars:*
#  Compiler flags  #
PKG_FCFLAGS = $(SHLIB_OPENMP_FFLAGS)
PKG_LIBS = $(SHLIB_OPENMP_CFLAGS)

#  Phony target for R's build system to invoke  #
all: $(SHLIB)

#  Clean target  #
clean:
rm -f *.o *.mod

And when I run my hello world function all the threads are used
regardless of what i specify:

> hello(ncores = 2) Hello from   1
 Hello from   3
 Hello from   0
 Hello from   9
 Hello from   8
 Hello from   2
 Hello from   6
 Hello from  10
 Hello from  11
 Hello from   5
 Hello from   7
 Hello from   4
$ncores
[1] 2



What am I missing? My Fortran subroutine uses !$call
omp_set_num_threads(ncores) to set the number of threads. Why is this
not working? How can I fix it?

Thanks a lot for the help

Ignacio


On Fri, Feb 1, 2019 at 4:51 PM Ignacio Martinez  wrote:

> 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] nlminb with constraints failing on some platforms

[Oliver Dechant]

Hello,

> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS/LAPACK:
/opt/intel/compilers_and_libraries_2019.1.144/linux/mkl/lib/intel64_lin/libmkl_rt.so

locale:
 [1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
 [5] LC_MONETARY=en_CA.UTF-8LC_MESSAGES=en_CA.UTF-8
 [7] LC_PAPER=en_CA.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.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.2
> 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 67
 $ evaluations: Named int [1:2] 98 850
  ..- 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.349781e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 3.81e-12"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] TRUE


On 2019-02-01 4:23 p.m., 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-8    LC_COLLATE=pt_PT.UTF-8
>  [5] LC_MONETARY=pt_PT.UTF-8    LC_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.0    colorspace_1.3-2 lattice_0.20-38
>  [9] R6_2.3.0 rlang_0.3.0.1    stringr_1.3.1    plyr_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

Re: [Rd] Runnable R packages

[Ben Bolker]

  remotes has fewer dependencies.  I believe that the current version of
devtools just re-exports install_github etc. from the remotes package.

On 2019-02-02 11:31 a.m., David Lindelof wrote:
> I see some value in Duncan’s proposal to implement this as an extra package
> instead of a change to base R, if only to see if the idea has legs. I’m
> minded to do so myself using your suggestion, but is there a particular
> reason why you recommend using the remotes package instead of devtools? The
> latter seems to have the same functions I would need, and I believe it is
> more widely installed that remotes?
> 
> Kind regards,
> 
> From: Duncan Murdoch  
> Reply: Duncan Murdoch  
> Date: 2 February 2019 at 15:37:16
> To: Barry Rowlingson 
> , Abs Spurdle 
> 
> Cc: r-devel  
> Subject:  Re: [Rd] Runnable R packages
> 
> On 02/02/2019 8:27 a.m., Barry Rowlingson wrote:
>> I don't think anyone denies that you *could* make an EXE to do all
>> that. The discussion is on *how easy* it should be to create a single
>> file that contains an initial "main" function plus a set of bundled
>> code (potentially as a package) and which when run will install its
>> package code (which is contained in itself, its not in a repo),
>> install dependencies, and run the main() function.
>>
>> Now, I could build a self-executable shar file that bundled a package
>> together with a script to do all the above. But if there was a "RUN"
>> command in R, and a convention that a function called "foo::main"
>> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
>> easier to develop and test.
> 
> I don't believe the "so much easier" argument that this requires a
> change to base R. If you put that functionality into a package, then
> the only extra effort the user would require is to install that other
> package. After that, they could run
> 
> Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')"
> 
> as I suggested before. This is no harder than running
> 
> R CMD RUN foo_1.1.1.tar.gz
> 
> The advantage of this from R Core's perspective is that you would be
> developing and maintaining "yourpackage", you wouldn't be passing the
> burden on to them. The advantage from your perspective is that you
> could work with whatever packages you liked. The "remotes" package has
> almost everything you need so that "yourpackage" could be nearly
> trivial. You wouldn't need to duplicate it within base R.
> 
> Duncan Murdoch
> 
>>
>> If people think this adds value, then if they want to offer that value
>> to me as $ or £, I'd consider writing it if their total value was more
>> than my cost
>>
>> Barry
>>
>>
>> On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle  wrote:
>>>
>>> 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
>>
>> __
>> 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
> 
> 
> David Lindelöf, Ph.D.
> +41 (0)79 415 66 41  or skype:david.lindelof
> http://computersandbuildings.com
> Follow me on Twitter:
> http://twitter.com/dlindelof
> 
>   [[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] nlminb with constraints failing on some platforms

[William Dunlap via R-devel]

Microsoft R Open 3.4.2
The enhanced R distribution from Microsoft
Microsoft packages Copyright (C) 2017 Microsoft Corporation

Using the Intel MKL for parallel mathematical computing (using 12 cores).

Default CRAN mirror snapshot taken on 2017-10-15.
See: https://mran.microsoft.com/.

> 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
[1] FALSE
> opt$objective - f(xhat)
[1] 3.696533
> str(opt)
List of 6
 $ par: num [1:10] 0.797 0.303 0.285 0.271 0.258 ...
 $ objective  : num -37.7
 $ convergence: int 1
 $ iterations : int 150
 $ evaluations: Named int [1:2] 155 1611
  ..- attr(*, "names")= chr [1:2] "function" "gradient"
 $ message: chr "iteration limit reached without convergence (10)"

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Jan 29, 2019 at 3:59 AM Kasper Kristensen via R-devel <
r-devel@r-project.org> wrote:

> 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
>
>
>
> [[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

[Abs Spurdle]

Creating an .exe file isn't necessarily difficult.
The main problems are that you have to write and compile the C (or other)
files.
Otherwise, the complexity depends on the level of Inter Process
Communication that's required.

Simply starting R with some initial conditions, is easy.
Even if you want to prompt the user to install missing packages, it isn't
necessarily difficult.

It would be possible to take this one step further, and write an .exe
builder, that automates the process of creating .exe files.
Obviously, it would require a compiler and supporting libraries.
I have a preference for GCC, and I'm not sure if you can run GCC on Windows
without Cygwin.

I may (or may not) look into this further, in a few weeks time.


On Sun, Feb 3, 2019 at 2:27 AM Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:

> I don't think anyone denies that you *could* make an EXE to do all
> that. The discussion is on *how easy* it should be to create a single
> file that contains an initial "main" function plus a set of bundled
> code (potentially as a package) and which when run will install its
> package code (which is contained in itself, its not in a repo),
> install dependencies, and run the main() function.
>
> Now, I could build a self-executable shar file that bundled a package
> together with a script to do all the above. But if there was a "RUN"
> command in R, and a convention that a function called "foo::main"
> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
> easier to develop and test.
>
> If people think this adds value, then if they want to offer that value
> to me as $ or £, I'd consider writing it if their total value was more
> than my cost
>
> Barry
>


___
> > 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] Set the number of threads using openmp with .Fortran?

[Ignacio Martinez]

I got this to work on Linux but it is not working on Windows. *My
understanding is that this should also work on windows, is that correct?*
If so, what should I do? differently?

To get it to work on Linux, I modified my R script as follows:

#' OpenMP Hello World
#'
#' @param nthreads The number of threads that you want to use
#' @example
#' hello(nthreads=2)
#' @export
#' @useDynLib helloOpenMP, .registration = TRUE

hello <- function(nthreads=4) {
   (OpenMPController::omp_set_num_threads(nthreads))
  .Fortran("hello")
  return('Each thread will say hi to you!')
}

> hello(nthreads = 2) Hello from   0
 Hello from   1
[1] "Each thread will say hi to you!"



Alas, on Windows the same command just returns "Each thread will say hi to
you!" without the Hello from X

Thanks for your help,

Ignacio





On Sat, Feb 2, 2019 at 11:34 AM Ignacio Martinez 
wrote:

>
>
> I was able to make some progress by using this
>  as
> a reference. Now:
>
> *This is my makevars:*
> #  Compiler flags  #
> PKG_FCFLAGS = $(SHLIB_OPENMP_FFLAGS)
> PKG_LIBS = $(SHLIB_OPENMP_CFLAGS)
>
> #  Phony target for R's build system to invoke  #
> all: $(SHLIB)
>
> #  Clean target  #
> clean:
> rm -f *.o *.mod
>
> And when I run my hello world function all the threads are used
> regardless of what i specify:
>
> > hello(ncores = 2) Hello from   1
>  Hello from   3
>  Hello from   0
>  Hello from   9
>  Hello from   8
>  Hello from   2
>  Hello from   6
>  Hello from  10
>  Hello from  11
>  Hello from   5
>  Hello from   7
>  Hello from   4
> $ncores
> [1] 2
>
>
>
> What am I missing? My Fortran subroutine uses !$call
> omp_set_num_threads(ncores) to set the number of threads. Why is this
> not working? How can I fix it?
>
> Thanks a lot for the help
>
> Ignacio
>
>
> On Fri, Feb 1, 2019 at 4:51 PM Ignacio Martinez 
> wrote:
>
>> 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