[Rd] Change between 86152 and 86534 - probably 86265 - that looks for zspmv in BLAS and not LAPACK causes R with OpenBLAS to fail

[Avraham Adler]

Executive summary:

I believe revision 86265 makes it more difficult to build R with
OpenBLAS on Windows as now the entire LAPACK needs to be built to
obtain zspmv. Is there anything that can be done to allow the former
behavior to be used, something in Mkrules.local perhaps?

Detailed Explanation:

I have been building R with OpenBLAS for Windows 64 for over a decade
by patching /src/extra/blas/Makevars.win as follows:

--- /c/r/trunk/src/extra/blas/Makefile.win2024-01-24
18:34:42.755255900 +
+++ /c/r/Makefile.win2024-01-24 18:39:39.716458000 +
@@ -12,7 +12,7 @@
 ../../../$(BINDIR)/Rblas.dll: blas00.o ../../gnuwin32/dllversion.o
 @$(ECHO)  Building $@ 
 $(DLL) -s -shared $(DLLFLAGS) -o $@ $^ Rblas.def \
-   -L../../../$(IMPDIR) -lR  -L"$(ATLAS_PATH)" -lf77blas -latlas
+   -L../../../$(IMPDIR) -lR -L"$(ATLAS_PATH)" -fopenmp -lopenblas
 else
 ../../../$(BINDIR)/Rblas.dll: blas.o blas2.o cmplxblas.o cmplxblas2.o
../../gnuwin32/dllversion.o
 @$(ECHO)  Building $@ 

and then passing USE_ATLAS = YES and ATLAS_PATH = C:/R/OPB/whatever in
Mkrules.local

When I compile OpenBLAS, I have always done so with NO_CBLAS,
NO_LAPACK, and NO_SHARED, as the Windows toolchain does not need
CBLAS, a shared library, or allow for a separate LAPACK and this has
worked, for the most part, since roughly 2013.
When building the recent R-devel (a revision slightly before 86534),
the compilation stopped when building Rblas with the following error:

 Building ../../../bin/x64/Rblas.dll 
gcc  -s -shared  -o ../../../bin/x64/Rblas.dll blas00.o
../../gnuwin32/dllversion.o Rblas.def \
   -L../../../bin/x64 -lR -L"C:/R/OPB/OpenBLAS-develop-f0560f9"
-fopenmp -lopenblas
C:\rtools44\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot export
zspmv_: symbol not defined
collect2.exe: error: ld returned 1 exit status
make[4]: *** [Makefile.win:14: ../../../bin/x64/Rblas.dll] Error 1
make[3]: *** [Makefile:227: Rblas] Error 2
make[2]: *** [Makefile:116: rbuild] Error 2
make[1]: *** [Makefile:17: all] Error 2
make: *** [Makefile:392: distribution] Error 2

I reached out to OpenBLAS (there were other issues with OPB 0.3.27)
and one of the maintainers responded:

> "for historical reasons, ZSPMV is in LAPACK although conceptionally [sic] it 
> belongs in BLAS. As you specified NO_LAPACK=1, this function gets omitted 
> since 0.3.20 to allow combining the BLAS-only build with an external LAPACK." 
> [1]

He later followed up with "0.3.26 built with NO_LAPACK=1 will likewise
omit the zspmv symbol (as directed)." [2]

I last successfully compiled v86152 with OpenBLAS 0.3.26 on
2024-03-19. When I compiled 86534 tonight with OPB 0.3.27, I got the
error above. I then tried with OPB 0.3.26—which worked for 86152—and
still got the zspmv error.

I am guessing this relates to revision 86265 "amending r85873: zspmv
is BLAS, not Lapack…" [3].

I built OpenBLAS AND its LAPACK, which takes MUCH MUCH longer, and
tried building R. This time, the build succeeded and passes make
check-devel.

Is there any way to allow the former functionality if the build
recognizes the use of OpenBLAS? Is the only option to compile
OpenBLAS's LAPACK too?

Thank you,

Avi


[1] https://github.com/OpenMathLib/OpenBLAS/issues/4684#issuecomment-2101123154
[2] https://github.com/OpenMathLib/OpenBLAS/issues/4684#issuecomment-2101213474
[3] 
https://github.com/r-devel/r-svn/commit/c9f3aba39aa89821d294f4a524331a21e6904aec

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

Re: [R-pkg-devel] package removed from CRAN

[Avraham Adler]

According to the CRAN links
,
your package had an error on r-devel-windows-x86_64 and
r-patched-linux-x86_64 which was not addressed. Specifically, some
examples failed. See

for more specific details. Usually, fixing the problem and
incrementing the version is enough to resubmit it to CRAN.

Thanks,

Avi

On Wed, May 8, 2024 at 11:33 AM Jose V. Die Ramon  wrote:
>
> Hello,
>
> I just discovered that my package 'refseqR' was removed from the CRAN 
> repository on April 30th.
> https://cran.r-project.org/web/packages/refseqR/index.html
>
> This news is extremely upsetting, especially because I did not receive any 
> communication or warning regarding the issue. Could anyone please help me 
> understand the reasons behind this, or suggest any steps I should take to 
> resolve it?
>
> Thanks,
> Jose
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] Check results on r-devel-windows claiming error but tests seem to pass?

[Avraham Adler]

I noticed that a few of my packages appear to be failing on
"r-devel-windows-x86_64". Specficially, Delaporte [1], lamW [2], and
revss[3]. However, checking the output of the tests shows that all
passed. Is this a hiccup or is there something that needs to be
changed? And why would my other two packages not suffer from this
(minimaApprox [4] and Pade [5])? I'm a bit confused.

Thank you,

Avi

[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
[2] https://cran.r-project.org/web/checks/check_results_lamW.html
[3] https://cran.r-project.org/web/checks/check_results_revss.html
[4] https://cran.r-project.org/web/checks/check_results_minimaxApprox.html
[5] https://cran.r-project.org/web/checks/check_results_Pade.html

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

Re: [R-pkg-devel] Unable to access log operator in C

[Avraham Adler]

Thank you, Dirk.

However, I am an absolute clod.I just realized; I was passing in the
SEXP indicating whether or not to log the function as "log", so I
"overwrote" the symbol.

Excuse me while I go bang my head into the wall a few dozen times.

My apologies,

Avi

On Wed, Feb 28, 2024 at 7:14 PM Dirk Eddelbuettel  wrote:
>
>
> On 28 February 2024 at 19:05, Avraham Adler wrote:
> | I am hoping the solution to this question is simple, but I have not
> | been able to find one. I am building a routine in C to be called from
> | R. I am including Rmath.h. However, when I have a call to "log", I get
> | the error "called object 'log' is not a function or a function
> | pointer. When I "trick" it by calling log1p(x - 1), which I *know* is
> | exported from Rmath.h, it works.
> |
> | More completely, my includes are:
> | #include 
> | #include 
> | #include 
> | #include 
> | #include  // for NULL
> | #include 
> |
> | The object being logged is a double, passed into C as an SEXP, call it
> | "a", which for now will always be a singleton. I initialize a pointer
> | double *pa = REAL(a). I eventually call log(pa[0]), which does not
> | compile and throws the error listed above. Switching the call to
> | log1p(pa[0] - 1.0) works and returns the proper answer.
> |
> | Even including math.h explicitly does not help, which makes sense as
> | it is included by Rmath.h.
>
> Can you show the actual line?  Worst case rename your source file to end in
> .cpp, include  and call std::log.
>
>   > Rcpp::cppFunction("double mylog(double x) { return std::log(x); }")
>   > mylog(exp(42))
>   [1] 42
>   >
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] Unable to access log operator in C

[Avraham Adler]

I am hoping the solution to this question is simple, but I have not
been able to find one. I am building a routine in C to be called from
R. I am including Rmath.h. However, when I have a call to "log", I get
the error "called object 'log' is not a function or a function
pointer. When I "trick" it by calling log1p(x - 1), which I *know* is
exported from Rmath.h, it works.

More completely, my includes are:
#include 
#include 
#include 
#include 
#include  // for NULL
#include 

The object being logged is a double, passed into C as an SEXP, call it
"a", which for now will always be a singleton. I initialize a pointer
double *pa = REAL(a). I eventually call log(pa[0]), which does not
compile and throws the error listed above. Switching the call to
log1p(pa[0] - 1.0) works and returns the proper answer.

Even including math.h explicitly does not help, which makes sense as
it is included by Rmath.h.

Thank you,

Avi

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

Re: [Rd] Advice debugging M1Mac check errors

[Avraham Adler]

I think I had that problem with the minimaxApprox package as well.

Avi

Sent from my iPhone

> On Feb 4, 2024, at 4:47 PM, J C Nash  wrote:
> 
> Slightly tangential: I had some woes with some vignettes in my
> optimx and nlsr packages (actually in examples comparing to OTHER
> packages) because the M? processors don't have 80 bit registers of
> the old IEEE 754 arithmetic, so some existing "tolerances" are too
> small when looking to see if is small enough to "converge", and one
> gets "did not converge" type errors. There are workarounds,
> but the discussion is beyond this post. However, worth awareness that
> the code may be mostly correct except for appropriate tests of
> smallness for these processors.
> 
> JN
> 
> 
> 
> 
>> On 2024-02-04 11:51, Dirk Eddelbuettel wrote:
>> On 4 February 2024 at 20:41, Holger Hoefling wrote:
>> | I wanted to ask if people have good advice on how to debug M1Mac package
>> | check errors when you don´t have a Mac? Is a cloud machine the best option
>> | or is there something else?
>> a) Use the 'mac builder' CRAN offers:
>>https://mac.r-project.org/macbuilder/submit.html
>> b) Use the newly added M1 runners at GitHub Actions,
>>
>> https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/
>> Option a) is pretty good as the machine is set up for CRAN and builds
>> fast. Option b) gives you more control should you need it.
>> Dirk
>> 
> 
> __
> 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] Segmentation fault early in compilation of revision 85514

[Avraham Adler]

On Mon, Nov 13, 2023 at 1:13 AM Dirk Eddelbuettel  wrote:
>
>
> Avi,
>
> Might be toolchain-dependent, might be options-dependent--it built fine here.
> Easier for you to vary option two so maybe try that?
>
> Dirk

Thank you, Dirk.

I think it was more a PEBCAK issue. When I deleted the entire trunk
folder and started the process from scratch, it compiled properly as
per usual. Although this was revision 85520, so perhaps something
changed in the interim.

Regardless, the issue resolved itself.

Thanks,

Avi

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

[Rd] Segmentation fault early in compilation of revision 85514

[Avraham Adler]

When trying to compile R on Windows 10 64-bit using LTO as I always do, I
encountered a segmentation fault early in the compilation. I am uncertain
as to what it means (please see below for error extract). I am using the
most recent version of Rtools43 (5863) and updated its libraries prior to
starting the build. My EOPTS is " -march=native -pipe -mno-rtm" and my
LTO/LTO_OPT/LTO_FC/LTO_FC_OPT is "-flto=1 -fuse-linker-plugin".

Any explanation or suggestions would be appreciated.

Thank you,

Avi

```
installing zoneinfo
making console.d from console.c
making dynload.d from dynload.c
making embeddedR.d from embeddedR.c
making preferences.d from preferences.c
making psignal.d from psignal.c
making rui.d from rui.c
making system.d from system.c
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
console.c -o console.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
dynload.c -o dynload.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
editor.c -o editor.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
embeddedR.c -o embeddedR.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD
-I../library/grDevices/src -O3 -Wall -pedantic -march=native -pipe -mno-rtm
-flto=1 -fuse-linker-plugin   -c extra.c -o extra.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
opt.c -o opt.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
pager.c -o pager.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
preferences.c -o preferences.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
psignal.c -o psignal.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
rhome.c -o rhome.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
rt_complete.c -o rt_complete.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
rui.c -o rui.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
run.c -o run.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD  -O3 -Wall
-pedantic -march=native -pipe -mno-rtm -flto=1 -fuse-linker-plugin   -c
sys-win32.c -o sys-win32.o
gcc  -I../include -I. -I../extra -DHAVE_CONFIG_H -DR_DLL_BUILD
-DR_ARCH='"x64"' -O3 -Wall -pedantic -march=native -pipe -mno-rtm -flto=1
-fuse-linker-plugin   -c system.c -o system.o
windres   -I../include -i dllversion.rc -o dllversion.o
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/nm.exe: mlutils.o: no
symbols
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/nm.exe: log1p.o: no symbols
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/nm.exe: printf.o: no symbols
C:\rtools43\x86_64-w64-mingw32.static.posix\bin/nm.exe: osdep.o: no symbols
gcc  -shared -O3 -Wall -pedantic -march=native -pipe -mno-rtm -flto=1
-fuse-linker-plugin -s -mwindows -o R.dll R.def console.o dynload.o
editor.o embeddedR.o extra.o opt.o pager.o preferences.o psignal.o rhome.o
rt_complete.o rui.o run.o shext.o sys-win32.o system.o dos_wglob.o
dllversion.o ../main/libmain.a ../appl/libappl.a ../nmath/libnmath.a
getline/gl.a ../extra/xdr/libxdr.a ../extra/intl/libintl.a
../extra/trio/libtrio.a ../extra/tzone/libtz.a ../extra/tre/libtre.a
-fopenmp -L. -lgfortran -lquadmath -lRblas -L../../bin/x64 -lRgraphapp
-lRiconv -lcomctl32 -lole32 -luuid -lwinmm -lversion
-L"/x86_64-w64-mingw32.static.posix"/lib/x64 -lpcre2-8 -lz -lbz2 -llzma
-L""/lib/x64 -lsicuin -lsicuuc
/x86_64-w64-mingw32.static.posix/lib/sicudt.a -lstdc++
rui.h:37:18: warning: type of 'RConsole' does not match original
declaration [-Wlto-type-mismatch]
   37 | LibExtern window RConsole;
  |  ^
rui.c:51:9: note: type 'struct objinfo' should match type 'struct gui_obj'
   51 | console RConsole = NULL;
  | ^
rui.c:51:9: note: 'RConsole' was previously declared here
rui.c:51:9: note: code may be misoptimized unless '-fno-strict-aliasing' is
used
make[5]: [C:\rtools43\tmp\ccUw2zA8.mk:81:
C:\rtools43\tmp\ccKMP0O7.ltrans26.ltrans.o] Error 1 (ignore
d)
make[5]: 

Re: [R-pkg-devel] What happened to mlr3proba on CRAN?

[Avraham Adler]

https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html

On Mon, Oct 9, 2023 at 12:37 AM Dr. Franz Király 
wrote:

> Dear all,
>
> can someone explain to me what exactly happened to mlr3proba on CRAN?
> https://cran.r-project.org/web/packages/mlr3proba/index.html
>
> Thanks
> Franz
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Spelling of PDB in Package Description

[Avraham Adler]

Regarding PDB, in Rd format it’s best to wrap that in an \acronym{} tag. See 
section 2.3 of https://cran.r-project.org/doc/manuals/R-exts.html#Marking-text

Avi

Sent from my iPhone

> On Sep 14, 2023, at 3:40 PM, Leonard Mada via R-package-devel 
>  wrote:
> 
> Dear List Members,
> 
> After resubmitting the updated version of the Rpdb package (2.3.1), the 
> following Notes were generated:
> 
> 1.) Spelling PDB
> https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Windows/00check.log
> https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Debian/00check.log
> 
> The PDB stands for Protein Data Bank:
> http://www.wwpdb.org/documentation/file-format-content/format33/v3.3.html
> 
> It should be the correct spelling (and was the same in the previous versions 
> of the package).
> 
> 2.)  Small Sample PDB Files
> * checking for non-standard things in the check directory ...
> NOTE Found the following files/directories: ‘Rpdb.pdb’
> 
> There is a directory with 3 very small sample pdb-files. The directory was 
> also present in the previous version.
> 
> How should I proceed? Or did I miss something?
> 
> 
> Sincerely,
> 
> 
> Leonard
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)

[Avraham Adler]

Hi, Thomas.

Since all the Fortran code must talk to R through SEXP's written in C,
wouldn't it make sense to use " C_DOUBLE_COMPLEX" and " C_DOUBLE" to ensure
maximum compatibility?

Thanks,

Avi

On Thu, Aug 31, 2023 at 9:42 AM Thomas Petzoldt <
thomas.petzo...@tu-dresden.de> wrote:

> On 30.08.2023 at 11:58 Ivan Krylov wrote:
> > On Wed, 30 Aug 2023 08:43:04 +0200
> > Thomas Petzoldt  wrote:
> >
> >> a) change REAL(kind=8) back to DOUBLE PRECISION that is again old
> >> style. It seems to be portable and is still widely used.
> >
> > I don't have a reference as good as the Fortran standard, but Steve
> > Lionel said in Dr. Fortran [*] that DOUBLE PRECISION is still part of
> > the standard fixed-form syntax.
> >
> >>   COMPLEX(KIND=8)
> >
> > This could be particularly problematic if you're trying to interoperate
> > with C, but will probably not surface unless you use LTO:
> > https://bugs.r-project.org/show_bug.cgi?id=18430
> >
> > Unfortunately, there's no standard DOUBLE COMPLEX.
> >
>
> Thank you, this helps. I had a look in Dr. Fortran myself and some other
> sites, but especially the COMPLEX definitions remain unclear.
>
> I tried now the following, because the included original Fortran codes
> follow slightly different standards:
>
> - replace COMPLEX(KIND=8) with DOUBLE COMPLEX in source files that use
> DOUBLE PRECISION otherwise
>
> - replace real(kind=8) with real(kind=kind(0.0d0)) in the more modern
> source files
>
> This is pragmatic and may not be the best way, but looks mostly
> consistent. Now I checked the package and everything was ok, but I was
> not able reproduce the warnings from the previous version.
>
> I assume that I have to set an environment variable to see the warnings,
> but which one?
>
> I use gfortran/gcc 13.2.1-1 on Fedora 38.
>
> Thanks!
>
> Thomas
>
> --
> https://tu-dresden.de/Members/thomas.petzoldt
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)

[Avraham Adler]

I’ve had no issues using the iso_c_binding schema. 

Avi

Sent from my iPhone

> On Aug 30, 2023, at 2:43 AM, Thomas Petzoldt  
> wrote:
> 
> Hi,
> 
> some package maintainers including me got a reminder from Prof. Brian Ripley 
> to modernize REAL and INTEGER declarations using the KIND option:
> 
>> On 29.08.2023 at 19:31 Prof Brian Ripley wrote:
>> According to the Fortran standards, numerical values are just an 
>> enumeration, and what e.g. real(kind=4) means (or even if it is accepted) is 
>> implementation dependent.
>> We see such constructs in packages
> 
> [... line with packages deleted to avoid exposing the other packages and 
> authors]
> 
>> Please change them to something portable (kind(1.0) or kind(1.0d0} are 
>> commonly used, as is c_double from iso_c_binding).
>> Before 2023-09-26 to safely retain your package on CRAN (some of you have 
>> earlier deadlines for other issues).
> 
> We use a lot of legacy code that though partly modernized due to similar 
> requests, still uses a mix of DOUBLE PRECISION and a few REAL(KIND=8) and 
> COMPLEX(KIND=8). As the code will still remain legacy style with respect to 
> some other constructs, I wonder what to use to go a step forward, but remain 
> as consistent as possible, which is of course a compromise. I see the 
> following options:
> 
> a) change REAL(kind=8) back to DOUBLE PRECISION that is again old style. It 
> seems to be portable and is still widely used.
> 
> b) just formally change the few occurrences to:REAL(kind=0.0d) as suggested. 
> It is easy, but inconsistency remains.
> 
> c) or, define "dp" as recommended in modern style guides and use it instead 
> of REAL(kind=8) and the future also for DOUBLE PRECISION this way:
> 
> integer,parameter::dp=kind(0.0d0)
> 
> and then
> 
> real(dp)::a,b,c
> 
> However, this would need changes at many places, the mix between old and new 
> constructswill generally get worse.
> 
> Another question is, that with either of these, we may not be sure to use 8 
> byte double. Changing this could influence for precision and pointer 
> arithmetics.
> 
> Any recommendations? Thanks a lot!
> 
> Thomas
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Avraham Adler]

To be fair, data.table defaults to using 1/2 the available cores; they do not 
take the entire machine by default. 

Avi

Sent from my iPhone

> On Aug 25, 2023, at 6:46 PM, Duncan Murdoch  wrote:
> 
> On 25/08/2023 6:13 p.m., Toby Hocking wrote:
>> Thanks Dirk. I agree.
>> data.table is not in a situation to update very soon, so the easiest
>> solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
>> to 2 on the Windows and Debian machines doing this test.
>> Otherwise the 1400+ packages with hard dependencies on data.table will
>> each have to implement custom logic to limit threads to 2.
> 
> That doesn't follow.  data.table could update soon even if that wasn't their 
> intention:  just include bug fixes and set the default OMP_THREAD_LIMIT to 2 
> in data.table.
> 
> The real problem is that there are two stubborn groups opposing each other:  
> the data.table developers and the CRAN maintainers.  The former think users 
> should by default dedicate their whole machine to data.table.  The latter 
> think users should opt in to do that.
> 
> Duncan Murdoch
> 
>> Toby
>>> On Fri, Aug 25, 2023 at 6:46 AM Dirk Eddelbuettel  wrote:
>>> 
>>> 
 On 24 August 2023 at 07:42, Fred Viole wrote:
>>> | Hi, I am receiving a NOTE upon submission regarding the re-building of
>>> | vignettes for CPU time for the Debian check.
>>> |
>>> | I am unable to find any documented instances or solutions to this issue.
>>> | The vignettes currently build in 1m 54.3s locally and in 56s on the Win
>>> | check.
>>> |
>>> | 
>>> https://win-builder.r-project.org/incoming_pretest/NNS_10.1_20230824_132459/Debian/00check.log
>>> 
>>> Please see, inter alia, the long running thread
>>> 
>>>"Trouble with long-running tests on CRAN debian server"
>>> 
>>> started earlier this week (!!) on this list covering exactly this issue.
>>> 
>>> We can only hope CRAN comes to understand our point that _it_ should set a
>>> clearly-identifable variable (the OpenMP thread count would do) so that
>>> package data.table can this for its several hundred users.
>>> 
>>> As things currently stand, CRAN expects several hundred packages (such as
>>> your, guessing there this comes from data.table which I do not know for sure
>>> but you do import it) to make the change which is pretty close to the text
>>> book definition of madness.
>>> 
>>> Also see https://github.com/Rdatatable/data.table/issues/5658 with by now 24
>>> comments.  It is on the same issue.
>>> 
>>> Uwe, Kurt: Please please please set OMP_THREAD_LIMIT to 2 on the Windows and
>>> Debian machines doing this test.
>>> 
>>> Dirk
>>> 
>>> --
>>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] status of "possibly invalid URL/403 error" NOTEs?

[Avraham Adler]

I had a similar issue with a paper on JSTOR. Usually CRAN let it through. 
However, I eventually switched from URL to DOI and now the user needs to find 
the free source so to rid myself of the constant hassle. CRAN really doesn’t 
like redirects. I guess you could wrap it in \code{} so as not to hyperlink. 

Avi

Sent from my iPhone

> On Aug 13, 2023, at 3:17 PM, Ben Bolker  wrote:
> 
>   I have a package whose documentation includes the reference 
> \doi{10.1137/18M1186411} which redirects here:
> https://epubs.siam.org/doi/10.1137/18M1186411
> 
> Running R CMD check --as-cran on the package gives
> 
> Found the following (possibly) invalid URLs:
>  URL: https://epubs.siam.org/doi/10.1137/18M1186411
>From: man/llig.Rd
>Status: 403
>Message: Forbidden
> 
>  I can access this perfectly well in the browser.
> 
>  Is there any way to avoid this (other than, say, including the URL in a form 
> that does *not* provide a link so that R CMD check won't try to access it? 
> (As Uwe Ligges says 
> [here](https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005195.html) 
> (for a more obviously problematic case), "mention the URL in plain text but 
> not link"
> 
>  Here Hadley Wickham says that these NOTEs can be ignored
> 
> https://twitter.com/hadleywickham/status/1358170607314235392
> 
> but "Hadley said it on twitter" is not an ideal source. The CRAN repository 
> policy says that packages must pass checks without "significant" notes, but 
> it's always hard to know what's significant and what's not ...
> 
>  There's a thread here: 
> https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005171.html
> 
>   Tangentially: is there a more convenient way to search the r-package-devel 
> archives than googling (e.g.) 
> "site:https://stat.ethz.ch/pipermail/r-package-devel  403" ?
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Package PowerSDI NOTES

[Avraham Adler]

Hello, Gabriel. 

CRAN policy is to rarely, if ever, allow long-running examples. It would be 
best if you could give an example of the function which requires as little run 
time as possible. Perhaps pre-compute some stages?

Avi

Sent from my iPhone

> On Jul 18, 2023, at 9:07 PM, Gabriel Constantino Blain 
>  wrote:
> 
> Dears,
> I submitted my R package to CRAN.
> However, it didn't pass the CRAN checks because of 2 notes:
> Note 1:
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
> Check: CRAN incoming feasibility, Result: NOTE
>  Maintainer: 'Gabriel Constantino Blain '
>  New submission
>Possibly misspelled words in DESCRIPTION:
>EP (14:45)
>NASAPOWER (11:18)
>OperatSDI (12:9)
>PowerSDI (7:18, 13:9)
>SPEI (3:31, 7:50, 10:20)
>SPI (3:23, 7:42, 10:12)
>ScientSDI (9:19)
>evapotranspitation (13:44)
>subperiods (15:76)
> Note 2:
> Flavor: r-devel-windows-x86_64
> Check: examples, Result: NOTE
>  Examples with CPU (user + system) or elapsed time > 10s
> user system elapsed
>  ScientSDI 82.71   0.75   88.00
>  Reference 29.75   0.05   29.80
>  Accuracy  10.02   1.11   11.12
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: examples, Result: NOTE
>  Examples with CPU (user + system) or elapsed time > 5s
>  user system elapsed
>  ScientSDI 52.674  0.176  57.765
>  Reference 20.749  0.148  20.898
>  Accuracy   6.001  0.024   6.024
> 
> Regarding note 1, not all the words are misspelled,
> EP, SPI and SPEI are acronyms
> OperatSDI and ScientSDI are functions of my package
> PowerSDI is the name of my package's name
> NASAPOWER is the project's name.
> 
> Regarding note 2, I don't know what's wrong. Is it related to the time to run 
> the examples (>5s)? If is it so, it is not an error. There are so many 
> calculations that it does take some time to do it.
> 
> The package is available at https://github.com/gabrielblain/PowerSDI
> I really appreciate any help you can provide.
> Best regards
> Gabriel
> 
>[[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error

[Avraham Adler]

Hi. 

Are you sure you have the most up-to-date version of the libraries? It should 
be version 5550. Tomas updates the entire toolchain semi-regularly. If you call 
“ cat /x86_64-w64-mingw32.static.posix/.version” and it’s not 5550, try 
updating the libraries as per 
https://cran.r-project.org/bin/windows/base/howto-R-devel.html.

Hope that helps,

Avi

Sent from my iPhone

> On May 10, 2023, at 9:07 PM, Gmail  wrote:
> 
> Windows 11 PRO Version  10.0.22621 Build 22621
> Processor: Intel(R) Core(TM) i7-1065G7 "Icelake-client"
> ```
> ​svn info
> Path: .
> Working Copy Root Path: /d/R_DEV/R-4/R42/R-4-2-branch
> URL: https://svn.r-project.org/R/branches/R-4-2-branch
> Relative URL: ^/branches/R-4-2-branch
> Repository Root: https://svn.r-project.org/R
> Repository UUID: 00db46b3-68df-0310-9c12-caf00c1e9a41
> Revision: 84417
> Node Kind: directory
> Schedule: normal
> Last Changed Author: kalibera
> Last Changed Rev: 84249
> Last Changed Date: 2023-04-13 07:12:24 + (Thu, 13 Apr 2023)
> ```
> 
> Only adaptation done in MkRules.local was adding: `EOPTS = -march=native`  - 
> that's why I included the cpu-type info above;
> running make all recommended​ fails at/with:
> ```
> gcc -shared -s -static-libgcc -o utils.dll tmp.def init.o io.o size.o sock.o 
> stubs.o utils.o hashtab.o windows/dataentry.o windows/dialogs.o 
> windows/registry.o windows/util.o windows/widgets.o 
> ../../../gnuwin32/dllversion.o -lRgraphapp -lversion 
> -L/x86_64-w64-mingw32.static.posix/lib/x64 -llzma 
> -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 
> -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -L../../../../bin/x64 -lR
> 
> lto1.exe: fatal error: bytecode stream in file 'windows/dataentry.o' 
> generated with LTO version 9.3 instead of the expected 9.4
> compilation terminated.
> 
> lto-wrapper.exe: fatal error: 
> C:\rtools42\x86_64-w64-mingw32.static.posix\bin\gcc.exe returned 1 exit status
> compilation terminated.
> C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: error: lto-wrapper 
> failed
> collect2.exe: error: ld returned 1 exit status
> cp: cannot stat 'utils.dll': No such file or directory
> make[4]: *** [Makefile.win:36: shlib] Error 1
> make[3]: *** [../../../share/make/basepkg.mk:145: mksrc-win2] Error 1
> make[2]: *** [Makefile.win:24: all] Error 2
> make[1]: *** [Makefile.win:34: R] Error 1
> make: *** [Makefile:18: all] Error 2
> ```
> Any hints/ideas on how to fix this? I guess I could 
> gcc -c -flto ... windows/dataentry.c -o windows/dataentry.o 
> with the exact path of that fiile ... 
> and it hopefully will fix that but I guess it would make sense to add a 
> Revision to update that LTO version mismatch there, and I don't know yet if 
> this is the only one?
> 
> Greetings,
> W
> 
> __
> 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: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Avraham Adler]

On Tue, Feb 7, 2023 at 12:10 AM Iñaki Ucar  wrote:
>
> On Tue, 7 Feb 2023 at 00:09, Avraham Adler  wrote:
> >
> > "If a package does have a src/Makevars[.win] file then also setting
> > the make variable ‘CXX_STD’ there is recommended,"
>
> That doesn't refer to the SystemRequirements field.
>
> Iñaki
>

No, but the prior sentence does. The complete excerpt is:

  ::Packages without a src/Makevars or src/Makefile file may specify a
C++ standard for code in the src directory by including something like
‘C++14’ in the ‘SystemRequirements’ field of the DESCRIPTION file,
e.g.
  SystemRequirements: C++14
 ::If a package does have a src/Makevars[.win] file then also setting
the make variable ‘CXX_STD’ there is recommended, as it allows R CMD
SHLIB to work correctly in the package’s src directory.

So one is supposed to add the requirement to DESCRIPTION via
SystemRequitements. If there is a Makevars, one should ALSO set the
variable in there.

If you wish, I can forward you personal communication with Professor
Ripley from last week where he makes this clear as well.

Thanks,

Avi


> >
> > Avi
> >
> > On Mon, Feb 6, 2023 at 10:58 PM Iñaki Ucar  wrote:
> > >
> > > On Mon, 6 Feb 2023 at 23:27, Avraham Adler  
> > > wrote:
> > > >
> > > > On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch 
> > > >  wrote:
> > > > >
> > > > > On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > > > > > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> > > > > >> I recently submitted a package to CRAN with "SystemRequirements: 
> > > > > >> C++11".
> > > > > >> This raises the following NOTE on R-devel, and I was asked to fix 
> > > > > >> and
> > > > > >> resubmit:
> > > > > >>
> > > > > >> * checking C++ specification ... NOTE
> > > > > >> Specified C++11: please update to current default of C++17
> > > > > >>
> > > > > >> If I understand correctly, I have two options, neither of which 
> > > > > >> will work:
> > > > > >> 1. Remove "SystemRequirements: C++11" entirely. The problem with 
> > > > > >> this is
> > > > > >> that on systems with older versions of R (3.6 and below, I 
> > > > > >> believe), it may
> > > > > >> try to compile the package with an older C++ standard, which will 
> > > > > >> fail.
> > > > > >> 2. Update it to "SystemRequirements: C++17". The problem here is 
> > > > > >> that on
> > > > > >> systems that don't have a C++17 compiler, the package won't build 
> > > > > >> -- even
> > > > > >> though the package only actually requires a C++11 compiler.
> > > > > >>
> > > > > >> How should I deal with this?
> > > > > >
> > > > > > Are you allowed to say "C++11 or C++17"?
> > > > >
> > > > > Actually I can partially answer this:  the test is not based on
> > > > > SystemRequirements, but on the log of the build, which now contains
> > > > > lines like this:
> > > > >
> > > > >using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > > > >using C++ compiler: ‘Apple clang version 12.0.0 
> > > > > (clang-1200.0.32.28)’
> > > > >using C++11
> > > > >using SDK: ‘MacOSX11.1.sdk’
> > > > >
> > > > > I get "using C++11" because of this line in Makevars:
> > > > >
> > > > >CXX_STD = CXX11
> > > > >
> > > > > So I guess the answer is to change your Makevars to make that line
> > > > > conditional on running under an old version of R.  If you figure out 
> > > > > how
> > > > > to do that, could you post the recipe here?
> > > >
> > > > I believe this is closely related to this email [1]. Dirk and I and
> > > > Aymeric have been going through the same issue with nloptr as well.
> > > > Our current opinion is to leave it out, as it would restrict more
> > > > users to demand C++17, which is unneeded, than to have users with over
> > > > a decade old compiler which does not have C++11. Dirk and Aymeric,
> > > > please chime in if I have misstated. Regardless, according to
> > > > Professor Ripley, if you require specific features, you should mark
> > > > them in _both_ Makevars and SystemRequirements, which is implied in
> > > > the "r-devel" version of WRE which adds the words "also" in section
> > > > 1.2.4.
> > >
> > > Could you please point to the specific passage? According to [1],
> > > section 1.2.4, declaring the C++ standard in SystemRequirements is
> > > only mandatory for C++17 or later.
> > >
> > > [1] 
> > > https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code
> > >
> > > --
> > > Iñaki Úcar
>
>
>
> --
> Iñaki Úcar

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

Re: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Avraham Adler]

"If a package does have a src/Makevars[.win] file then also setting
the make variable ‘CXX_STD’ there is recommended,"

Avi

On Mon, Feb 6, 2023 at 10:58 PM Iñaki Ucar  wrote:
>
> On Mon, 6 Feb 2023 at 23:27, Avraham Adler  wrote:
> >
> > On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch  
> > wrote:
> > >
> > > On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > > > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> > > >> I recently submitted a package to CRAN with "SystemRequirements: 
> > > >> C++11".
> > > >> This raises the following NOTE on R-devel, and I was asked to fix and
> > > >> resubmit:
> > > >>
> > > >> * checking C++ specification ... NOTE
> > > >> Specified C++11: please update to current default of C++17
> > > >>
> > > >> If I understand correctly, I have two options, neither of which will 
> > > >> work:
> > > >> 1. Remove "SystemRequirements: C++11" entirely. The problem with this 
> > > >> is
> > > >> that on systems with older versions of R (3.6 and below, I believe), 
> > > >> it may
> > > >> try to compile the package with an older C++ standard, which will fail.
> > > >> 2. Update it to "SystemRequirements: C++17". The problem here is that 
> > > >> on
> > > >> systems that don't have a C++17 compiler, the package won't build -- 
> > > >> even
> > > >> though the package only actually requires a C++11 compiler.
> > > >>
> > > >> How should I deal with this?
> > > >
> > > > Are you allowed to say "C++11 or C++17"?
> > >
> > > Actually I can partially answer this:  the test is not based on
> > > SystemRequirements, but on the log of the build, which now contains
> > > lines like this:
> > >
> > >using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > >using C++ compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > >using C++11
> > >using SDK: ‘MacOSX11.1.sdk’
> > >
> > > I get "using C++11" because of this line in Makevars:
> > >
> > >CXX_STD = CXX11
> > >
> > > So I guess the answer is to change your Makevars to make that line
> > > conditional on running under an old version of R.  If you figure out how
> > > to do that, could you post the recipe here?
> >
> > I believe this is closely related to this email [1]. Dirk and I and
> > Aymeric have been going through the same issue with nloptr as well.
> > Our current opinion is to leave it out, as it would restrict more
> > users to demand C++17, which is unneeded, than to have users with over
> > a decade old compiler which does not have C++11. Dirk and Aymeric,
> > please chime in if I have misstated. Regardless, according to
> > Professor Ripley, if you require specific features, you should mark
> > them in _both_ Makevars and SystemRequirements, which is implied in
> > the "r-devel" version of WRE which adds the words "also" in section
> > 1.2.4.
>
> Could you please point to the specific passage? According to [1],
> section 1.2.4, declaring the C++ standard in SystemRequirements is
> only mandatory for C++17 or later.
>
> [1] 
> https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code
>
> --
> Iñaki Úcar

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

Re: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Avraham Adler]

On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch  wrote:
>
> On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> >> I recently submitted a package to CRAN with "SystemRequirements: C++11".
> >> This raises the following NOTE on R-devel, and I was asked to fix and
> >> resubmit:
> >>
> >> * checking C++ specification ... NOTE
> >> Specified C++11: please update to current default of C++17
> >>
> >> If I understand correctly, I have two options, neither of which will work:
> >> 1. Remove "SystemRequirements: C++11" entirely. The problem with this is
> >> that on systems with older versions of R (3.6 and below, I believe), it may
> >> try to compile the package with an older C++ standard, which will fail.
> >> 2. Update it to "SystemRequirements: C++17". The problem here is that on
> >> systems that don't have a C++17 compiler, the package won't build -- even
> >> though the package only actually requires a C++11 compiler.
> >>
> >> How should I deal with this?
> >
> > Are you allowed to say "C++11 or C++17"?
>
> Actually I can partially answer this:  the test is not based on
> SystemRequirements, but on the log of the build, which now contains
> lines like this:
>
>using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
>using C++ compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
>using C++11
>using SDK: ‘MacOSX11.1.sdk’
>
> I get "using C++11" because of this line in Makevars:
>
>CXX_STD = CXX11
>
> So I guess the answer is to change your Makevars to make that line
> conditional on running under an old version of R.  If you figure out how
> to do that, could you post the recipe here?

I believe this is closely related to this email [1]. Dirk and I and
Aymeric have been going through the same issue with nloptr as well.
Our current opinion is to leave it out, as it would restrict more
users to demand C++17, which is unneeded, than to have users with over
a decade old compiler which does not have C++11. Dirk and Aymeric,
please chime in if I have misstated. Regardless, according to
Professor Ripley, if you require specific features, you should mark
them in _both_ Makevars and SystemRequirements, which is implied in
the "r-devel" version of WRE which adds the words "also" in section
1.2.4.

Thanks,

Avi

[1] https://stat.ethz.ch/pipermail/r-package-devel/2023q1/008865.html

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

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

Re: [R-pkg-devel] Proper way to express Fortran 2008 dependence for R package

[Avraham Adler]

For closure, I was advised by Professor Ripley to both pass
"-std=f008" in Makevars and add "SystemRequirements: A version of
gfortran supporting Fortran 2008" to the DESCRIPTION. CRAN accepted
the package with those two changes. I also note that the R Daily News
of 2023-02-03 [1] has the following entry under "R-devel": ‘check’'s
‘checking compilation flags in Makevars’ has been relaxed to accept
the use of flags such as ‘-std=f2008’ in ‘PKG_FFLAGS’. Hopefully, this
means future packages will have an easier time relying on more modern
features, albeit they are 5 or 15 years old by now :).

Thank you,

Avi

[1]: 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2023/02/02#n2023-02-02

On Mon, Jan 30, 2023 at 12:12 AM Avraham Adler  wrote:
>
> I would like to convert some of my hand-rolled Fortran code to Fortran
> intrinsics which entered the language in Fortran 2008, which should be
> extremely widely supported at this time. Specifically, I would like to
> use the log_gamma function and ieee_arithmetic functions and values.
> If it helps, the current package is at [1] and devel branch with new
> code is at [2].
>
> If I understand it correctly, WRE allows for dependence on Fortran
> 2008 by explicitly passing -std=f2008 in PKG_FFLAGS (WRE section 1.2.3
> Using F9x code [3]). However, checking a package as-cran with that
> addition delivers a warning (further confirmed by win-builder and
> rhub).
>
> My question is is it appropriate to submit a package with that warning
> and note it in the submission or is there a better way to express
> reliance on Fortran 2008. The implication from WRE 1.2.4 is that
> passing standards in Makevars is preferable to stating them in
> DESCRIPTION, at least as regards C++.
>
> What somewhat complicates matters is that if I build my package
> (Rtools43 on Windows 10) without passing "-std=f2008" it still builds
> properly and passes all the tests because Rtools43 is based on GCC12.2
> which supports Fortran 2008 intrinsics. So I can probably submit it
> without the flag, but someone with a very old Fortran installation may
> suffer.
>
> I understand being told I should just address CRAN directly, but I
> thought I would try the collected institutional memory here first.
>
> Thank you,
>
> Avi
>
> [1] https://github.com/aadler/Delaporte
> [2] https://github.com/aadler/Delaporte/tree/devel
> [3] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-F9x-code

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

[R-pkg-devel] Proper way to express Fortran 2008 dependence for R package

[Avraham Adler]

I would like to convert some of my hand-rolled Fortran code to Fortran
intrinsics which entered the language in Fortran 2008, which should be
extremely widely supported at this time. Specifically, I would like to
use the log_gamma function and ieee_arithmetic functions and values.
If it helps, the current package is at [1] and devel branch with new
code is at [2].

If I understand it correctly, WRE allows for dependence on Fortran
2008 by explicitly passing -std=f2008 in PKG_FFLAGS (WRE section 1.2.3
Using F9x code [3]). However, checking a package as-cran with that
addition delivers a warning (further confirmed by win-builder and
rhub).

My question is is it appropriate to submit a package with that warning
and note it in the submission or is there a better way to express
reliance on Fortran 2008. The implication from WRE 1.2.4 is that
passing standards in Makevars is preferable to stating them in
DESCRIPTION, at least as regards C++.

What somewhat complicates matters is that if I build my package
(Rtools43 on Windows 10) without passing "-std=f2008" it still builds
properly and passes all the tests because Rtools43 is based on GCC12.2
which supports Fortran 2008 intrinsics. So I can probably submit it
without the flag, but someone with a very old Fortran installation may
suffer.

I understand being told I should just address CRAN directly, but I
thought I would try the collected institutional memory here first.

Thank you,

Avi

[1] https://github.com/aadler/Delaporte
[2] https://github.com/aadler/Delaporte/tree/devel
[3] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-F9x-code

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

[Rd] R-devel 83314 fails datetime3 on Windows

[Avraham Adler]

Hello.

Building 83314 on R using R-tools I get the following failure which
relates to lines 463--470 in the datetime3.R test:

```
> ifi3 <- is.finite(dctm3)
> stopifnot(exprs = {
+ all.equal(dD, dDc, tolerance = 1e-4)
+ (dDm3 - dDcm3)[ifi3] %in% 0:1
+   (dD - dDc  )[ifi]  %in% 0:1
+   (nD - nDc  )[ifi]  %in% 0:1
+ is.na((dD   - dDc  )[!ifi])
+ is.na((dDm3 - dDcm3)[!ifi3])
+ })
Error: (dDm3 - dDcm3)[ifi3] %in% 0:1 are not all TRUE
Execution halted
```

In particular, please note that the first entries in the following two
vectors differ by one day:

```
> dDm3
 [1] "2016-12-06" NA   NA   "2016-12-06" NA
"2016-04-06" NA   NA   "2016-04-07"
[10] "2016-12-06" NA   "-Inf"   NA
> dDcm3
 [1] "2016-12-07" NA   NA   "2016-12-06" NA
"2016-04-06" NA   NA   "2016-04-07"
[10] "2016-12-06" NA   "-Inf"   NA
```
Also, in the sessionInfo below, I wonder why my computer returns a
time zone of Australia/Melbourne when I am based in US/New York

Session Info:

R Under development (unstable) (2022-11-08 r83314 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United
States.utf8LC_MONETARY=English_United States.utf8
[4] LC_NUMERIC=C   LC_TIME=English_United
States.utf8

time zone: Australia/Melbourne
tzcode source: internal

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

loaded via a namespace (and not attached):
[1] compiler_4.3.0

Note that Rblas is based on OpenBLAS 0.3.21

Thank you,

Avi

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

Re: [Rd] Linking to Intel's MKL on Windows

[Avraham Adler]

Also, you can build Rblas against OpenBLAS even on Windows which will go far in 
speeding up matrix calculations. 

Thanks,

Avi

Sent from my iPhone

> On Oct 1, 2022, at 12:49 PM, Ben Bolker  wrote:
> 
>    Maybe you can find out more about Microsoft's development/release process 
> for MRO and why they're still on 4.0.2 (from June 2020)?  I followed the 
> "user forum" link on their web page, but it appears to be a generic Windows 
> forum ...
> 
> https://social.msdn.microsoft.com/Forums/en-US/home?forum%20=ropen
> 
>   I might tweet at @revodavid (David Smith) to see if there's any more 
> information available about the MRO release schedule ...
> 
>  good luck,
>   Ben Bolker
> 
> 
> 
> 
>> On 2022-10-01 12:00 p.m., Viechtbauer, Wolfgang (NP) wrote:
>> Hi Christine,
>> MKL is a closed-source commercial product (yes, one can get it for free, but 
>> it is not libre/open-source software).
>> Best,
>> Wolfgang
>>> -Original Message-
>>> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Christine
>>> Stawitz - NOAA Federal via R-devel
>>> Sent: Friday, 30 September, 2022 18:46
>>> To: r-devel@r-project.org
>>> Subject: [Rd] Linking to Intel's MKL on Windows
>>> 
>>> Hi,
>>> 
>>> Recently I became aware that Microsoft R Open provides accelerated matrix
>>> algebra computations through Intel's Math Kernel Libraries. However, the
>>> version of R shipped with the Microsoft R Open is too out of date to be
>>> able to use concurrently with other dependencies while developing our
>>> package. This thread suggests a way to get the updated matrix libraries
>>> with a more recent version of R, however it is unlikely to be approved by
>>> our IT admin since those of us in government agencies aren't typically
>>> given admin privileges: Linking Intel's Math Kernel Library (MKL) to R on
>>> Windows - Stack Overflow
>>> >> mkl-to-r-on-windows>
>>> 
>>> Is there a reason why CRAN doesn't provide a version of R with the updated
>>> libraries such that developers don't have to recompile R or copy .dlls
>>> around as described above? It would help those of us running software with
>>> slow-running matrix calculations in R.
>>> 
>>> Thanks,
>>> Christine
>>> 
>>> --
>>> Christine C. Stawitz, PhD. (pronouns: she/her)
>>> 
>>> National Stock Assessment Program Modeling Team
>>> 
>>> NOAA Fisheries Office of Science and Technology |  U.S. Department of
>>> Commerce
>>> 
>>> Mobile: 206-617-2060
>>> 
>>> www.fisheries.noaa.gov
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -- 
> Dr. Benjamin Bolker
> Professor, Mathematics & Statistics and Biology, McMaster University
> Director, School of Computational Science and Engineering
> (Acting) Graduate chair, Mathematics & Statistics
> > E-mail is sent at my convenience; I don't expect replies outside of working 
> > hours.
> 
> __
> 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] Parser bug? A comma too much.

[Avraham Adler]

That may actually be the case for EVERY default plot, if I understand
correctly. The default S# plot is defined as

## Default S3 method:
plot(x, y = NULL, type = "p",  xlim = NULL, ylim = NULL,
 log = "", main = NULL, sub = NULL, xlab = NULL, ylab = NULL,
 ann = par("ann"), axes = TRUE, frame.plot = axes,
 panel.first = NULL, panel.last = NULL, asp = NA,
 xgap.axis = NA, ygap.axis = NA,
 ...)

By putting in the comma, unless I am mistaken, you are effectively
saying the second element is NULL, which is how it's naturally
defined.

Thanks,

Avi

On Fri, Sep 16, 2022 at 2:33 PM Rui Barradas  wrote:
>
> Hello,
>
> Why doesn't the comma throw an error?
>
>
> plot(1:5,)# works, no complaints
>
>
> Shouldn't this be considered a bug? I would expect the parser to at
> least give a warning.
>
>
> sessionInfo()
> R version 4.2.1 (2022-06-23 ucrt)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 22000)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=Portuguese_Portugal.utf8
> LC_CTYPE=Portuguese_Portugal.utf8
> [3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C
>
> [5] LC_TIME=Portuguese_Portugal.utf8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.2.1
>
>
> Rui Barradas
>
> __
> 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: [R-pkg-devel] No package called 'scales' (r-oldrel-windows)

[Avraham Adler]

Scales is the package which is called when you use something like
"dollar" or "comma" in scale_x_whatever(); perhaps you have a similar
invocation without realizing it?

Thanks,

Avi

On Tue, Aug 23, 2022 at 5:40 PM Paul Hibbing  wrote:
>
> Hi all,
>
> I recently submitted an update to `PAutilities`.
>
> It has errored for r-oldrel-windows with "there is no package called
> 'scales'" (see 
> https://www.r-project.org/nosvn/R.check/r-oldrel-windows-ix86+x86_64/PAutilities-00install.html).
>
> I am a bit mystified by this, as the package builds fine on Winbuilder
> old release (see
> https://win-builder.r-project.org/g6EPG1y3nGN9/00check.log), as well
> as my older local Windows installation (4.0.5) and all other platforms
> I have checked.
>
> Does anyone have insights about this? I assume it is related to
> dependency on ggplot2, but I'm struggling to replicate the error and
> thus unsure where to start.
>
> Many thanks,
> Paul
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Two problems with fda

[Avraham Adler]

Hello, Spencer.

I am solely on Windows, so I am not familiar with the workflow you
need, but I have found the following posts which discuss tlmgr in the
context of a Github action. Perhaps they can provide you with insight:
[1], [2].

Hope that helps!

Avi

[1] 
https://tex.stackexchange.com/questions/551383/cant-run-tex-lives-tlmgr-in-a-github-action
[2] https://github.com/xu-cheng/texlive-action

On Thu, Apr 28, 2022 at 2:28 PM Duncan Murdoch  wrote:
>
> On 28/04/2022 10:17 a.m., Spencer Graves wrote:
> > Hi, Duncan et al.:
> >
> >
> > I passed Duncan's suggestions to Jim Ramsay, who implemented
> > something -- not sure what -- and "fda_6.0.3.tar.gz has been built for
> > Windows and will be published within 24 hours in the corresponding CRAN
> > directory"!  (Thanks, Duncan!)
>
> You're welcome.
>
> > My attempts to fix ".github/workflows/R-CMD-check.yaml" have so far
> > been unsuccessful:
> >
> >
> > https://github.com/JamesRamsay5/fda/commit/3dd1938d95055ed798a8b6caebcfe0eb8a03668b
>
> Line 50 in that update looks wrong.  It might make sense to have "tlmgr
> --version" just after line 53, indented like lines 54 and 55.
>
> Duncan Murdoch
>
> >
> > For me currently, yaml = "yet another misunderstood language" ;-)
> > And I've misplaced Yihui Xie's recommendations on how to ask for help.
> > I remember he suggested submitting a question first to Stack Exchange or
> > Stack Overflow or ..., but I can't find those recommendations, so I
> > thought I'd here thank Avraham Adler  and
> > everyone else who has considered replying to this question, hoping that
> > someone can help me take the next step.
> >
> >
> > Thanks again,
> > Spencer Graves
> >
> >
> > On 4/26/22 11:46 AM, Duncan Murdoch wrote:
> >> On 25/04/2022 8:24 p.m., Duncan Murdoch wrote:
> >>...
> >>>
> >>> \value{
> >>>  These functions return either a standard \code{fRegress} fit
> >>> object or
> >>>  or a model specification:
> >>>  \item{The \code{fRegress} fit object case:}{
> >>>
> >>>
> >>> Aha, in a \value{} section, bare \items are supposed to mark components
> >>> of the value, so they are automatically code.  I think the fix for this
> >>> is to make it an explicit \describe list:
> >>>
> >>> \value{
> >>>  These functions return either a standard \code{fRegress} fit
> >>> object or
> >>>  or a model specification:
> >>>  \describe{
> >>>\item{The \code{fRegress} fit object case:}{
> >>>
> >>>  ... eventually ...
> >>>
> >>>  }
> >>
> >> An even simpler fix:  don't mark the section title as an \item, i.e.
> >> write as
> >>
> >> \value{
> >>  These functions return either a standard \code{fRegress} fit object or
> >>  or a model specification.
> >>
> >>  The \code{fRegress} fit object case:
> >>
> >>
> >>  \item{field}{description  }
> >>
> >>
> >> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] Appropriate mailing list for " Improved LP/MIP solver "

[Avraham Adler]

I defer completely and totally to Martin!

Apologies,

Avi

On Mon, Dec 13, 2021 at 10:59 AM Martin Maechler 
wrote:

> >>>>> Avraham Adler
> >>>>> on Sun, 12 Dec 2021 16:27:02 + writes:
>
>  []
>
> Thank you, Julian and Avi,  on the topic of asking and replying
> if there's interest on getting improved LP / MIP  (and QP, I think was
> mentioned too!) solver interfaces for R.
>
> However, Avi writes
>
> > Also, to be good R-citizens, this thread should probably be moved to
> > R-package-devel [1].
>
> > Thanks,
> > Avi
>
> and I'm of an entirely different opinion.
>
> R-package-devel  has been created, aons after R-devel,  to
> *help* R package developers to get their packaging problems
> solved, notably to get advice in making their packages ready for
> CRAN.
>
> Julian's question was really addressing the whole R developer
> community asking if some functionality was desirable to be added
> to the R-package space.
>
> For me one *the* appropriate topics for this R-devel mailing
> list.
>
> Best,
> Martin
>
> ---
> Martin Maechler
> ETH Zurich  and  R Core
> (and original creator of R-help, R-devel, .. lists)
>
> > [1] https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Improved LP/MIP solver

[Avraham Adler]

On Sun, Dec 12, 2021 at 4:24 PM Avraham Adler  wrote:
>
> On Sun, Dec 12, 2021 at 3:44 PM Julian Hall  wrote:
> >
> > Dear All,
> >
> > I am leading the development of HiGHS, which is now the top performing open 
> > source linear optimization software on the industry standard benchmarks. In 
> > particular, our MIP solver out-performs SCIP, and is way ahead of the 
> > COIN-OR solver Cbc.
> >
> > HiGHS solves LPs via simplex or interior point, MIPs via branch-and-cut, 
> > and QPs via an active set method.
> >
> > We were wondering what interest there would be in developing an R interface 
> > to HiGHS. I'm not an R user, but have done a bit of searching and see 
> > references to Rsymphony and an interface to Lpsolve.
> >
> > Performance-wise Lpsolve is very poor, but I know that it has a community 
> > of devoted followers. I've not seen benchmark results for Symphony, but I 
> > know that Cbc is the preferred COIN-OR MIP solver when it comes to general 
> > performance.  And, as I observed, the performance of HiGHS is way better 
> > than Cbc.
> >
> > Are people in the R community tearing their hair out over the performance 
> > of software requiring the solution of LPs or MIPs?
> >
> > Would a significantly better LP/MIP solver be valuable to the R community?
> >
> > Thanks,
> >
> > Julian
> > --
> > Dr. J. A. Julian Hall, Reader, School of Mathematics,
> > University of Edinburgh, James Clerk Maxwell Building,
> > Peter Guthrie Tait Road, EDINBURGH, EH9 3FD, UK.
> > Room: 5418 Phone: [+44](131) 650 5075 Email: 
> > j.a.j.h...@ed.ac.uk<mailto:j.a.j.h...@ed.ac.uk>
> > Web: https://www.maths.ed.ac.uk/school-of-mathematics/people/a-z?person=47
> > [HiGHS]<http://www.highs.dev>
> >
> > My working hours may not be your working hours. Do not feel pressure to 
> > reply to this email outside your working hours.
> > The University of Edinburgh is a charitable body, registered in Scotland, 
> > with registration number SC005336. Is e buidheann carthannais a th’ ann an 
> > Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
> Hello, Julian.
>
> I cannot speak for the R community, but as someone who needs
> optimization on a regular basis, this sounds intriguing. The fact that
> HiGHS appears to be FLOSS, and thus usable as-is in the corporate
> setting, appeals to those of us who use R in industry. Would you have
> any statistics on how the solvers in HiGHS compare with similar ones
> currently available in R, specifically the following in NLOPT [1]
> (which is called through nloptr): SLSQP (gradient-based) and COBYLA
> (gradient-free) both of which support equality and inequality
> constraints, and MMA/CCSA (gradient based) which supports inequality
> constraints? As for integer or mixed integer programming, I believe
> that there is a lot of room for improvement in R. Personally, I've
> resorted to using DEOptim with the "fnMap" entry calling a round
> function similar to [2]. So speaking for myself, giving richer options
> for optimization is a good thing, especially if the installation
> procedure can be simplified!
>
> Thank you,
>
> Avi
>
> [1] https://nlopt.readthedocs.io/en/latest/NLopt_Algorithms/
> [2] 
> https://stackoverflow.com/questions/42197353/how-to-set-integer-constraint-using-fnmap-in-deoptim-r

Also, to be good R-citizens, this thread should probably be moved to
R-package-devel [1].

Thanks,

Avi

[1] https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] Improved LP/MIP solver

[Avraham Adler]

On Sun, Dec 12, 2021 at 3:44 PM Julian Hall  wrote:
>
> Dear All,
>
> I am leading the development of HiGHS, which is now the top performing open 
> source linear optimization software on the industry standard benchmarks. In 
> particular, our MIP solver out-performs SCIP, and is way ahead of the COIN-OR 
> solver Cbc.
>
> HiGHS solves LPs via simplex or interior point, MIPs via branch-and-cut, and 
> QPs via an active set method.
>
> We were wondering what interest there would be in developing an R interface 
> to HiGHS. I'm not an R user, but have done a bit of searching and see 
> references to Rsymphony and an interface to Lpsolve.
>
> Performance-wise Lpsolve is very poor, but I know that it has a community of 
> devoted followers. I've not seen benchmark results for Symphony, but I know 
> that Cbc is the preferred COIN-OR MIP solver when it comes to general 
> performance.  And, as I observed, the performance of HiGHS is way better than 
> Cbc.
>
> Are people in the R community tearing their hair out over the performance of 
> software requiring the solution of LPs or MIPs?
>
> Would a significantly better LP/MIP solver be valuable to the R community?
>
> Thanks,
>
> Julian
> --
> Dr. J. A. Julian Hall, Reader, School of Mathematics,
> University of Edinburgh, James Clerk Maxwell Building,
> Peter Guthrie Tait Road, EDINBURGH, EH9 3FD, UK.
> Room: 5418 Phone: [+44](131) 650 5075 Email: 
> j.a.j.h...@ed.ac.uk
> Web: https://www.maths.ed.ac.uk/school-of-mathematics/people/a-z?person=47
> [HiGHS]
>
> My working hours may not be your working hours. Do not feel pressure to reply 
> to this email outside your working hours.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th’ ann an 
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

Hello, Julian.

I cannot speak for the R community, but as someone who needs
optimization on a regular basis, this sounds intriguing. The fact that
HiGHS appears to be FLOSS, and thus usable as-is in the corporate
setting, appeals to those of us who use R in industry. Would you have
any statistics on how the solvers in HiGHS compare with similar ones
currently available in R, specifically the following in NLOPT [1]
(which is called through nloptr): SLSQP (gradient-based) and COBYLA
(gradient-free) both of which support equality and inequality
constraints, and MMA/CCSA (gradient based) which supports inequality
constraints? As for integer or mixed integer programming, I believe
that there is a lot of room for improvement in R. Personally, I've
resorted to using DEOptim with the "fnMap" entry calling a round
function similar to [2]. So speaking for myself, giving richer options
for optimization is a good thing, especially if the installation
procedure can be simplified!

Thank you,

Avi

[1] https://nlopt.readthedocs.io/en/latest/NLopt_Algorithms/
[2] 
https://stackoverflow.com/questions/42197353/how-to-set-integer-constraint-using-fnmap-in-deoptim-r

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

Re: [Rd] string concatenation operator (revisited)

[Avraham Adler]

Gabe, I agree that missingness is important to factor in. To somewhat abuse
the terminology, NA is often used to represent missingness. Perhaps
concatenating character something with character something missing should
result in the original character?

Avi

On Mon, Dec 6, 2021 at 3:35 PM Gabriel Becker  wrote:

> Hi All,
>
> Seeing this and the other thread (and admittedly not having clicked through
> to the linked r-help thread), I wonder about NAs.
>
> Should NA  "hi there"  not result in NA_character_? This is not
> what any of the paste functions do, but in my opinoin, NA + 
> seems like it should be NA  (not "NA"), particularly if we are talking
> about `+` overloading, but potentially even in the case of a distinct
> concatenation operator?
>
> I guess what I'm saying is that in my head missingness propagation rules
> should take priority in such an operator (ie NA +  should
> *always * be NA).
>
> Is that something others disagree with, or has it just not come up yet in
> (the parts I have read) of this discussion?
>
> Best,
> ~G
>
> On Mon, Dec 6, 2021 at 10:03 AM Radford Neal 
> wrote:
>
> > > > In pqR (see pqR-project.org), I have implemented ! and !! as binary
> > > > string concatenation operators, equivalent to paste0 and paste,
> > > > respectively.
> > > >
> > > > For instance,
> > > >
> > > >  > "hello" ! "world"
> > > >  [1] "helloworld"
> > > >  > "hello" !! "world"
> > > >  [1] "hello world"
> > > >  > "hello" !! 1:4
> > > >  [1] "hello 1" "hello 2" "hello 3" "hello 4"
> > >
> > > I'm curious about the details:
> > >
> > > Would `1 ! 2` convert both to strings?
> >
> > They're equivalent to paste0 and paste, so 1 ! 2 produces "12", just
> > like paste0(1,2) does.  Of course, they wouldn't have to be exactly
> > equivalent to paste0 and paste - one could impose stricter
> > requirements if that seemed better for error detection.  Off hand,
> > though, I think automatically converting is more in keeping with the
> > rest of R.  Explicitly converting with as.character could be tedious.
> >
> > I suppose disallowing logical arguments might make sense to guard
> > against typos where ! was meant to be the unary-not operator, but
> > ended up being a binary operator, after some sort of typo.  I doubt
> > that this would be a common error, though.
> >
> > (Note that there's no ambiguity when there are no typos, except that
> > when negation is involved a space may be needed - so, for example,
> > "x" !  !TRUE is "xFALSE", but "x"!!TRUE is "x TRUE".  Existing uses of
> > double negation are still fine - eg, a <- !!TRUE still sets a to TRUE.
> > Parsing of operators is greedy, so "x"!!!TRUE is "x FALSE", not "xTRUE".)
> >
> > > Where does the binary ! fit in the operator priority?  E.g. how is
> > >
> > >   a ! b > c
> > >
> > > parsed?
> >
> > As (a ! b) > c.
> >
> > Their precedence is between that of + and - and that of < and >.
> > So "x" ! 1+2 evalates to "x3" and "x" ! 1+2 < "x4" is TRUE.
> >
> > (Actually, pqR also has a .. operator that fixes the problems with
> > generating sequences with the : operator, and it has precedence lower
> > than + and - and higher than ! and !!, but that's not relevant if you
> > don't have the .. operator.)
> >
> >Radford Neal
> >
> > __
> > 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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN no longer checking for solaris?

[Avraham Adler]

Would this mean we could start using little endian bit strings, as I think
only the Solaris platform was big endian (or was it the other way around)?

Avi

On Sun, Dec 5, 2021 at 8:56 PM Dirk Eddelbuettel  wrote:

>
> On 5 December 2021 at 17:23, Travers Ching wrote:
> | I see that there doesn't exist a Solaris flavor on any CRAN check page.
> | However, I'm certain that Solaris was being checked up until very
> recently.
> |
> | Is this just temporary?
> |
> | Is there any information for the future of Solaris on CRAN?
>
> No "official" word yet on this list, r-devel or elsewhere, or via commits
> to
> the CRAN Policy (which a cron job of mine monitors).
>
> But Henrik was eagle-eyed and spotted a number of changes to the svn (or
> git
> mirror thereof) writing Solaris out of the official documentation:
>
>   https://twitter.com/henrikbengtsson/status/1466877096471379970
>
> So yes it seems like an era is coming to a close.
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

On Wed, Nov 24, 2021 at 11:45 AM Martin Maechler
 wrote:
>
> >>>>> Avraham Adler  on Thu, 18 Nov 2021 02:18:54 + writes:
>
> > Hello.  I have isolated the issue: it is the
> > fused-multiply-add instruction set (FMA on Intel
> > processors). Running -march=skylake -mno-fma not only does
> > not hang, but passes make check-all (using R's native
> > BLAS).  My intuition remains that something in the new
> > more precise ebd0 code used in dpois_raw—called by dgamma,
> > called by dchsq, called by dnchisq—is hanging when the
> > assembler uses FMA. Unfortunately, I have come across
> > other cases online where the extra precision and the
> > different assembler code of FMA vs. non-FMA has caused
> > bugs, such as [1]. Page 5 of this paper by Dr. William
> > Kahan sheds some light on why this may be happening [2]
> > (PDF).
>
> > Martin & Morton, having written (PR#15628 [3]) and/or
> > implemented the ebd0 code that is now being used, can
> > either of you think of any reason why it would hang if
> > compiled using FMA?
>
> I vaguely remember I had a version of ebd0(), either Morton
> Welinder's original, or a slight modification of it that needed some
> mending, because in some border case, there was an out of
> array-boundary indexing... but that's just a vague recollection.
>
> I had investigated  ebd0()'s behavior quite a bit, also notably
> the version -- together with a pure R code version --
> in my CRAN package DPQ, yesterday updated to version 0.5-0 on CRAN
> {written in Summer, but published to CRAN only yesterday}
> where I have  dpois_raw() optionally using several experimental versions of
> bd0(), and both 'pure R' and a C version of ebd0(),
> as DPQ::ebd0() and DPQ::edb0C()
> each with an option  'verbose' which shows you which branches are chosen
> for the given arguments.
>
> So, if you install this version (0.5-0 or newer) from the development
> sources, using the *same* FMA configuration,
> I hope you should see the same "hanging" but would be able to see some
> more.. ?
>
> Can you install it from R-forge
>
> install.packages("DPQ", type = "source",
>  repos="http://R-Forge.R-project.org;)
>
> and then experiment?
> I'd be grateful  {and we maybe can move "off - mailing list"}
>
> Thank you in advance,
> Martin
>
> Martin Maechler
> ETH Zurich  and  R Core team

Sure. Responding here simply for closure. Will direct further
questions and output directly to you.

Thank yyou,

Avi

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

Re: [Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

Hello.

I have isolated the issue: it is the fused-multiply-add instruction
set (FMA on Intel processors). Running -march=skylake -mno-fma not
only does not hang, but passes make check-all (using R's native BLAS).
My intuition remains that something in the new more precise ebd0 code
used in dpois_raw—called by dgamma, called by dchsq, called by
dnchisq—is hanging when the assembler uses FMA. Unfortunately, I have
come across other cases online where the extra precision and the
different assembler code of FMA vs. non-FMA has caused bugs, such as
[1]. Page 5 of this paper by Dr. William Kahan sheds some light on why
this may be happening [2] (PDF).

Martin & Morton, having written (PR#15628 [3]) and/or implemented the
ebd0 code that is now being used, can either of you think of any
reason why it would hang if compiled using FMA? Again, I'm not a
professional, but line 325 of the ebd0 function in bd0.c [4] has
"ADD1(-x * log1pmx ((M * fg - x) / x))" which looks like a
Multiply-Add to me, at least in the inner parenthesis. Is there
anything that can be, or should be, done with the code to prevent the
hang, or must we forbid the use of FMA instructions (and I guess FMA4
on AMD processors) when compiling R?

Also, What happens in the case where M/x neither over- nor
under-flowed, M_LN2 * ((double) -e) <= 1. + DBL_MAX / x, fg != 1, and
after 4 loops of lines 329 & 330, *yh is still finite? How does ebd0
exit in that case? There is no "return" after line 331. Am I missing
something? Could that be related to this issue?

As an aside, could ebd0 be enhanced by using FMA instructions on
processors which support them?

Thank you very much,

Avi

[1] 
https://flameeyes.blog/2014/10/27/the-subtlety-of-modern-cpus-or-the-search-for-the-phantom-bug/
[2] https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
[3] https://bugs.r-project.org/show_bug.cgi?id=15628
[4] https://github.com/wch/r-source/blob/trunk/src/nmath/bd0.c

On Wed, Nov 17, 2021 at 3:55 PM Avraham Adler  wrote:
>
> Hello, Martin et. al.
>
> I apologize for top posting, but I believe I have tracked down the
> difference why last time my build worked and now it hangs on
> `dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1)`. and it's NOT the
> BLAS. I built against both 3.15 AND R's vanilla and it hung both
> times. The issue was passing "march=skylake". I own an i7-8700K which
> gcc considers a skylake. When I pass mtune=skylake, it does not hang
> and the make check-devel after the build completes.
>
> Below is a list of the different flags passed when using mtune vs.
> march. It stands to reason that at least one of them contributed to
> the hanging issue which Martin fixed in
> https://bugs.r-project.org/show_bug.cgi?id=13309. While I recognize
> the obvious ones, I'm not an expert and do not understand which if any
> may be the culprit. For reference, most of these flags are described
> here: 
> https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/x86-Options.html#x86-Options.
>
> All the following flags are DISABLED for mtune=skylake (so
> march=x86-64) and ENABLED when passing march-skylake. For the record,
> I usually passed march in the past without problem:
>
> madx, maes, mavx, mavx2, mbmi, mbmi2, mclflushopt, mcx16, mf16c, mfma,
> mfsgsbase, mhle, mlzcnt, mmovbe, mpclmul, mpopcnt, mprfchw, mrdrnd,
> mrdseed, msahf, msgx, msse3, msse4, msse4.1, msse4.2, mssse3, mxsave,
> mxsavec, mxsaveopt, and mxsaves.
>
> Inversely, mno-sse4 is enabled when using mtune and disabled when
> using arch, of course.
>
> For completeness, the following two are disabled on both mtune and
> march but enabled when passing march=native, otherwise the latter is
> the same as march=skylake: mabm and mrtm. Obviously these cannot
> contribute to the hanging issue.
>
> Any ideas, especially from the experts who understand how the flags
> would address the code in dchisq, would be greatly appreciated.
>
> Thank you,
>
> Avi
>
> On Wed, Nov 17, 2021 at 7:15 AM Avraham Adler  wrote:
> >
> > On Tue, Nov 16, 2021 at 10:42 PM Kevin Ushey  wrote:
> > >
> > > Do you see this same hang in a build of R with debug symbols? Can you
> > > try running R with GDB, or even WinDbg or another debugger, to see
> > > what the call stack looks like when the hang occurs? Does the hang
> > > depend on the number of threads used by OpenBLAS?
> > >
> > > On the off chance it's relevant, I've seen hangs / crashes when using
> > > a multithreaded OpenBLAS with R on some Linux systems before, but
> > > never found the time to isolate a root cause.
> > >
> >
> >
> > This last was a good thought, Kevin, as I had just compiled OpenBLAS
> > 3.18 multi-threaded, but I recompiled it single threaded and

Re: [Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

Hello, Martin et. al.

I apologize for top posting, but I believe I have tracked down the
difference why last time my build worked and now it hangs on
`dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1)`. and it's NOT the
BLAS. I built against both 3.15 AND R's vanilla and it hung both
times. The issue was passing "march=skylake". I own an i7-8700K which
gcc considers a skylake. When I pass mtune=skylake, it does not hang
and the make check-devel after the build completes.

Below is a list of the different flags passed when using mtune vs.
march. It stands to reason that at least one of them contributed to
the hanging issue which Martin fixed in
https://bugs.r-project.org/show_bug.cgi?id=13309. While I recognize
the obvious ones, I'm not an expert and do not understand which if any
may be the culprit. For reference, most of these flags are described
here: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/x86-Options.html#x86-Options.

All the following flags are DISABLED for mtune=skylake (so
march=x86-64) and ENABLED when passing march-skylake. For the record,
I usually passed march in the past without problem:

madx, maes, mavx, mavx2, mbmi, mbmi2, mclflushopt, mcx16, mf16c, mfma,
mfsgsbase, mhle, mlzcnt, mmovbe, mpclmul, mpopcnt, mprfchw, mrdrnd,
mrdseed, msahf, msgx, msse3, msse4, msse4.1, msse4.2, mssse3, mxsave,
mxsavec, mxsaveopt, and mxsaves.

Inversely, mno-sse4 is enabled when using mtune and disabled when
using arch, of course.

For completeness, the following two are disabled on both mtune and
march but enabled when passing march=native, otherwise the latter is
the same as march=skylake: mabm and mrtm. Obviously these cannot
contribute to the hanging issue.

Any ideas, especially from the experts who understand how the flags
would address the code in dchisq, would be greatly appreciated.

Thank you,

Avi

On Wed, Nov 17, 2021 at 7:15 AM Avraham Adler  wrote:
>
> On Tue, Nov 16, 2021 at 10:42 PM Kevin Ushey  wrote:
> >
> > Do you see this same hang in a build of R with debug symbols? Can you
> > try running R with GDB, or even WinDbg or another debugger, to see
> > what the call stack looks like when the hang occurs? Does the hang
> > depend on the number of threads used by OpenBLAS?
> >
> > On the off chance it's relevant, I've seen hangs / crashes when using
> > a multithreaded OpenBLAS with R on some Linux systems before, but
> > never found the time to isolate a root cause.
> >
>
>
> This last was a good thought, Kevin, as I had just compiled OpenBLAS
> 3.18 multi-threaded, but I recompiled it single threaded and it still
> crashes. The version of R I built from source last time, (2021-05-20
> r80347), does not hang when calling `dchisq(c(Inf, 1e80, 1e50, 1e40),
> df=10, ncp=1)`. I think I built that with OpenBLAS 3.15. I can try
> doing that here. As for building with debug symbols, I have never done
> that before, so if you could provide some guidance (off-list if you
> think it is inappropriate to keep it here) or point me in the
> direction of some already posted advice, I would appreciate it!
>
> Avi
>
>
>
> > Best,
> > Kevin
> >
> > On Tue, Nov 16, 2021 at 5:12 AM Avraham Adler  
> > wrote:
> > >
> > > On Tue, Nov 16, 2021 at 8:43 AM Martin Maechler
> > >  wrote:
> > > >
> > > > >>>>> Avraham Adler
> > > > >>>>> on Tue, 16 Nov 2021 02:35:56 + writes:
> > > >
> > > > > I am building r-devel on Windows 10 64bit using Jeroen's mingw 
> > > > system,
> > > > > and I am finding that my make check-devel hangs on the above 
> > > > issue.
> > > > > Everything is vanila except that I am using OpenBLAS 0.3.18. I 
> > > > have
> > > > > been using OpenBLAS for over a decade and have not had this issue
> > > > > before. Is there anything I can do to dig deeper into this issue 
> > > > from
> > > > > my end? Could there be anything that changed in R-devel that may 
> > > > have
> > > > > triggered this? The bugzilla report doesn't have any code 
> > > > attached to
> > > > > it.
> > > >
> > > > > Thank you,
> > > > > Avi
> > > >
> > > > Hmm.. it would've be nice to tell a bit more, instead of having all
> > > > your readers to search links, etc.
> > > >
> > > > In the bugzilla bug report PR#13309
> > > > https://bugs.r-project.org/show_bug.cgi?id=13309 ,the example was
> > > >
> > > >  dchisq(x=Inf, df=10, ncp=1)
> > > >
> > > > I had fixed the bu

Re: [Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

On Tue, Nov 16, 2021 at 10:42 PM Kevin Ushey  wrote:
>
> Do you see this same hang in a build of R with debug symbols? Can you
> try running R with GDB, or even WinDbg or another debugger, to see
> what the call stack looks like when the hang occurs? Does the hang
> depend on the number of threads used by OpenBLAS?
>
> On the off chance it's relevant, I've seen hangs / crashes when using
> a multithreaded OpenBLAS with R on some Linux systems before, but
> never found the time to isolate a root cause.
>


This last was a good thought, Kevin, as I had just compiled OpenBLAS
3.18 multi-threaded, but I recompiled it single threaded and it still
crashes. The version of R I built from source last time, (2021-05-20
r80347), does not hang when calling `dchisq(c(Inf, 1e80, 1e50, 1e40),
df=10, ncp=1)`. I think I built that with OpenBLAS 3.15. I can try
doing that here. As for building with debug symbols, I have never done
that before, so if you could provide some guidance (off-list if you
think it is inappropriate to keep it here) or point me in the
direction of some already posted advice, I would appreciate it!

Avi



> Best,
> Kevin
>
> On Tue, Nov 16, 2021 at 5:12 AM Avraham Adler  wrote:
> >
> > On Tue, Nov 16, 2021 at 8:43 AM Martin Maechler
> >  wrote:
> > >
> > > >>>>> Avraham Adler
> > > >>>>> on Tue, 16 Nov 2021 02:35:56 + writes:
> > >
> > > > I am building r-devel on Windows 10 64bit using Jeroen's mingw 
> > > system,
> > > > and I am finding that my make check-devel hangs on the above issue.
> > > > Everything is vanila except that I am using OpenBLAS 0.3.18. I have
> > > > been using OpenBLAS for over a decade and have not had this issue
> > > > before. Is there anything I can do to dig deeper into this issue 
> > > from
> > > > my end? Could there be anything that changed in R-devel that may 
> > > have
> > > > triggered this? The bugzilla report doesn't have any code attached 
> > > to
> > > > it.
> > >
> > > > Thank you,
> > > > Avi
> > >
> > > Hmm.. it would've be nice to tell a bit more, instead of having all
> > > your readers to search links, etc.
> > >
> > > In the bugzilla bug report PR#13309
> > > https://bugs.r-project.org/show_bug.cgi?id=13309 ,the example was
> > >
> > >  dchisq(x=Inf, df=10, ncp=1)
> > >
> > > I had fixed the bug 13 years ago, in svn rev 47005
> > > with regression test in /tests/d-p-q-r-tests.R :
> > >
> > >
> > > ## Non-central Chi^2 density for large x
> > > stopifnot(0 == dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1))
> > > ## did hang in 2.8.0 and earlier (PR#13309).
> > >
> > >
> > > and you are seeing your version of R hanging at exactly this
> > > location?
> > >
> > >
> > > I'd bet quite a bit that the underlying code in these
> > > non-central chi square computations *never* calls BLAS and hence
> > > I cannot imagine how openBLAS could play a role.
> > >
> > > However, there must be something peculiar in your compiler setup,
> > > compilation options, 
> > > as of course the above regression test has been run 100s of
> > > 1000s of times also under Windows in the last 13 years ..
> > >
> > > Last but not least (but really only vaguely related):
> > >There is still a FIXME in the source code (but not about
> > > hanging, but rather of loosing some accuracy in border cases),
> > > see e.g. https://svn.r-project.org/R/trunk/src/nmath/dnchisq.c
> > > and for that reason I had written an R version of that C code
> > > even back in 2008 which I've made available in  CRAN package
> > > DPQ  a few years ago (together with many other D/P/Q
> > > distribution computations/approximations).
> > >  -> https://cran.r-project.org/package=DPQ
> > >
> > > Best,
> > > Martin
> > >
> >
> > Hello, Martin.
> >
> > Apologies, I thought the PR # was sufficient. Yes, I am seeing this at
> > this exact location. This is what I saw in d-p-q-r-tst-2.Rout.fail and
> > I then ran d-p-q-r-tst.R line-by-line and R hung precisely after
> > `stopifnot(0 == dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1))`.
> >
> > Is it at all possible that this has to do with the recent change from
> > bd0 to ebd0 (PR #15628) [1]?
> >
> > For completeness, I ran all the code _beneath_ the cal

Re: [Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

On Tue, Nov 16, 2021 at 8:43 AM Martin Maechler
 wrote:
>
> >>>>> Avraham Adler
> >>>>> on Tue, 16 Nov 2021 02:35:56 + writes:
>
> > I am building r-devel on Windows 10 64bit using Jeroen's mingw system,
> > and I am finding that my make check-devel hangs on the above issue.
> > Everything is vanila except that I am using OpenBLAS 0.3.18. I have
> > been using OpenBLAS for over a decade and have not had this issue
> > before. Is there anything I can do to dig deeper into this issue from
> > my end? Could there be anything that changed in R-devel that may have
> > triggered this? The bugzilla report doesn't have any code attached to
> > it.
>
> > Thank you,
> > Avi
>
> Hmm.. it would've be nice to tell a bit more, instead of having all
> your readers to search links, etc.
>
> In the bugzilla bug report PR#13309
> https://bugs.r-project.org/show_bug.cgi?id=13309 ,the example was
>
>  dchisq(x=Inf, df=10, ncp=1)
>
> I had fixed the bug 13 years ago, in svn rev 47005
> with regression test in /tests/d-p-q-r-tests.R :
>
>
> ## Non-central Chi^2 density for large x
> stopifnot(0 == dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1))
> ## did hang in 2.8.0 and earlier (PR#13309).
>
>
> and you are seeing your version of R hanging at exactly this
> location?
>
>
> I'd bet quite a bit that the underlying code in these
> non-central chi square computations *never* calls BLAS and hence
> I cannot imagine how openBLAS could play a role.
>
> However, there must be something peculiar in your compiler setup,
> compilation options, 
> as of course the above regression test has been run 100s of
> 1000s of times also under Windows in the last 13 years ..
>
> Last but not least (but really only vaguely related):
>There is still a FIXME in the source code (but not about
> hanging, but rather of loosing some accuracy in border cases),
> see e.g. https://svn.r-project.org/R/trunk/src/nmath/dnchisq.c
> and for that reason I had written an R version of that C code
> even back in 2008 which I've made available in  CRAN package
> DPQ  a few years ago (together with many other D/P/Q
> distribution computations/approximations).
>  -> https://cran.r-project.org/package=DPQ
>
> Best,
> Martin
>

Hello, Martin.

Apologies, I thought the PR # was sufficient. Yes, I am seeing this at
this exact location. This is what I saw in d-p-q-r-tst-2.Rout.fail and
I then ran d-p-q-r-tst.R line-by-line and R hung precisely after
`stopifnot(0 == dchisq(c(Inf, 1e80, 1e50, 1e40), df=10, ncp=1))`.

Is it at all possible that this has to do with the recent change from
bd0 to ebd0 (PR #15628) [1]?

For completeness, I ran all the code _beneath_ the call, and while
nothing else cause an infinite loop, I posted what I believe may be
unexpected results below,

Thank you,

Avi

[1]: https://bugs.r-project.org/show_bug.cgi?id=15628

> ## FIXME ?!:  MxM/2 seems +- ok ??
> (dLmM <- dnbinom(xL, mu = 1, size = MxM))  # all NaN but the last
Warning in dnbinom(xL, mu = 1, size = MxM) : NaNs produced
 [1] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN   0
> (dLpI <- dnbinom(xL, prob=1/2, size = Inf))#  ditto
Warning in dnbinom(xL, prob = 1/2, size = Inf) : NaNs produced
 [1] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN   0
> (dLpM <- dnbinom(xL, prob=1/2, size = MxM))#  ditto
Warning in dnbinom(xL, prob = 1/2, size = MxM) : NaNs produced
 [1] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN   0

> d <- dnbinom(x,  mu = mu, size = Inf) # gave NaN (for 0 and L), now all 0
Warning in dnbinom(x, mu = mu, size = Inf) : NaNs produced
> p <- pnbinom(x,  mu = mu, size = Inf) # gave all NaN, now uses ppois(x, mu)
Warning in pnbinom(x, mu = mu, size = Inf) : NaNs produced

> pp <- (0:16)/16
> q <- qnbinom(pp, mu = mu, size = Inf) # gave all NaN
> set.seed(1); NI <- rnbinom(32, mu = mu, size = Inf)# gave all NaN
> set.seed(1); N2 <- rnbinom(32, mu = mu, size = L  )
> stopifnot(exprs = {
+ all.equal(d, c(0.006737947, 0.033689735, 0.0842243375,
0.140373896, 0,0,0,0), tol = 9e-9)# 7.6e-10
+ all.equal(p, c(0.006737947, 0.040427682, 0.1246520195,
0.265025915, 1,1,1,1), tol = 9e-9)# 7.3e-10
+ all.equal(d, dpois(x, mu))# current implementation: even identical()
+ all.equal(p, ppois(x, mu))
+ q == c(0, 2, 3, 3, 3, 4, 4, 4, 5, 5, 6, 6, 6, 7, 8, 9, Inf)
+ q == qpois(pp, mu)
+ identical(NI, N2)
+ })
Error: d and c(0.006737947, 0.033689735, 0.0842243375, 0.140373896, 0,
0,   are not equal:
  'is.NA' value mismatch: 0 i

[Rd] R-devel (r81196) hanging at dchisq(large) (PR#13309)

[Avraham Adler]

I am building r-devel on Windows 10 64bit using Jeroen's mingw system,
and I am finding that my make check-devel hangs on the above issue.
Everything is vanila except that I am using OpenBLAS 0.3.18. I have
been using OpenBLAS for over a decade and have not had this issue
before. Is there anything I can do to dig deeper into this issue from
my end? Could there be anything that changed in R-devel that may have
triggered this? The bugzilla report doesn't have any code attached to
it.

Thank you,

Avi

sessionInfo:
R Under development (unstable) (2021-11-15 r81196)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19043)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] 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_4.2.0 tools_4.2.0

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

Re: [Rd] WISH: set.seed(seed) to produce error if length(seed) != 1 (now silent)

[Avraham Adler]

Hi, Henrik.

I’m curious, other than proper programming practice, why?

Avi

On Fri, Sep 17, 2021 at 11:48 AM Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:

> Hi,
>
> according to help("set.seed"), argument 'seed' to set.seed() should be:
>
>   a single value, interpreted as an integer, or NULL (see ‘Details’).
>
> From code inspection (src/main/RNG.c) and testing, it turns out that
> if you pass a 'seed' with length greater than one, it silently uses
> seed[1], e.g.
>
> > set.seed(1); sum(.Random.seed)
> [1] 4070365163
> > set.seed(1:3); sum(.Random.seed)
> [1] 4070365163
> > set.seed(1:100); sum(.Random.seed)
> [1] 4070365163
>
> I'd like to suggest that set.seed() produces an error if length(seed)
> > 1.  As a reference, for length(seed) == 0, we get:
>
> > set.seed(integer(0))
> Error in set.seed(integer(0)) : supplied seed is not a valid integer
>
> /Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] "Connections left open" Error

[Avraham Adler]

On Fri, Aug 27, 2021 at 10:25 AM Uwe Ligges 
wrote:

>
>
> On 23.08.2021 18:07, Alan Aw wrote:
> > Hi,
> >
> > I submitted a package to CRAN, but it keeps failing a particular check
> for
> > Windows. This error shows up when I check my code examples.
> >
> > Error: connections left open:
> >>  <-CRANwin.fb05.statistik.uni-dortmund.de:11602
> >>  (sockconn)
> >>  <-CRANwin.fb05.statistik.uni-dortmund.de:11602
> >>  (sockconn)
> >> Execution halted
> >
> >
> > For context, my code example does the following.
> >
> > suppressWarnings(require(doParallel))
> >> registerDoParallel(cores = 2)
> >>
> >
> >
> > # Some code examples that use foreach and %dopar%
> >
> >
> >
> > stopImplicitCluster()
> >
> >
> > Other contextual information:
> >
> > - I already import doParallel in the DESCRIPTION file.
> > - My package passes all checks on the Linux machine.
> >
> > I have read elsewhere (e.g., this thread
> > ) that examples
> with
> > parallelization lead to this error. However stopImplicitCluster() does
> not
> > seem to fix it.
> >
> > Could someone familiar with this please troubleshoot? Thank you.
>
> No idea about the doParallel package, but perhaps it helps to open a
> cluster explicitly and in the end stop exactly that cluster?
>
> Best,
> Uwe Ligges
> >
> > Alan


As per Dr. Ligges, I’ve had more success closing the named cluster than
using stopImplicit.

Avi

>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] [External] Re: Update on rtools4 and ucrt support

[Avraham Adler]

On Tue, Aug 24, 2021 at 12:47 AM Simon Urbanek 
wrote:

> Avi,
>
> please see the announcement:
>
>
> https://developer.r-project.org/Blog/public/2021/03/12/windows/utf-8-toolchain-and-cran-package-checks/index.html
>
> the documentation is in
>
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/howto.html
>
> Cheers,
> Simon
>
>
>
>
> On Aug 24, 2021, at 8:34 AM, Avraham Adler 
> wrote:
>
> On Mon, Aug 23, 2021 at 11:09 PM  wrote:
>
> On Mon, 23 Aug 2021, Duncan Murdoch wrote:
>
> On 23/08/2021 8:15 a.m., jan Vitek via R-devel wrote:
>
> Hi Jeroen,
>
> I mostly lurk on this list, but I was struck by your combative tone.
>
> To pick on two random bits:
>
> … a 6gb tarball with manually built things on his personal machine…
>
>
> … a black-box system that is so opaque and complex that only one person
> knows how it works, and would make it much more difficult for
> students, universities, and other organisations to build R packages
> and libraries on Windows…
>
>
>
> Tomas’ tool chain isn't a blackbox, it has copious documentation (see
>
> [1])
>
> and builds on any machine thanks to the provided docker container.
>
> This is not to criticise your work which has its unique strengths, but
>
> to
>
> state the obvious: these strengths are best discussed without passion
> based on factually accurate descriptions.
>
>
> I agree with Jan.  I'm not sure a discussion in this forum would be
>
> fruitful,
>
> but I really wish Jeroen and Tomas would get together, aiming to merge
>
> their
>
> toolchains, keeping the best aspects of both.
>
> I haven't been involved in the development of either one, but have been
>
> a
>
> "victim" of the two chain rivalry, because the rgl package is not easy
>
> to
>
> build.  I get instructions from each of them on how to do the build, and
> those instructions for one toolchain generally break the build on the
>
> other
>
> one.  While it is probably possible to detect the toolchain and have the
> build adapt to whichever one is in use, it would be a lot easier for me
>
> (and
>
> I imagine every other maintainer of a package using external libs) if I
>
> just
>
> had to follow one set of instructions.
>
> Duncan Murdoch
>
>
> Here are just a few comments from my perspective (I am an R-core
> member, but am not part of the CRAN team and do only very limited work
> on Windows). Other R-core members may have different perspectives and
> insights.
>
> One bit of background: dealing with encoding issues on Windows has
> been taking an unsustainable amount of R-core resources for some time
> now. Tomas Kalibera has been taking the lead on trying to address
> these issues in the existing framework, but this means he has not had
> the time to make any of the many other valuable and important
> contributions he could make. The only viable way forward is to move to
> a Windows tool chain that supports UTF-8 as the C library current
> encoding via the Windows UCRT framework.
>
> Tomas Kalibera has, on behalf of all of R core and in
> coordination with CRAN, been looking for a way forward for some
> time and has reported on the progress in several blog posts at
> https://developer.r-project.org/Blog/public/. This has lead to
> the development of the MXE-based UCRT tool chain, which is now
> well tested and ready for deployment.  Checks using the UCRT tool
> chain have been part of the CRAN check process for a while. I
> believe CRAN plans to switch R-devel checks and builds to the
> UCRT tool chain during the upcoming CRAN downtime. I expect there
> will be some communication from CRAN on this soon, including on
> any issues in supporting binaries for both R-devel and R-patched.
>
> In putting together something as large as a tool chain there will
> always be many choices, each with advantages and disadvantages.  Some
> things may be advantages in some settings and not others. Taking just
> one case in point: Cross compilation. This is likely to be a better
> approach for CRAN in the future and is supported by the MXE framework
> on which the new tool chain is based.
>
> The much more recent changes in rtools4 to support UCRT are at this
> point not yet as well tested as the new tool chain. Once these changes
> to rtools4 mature, and if binary compatibility can be assured, then
> having a second tool chain may be useful in some cases.  But if there
> are incompatibilities then it will be up to rtools4 to keep up with
> the tool chain used by CRAN. On the other, contributing to improving
> the MXE-based tool chain may be a better investment of time.
>
&

Re: [Rd] [External] Re: Update on rtools4 and ucrt support

[Avraham Adler]

On Mon, Aug 23, 2021 at 11:09 PM  wrote:

> On Mon, 23 Aug 2021, Duncan Murdoch wrote:
>
> > On 23/08/2021 8:15 a.m., jan Vitek via R-devel wrote:
> >> Hi Jeroen,
> >>
> >> I mostly lurk on this list, but I was struck by your combative tone.
> >>
> >> To pick on two random bits:
> >>
> >>> … a 6gb tarball with manually built things on his personal machine…
> >>
> >>> … a black-box system that is so opaque and complex that only one person
> >>> knows how it works, and would make it much more difficult for
> >>> students, universities, and other organisations to build R packages
> >>> and libraries on Windows…
> >>
> >>
> >> Tomas’ tool chain isn't a blackbox, it has copious documentation (see
> [1])
> >> and builds on any machine thanks to the provided docker container.
> >>
> >> This is not to criticise your work which has its unique strengths, but
> to
> >> state the obvious: these strengths are best discussed without passion
> >> based on factually accurate descriptions.
> >
> > I agree with Jan.  I'm not sure a discussion in this forum would be
> fruitful,
> > but I really wish Jeroen and Tomas would get together, aiming to merge
> their
> > toolchains, keeping the best aspects of both.
> >
> > I haven't been involved in the development of either one, but have been
> a
> > "victim" of the two chain rivalry, because the rgl package is not easy
> to
> > build.  I get instructions from each of them on how to do the build, and
> > those instructions for one toolchain generally break the build on the
> other
> > one.  While it is probably possible to detect the toolchain and have the
> > build adapt to whichever one is in use, it would be a lot easier for me
> (and
> > I imagine every other maintainer of a package using external libs) if I
> just
> > had to follow one set of instructions.
> >
> > Duncan Murdoch
>
> Here are just a few comments from my perspective (I am an R-core
> member, but am not part of the CRAN team and do only very limited work
> on Windows). Other R-core members may have different perspectives and
> insights.
>
> One bit of background: dealing with encoding issues on Windows has
> been taking an unsustainable amount of R-core resources for some time
> now. Tomas Kalibera has been taking the lead on trying to address
> these issues in the existing framework, but this means he has not had
> the time to make any of the many other valuable and important
> contributions he could make. The only viable way forward is to move to
> a Windows tool chain that supports UTF-8 as the C library current
> encoding via the Windows UCRT framework.
>
> Tomas Kalibera has, on behalf of all of R core and in
> coordination with CRAN, been looking for a way forward for some
> time and has reported on the progress in several blog posts at
> https://developer.r-project.org/Blog/public/. This has lead to
> the development of the MXE-based UCRT tool chain, which is now
> well tested and ready for deployment.  Checks using the UCRT tool
> chain have been part of the CRAN check process for a while. I
> believe CRAN plans to switch R-devel checks and builds to the
> UCRT tool chain during the upcoming CRAN downtime. I expect there
> will be some communication from CRAN on this soon, including on
> any issues in supporting binaries for both R-devel and R-patched.
>
> In putting together something as large as a tool chain there will
> always be many choices, each with advantages and disadvantages.  Some
> things may be advantages in some settings and not others. Taking just
> one case in point: Cross compilation. This is likely to be a better
> approach for CRAN in the future and is supported by the MXE framework
> on which the new tool chain is based.
>
> The much more recent changes in rtools4 to support UCRT are at this
> point not yet as well tested as the new tool chain. Once these changes
> to rtools4 mature, and if binary compatibility can be assured, then
> having a second tool chain may be useful in some cases.  But if there
> are incompatibilities then it will be up to rtools4 to keep up with
> the tool chain used by CRAN. On the other, contributing to improving
> the MXE-based tool chain may be a better investment of time.
>
> Best,
>
> luke
>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>

Thank you, Dr. Tierney. However, I am concerned about the not-insignificant
number of us who for various reasons can only do our development on
Windows. Rtools has been the official tool chain with which to build
windows for the at least 20 

Re: [Rd] svd for Large Matrix

[Avraham Adler]

If you’re crossproding X by itself, I think passing symmetric = TRUE to
eigen will eke out more speed.

Avi

On Mon, Aug 16, 2021 at 6:30 PM Radford Neal  wrote:

> > Dario Strbenac  writes:
> >
> > I have a real scenario involving 45 million biological cells
> > (samples) and 60 proteins (variables) which leads to a segmentation
> > fault for svd. I thought this might be a good example of why it
> > might benefit from a long vector upgrade.
>
> Rather than the full SVD of a 4500x60 X, my guess is that you
> may really only be interested in the eigenvalues and eigenvectors of
> X^T X, in which case eigen(t(X)%*%X) would probably be much faster.
> (And eigen(crossprod(X)) would be even faster.)
>
> Note that if you instead want the eigenvalues and eigenvectors of
> X X^T (which is an enormous matrix), the eigenvalues of this are the
> same as those of X^T X, and the eigenvectors are Xv, where v is an
> eigenvector of X^T X.
>
> For example, with R 4.0.2, and the reference BLAS/LAPACK, I get
>
>   > X<-matrix(rnorm(10),1,10)
>   > system.time(for(i in 1:1000) rs<-svd(X))
>  user  system elapsed
> 2.393   0.008   2.403
>   > system.time(for(i in 1:1000) re<-eigen(crossprod(X)))
>  user  system elapsed
> 0.609   0.000   0.609
>   > rs$d^2
>[1] 10568.003 10431.864 10318.959 10219.961 10138.025 10068.566
> 9931.538
>[8]  9813.841  9703.818  9598.532
>   > re$values
>[1] 10568.003 10431.864 10318.959 10219.961 10138.025 10068.566
> 9931.538
>[8]  9813.841  9703.818  9598.532
>
> Possibly some other LAPACK might implement svd better, though I
> suspect that R will allocate more big matrices than really necessary
> for the svd even aside from whatever LAPACK is doing.
>
> Regards,
>
>Radford Neal
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Tools beyond roxygen2 to write Rd documentation

[Avraham Adler]

I always write mine by hand. Used to do it in notepad++. Now I just do it
as a text file in the Rstudio IDE.

Avi

On Thu, Aug 5, 2021 at 11:52 AM Martin Maechler 
wrote:

> > Iago Giné-Vázquez
> > on Thu, 05 Aug 2021 08:09:48 + writes:
>
> > Dear all, Are there any tools to edit .Rd files by hand
> > (so avoiding roxygen2), as an editor (like could be
> > *RdStudio*, à la RStudio or TeXstudio) or a plugin for ViM
> > or another editor (like could be *vim-Rd*, à la
> > vim-latex)?
>
> > Thanks for your answers,
>
> > Stay safe, Iago
>
> Yes, of course:
> "All good" R package authors edit *.Rd files by hand
> ((;-), well no, I know it's not true ..
>  I personally use roxygen (in ESS, see below) only sometimes at the very
>  beginning of writing a new function, or for functions that I
>  do *not* export, because there's a nice key stroke to create
>  the outline). ... and if I export that function use the
>  Roxygen -> Rd *once* only, and from then on, I edit the *.Rd nicely
>  including using descriptions lists, some math, etc... all well
>  indented, nicely human-readable etc, much nicer than hidden in
>  roxygen R comments)
>
> Rstudio has supported *.Rd in the past but as I'm not using it
> regularly .. I don't know if they dropped it now... that would
> honestly surprise me, though.
>
> Rather  ESS (Emacs Speaks Statistics) has always well supported
> Rd editing, and I thought the  vim - plugin for R would also
> support *.Rd  but probably not ??
>
> Best,
> Martin
>
> --
> Martin Maechler
> ETH Zurich,  R Core Team  (*and* ESS Core team)
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Feature request: Change default library path on Windows

[Avraham Adler]

On Sun, Jul 25, 2021 at 5:56 PM Duncan Murdoch 
wrote:

> On 25/07/2021 9:54 a.m., Steve Haroz wrote:
> >> Shouldn't it be in one of the AppData directories?
> >
> > I asked that same question on twitter. Here was a response
> > (https://twitter.com/bmwiernik/status/1419033079495147522):
> > * But it's not for files that should be user-accessible, like a
> > library (cf. Zotero has preferences in AppData , but library files in
> > %USERPROFILE%/Zotero)
> > * So, for example, in R's case it could make sense for the core
> > packages to be installed in %APPDATA%/R/R-4.1.0/library" rather than
> > "C:/Program Files/R/R-4.1.0/library" (either is fairly common), but
> > user packages should be somewhere more accessible.
> >
> > Here is a quote from
> >
> https://docs.microsoft.com/en-us/windows/apps/design/app-settings/store-and-retrieve-app-data
> :
> > "App data is mutable data that is created and managed by a specific
> > app. It includes runtime state, app settings, user preferences,
> > reference content (such as the dictionary definitions in a dictionary
> > app), and other settings"
> > I don't think libraries fall into the categories of state or settings.
>
> I saw that link, and like you and Gabe, found it somewhat ambiguous.
>
> I don't know bmwiernik, but from the sound of it, he doesn't speak for
> Microsoft.
>
> So I would say that I still believe Microsoft doesn't give clear
> guidance for this.  Yes, %USERPROFILE%/R has some non-Microsoft
> precedents, but that's irrelevant.  This is an issue to take up with MS,
> not with R.  Let them describe *clearly* what they want, and R will
> (eventually) do it (but probably not before they've changed their clear
> guidance).
>
> Duncan Murdoch
>
> P.S. I am a former member of R Core who did Windows support.  I now
> detest that OS.  I suspect nobody who is still on R Core doesn't detest it.



I remember well and greatly appreciate your work, Dr. Murdoch. As someone
whose R work must be almost exclusively on Windows due to the nature of my
employment, I want to once again show appreciation to the members of R Core
and others, specifically Drs. Liggs and Tierney, and Jeroen Oomes, Dirk
Eddelbuttel, and the many others who continue to support R for Windows.

Avi

> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Avraham Adler]

On the other hand, MIT does not restrict what you do with your own
contributions, just the included code. GPL restricts rights on
redistributing your own work if a component is GPL as well.

Avi

On Thu, Jun 3, 2021 at 6:51 AM Berwin A Turlach
 wrote:
>
> G'day Jeff,
>
> On Wed, 02 Jun 2021 11:34:21 -0700
> Jeff Newmiller  wrote:
>
> Not that I want to get involved in old discussions :), but...
>
> > MIT is more permissive than GPL2,
>
> ... this statement depends on how one defines "permissive".
>
> MIT requires that you fulfil: "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software." (https://opensource.org/licenses/MIT)
>
> Whereas GPL 2 merely requires that you "[...] conspicuously and
> appropriately publish on each copy an appropriate copyright notice and
> disclaimer of warranty [...]".
>
> Thus, arguably, GPL 2 is more permissive.
>
> >  so there is a collision there.
>
> Well, luckily the FSF does not think that the MIT license is
> incompatible with the GPL license, though it finds the term "MIT
> license" misleading and discourages its use, see
> https://www.gnu.org/licenses/license-list.html
>
> Cheers,
>
> Berwin
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Avraham Adler]

Exactly. Is square is just brow=ncol, is positive definite can be
implemented as a check that all eigenvalues > 0, which can be done with
base, and is.symmetric can be simply brute forced in a loop comparing i,j
with j,i.

The fewer dependencies a package has, the more robust it is. It’s a fine
balance between not reinventing the wheel and ceding too much stability to
other packages.

Thanks,

Avi

On Wed, Jun 2, 2021 at 3:15 PM John Harrold 
wrote:

> To add another option. In the past when this has happened to me I've found
> other packages that provide similar functionality.
>
> I'm assuming that is.square just checks the number of columns == number of
> rows? And the others can probably be implemented pretty easily.
>
> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton  wrote:
>
> > My package uses the MIT license, so would that not meet the compatibility
> > requirements?
> >
> > I will attempt to reach out to the package author - thanks for your help!
> >
> > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:
> >
> > > That all sounds exactly right.
> > >GPL >= 2 allows you to use the material without asking permission as
> > > long as your package is compatibly licensed (e.g. also GPL).
> > >Under normal circumstances it would be polite to ask permission, but
> > > if the reason for doing this is that the maintainer is unreachable in
> > > the first place ...
> > >
> > >   If you want to try a little harder, it seems quite possible that you
> > > can reach the matrixcalc maintainer at the (personal) e-mail address
> > > shown in this page:
> > >
> > >
> >
> https://www.facebook.com/photo/?fbid=10208324530363130=ecnf.1000413042
> > >
> > >(Possibly an identity confusion, but I rate that as unlikely based
> on
> > > other facebook snooping)
> > >
> > >I don't think a short, polite e-mail request would be out of bounds,
> > > they can always ignore it or tell you to go away.
> > >
> > >cheers
> > > Ben Bolker
> > >
> > > On 6/2/21 1:15 PM, Ben Staton wrote:
> > > > Hello,
> > > >
> > > > Thank you for your detailed list of solutions.
> > > >
> > > > I was initially tempted to go with option 1 (move matrixcalc to
> > suggests
> > > > and check for its existence before using functions that rely on it),
> > but
> > > as
> > > > mentioned, this is not a long term fix.
> > > >
> > > > I unfortunately can't take on the responsibilities of option 2
> > (becoming
> > > > the package maintainer) -- there is much that this package does that
> I
> > do
> > > > not understand, and do not wish to feign authority!
> > > >
> > > > I plan to take option 3 (copy the needed functions into my package).
> > > There
> > > > are only three functions I need from matrixcalc, and all three are
> > fairly
> > > > simple (is.square.matrix
> > > > ,
> > > > is.symmetric.matrix
> > > > , and
> > > > is.positive.definite
> > > > ) and
> > > there
> > > > is only one function in postpack that needs them. I plan to define
> them
> > > > within the postpack function. matrixcalc is licensed under GPL >= 2
> and
> > > > based on my scan of the license text, this is allowed. Is that
> correct?
> > > >
> > > > Regarding option 4 (contacting the matrixcalc maintainer), the
> original
> > > > email from CRAN mentioned that they have attempted to contact the
> > package
> > > > author with no response.
> > > >
> > > > Thank you!
> > > >
> > > > On Wed, Jun 2, 2021 at 9:52 AM J C Nash 
> wrote:
> > > >
> > > >> I just downloaded the source matrixcalc package to see what it
> > > contained.
> > > >> The functions
> > > >> I looked at seem fairly straightforward and the OP could likely
> > develop
> > > >> equivalent features
> > > >> in his own code, possibly avoiding a function call. Avoiding the
> > > function
> > > >> call means NAMESPACE etc. are not involved, so fewer places for
> > getting
> > > >> into
> > > >> trouble, assuming the inline code works properly.
> > > >>
> > > >> JN
> > > >>
> > > >>
> > > >> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
> > > >>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
> > >  Hello,
> > > 
> > >  I received an email notice from CRAN indicating that my R package
> > >  ('postpack') will be archived soon if I do not take any action
> and I
> > > >> want
> > >  to avoid that outcome. The issue is not caused by my package, but
> > > >> instead a
> > >  package that my package depends on:
> > > 
> > >  "... package 'matrixcalc' is now scheduled for archival on
> > 2021-06-09,
> > >  and archiving this will necessitate also archiving its strong
> > reverse
> > >  dependencies."
> > > 
> > >  Evidently, xyz has been returning errors on new R builds prompting
> > > CRAN
> > > >> to
> > >  list it as a package to be archived. My package, 'postpack' has
> > 

Re: [Rd] problem adding gdb to RTOOLS40 on Windows

[Avraham Adler]

Also, packages should be installed in the MSYS2 environment and not the
MINGW64. Invoke msys2.exe, synchronize with Jeroen’s via the pacman -Syu,
and then try the install. It should work as Jeroen has gdb in the upstream
repository [
https://github.com/r-windows/rtools-packages/tree/master/mingw-w64-gdb]

Thanks,

Avi

On Thu, Apr 15, 2021 at 2:59 AM Voeten, C.C. 
wrote:

> Hi Mark,
>
> Try pacman -Suy first to update pacman's package database. It's quite
> possible that the versions pacman is trying to install are no longer
> available due to being out of date.
>
> HTH,
> Cesko
>
> -Original Message-
> From: R-devel  On Behalf Of Bravington,
> Mark (Data61, Hobart)
> Sent: Thursday, April 15, 2021 6:53 AM
> To: R-Devel-2 
> Subject: [Rd] problem adding gdb to RTOOLS40 on Windows
>
> I've not been able to install gdb for RTOOLS40 on Windows 10. The rtools
> installer (rtools40-x64_86.exe) doesn't seem to include gdb by default, and
> when I follow the instructions for adding gdb (which I tracked down at
> https://github.com/r-windows/docs/blob/master/faq.md) this is what
> happened:
>
> 
> 
> $ pacman -S mingw-w64-x86_64-gdb
> resolving dependencies...
> looking for conflicting packages...
>
> Packages (8) mingw-w64-x86_64-expat-2.2.9-9002
>  mingw-w64-x86_64-gettext-0.19.8.1-9002
>  mingw-w64-x86_64-libsystre-1.0.1-9002
>  mingw-w64-x86_64-libtre-git-r128.6fb7206-9002
>  mingw-w64-x86_64-ncurses-6.1.20180526-9002
>  mingw-w64-x86_64-readline-8.0.001-2
>  mingw-w64-x86_64-termcap-1.3.1-9002
>  mingw-w64-x86_64-gdb-8.3.1-9500
>
> Total Download Size:3.46 MiB
> Total Installed Size:  83.77 MiB
>
> :: Proceed with installation? [Y/n] y
> :: Retrieving packages...
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from cloud.r-project.org
> : The requested URL returned error: 404
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from cran.r-project.org
> : The requested URL returned error: 404
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from dl.bintray.com :
> The requested URL returned error: 404
> warning: failed to retrieve some files
> error: failed to commit transaction (failed to retrieve some files)
> Errors occurred, no packages were upgraded.
>
> Something very similar happens if I try the 32bit version.
>
> Do you have any suggestions?
>
>  - I used to have this stuff working OK with R3.6/RTOOLS35 but have not
> needed to go back to C for a while. The version of gdb in RTOOLS is 7.9.1;
> I tried copying that gdb.exe into RTOOLS40 but it just exited instantly
> when I tried to run it from there.
>
>  - NB I have absolutely no idea what is meant by msys2 or pacman or any of
> that, I'm just following instructions...
>
>
> Thanks
> Mark
>
>
>
>
> Mark Bravington
> CSIRO Marine Lab
> Hobart
> Australia
>
> __
> 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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Faster sorting algorithm...

[Avraham Adler]

Isn’t the default method now “radix” which is the data.table sort, and
isn’t that already parallel using openmp where available?

Avi

On Mon, Mar 15, 2021 at 12:26 PM Morgan Morgan 
wrote:

> Hi,
> I am not sure if this is the right mailing list, so apologies in advance if
> it is not.
>
> I found the following link/presentation:
> https://www.r-project.org/dsc/2016/slides/ParallelSort.pdf
>
> The implementation of fsort is interesting but incomplete (not sure why?)
> and can be improved or made faster (at least 25%  I believe). I might be
> wrong but there are maybe a couple of bugs as well.
>
> My questions are:
>
> 1/ Is the R Core team interested in a faster sorting algo? (Multithread or
> even single threaded)
>
> 2/ I see an issue with the license, which is MPL-2.0, and hence not
> compatible with base R, Python and Julia. Is there an interest to change
> the license of fsort so all 3 languages (and all the people using these
> languages) can benefit from it? (Like suggested on the first page)
>
> Please let me know if there is an interest to address the above points, I
> would be happy to look into it (free of charge of course!).
>
> Thank you
> Best regards
> Morgan
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] From .Fortran to .Call?

[Avraham Adler]

I had some time, so I updated a toy package I have for explaining R
and Fortran use to use both the .Call and the .Fortran interfaces [1].
I think the actual Fortran code is as close to identical as I can
reasonably make it. On my computer, the .Call interface (_f) is around
4 times as fast as the .Fortran interface (_f2).

Bill, I don't know if you can, or should, "just" change .Fortran to
.Call. You certainly cannot do the reverse. I think my source code
made as minimal a change as possible; maybe that would help.

---
set.seed(77)
A <- runif(100, 0, 2000)
microbenchmark(LLC_f(A, 500, 500), LLC_f2(A, 500, 500), times =
1L, control = list(order = 'block'), check = 'equal')
Unit: nanoseconds
expr  min   lq  mean median   uq   max neval cld
  LLC_f(A, 500, 500)  700  702  799.5906801  802  6601 1  a
 LLC_f2(A, 500, 500) 3000 3101 3328.8712   3201 3401 19802 1   b


Thanks,

Avi

[1] https://github.com/aadler/SimpFort


On Sat, Dec 26, 2020 at 10:48 PM Avraham Adler  wrote:
>
> I’ve tried recoding some of Delaporte to use the .Fortran interface and I 
> don’t know what I’m doing wrong but it either doesn’t work or crashes my R 
> instance completely.
>
> Avi
>
> On Sat, Dec 26, 2020 at 11:48 AM Koenker, Roger W  
> wrote:
>>
>> I’ve recoded a version of one of my quantile regression fitting functions to 
>> use .C64 from dotCall64 rather than .Fortran.
>> For a moderately large problem with n = 500,000 and p = 5, and solving for  
>> 1:49/50 quantiles the new version shows
>> a 3% speedup, although for smaller problems it is actually slower that the 
>> .Fortran version.  So, I’m (provisionally)
>> unimpressed by the claims that .Fortran has a big “overhead” performance 
>> penalty.  Compared to the(more than) an order of
>> magnitude (base 10) improvement that moving from R to fortran produces,  3% 
>> isn’t really worth the (admittedly) minimal
>> additional coding effort.
>>
>> > On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan 
>> >  wrote:
>> >
>> > Also, just came to know about dotcall64::.C64() (on CRAN) which allows for 
>> > Fortran to be called using .Call().
>> >
>> > -Naras
>> >
>> > On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
>> >> I think it should be pretty easy to fix up SUtools to use the .Call 
>> >> instead of .Fortran following along the lines of
>> >>
>> >> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>> >> I too deal with a lot of f77 and so I will most likely finish it before 
>> >> the new year, if not earlier. (Would welcome testers besides myself.)
>> >>
>> >> Incidentally, any idea of what the performance hit is, quantitatively? I 
>> >> confess I never paid attention to it myself as most Fortran code I use 
>> >> seems pretty fast, i.e. glmnet.
>> >>
>> >> -Naras
>> >>
>> >>
>> >> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
>> >>> Thanks to all and best wishes for a better 2021.
>> >>>
>> >>> Unfortunately I remain somewhat confused:
>> >>>
>> >>> o  Bill reveals an elegant way to get from my rudimentary 
>> >>> registration setup to
>> >>> one that would explicitly type the C interface functions,
>> >>>
>> >>> o Ivan seems to suggest that there would be no performance gain from 
>> >>> doing this.
>> >>>
>> >>> o  Naras’s pcLasso package does use the explicit C typing, but then 
>> >>> uses .Fortran
>> >>> not .Call.
>> >>>
>> >>> o  Avi uses .Call and cites the Romp package 
>> >>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>> >>>  where it is asserted that "there is a (nearly) deprecated interface 
>> >>> .Fortran() which you
>> >>> should not use due to its large performance overhead.”
>> >>>
>> >>> As the proverbial naive R (ab)user I’m left wondering:
>> >>>
>> >>> o  if I updated my quantreg_init.c file in accordance with Bill’s 
>> >>> suggestion could I
>> >>> then simply change my .Fortran calls to .Call?
>> >>>
>> >>> o  and if so, do I need to include ALL the fortran 

Re: [Rd] From .Fortran to .Call?

[Avraham Adler]

I’ve tried recoding some of Delaporte to use the .Fortran interface and I
don’t know what I’m doing wrong but it either doesn’t work or crashes my R
instance completely.

Avi

On Sat, Dec 26, 2020 at 11:48 AM Koenker, Roger W 
wrote:

> I’ve recoded a version of one of my quantile regression fitting functions
> to use .C64 from dotCall64 rather than .Fortran.
> For a moderately large problem with n = 500,000 and p = 5, and solving
> for  1:49/50 quantiles the new version shows
> a 3% speedup, although for smaller problems it is actually slower that the
> .Fortran version.  So, I’m (provisionally)
> unimpressed by the claims that .Fortran has a big “overhead” performance
> penalty.  Compared to the(more than) an order of
> magnitude (base 10) improvement that moving from R to fortran produces,
> 3% isn’t really worth the (admittedly) minimal
> additional coding effort.
>
> > On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan <
> na...@stanford.edu> wrote:
> >
> > Also, just came to know about dotcall64::.C64() (on CRAN) which allows
> for Fortran to be called using .Call().
> >
> > -Naras
> >
> > On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
> >> I think it should be pretty easy to fix up SUtools to use the .Call
> instead of .Fortran following along the lines of
> >>
> >>
> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
> >> I too deal with a lot of f77 and so I will most likely finish it before
> the new year, if not earlier. (Would welcome testers besides myself.)
> >>
> >> Incidentally, any idea of what the performance hit is, quantitatively?
> I confess I never paid attention to it myself as most Fortran code I use
> seems pretty fast, i.e. glmnet.
> >>
> >> -Naras
> >>
> >>
> >> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
> >>> Thanks to all and best wishes for a better 2021.
> >>>
> >>> Unfortunately I remain somewhat confused:
> >>>
> >>> o  Bill reveals an elegant way to get from my rudimentary
> registration setup to
> >>> one that would explicitly type the C interface functions,
> >>>
> >>> o Ivan seems to suggest that there would be no performance gain
> from doing this.
> >>>
> >>> o  Naras’s pcLasso package does use the explicit C typing, but
> then uses .Fortran
> >>> not .Call.
> >>>
> >>> o  Avi uses .Call and cites the Romp package
> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>where it is asserted that "there is a (nearly) deprecated interface
> .Fortran() which you
> >>> should not use due to its large performance overhead.”
> >>>
> >>> As the proverbial naive R (ab)user I’m left wondering:
> >>>
> >>> o  if I updated my quantreg_init.c file in accordance with Bill’s
> suggestion could I
> >>> then simply change my .Fortran calls to .Call?
> >>>
> >>> o  and if so, do I need to include ALL the fortran subroutines in
> my src directory
> >>> or only the ones called from R?
> >>>
> >>> o  and in either case could I really expect to see a significant
> performance gain?
> >>>
> >>> Finally, perhaps I should stipulate that my fortran is strictly f77,
> so no modern features
> >>> are in play, indeed most of the code is originally written in ratfor,
> Brian Kernighan’s
> >>> dialect from ancient times at Bell Labs.
> >>>
> >>> Again,  thanks to all for any advice,
> >>> Roger
> >>>
> >>>
> >>>> On Dec 23, 2020, at 1:11 AM, Avraham Adler 
> wrote:
> >>>>
> >>>> Hello, Ivan.
> >>>>
> >>>> I used .Call instead of .Fortran in the Delaporte package [1]. What
> >>>> helped me out a lot was Drew Schmidt's Romp examples and descriptions
> >>>> [2]. If you are more comfortable with the older Fortran interface,
> >>>> Tomasz Kalinowski has a package which uses Fortran 2018 more
> >>>> efficiently [3]. I haven't tried this last in practice, however.
> >>>>
> >>>> Hope that helps,
> >>>>
> >>>> Avi
> >>>>
> >>>> [1]
> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Del

Re: [Rd] From .Fortran to .Call?

[Avraham Adler]

Hi.

I haven't tested the speed of the old .Fortran interface, but in this
post [1] I describe how to build a simple interface (there are two
small packages on github that correspond to the code) and in this one
[2] I compare the speed of the different languages, but all using
.Call.

Hope that helps,

Avi

[1] 
https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/
[2] 
https://www.avrahamadler.com/2018/12/23/the-need-for-speed-part-2-c-vs-fortran-vs-c/

On Wed, Dec 23, 2020 at 11:34 AM Balasubramanian Narasimhan
 wrote:
>
> I think it should be pretty easy to fix up SUtools to use the .Call
> instead of .Fortran following along the lines of
>
> https://github.com/wrathematics/Romp
>
> I too deal with a lot of f77 and so I will most likely finish it before
> the new year, if not earlier. (Would welcome testers besides myself.)
>
> Incidentally, any idea of what the performance hit is, quantitatively? I
> confess I never paid attention to it myself as most Fortran code I use
> seems pretty fast, i.e. glmnet.
>
> -Naras
>
>
> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
> > Thanks to all and best wishes for a better 2021.
> >
> > Unfortunately I remain somewhat confused:
> >
> >   o  Bill reveals an elegant way to get from my rudimentary  
> > registration setup to
> >   one that would explicitly type the C interface functions,
> >
> >   o Ivan seems to suggest that there would be no performance gain from 
> > doing this.
> >
> >   o  Naras’s pcLasso package does use the explicit C typing, but then 
> > uses .Fortran
> >   not .Call.
> >
> >   o  Avi uses .Call and cites the Romp package 
> > https://github.com/wrathematics/Romp
> >   where it is asserted that "there is a (nearly) deprecated interface 
> > .Fortran() which you
> >   should not use due to its large performance overhead.”
> >
> > As the proverbial naive R (ab)user I’m left wondering:
> >
> >   o  if I updated my quantreg_init.c file in accordance with Bill’s 
> > suggestion could I
> >   then simply change my .Fortran calls to .Call?
> >
> >   o  and if so, do I need to include ALL the fortran subroutines in my 
> > src directory
> >   or only the ones called from R?
> >
> >   o  and in either case could I really expect to see a significant 
> > performance gain?
> >
> > Finally, perhaps I should stipulate that my fortran is strictly f77, so no 
> > modern features
> > are in play, indeed most of the code is originally written in ratfor, Brian 
> > Kernighan’s
> > dialect from ancient times at Bell Labs.
> >
> > Again,  thanks to all for any advice,
> > Roger
> >
> >
> >> On Dec 23, 2020, at 1:11 AM, Avraham Adler  wrote:
> >>
> >> Hello, Ivan.
> >>
> >> I used .Call instead of .Fortran in the Delaporte package [1]. What
> >> helped me out a lot was Drew Schmidt's Romp examples and descriptions
> >> [2]. If you are more comfortable with the older Fortran interface,
> >> Tomasz Kalinowski has a package which uses Fortran 2018 more
> >> efficiently [3]. I haven't tried this last in practice, however.
> >>
> >> Hope that helps,
> >>
> >> Avi
> >>
> >> [1] 
> >> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
> >> [2] 
> >> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
> >> [3] 
> >> https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
> >>
> >> Tomasz Kalinowski
> >>
> >>
> >>
> >> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
> >>  wrote:
> >>> To deal with such Fortran issues in several packages I deal with, I
> >>> wrote the SUtools package 
> >>> (https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$
> >>>  ) that you
> >>> can try.  The current version generates the registration assuming
> >>> implicit Fortran naming conventions though. (I've been meaning to
> >>> upgrade it to use the gfortran -fc-prototypes-external flag which should
> >>> be easy; I might just finish that during these holidays.)
> 

Re: [Rd] From .Fortran to .Call?

[Avraham Adler]

Hello, Ivan.

I used .Call instead of .Fortran in the Delaporte package [1]. What
helped me out a lot was Drew Schmidt's Romp examples and descriptions
[2]. If you are more comfortable with the older Fortran interface,
Tomasz Kalinowski has a package which uses Fortran 2018 more
efficiently [3]. I haven't tried this last in practice, however.

Hope that helps,

Avi

[1] https://CRAN.R-project.org/package=Delaporte
[2] https://github.com/wrathematics/Romp
[3] https://github.com/t-kalinowski/RFI

Tomasz Kalinowski



On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
 wrote:
>
> To deal with such Fortran issues in several packages I deal with, I
> wrote the SUtools package (https://github.com/bnaras/SUtools) that you
> can try.  The current version generates the registration assuming
> implicit Fortran naming conventions though. (I've been meaning to
> upgrade it to use the gfortran -fc-prototypes-external flag which should
> be easy; I might just finish that during these holidays.)
>
> There's a vignette as well:
> https://bnaras.github.io/SUtools/articles/SUtools.html
>
> -Naras
>
>
> On 12/19/20 9:53 AM, Ivan Krylov wrote:
> > On Sat, 19 Dec 2020 17:04:59 +
> > "Koenker, Roger W"  wrote:
> >
> >> There are comments in various places, including R-extensions §5.4
> >> suggesting that .Fortran is (nearly) deprecated and hinting that use
> >> of .Call is more efficient and now preferred for packages.
> > My understanding of §5.4 and 5.5 is that explicit routine registration
> > is what's important for efficiency, and your package already does that
> > (i.e. calls R_registerRoutines()). The only two things left to add
> > would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
> > R_ARG_OUT/...) of the arguments of each subroutine.
> >
> > Switching to .Call makes sense if you want to change the interface of
> > your native subroutines to accept arbitrary heavily structured SEXPs
> > (and switching to .External could be useful if you wanted to play with
> > evaluation of the arguments).
> >
>
> __
> 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] [External] use of the tcltk package crashes R 4.0.1 for Windows

[Avraham Adler]

Jeroen, how "reactive" are the rtools40 scripts. Will they pull the latest
version committed by Dr. Tierney or is there something which must be done
manually prior to we end-users rebuilding from source?

Thank you,

Avi

On Sun, Jun 7, 2020 at 11:01 PM peter dalgaard  wrote:

> Ah, I see it now:
>
> The remapping of free() to Rm_free() and calloc() to Rm_calloc() happens
> in memory.c, but not in tcltk.c; the macro Calloc in R_ext/RS.h maps to a
> call to R_chk_alloc which is defined in memory.h; RS.h is included in
> tcltk.c, so tcltk.c winds up calling Rm_calloc() via Calloc(), but then the
> NON-remapped free(), and the walls come tumbling down.
>
> If the  "#if defined(Win32)" block had been inside RS.h, the problem
> wouldn't arise.
>
> -pd
>
> > On 8 Jun 2020, at 00:03 , luke-tier...@uiowa.edu wrote:
> >
> > I've committed the change to use Free instead of free in tcltk.c and
> > sys-std.c (r78652 for R-devel, r78653 for R-patched).
> >
> > We might consider either moving Calloc/Free out of the Windows
> > remapping or moving the remapping into header files so everything
> > seeing our header files uses our calloc/free. Either would be less
> > brittle that the current status.
> >
> > Best,
> >
> > luke
> >
> > On Sun, 7 Jun 2020, peter dalgaard wrote:
> >
> >>
> >>
> >>> On 7 Jun 2020, at 18:59 , Jeroen Ooms  wrote:
> >>>
> >>> On Sun, Jun 7, 2020 at 5:53 PM  wrote:
> 
>  On Sun, 7 Jun 2020, peter dalgaard wrote:
> 
> > So this wasn't tested for a month?
> >
> > Anyways, Free() is just free() with a check that we're not freeing a
> null pointer, followed by setting the pointer to NULL. At that point of
> tcltk.c, we have
> >
> > for (objc = i = 0; i < length(avec); i++){
> >  const char *s;
> >  char *tmp;
> >  if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm,
> i{
> >  //  tmp = calloc(strlen(s)+2, sizeof(char));
> >  tmp = Calloc(strlen(s)+2, char);
> >  *tmp = '-';
> >  strcpy(tmp+1, s);
> >  objv[objc++] = Tcl_NewStringObj(tmp, -1);
> >  free(tmp);
> >  }
> >  if (!isNull(t = VECTOR_ELT(avec, i)))
> >  objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
> >  }
> >
> > and I can't see how tmp can be NULL at the free(), nor can I see it
> mattering if it is not set to NULL (notice that it goes out of scope with
> the for loop).
> 
>  Right. And the calloc->Calloc change doesn't look like an issue either
>  -- just checking for a NULL.
> 
>  If the crash is happening in free() then that most likely means
>  corrupted malloc data structures. Unfortunately that could be
>  happening anywhere.
> >>>
> >>> Writing R extensions, section 6.1.2 says: "Do not assume that memory
> >>> allocated by Calloc/Realloc comes from the same pool as used by
> >>> malloc: in particular do not use free or strdup with it."
> >>>
> >>> I think the reason is that R uses dlmalloc for Calloc on Windows:
> >>>
> https://github.com/wch/r-source/blob/c634fec5214e73747b44d7c0e6f047fefe44667d/src/main/memory.c#L94-L103
> >>
> >> But that section #defines calloc and free to Rm_... counterparts in
> lockstep? (I assume that is where dlmalloc comes in?)
> >>
> >> Anyways, does it actually work to change free() to Free()? If so, then
> all this post mortem analysis is rather a moot point.
> >>
> >> -pd
> >>
> >>
> >
> > --
> > Luke Tierney
> > Ralph E. Wareham Professor of Mathematical Sciences
> > University of Iowa  Phone: 319-335-3386
> > Department of Statistics andFax:   319-335-3017
> >   Actuarial Science
> > 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> > Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
> __
> 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: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

I respectfully submit that the mechanism is accurately described as “viral”
albeit the connotations may be uncomfortable. I will refrain from
commenting further in this thread. Happy to continue with you off-list if
you wish.

Thank you,

Aavi

On Tue, Jun 2, 2020 at 8:43 PM Jeff Newmiller 
wrote:

> The obvious answer is simply to refer to GPL. It isn't necessary to
> propagate a derogatory point of view by finding another word for an
> incorrect idea.  Try re-reading my previous words without trying to hold on
> to a flawed interpretation.
>
> On June 2, 2020 5:33:56 PM PDT, Avraham Adler 
> wrote:
> >Apologies; my intent was not to disparage, but that is the term is used
> >in
> >the industry and in venues which discuss FLOSS because it reflects that
> >the
> >addition of one component with that kind of copyleft license causes the
> >entire project to need that particular copyleft license. If there is a
> >term
> >which reflects that mechanism from a discipline other than biology,
> >please let me know.
> >
> >Thanks,
> >
> >Avi
> >
> >On Tue, Jun 2, 2020 at 8:25 PM Jeff Newmiller
> >
> >wrote:
> >
> >> "Viral" is has connotations that reflect the biases of the person
> >using
> >> the term. A less loaded perspective is that some people don't want
> >you to
> >> take their contributions out of circulation by using it as the
> >foundation
> >> of your proprietary work. If you want to close it up, build from
> >scratch or
> >> find some other code that isn't GPL.
> >>
> >> Describing it as "viral" makes it sound as if they were trying to
> >steal
> >> something you did instead of protecting their code from being stolen.
> >> Please refrain from being inflammatory.
> >>
> >> On June 2, 2020 4:49:25 PM PDT, Avraham Adler
> >
> >> wrote:
> >> >IANAL, but the GPL family of licenses is VIRAL copy left so it
> >infects
> >> >anything it touched, which is why many shy away and prefer something
> >> >like
> >> >the Mozilla Public License 2 (MPL) as a compromise between viral
> >> >copyleft
> >> >and the permissive MIT/ISC/BSD2.
> >> >
> >> >Avi
> >> >
> >> >On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
> >> >
> >> >> Spencer,
> >> >>
> >> >> I apologize for my obvious (in hindsight) error in bringing up the
> >> >topic.
> >> >> I will bring up one example, because of your request. Google has
> >> >listed
> >> >> GPL-1, 2, and 3 as one of several licenses that are restricted and
> >> >cannot
> >> >> be used by a Google product delivered to outside customers. This
> >> >include
> >> >> downloadable client software and software such as insdie the
> >Google
> >> >Search
> >> >> Appliance. This includes having scripts that load packages
> >> >dynamically as
> >> >> with “library()” and “require()”. Please see
> >> >> https://opensource.google/docs/thirdparty/licenses/#restricted for
> >> >their
> >> >> wording.
> >> >>
> >> >> I am not defending their position and disagree with it. However,
> >it
> >> >is
> >> >> their position based on what I think is a conservative or overly
> >> >cautious
> >> >> legal interpretation. I am not a lawyer, however, so my opinions
> >are
> >> >of no
> >> >> import.
> >> >>
> >> >> Mark
> >> >> R. Mark Sharp, Ph.D.
> >> >> Data Scientist and Biomedical Statistical Consu
> >>
> ><
> https://www.google.com/maps/search/a+Scientist+and+Biomedical+Statistical+Consu?entry=gmail=g
> >
> >> ltant
> >> >> 7526 Meadow Green St.
> >> >> San Antonio, TX 78251
> >> >> mobile: 210-218-2868
> >> >> rmsh...@me.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> >> >> spencer.gra...@effectivedefense.org> wrote:
> >> >> >
> >> >> >   Can Dr. Sharp kindly provide a credible reference,
> >discussing
> 

Re: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

Apologies; my intent was not to disparage, but that is the term is used in
the industry and in venues which discuss FLOSS because it reflects that the
addition of one component with that kind of copyleft license causes the
entire project to need that particular copyleft license. If there is a term
which reflects that mechanism from a discipline other than biology,
please let me know.

Thanks,

Avi

On Tue, Jun 2, 2020 at 8:25 PM Jeff Newmiller 
wrote:

> "Viral" is has connotations that reflect the biases of the person using
> the term. A less loaded perspective is that some people don't want you to
> take their contributions out of circulation by using it as the foundation
> of your proprietary work. If you want to close it up, build from scratch or
> find some other code that isn't GPL.
>
> Describing it as "viral" makes it sound as if they were trying to steal
> something you did instead of protecting their code from being stolen.
> Please refrain from being inflammatory.
>
> On June 2, 2020 4:49:25 PM PDT, Avraham Adler 
> wrote:
> >IANAL, but the GPL family of licenses is VIRAL copy left so it infects
> >anything it touched, which is why many shy away and prefer something
> >like
> >the Mozilla Public License 2 (MPL) as a compromise between viral
> >copyleft
> >and the permissive MIT/ISC/BSD2.
> >
> >Avi
> >
> >On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
> >
> >> Spencer,
> >>
> >> I apologize for my obvious (in hindsight) error in bringing up the
> >topic.
> >> I will bring up one example, because of your request. Google has
> >listed
> >> GPL-1, 2, and 3 as one of several licenses that are restricted and
> >cannot
> >> be used by a Google product delivered to outside customers. This
> >include
> >> downloadable client software and software such as insdie the Google
> >Search
> >> Appliance. This includes having scripts that load packages
> >dynamically as
> >> with “library()” and “require()”. Please see
> >> https://opensource.google/docs/thirdparty/licenses/#restricted for
> >their
> >> wording.
> >>
> >> I am not defending their position and disagree with it. However, it
> >is
> >> their position based on what I think is a conservative or overly
> >cautious
> >> legal interpretation. I am not a lawyer, however, so my opinions are
> >of no
> >> import.
> >>
> >> Mark
> >> R. Mark Sharp, Ph.D.
> >> Data Scientist and Biomedical Statistical Consu
> <https://www.google.com/maps/search/a+Scientist+and+Biomedical+Statistical+Consu?entry=gmail=g>
> ltant
> >> 7526 Meadow Green St.
> >> San Antonio, TX 78251
> >> mobile: 210-218-2868
> >> rmsh...@me.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> >> spencer.gra...@effectivedefense.org> wrote:
> >> >
> >> >   Can Dr. Sharp kindly provide a credible reference, discussing
> >the
> >> alleged ambiguities in GPL-2 and GPL-3 that convince some companies
> >to
> >> avoid them?
> >> >
> >> >
> >> >   I like Wikimedia Foundation projects like Wikipedia, where
> >almost
> >> anyone can change almost anything, and what stays tends to be written
> >from
> >> a neutral point of view, citing credible sources.  I get several
> >emails a
> >> day notifying me of changes in articles I'm "watching".  FUD,
> >vandalism,
> >> etc., are generally reverted fairly quickly or moved to the "Talk"
> >page
> >> associated with each article, where the world is invited to provide
> >> credible source(s).
> >> >
> >> >
> >> >   Spencer Graves
> >> >
> >> >
> >> > On 2020-06-02 10:12, Dirk Eddelbuettel wrote:
> >> >> On 2 June 2020 at 10:06, R. Mark Sharp wrote:
> >> >> | The GPL-2 and GPL-3 licenses are apparently sufficiently
> >ambiguous in
> >> the legal community that some companies avoid them.
> >> >>
> >> >> Wittgenstein:  'That whereof we cannot speak, thereof we must
> >remain
> >> silent'
> >> >>
> >> >> This is a mailing list of the R project. R is a GNU Project. R is
> >> licensed
> >> >> under the GPL, version two or later. That has not stopped large
&g

Re: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

IANAL, but the GPL family of licenses is VIRAL copy left so it infects
anything it touched, which is why many shy away and prefer something like
the Mozilla Public License 2 (MPL) as a compromise between viral copyleft
and the permissive MIT/ISC/BSD2.

Avi

On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:

> Spencer,
>
> I apologize for my obvious (in hindsight) error in bringing up the topic.
> I will bring up one example, because of your request. Google has listed
> GPL-1, 2, and 3 as one of several licenses that are restricted and cannot
> be used by a Google product delivered to outside customers. This include
> downloadable client software and software such as insdie the Google Search
> Appliance. This includes having scripts that load packages dynamically as
> with “library()” and “require()”. Please see
> https://opensource.google/docs/thirdparty/licenses/#restricted for their
> wording.
>
> I am not defending their position and disagree with it. However, it is
> their position based on what I think is a conservative or overly cautious
> legal interpretation. I am not a lawyer, however, so my opinions are of no
> import.
>
> Mark
> R. Mark Sharp, Ph.D.
> Data Scientist and Biomedical Statistical Consultant
> 7526 Meadow Green St.
> San Antonio, TX 78251
> mobile: 210-218-2868
> rmsh...@me.com
>
>
>
>
>
>
>
>
>
>
>
> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> spencer.gra...@effectivedefense.org> wrote:
> >
> >   Can Dr. Sharp kindly provide a credible reference, discussing the
> alleged ambiguities in GPL-2 and GPL-3 that convince some companies to
> avoid them?
> >
> >
> >   I like Wikimedia Foundation projects like Wikipedia, where almost
> anyone can change almost anything, and what stays tends to be written from
> a neutral point of view, citing credible sources.  I get several emails a
> day notifying me of changes in articles I'm "watching".  FUD, vandalism,
> etc., are generally reverted fairly quickly or moved to the "Talk" page
> associated with each article, where the world is invited to provide
> credible source(s).
> >
> >
> >   Spencer Graves
> >
> >
> > On 2020-06-02 10:12, Dirk Eddelbuettel wrote:
> >> On 2 June 2020 at 10:06, R. Mark Sharp wrote:
> >> | The GPL-2 and GPL-3 licenses are apparently sufficiently ambiguous in
> the legal community that some companies avoid them.
> >>
> >> Wittgenstein:  'That whereof we cannot speak, thereof we must remain
> silent'
> >>
> >> This is a mailing list of the R project. R is a GNU Project. R is
> licensed
> >> under the GPL, version two or later. That has not stopped large
> corporations
> >> from using R, adopting R, or starting or acquiring R related businesses.
> >>
> >> If you have a strong urge to spread FUD about the GPL and R, could you
> have the
> >> modicum of etiquette to not do it on a mailing list of the R Project?
> >>
> >> Dirk
> >>
> >
> > __
> > R-package-devel@r-project.org 
> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel <
> https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

On Tue, Jun 2, 2020 at 5:04 PM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:
> QUESTION:  How much money have people on this list received for what
> they've written?  I've received not one penny for any technical article
> I've written or for software contributed to CRAN.
>
>Spencer

Ditto. What's even more annoying is when people clearly use one's package
in their published work and do not cite it, but that is for a different
thread.

Avi

[[alternative HTML version deleted]]

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

Re: [Rd] Debugging packages with compiled C code on Windows

[Avraham Adler]

Hello, Sue.

1. I work exclusively on Windows have packages with compiled C, C++,
and Fortran (2003+)  and I use RStudio to debug and work with them
using Rtools40, so I guess it's possible. Have I misunderstood and are
you asking about debugging assembler?
2. If you're using Jeroen's scripts, have you tried uncommenting and
adding that to EOPTS in MkRules.local.in? Note that
./src/gnuwin32/fixed/Makefile has a nasty habit of overriding various
optimizations that affect packages.
3. I don't think so
4. The default is that EOPTS is commented out. I talk about it a nit
more at length here [1]. Perhaps that would be of use?

[1] 


Good Luck,

Avi


On Mon, Jun 1, 2020 at 9:36 PM Sue McDonald  wrote:
>
> I have several related questions.
>
> 1.  Is it possible to use a GUI: Rstudio/Eclipse/Visual-studio to debug
> compiled code on Windows? Things that work on Eclipse for Windows do not
> work on Eclipse for Windows.
> 2.  R CMD INSTALL seems to override default attempts to provide
> CFLAGS="-DDEBUG -g3 -O0"
> 3.  Is it necessary to compile R with debug turned on?   One of the FAQs
> mentioned to compile R with make DEBUG=T.
> 4.  Using Rtools 4.0 and Jeroen's scripts for building R works great (many
> thanks). But does not seem to have an impact on optimization, other than
> including -gwarf-2.  It adds -DNDEBUG flag.  Is that sufficient for
> debugging compiled code in a package?  Obviously, I just need to debug
> package code, so does it matter?
>
> I am happy to write-up a FAQ.
>
> Thanks, SM
>
> [[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] edit() doubles backslashes when keep.source=TRUE

[Avraham Adler]

I build windows binaries from source. As of now, the only choice is R-revel
unless I want to monkey around more with Jeroens’s PKGBUILD script (which
is On my to-do list).

It’s pretty straightforward, although I’m seeing a lot of issues with
packages which had explicit calls to LOCALSOFT in configure.win as that
doesn’t exist anymore.

The binaries have passed make check, though. Would it help if I built some
and forwarded it somewhere?

Avi

On Fri, May 15, 2020 at 12:48 PM brodie gaslam via R-devel <
r-devel@r-project.org> wrote:

>
> > On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <
> e...@debian.org> wrote:
> > On 15 May 2020 at 15:41, Martin Maechler wrote:
> > | 
> > |
> > |Why does nobody anymore  help R development by working with
> > |"R-devel", or at least then the alpha, beta and the "RC"
> > |(Release Candidate) versions that we release daily for about one
> > |month before the final release?
> > |
> > |Notably a highly staffed enterprise such as Rstudio (viz the bug
> > |report 17800 above), but also others could really help by
> > |starting to use the "next version" of R on a routine basis ...
> > |
> > | 
> >
> > Seconded. Without testing we can never know. R Core does their part.
> >
> > I provided weekly Debian binaries. One each for the two alphas releases,
> for
> > the beta release, for the release candidate.  It is easy to use these,
> for
> > example in a Docker container.
> >
> > It is also easy to use this on a normal machine as they are standard
> (Debian)
> > packages: install, try some tests, uninstall, revert to previous version
> by
> > installing that.
> >
> > Dirk
>
> This is a very reasonably request, and all useRs who benefit from the
> tireless work of R-core should consider doing it.  I have considered
> it, but compiling R from sources on OS X has been my stumbling block.
> At least last time I tried I got stuck at the  Fortran step. It doesn't
>  help I have very limited experience compiling  software of the complexity
> of R.  Really, I've only done it within the warm welcoming confines of the
>  vagrant image Tomas Kalibera set up for `rchk`.
>
> I also use r-devel on docker, but that isn't very practical for
> day-to-day usage, which is what I think we need.
>
> What would it take to generate pre-release binaries for OS X (and
> Windows)?  I
> imagine if such were available the volume of testers would increase
> dramatically (at least, I haven't seen them if they exist).
> Maybe something the R Consortium would consider funding?
>
> Best,
>
> B.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Rtools and R 4.0.0?

[Avraham Adler]

Absolutely; this is a complicated and frustrating procedure, and we
owe Jeoren and all our gratitude!

Avi

On Tue, Apr 28, 2020 at 3:37 PM Gabriel Becker  wrote:
>
>  Huge thanks to you (Jeroen) and R-core for doing this.
>
> I wasn't involved with this directly but I know it was a pretty seriously
> heavy list so well done all around!
>
> ~G
>
>
>
> On Tue, Apr 28, 2020, 11:04 AM Hervé Pagès  wrote:
>
> > Thanks Jeroen!
> >
> > > On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey  wrote:
> > >>
> > >> Regardless, I would like to thank R core, CRAN, and Jeroen for all of
> > >> the time that has gone into creating and validating this new
> > >> toolchain. This is arduous work at an especially arduous time, so I'd
> > >> like to voice my appreciation for all the time and energy they have
> > >> spent on making this possible.
> >
> > Absolutely. Thanks to R core, CRAN, Jeroen, and all the other people
> > involved in creating the new Windows toolchain.
> >
> > Cheers,
> > H.
> >
> > >>
> > >> Best,
> > >> Kevin
> > >>
> > >> On Tue, Apr 7, 2020 at 7:47 AM Dirk Eddelbuettel 
> > wrote:
> > >>>
> > >>>
> > >>> There appears to have been some progress on this matter:
> > >>>
> > >>> -Note that @command{g++} 4.9.x (as used for @R{} on Windows up to
> > 3.6.x)
> > >>> +Note that @command{g++} 4.9.x (as used on Windows prior to @R{} 4.0.0)
> > >>>
> > >>> See SVN commit r78169 titled 'anticipate change in Windows toolchain',
> > or the
> > >>> mirrored git commit at
> > >>>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wch_r-2Dsource_commit_bd674e2b76b2384169424e3d899fbfb5ac174978=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=oQL_LnqplfOV3qS3_v0vWloGk5Qhr6pWl4Yjzs4Tzzo=
> > >>>
> > >>> Dirk
> > >>>
> > >>> --
> > >>>
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__dirk.eddelbuettel.com=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=nOplDwpoh_urogK65Old_l1Qi-EbVpyC0Mv4LgeLl64=
> > | @eddelbuettel | e...@debian.org
> > >>>
> > >>> __
> > >>> R-devel@r-project.org mailing list
> > >>>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
> > >>
> > >> __
> > >> R-devel@r-project.org mailing list
> > >>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=zMjaTujju0afmK5eIVPZrNajypj8QjuNbSyoAv93ISk=vUQZdkVyqq3iT9HukcKqEjg80sI-OZoKuy9DKiufquw=
> > >
> >
> > --
> > 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
> >
> > __
> > 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

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

Re: [Rd] [External] Re: rpois(9, 1e10)

[Avraham Adler]

Fantastic!!

Thanks,

Avi

On Wed, Jan 22, 2020 at 11:14 AM Spencer Graves 
wrote:

>
>
> On 2020-01-22 02:54, Martin Maechler wrote:
> >> Martin Maechler
> >>  on Tue, 21 Jan 2020 09:25:19 +0100 writes:
> >> Ben Bolker
> >>  on Mon, 20 Jan 2020 12:54:52 -0500 writes:
> >  >> Ugh, sounds like competing priorities.
> >
> >  > indeed.
> >
> >  >> * maintain type consistency
> >  >> * minimize storage (= current version, since 3.0.0)
> >  >> * maximize utility for large lambda (= proposed change)
> >  >> * keep user interface, and code, simple (e.g., it would be easy
> enough
> >  >> to add a switch that provided user control of int vs double
> return value)
> >  >> * backward compatibility
> >
> >  > Last night, it came to my mind that we should do what we have
> >  > been doing in quite a few places in R, the last couple of years:
> >
> >  > Return integer when possible, and switch to return double when
> >  > integers don't fit.
> >
> >  > We've been doing so even for  1:N  (well, now with additional
> ALTREP wrapper),
> >  > seq(), and even the fundamental  length()  function.
> >
> >  > So I sat down and implemented it .. and it seemed to work
> >  > perfectly:  Returning the same random numbers as now, but
> >  > switching to use double (instead of returning NAs) when the
> >  > values are too large.
> >
> >  > I'll probably commit that to R-devel quite soonish.
> >  > Martin
> >
> > Committed in svn rev 77690; this is really very advantageous, as
> > in some cases / applications or even just limit cases, you'd
> > easily get into overflow sitations.
> >
> > The new R 4.0.0 behavior is IMO  "the best of" being memory
> > efficient (integer storage) in most cases (back compatible to R 3.x.x)
> and
> > returning desired random numbers in large cases (compatible to R <=
> 2.x.x).
> >
> > Martin
>
>
> Wunderbar!  Sehr gut gemacht!  ("Wonderful!  Very well done!") Thanks,
> Spencer
> >
> >  >> On 2020-01-20 12:33 p.m., Martin Maechler wrote:
> >   Benjamin Tyner
> >   on Mon, 20 Jan 2020 08:10:49 -0500 writes:
> >  >>>
> >  >>> > On 1/20/20 4:26 AM, Martin Maechler wrote:
> >  >>> >> Coming late here -- after enjoying a proper weekend ;-) --
> >  >>> >> I have been agreeing (with Spencer, IIUC) on this for a long
> >  >>> >> time (~ 3 yrs, or more?), namely that I've come to see it as
> a
> >  >>> >> "design bug" that  rpois() {and similar} must return return
> typeof() "integer".
> >  >>> >>
> >  >>> >> More strongly, I'm actually pretty convinced they should
> return
> >  >>> >> (integer-valued) double instead of NA_integer_   and for that
> >  >>> >> reason should always return double:
> >  >>> >> Even if we have (hopefully) a native 64bit integer in R,
> >  >>> >> 2^64 is still teeny tiny compared .Machine$double.max
> >  >>> >>
> >  >>> >> (and then maybe we'd have .Machine$longdouble.max  which
> would
> >  >>> >> be considerably larger than double.max unless on Windows,
> where
> >  >>> >> the wise men at Microsoft decided to keep their workload
> simple
> >  >>> >> by defining "long double := double" - as 'long double'
> >  >>> >> unfortunately is not well defined by C standards)
> >  >>> >>
> >  >>> >> Martin
> >  >>> >>
> >  >>> > Martin if you are in favor, then certainly no objection from
> me! ;-)
> >  >>>
> >  >>> > So now what about other discrete distributions e.g. could a
> similar
> >  >>> > enhancement apply here?
> >  >>>
> >  >>>
> >  >>> >> rgeom(10L, 1e-10)
> >  >>> >  [1] NA 1503061294 NA NA
> 1122447583 NA
> >  >>> >  [7] NA NA NA NA
> >  >>> > Warning message:
> >  >>> > In rgeom(10L, 1e-10) : NAs produced
> >  >>>
> >  >>> yes, of course there are several such distributions.
> >  >>>
> >  >>> It's really something that should be discussed (possibly not
> >  >>> here, .. but then I've started it here ...).
> >  >>>
> >  >>> The  NEWS  for R 3.0.0 contain (in NEW FEATURES) :
> >  >>>
> >  >>> * Functions rbinom(), rgeom(), rhyper(), rpois(), rnbinom(),
> >  >>> rsignrank() and rwilcox() now return integer (not double)
> >  >>> vectors.  This halves the storage requirements for large
> >  >>> simulations.
> >  >>>
> >  >>> and what I've been suggesting is to revert this change
> >  >>> (svn rev r60225-6) which was purposefully and diligently done by
> >  >>> a fellow R core member, so indeed must be debatable.
> >  >>>
> >  >>> Martin
> >  >>>
> >  >>> __
> >  >>> R-devel@r-project.org mailing list
> >  >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >  >>>
> >
> >  >> __
> >  

Re: [Rd] rpois(9, 1e10)

[Avraham Adler]

Floor (maybe round) of non-negative numerics, though. Poisson should never
have anything after decimal.

Still think it’s worth allowing long long for R64 bit, just for purity
sake.

Avi

On Sun, Jan 19, 2020 at 4:38 PM Spencer Graves 
wrote:

>
>
> On 2020-01-19 13:01, Avraham Adler wrote:
>
> Crazy thought, but being that a sum of Poissons is Poisson in the sum, can
> you break your “big” simulation into the sum of a few smaller ones? Or is
> the order of magnitude difference just too great?
>
>
>
>   I don't perceive that as feasible.  Once I found what was generating
> NAs, it was easy to code a function to return pseudo-random numbers using
> the standard normal approximation to the Poisson for those extreme cases.
> [For a Poisson with mean = 1e6, for example, the skewness (third
> standardized moment) is 0.001.  At least for my purposes, that should be
> adequate.][1]
>
>
>   What are the negative consequences of having rpois return numerics
> that are always nonnegative?
>
>
>   Spencer
>
>
> [1]  In the code I reported before, I just changed the threshold of 1e6 to
> 0.5*.Machine$integer.max.  On my Mac, .Machine$integer.max = 2147483647 =
> 2^31 > 1e9.  That still means that a Poisson distributed pseudo-random
> number just under that would have to be over 23000 standard deviations
> above the mean to exceed .Machine$integer.max.
>
>
> On Sun, Jan 19, 2020 at 1:58 PM Spencer Graves <
> spencer.gra...@prodsyse.com> wrote:
>
>>   This issue arose for me in simulations to estimate confidence,
>> prediction, and tolerance intervals from glm(., family=poisson) fits
>> embedded in a BMA::bic.glm fit using a simulate.bic.glm function I added to
>> the development version of Ecfun, available at
>> "https://github.com/sbgraves237/Ecfun;
>> <https://github.com/sbgraves237/Ecfun>.  This is part of a vignette I'm
>> developing, available at
>> "https://github.com/sbgraves237/Ecfun/blob/master/vignettes/time2nextNuclearWeaponState.Rmd;
>> <https://github.com/sbgraves237/Ecfun/blob/master/vignettes/time2nextNuclearWeaponState.Rmd>.
>> This includes a simulated mean of a mixture of Poissons that exceeds 2e22.
>> It doesn't seem unreasonable to me to have rpois output a numerics rather
>> than integers when a number simulated exceeds .Machine$integer.max.  And it
>> does seem to make less sense in such cases to return NAs.
>>
>>
>>Alternatively, might it make sense to add another argument to
>> rpois to give the user the choice?  E.g., an argument "bigOutput" with (I
>> hope) default = "numeric" and "NA" as a second option.  Or NA is the
>> default, so no code that relied that feature of the current code would be
>> broken by the change.  If someone wanted to use arbitrary precision
>> arithmetic, they could write their own version of this function with
>> "arbitraryPrecision" as an optional value for the "bigOutput" argument.
>>
>>
>>   Comments?
>>   Thanks,
>>   Spencer Graves
>>
>>
>>
>> On 2020-01-19 10:28, Avraham Adler wrote:
>>
>> Technically, lambda can always be numeric. It is the observations which
>> must be integral.
>>
>> Would hitting everything larger than maxint or maxlonglong with floor or
>> round fundamentally change the distribution? Well, yes, but enough that it
>> would matter over process risk?
>>
>> Avi
>>
>> On Sun, Jan 19, 2020 at 11:20 AM Benjamin Tyner  wrote:
>>
>>> So imagine rpois is changed, such that the storage mode of its return
>>> value is sometimes integer and sometimes numeric. Then imagine the case
>>> where lambda is itself a realization of a random variable. Do we really
>>> want the storage mode to inherit that randomness?
>>>
>>>
>>> On 1/19/20 10:47 AM, Avraham Adler wrote:
>>> > Maybe there should be code for 64 bit R to use long long or the like?
>>> >
>>> > On Sun, Jan 19, 2020 at 10:45 AM Spencer Graves
>>> > mailto:spencer.gra...@prodsyse.com>>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On 2020-01-19 09:34, Benjamin Tyner wrote:
>>> > >>
>>> >
>>>  
>>> > >> Hello, All:
>>> > >>
>>> > >>
>>> > >> Consider:
>>> > >>
>>> > >>
>>> > >> Browse[2

Re: [Rd] rpois(9, 1e10)

[Avraham Adler]

Crazy thought, but being that a sum of Poissons is Poisson in the sum, can
you break your “big” simulation into the sum of a few smaller ones? Or is
the order of magnitude difference just too great?

On Sun, Jan 19, 2020 at 1:58 PM Spencer Graves 
wrote:

>   This issue arose for me in simulations to estimate confidence,
> prediction, and tolerance intervals from glm(., family=poisson) fits
> embedded in a BMA::bic.glm fit using a simulate.bic.glm function I added to
> the development version of Ecfun, available at
> "https://github.com/sbgraves237/Ecfun;
> <https://github.com/sbgraves237/Ecfun>.  This is part of a vignette I'm
> developing, available at
> "https://github.com/sbgraves237/Ecfun/blob/master/vignettes/time2nextNuclearWeaponState.Rmd;
> <https://github.com/sbgraves237/Ecfun/blob/master/vignettes/time2nextNuclearWeaponState.Rmd>.
> This includes a simulated mean of a mixture of Poissons that exceeds 2e22.
> It doesn't seem unreasonable to me to have rpois output a numerics rather
> than integers when a number simulated exceeds .Machine$integer.max.  And it
> does seem to make less sense in such cases to return NAs.
>
>
>Alternatively, might it make sense to add another argument to rpois
> to give the user the choice?  E.g., an argument "bigOutput" with (I hope)
> default = "numeric" and "NA" as a second option.  Or NA is the default, so
> no code that relied that feature of the current code would be broken by the
> change.  If someone wanted to use arbitrary precision arithmetic, they
> could write their own version of this function with "arbitraryPrecision" as
> an optional value for the "bigOutput" argument.
>
>
>   Comments?
>   Thanks,
>   Spencer Graves
>
>
>
> On 2020-01-19 10:28, Avraham Adler wrote:
>
> Technically, lambda can always be numeric. It is the observations which
> must be integral.
>
> Would hitting everything larger than maxint or maxlonglong with floor or
> round fundamentally change the distribution? Well, yes, but enough that it
> would matter over process risk?
>
> Avi
>
> On Sun, Jan 19, 2020 at 11:20 AM Benjamin Tyner  wrote:
>
>> So imagine rpois is changed, such that the storage mode of its return
>> value is sometimes integer and sometimes numeric. Then imagine the case
>> where lambda is itself a realization of a random variable. Do we really
>> want the storage mode to inherit that randomness?
>>
>>
>> On 1/19/20 10:47 AM, Avraham Adler wrote:
>> > Maybe there should be code for 64 bit R to use long long or the like?
>> >
>> > On Sun, Jan 19, 2020 at 10:45 AM Spencer Graves
>> > mailto:spencer.gra...@prodsyse.com>>
>> wrote:
>> >
>> >
>> >
>> > On 2020-01-19 09:34, Benjamin Tyner wrote:
>> > >>
>> >
>>  
>> > >> Hello, All:
>> > >>
>> > >>
>> > >> Consider:
>> > >>
>> > >>
>> > >> Browse[2]> set.seed(1)
>> > >> Browse[2]> rpois(9, 1e10)
>> > >> NAs produced[1] NA NA NA NA NA NA NA NA NA
>> > >>
>> > >>
>> > >> Should this happen?
>> > >>
>> > >>
>> > >> I think that for, say, lambda>1e6, rpois should return
>> > rnorm(.,
>> > >> lambda, sqrt(lambda)).
>> > > But need to implement carefully; rpois should always return a
>> > > non-negative integer, whereas rnorm always returns numeric...
>> > >
>> >
>> >Thanks for the reply.
>> >
>> >
>> >However, I think it's not acceptable to get an NA from a
>> > number
>> > that cannot be expressed as an integer.  Whenever a randomly
>> > generated
>> > number would exceed .Machine$integer.max, the choice is between
>> > returning NA or a non-integer numeric.  Consider:
>> >
>> >
>> >  > 2*.Machine$integer.max
>> > [1] 4294967294
>> >  > as.integer(2*.Machine$integer.max)
>> > [1] NA
>> > Warning message:
>> > NAs introduced by coercion to integer range
>> >
>> >
>> >I'd rather have the non-integer numeric.
>> >
>> >
>> >Spencer
>> >
>> > __
>> > R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>> > --
>> > Sent from Gmail Mobile
>>
> --
> Sent from Gmail Mobile
>
>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] rpois(9, 1e10)

[Avraham Adler]

Technically, lambda can always be numeric. It is the observations which
must be integral.

Would hitting everything larger than maxint or maxlonglong with floor or
round fundamentally change the distribution? Well, yes, but enough that it
would matter over process risk?

Avi

On Sun, Jan 19, 2020 at 11:20 AM Benjamin Tyner  wrote:

> So imagine rpois is changed, such that the storage mode of its return
> value is sometimes integer and sometimes numeric. Then imagine the case
> where lambda is itself a realization of a random variable. Do we really
> want the storage mode to inherit that randomness?
>
>
> On 1/19/20 10:47 AM, Avraham Adler wrote:
> > Maybe there should be code for 64 bit R to use long long or the like?
> >
> > On Sun, Jan 19, 2020 at 10:45 AM Spencer Graves
> > mailto:spencer.gra...@prodsyse.com>>
> wrote:
> >
> >
> >
> > On 2020-01-19 09:34, Benjamin Tyner wrote:
> > >>
> >
>  
> > >> Hello, All:
> > >>
> > >>
> > >> Consider:
> > >>
> > >>
> > >> Browse[2]> set.seed(1)
> > >> Browse[2]> rpois(9, 1e10)
> > >> NAs produced[1] NA NA NA NA NA NA NA NA NA
> > >>
> > >>
> > >> Should this happen?
> > >>
> > >>
> > >> I think that for, say, lambda>1e6, rpois should return
> > rnorm(.,
> > >> lambda, sqrt(lambda)).
> > > But need to implement carefully; rpois should always return a
> > > non-negative integer, whereas rnorm always returns numeric...
> > >
> >
> >Thanks for the reply.
> >
> >
> >However, I think it's not acceptable to get an NA from a
> > number
> > that cannot be expressed as an integer.  Whenever a randomly
> > generated
> > number would exceed .Machine$integer.max, the choice is between
> > returning NA or a non-integer numeric.  Consider:
> >
> >
> >  > 2*.Machine$integer.max
> > [1] 4294967294
> >  > as.integer(2*.Machine$integer.max)
> > [1] NA
> > Warning message:
> > NAs introduced by coercion to integer range
> >
> >
> >I'd rather have the non-integer numeric.
> >
> >
> >Spencer
> >
> > __
> > R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > --
> > Sent from Gmail Mobile
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] rpois(9, 1e10)

[Avraham Adler]

Maybe there should be code for 64 bit R to use long long or the like?

On Sun, Jan 19, 2020 at 10:45 AM Spencer Graves 
wrote:

>
>
> On 2020-01-19 09:34, Benjamin Tyner wrote:
> >> 
> >> Hello, All:
> >>
> >>
> >> Consider:
> >>
> >>
> >> Browse[2]> set.seed(1)
> >> Browse[2]> rpois(9, 1e10)
> >> NAs produced[1] NA NA NA NA NA NA NA NA NA
> >>
> >>
> >> Should this happen?
> >>
> >>
> >> I think that for, say, lambda>1e6, rpois should return rnorm(.,
> >> lambda, sqrt(lambda)).
> > But need to implement carefully; rpois should always return a
> > non-negative integer, whereas rnorm always returns numeric...
> >
>
>Thanks for the reply.
>
>
>However, I think it's not acceptable to get an NA from a number
> that cannot be expressed as an integer.  Whenever a randomly generated
> number would exceed .Machine$integer.max, the choice is between
> returning NA or a non-integer numeric.  Consider:
>
>
>  > 2*.Machine$integer.max
> [1] 4294967294
>  > as.integer(2*.Machine$integer.max)
> [1] NA
> Warning message:
> NAs introduced by coercion to integer range
>
>
>I'd rather have the non-integer numeric.
>
>
>Spencer
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] For reproducibility issue

[Avraham Adler]

If I understand what you're doing, your Fortran seed knows nothing
about the R state. Is it possible to switch to using the R random
number generators? Or can you at least use the probability integral
transform to generate uniform [0, 1] via R and then convert those to
observations in Fortran (that's what I did)?

Avi

‪On Fri, Jan 17, 2020 at 7:10 PM ‫وليد خلف معوض المطيرى‬‎
 wrote:‬
>
> Hi all,
>
>
>
> I think what I’ve done is something different. Inside the Fortran subroutine, 
> I have a subroutine for setting the seed value of the RNG of GNU Fortran 
> which I think it is not related to the R RNG like the one below:
>
>
>
> subroutine initrandomseedsinr(temp)
>
> implicit none
>
> integer :: n
>
> integer, intent(in):: temp
>
> integer, dimension(:), allocatable :: seed
>
>
>
> call random_seed(size = n)
>
> allocate(seed(n))
>
> seed = temp
>
> call random_seed(PUT = seed)
>
> deallocate(seed)
>
>
>
> end subroutine initrandomseedsinr
>
> , where temp is an argument of the Fortran subroutine as well as in the 
> wrapper R function. This will be related to the RNG method used in the GNU 
> Fortran that build on GCC not to the R. I am not sure if I am right on this, 
> but tried with using RNGkind(sample.kind = "Rounding") and it doesn’t help. 
> The difference in the results were not major. The output at the end of 
> running the functions kept having very similar results, but still have the 
> issue of reproducing exact results which I need it for relating work that is 
> based on the package.
>
>
>
> Many thanks,
>
>
>
> Waleed
>
>
>
>
>
>
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Avraham Adler
> Sent: ‏Friday,‏ ‏January ‏17,‏ ‏2020 ‏06:30 ‏م
> To: Ivan Krylov
> Cc: وليد خلف معوض المطيرى; R Package Development
> Subject: Re: [R-pkg-devel] For reproducibility issue
>
>
>
> Hi.
>
> If it helps, I call the R RNG from Fortran in my Delaporte package
> [1], also using iso_c_bindings. Specifically, I have the following C
> code [2]:
>
> void F77_SUB(unifrnd) (int *n, double *x){
> GetRNGstate();
> for (int i = 0; i < *n; ++i){
> *(x + i) = unif_rand();
> }
> PutRNGstate();
> }
> and call it in Fortran like so [3]:
>
> subroutine rdelap_f(n, a, na, b, nb, l, nl, vars) bind(C, name="rdelap_f_")
>
> external unifrnd
>
> integer(kind = c_int), intent(in), value :: n, na, nb, nl
> real(kind = c_double), intent(out), dimension(n) :: vars
> real(kind = c_double), intent(in) :: a(na), b(nb), l(nl)
> real(kind = c_double), dimension(n) :: p
> integer(kind = c_int) :: lg, lt
>
> call unifrnd(n, p)
> lt = 1_c_int
> lg = 0_c_int
> call qdelap_f(p, n, a, na, b, nb, l, nl, lt, lg, vars)
>
> end subroutine rdelap_f
>
> The package passes CRAN tests (at least as of now) on anything between
> GCC 4 and GCC9 [4].
>
> Hope that helps,
>
> Avi
>
> [1] https://bitbucket.org/aadler/delaporte/src/master/
> [2] https://bitbucket.org/aadler/delaporte/src/master/src/utils_and_wrappers.c
> [3] https://bitbucket.org/aadler/delaporte/src/master/src/delaporte.f95
> [4] https://cran.r-project.org/web/checks/check_results_Delaporte.html
>
>
> On Fri, Jan 17, 2020 at 2:39 PM Ivan Krylov  wrote:
> >
> > On Fri, 17 Jan 2020 13:55:39 +
> > وليد خلف معوض المطيرى  wrote:
> >
> > > So, does anyone have an idea of how to solve this issue.
> >
> > "Writing R Extensions", 1.6. Writing portable packages:
> >
> > >> Compiled code should not call the system random number generators
> > >> such as rand, drand48 and random, but rather use the interfaces to
> > >> R’s RNGs described in Random numbers. In particular, if more than
> > >> one package initializes the system RNG (e.g. via srand), they will
> > >> interfere with each other.
> >
> > >> Nor should the C++11 random number library be used, nor any other
> > >> third-party random number generators such as those in GSL.
> >
> > It somewhat less convenient to call the R random number generator from
> > Fortran than it would be from C or C++, but still possible. There is a
> > F77-style example of such use [1], but since you are already using
> > iso_c_binding, you should be able to declare the C API [2] right in the
> > Fortran source:
> >
> > subroutine GetRNGState() bind(c)
> > end subroutine
> >
> > subroutine PutRNGstate() bind(c)
> > end subroutine
> >
> > As a bonus, you get to use the R distribution functions [3], without
&

Re: [R-pkg-devel] For reproducibility issue

[Avraham Adler]

Hi.

If it helps, I call the R RNG from Fortran in my Delaporte package
[1], also using iso_c_bindings. Specifically, I have the following C
code [2]:

void F77_SUB(unifrnd) (int *n, double *x){
GetRNGstate();
for (int i = 0; i < *n; ++i){
*(x + i) = unif_rand();
}
PutRNGstate();
}
and call it in Fortran like so [3]:

subroutine rdelap_f(n, a, na, b, nb, l, nl, vars) bind(C, name="rdelap_f_")

external unifrnd

integer(kind = c_int), intent(in), value :: n, na, nb, nl
real(kind = c_double), intent(out), dimension(n) :: vars
real(kind = c_double), intent(in) :: a(na), b(nb), l(nl)
real(kind = c_double), dimension(n) :: p
integer(kind = c_int) :: lg, lt

call unifrnd(n, p)
lt = 1_c_int
lg = 0_c_int
call qdelap_f(p, n, a, na, b, nb, l, nl, lt, lg, vars)

end subroutine rdelap_f

The package passes CRAN tests (at least as of now) on anything between
GCC 4 and GCC9 [4].

Hope that helps,

Avi

[1] https://bitbucket.org/aadler/delaporte/src/master/
[2] https://bitbucket.org/aadler/delaporte/src/master/src/utils_and_wrappers.c
[3] https://bitbucket.org/aadler/delaporte/src/master/src/delaporte.f95
[4] https://cran.r-project.org/web/checks/check_results_Delaporte.html


On Fri, Jan 17, 2020 at 2:39 PM Ivan Krylov  wrote:
>
> On Fri, 17 Jan 2020 13:55:39 +
> وليد خلف معوض المطيرى  wrote:
>
> > So, does anyone have an idea of how to solve this issue.
>
> "Writing R Extensions", 1.6. Writing portable packages:
>
> >> Compiled code should not call the system random number generators
> >> such as rand, drand48 and random, but rather use the interfaces to
> >> R’s RNGs described in Random numbers. In particular, if more than
> >> one package initializes the system RNG (e.g. via srand), they will
> >> interfere with each other.
>
> >> Nor should the C++11 random number library be used, nor any other
> >> third-party random number generators such as those in GSL.
>
> It somewhat less convenient to call the R random number generator from
> Fortran than it would be from C or C++, but still possible. There is a
> F77-style example of such use [1], but since you are already using
> iso_c_binding, you should be able to declare the C API [2] right in the
> Fortran source:
>
> subroutine GetRNGState() bind(c)
> end subroutine
>
> subroutine PutRNGstate() bind(c)
> end subroutine
>
> As a bonus, you get to use the R distribution functions [3], without
> the need to implement them yourself from uniformly distributed samples:
>
> function rnorm(mu, sigma) bind(c) result(ret)
>  use intrinsic, iso_c_binding, only: c_double
>  real(c_double), value :: mu, sigma
>  real(c_double) ret
> end function
>
> function rgamma(shape, scale) bind(c) result(ret)
>  use intrinsic, iso_c_binding, only: c_double
>  real(c_double), value :: shape, scale
>  real(c_double) ret
> end function
>
> (The prototypes above are unchecked; I haven't written any Fortran 2003
> in more than a year.)
>
> --
> Best regards,
> Ivan
>
> [1]:
> https://cran.r-project.org/doc/manuals/R-exts.html#index-Random-numbers-in-Fortran
>
> [2]: https://cran.r-project.org/doc/manuals/R-exts.html#Random-numbers
>
> [3]:
> https://cran.r-project.org/doc/manuals/R-exts.html#Distribution-functions
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

[Avraham Adler]

Those of us stuck on Windows but who attempt to develop properly are
wounded to the quick, sir!

:)

Avi

On Mon, Jan 13, 2020 at 12:24 PM Martin Maechler 
wrote:

> > Ben Bolker
> > on Mon, 13 Jan 2020 11:49:09 -0500 writes:
>
> > From R NEWS (changes in 3.6.0)
> > Experimentally, setting environment variable
> _R_CHECK_LENGTH_1_LOGIC2_
> > will lead to warnings (or errors if the variable is set to a ‘true’
> > value) when && or || encounter and use arguments of length more than
> one.
>
> Indeed,  thank you, Ben.
>
> Note (Dirk) this is not just something
>   "by Henrik (..) as he tried to convince us all to use it more"
>
> I've activated this (and the other
>   _R_CHECK_LENGTH_1_CONDITION_ ! )
> for years (maybe not many years, it just feels like it), and *EVERY TIME*
> it triggers, it's been revealing a programmeR's thinko / bug / ..,
> something where the code was clearly suboptimal and should've been
> improved.
> (Unfortunately, the bug has often been in packages, and sometimes I had to
>  disable the setting when I wanted that "buggy" package to work ..)
>
> Occasionally being puristic, let me state this:
>__
>   /--\
>   |  |
>   | Every careful R programmer should use (something like "true",|
>   | "verbose", or even package=... ) |
>   |  |
>   | export _R_CHECK_LENGTH_1_CONDITION_=true |
>   | export _R_CHECK_LENGTH_1_LOGIC2_=verbose |
>   |  |
>   | in her/his ~/.profile equivalent (*) |
>   \__/
>
>
> *) well assuming a careful R programmer would never develop on
>Windows anyway (where you need different means to set such
>environment variables).
>
>
>
> > On 2020-01-13 11:46 a.m., Therneau, Terry M., Ph.D. via R-devel
> wrote:
> >> Thanks for the feedback Dirk.   I sent my follow-up before I saw it.
> >>
> >> Looking at the source code, it appears that there is no options()
> call
> >> to turn this on. Nor does "R --help" reveal a command line option.
> >> How then does a user turn this on outside of the R CMD check
> >> envirionment, so as to chase things like this down?
> >>
> >> The fact that 1. renaming my function makes the error go away, 2. my
> >> function is just a wrapper to inherits(), and 3. its a new error in
> code
> >> that hasn't changed, all point me towards some oddity with the check
> >> function.
> >>
> >> Terry
> >>
> >>
> >> On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:
> >>>
> >>> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel
> wrote:
> >>> | Where can I find out (and replicate) what options as-cran turns
> on?
> >>>
> >>> See the file src/library/tools/R/check.R in the R sources, and
> grep for
> >>> as_cran which is the internal variable controlled by the --as-cran
> option
> >>>
> >>> [...]
> >>>
> >>> | The check log contains multiple instances of the lines below:
> >>> |
> >>> | < Warning message:
> >>> | < In if (ismat(kmat)) { :
> >>> | <   the condition has length > 1 and only the first element will
> be
> >>> used
> >>> |
> >>> | I don't see how the error could arise, but if I know what
> as-cran is
> >>> doing perhaps I can
> >>> | replicate it.
> >>>
> >>> This was widely discussed on this list and should also be in the
> NEWS
> >>> file.
> >>>
> >>> The change is about what the message says: the if () tests a scalar
> >>> logical,
> >>> it appears that ismat(kmat) returns more than a scalar.
> >>>
> >>> There has always been an opt-in for this to error -- cf many
> messages
> >>> by Henrik
> >>> over the years as he tried to convince us all to use it more.
> >>>
> >>>
> >>> Dirk
> >>>
> >>
> >> __
> >> 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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] R 3.6.2 is released

[Avraham Adler]

Thank you.

I apologize for not providing the link. [1] Under the news for R-revel
there is a single entry for R 3.6.2-patched.

The file I downloaded was [2] with a date of 2019-12-12 01:50.

Is it safe to say that 3.6.2 has the LAPACK upgrades and fixes?

Apologies in advance if iOS links the URL below. I cannot access gmail
desktop from behind my corporate firewall.

Thank you again,

Avi

[1]
https://cran.r-project.org/doc/manuals/r-devel/NEWS.html
[2]
https://stat.ethz.ch/R/daily/R-patched.tar.gz

On Thu, Dec 12, 2019 at 11:10 AM Peter Dalgaard  wrote:

> It is not obvious what it is that you are calling "R-patched", nor where
> there could be an entry for "3.6.2 patched".
>
> The prerelease/patched versions are snapshots of R-3-6-branch made at
> 00:20 so the current one will have been made before the release version run
> started at 09:00 this morning, and hence the nightly tarball will be of the
> release candidate. However it will not be called R-patched:
>
> lrwxr-xr-x  1 pd  staff29 Dec 12 00:20 R-latest.tar.gz ->
> R-rc_2019-12-06_r77555.tar.gz
>
> The current version in SVN differs only by the VERSION file. Its NEWS.Rd
> starts
>
> Peters-MacBook-Air:R pd$ more VERSION
> 3.6.2 Patched
> Peters-MacBook-Air:R pd$ more doc/NEWS.Rd
> % -*- coding: utf-8 -*-
> \newcommand{\Rlogo}{\if{html}{\figure{../../html/Rlogo.svg}{options:
> class="toplogo" alt="[R logo]"}}\if{latex}{\figure{Rlogo.pdf}{options:
> width=0.5in}}}
>
> \name{NEWS}
> \title{R News}
> \encoding{UTF-8}
>
> \section{\Rlogo CHANGES IN R 3.6.2}{
>
>   \subsection{NEW FEATURES}{
> \itemize{
>   ....
>
> and any changes for 3.6.2 patched should go above the entries for 3.6.2.
>
> - pd
>
>
> > On 12 Dec 2019, at 16:34 , Avraham Adler 
> wrote:
> >
> > Hi.
> >
> > Under R-news there is an entry for 3.6.2 patched regarding LAPACK.
> However, when uncompresding the current R-patched, it creates R-Rc
> directories. Is this a naming oversight or is the patched version actually
> the unadjusted release candidate?
> >
> > Thank you,
> >
> > Avi
> >
> > On Thu, Dec 12, 2019 at 4:58 AM Peter Dalgaard via R-devel <
> r-devel@r-project.org> wrote:
> > The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy
> Night") this morning.
> >
> > The list below details the changes in this release.
> >
> > You can get the source code from
> >
> > http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz
> >
> > or wait for it to be mirrored at a CRAN site nearer to you.
> >
> > Binaries for various platforms will appear in due course.
> >
> >
> > For the R Core Team,
> >
> > Peter Dalgaard
> >
> > These are the checksums (md5 and SHA-256) for the freshly created files,
> in case you wish
> > to check that they are uncorrupted:
> >
> > MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
> > MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
> > MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
> > MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052
> > MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
> > MD5 (NEWS) = 45437b38c75e0248b527c00e6d42ee6a
> > MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
> > MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
> > MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9
> > MD5 (R-latest.tar.gz) = 90d23d138cee26d275da14b58296e521
> > MD5 (README) = f468f281c919665e276a1b691decbbe6
> > MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
> > MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
> > MD5 (VERSION-INFO.dcf) = 9c33701e25092aefc1d16beb5858f20f
> > MD5 (R-3/R-3.6.2.tar.gz) = 90d23d138cee26d275da14b58296e521
> >
> >
> > 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09  AUTHORS
> > e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4  COPYING
> > 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3
> COPYING.LIB
> > 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d  FAQ
> > f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31  INSTALL
> > 0ceb6fbab3e0e29bc374683fd5c2ccd0c9c62ce8eca2a394a4603775b3ef129c  NEWS
> > 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62  NEWS.0
> > 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01  NEWS.1
> > ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc  NEWS.2
> > bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954
> R-latest.tar.gz
> > 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc  REA

Re: [Rd] R 3.6.2 is released

[Avraham Adler]

Hi.

Under R-news there is an entry for 3.6.2 patched regarding LAPACK. However,
when uncompresding the current R-patched, it creates R-Rc directories. Is
this a naming oversight or is the patched version actually the unadjusted
release candidate?

Thank you,

Avi

On Thu, Dec 12, 2019 at 4:58 AM Peter Dalgaard via R-devel <
r-devel@r-project.org> wrote:

> The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy
> Night") this morning.
>
> The list below details the changes in this release.
>
> You can get the source code from
>
> http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz
>
> or wait for it to be mirrored at a CRAN site nearer to you.
>
> Binaries for various platforms will appear in due course.
>
>
> For the R Core Team,
>
> Peter Dalgaard
>
> These are the checksums (md5 and SHA-256) for the freshly created files,
> in case you wish
> to check that they are uncorrupted:
>
> MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
> MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
> MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
> MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052
> MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
> MD5 (NEWS) = 45437b38c75e0248b527c00e6d42ee6a
> MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
> MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
> MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9
> MD5 (R-latest.tar.gz) = 90d23d138cee26d275da14b58296e521
> MD5 (README) = f468f281c919665e276a1b691decbbe6
> MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
> MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
> MD5 (VERSION-INFO.dcf) = 9c33701e25092aefc1d16beb5858f20f
> MD5 (R-3/R-3.6.2.tar.gz) = 90d23d138cee26d275da14b58296e521
>
>
> 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09  AUTHORS
> e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4  COPYING
> 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3
> COPYING.LIB
> 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d  FAQ
> f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31  INSTALL
> 0ceb6fbab3e0e29bc374683fd5c2ccd0c9c62ce8eca2a394a4603775b3ef129c  NEWS
> 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62  NEWS.0
> 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01  NEWS.1
> ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc  NEWS.2
> bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954
> R-latest.tar.gz
> 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc  README
> 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9  RESOURCES
> 2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a  THANKS
> 40cc7cea5f0e67cf8f2f7b25a534ae6bc53f38eae2ab2c2649a952ed37f0654a
> VERSION-INFO.dcf
> bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954
> R-3/R-3.6.2.tar.gz
>
> This is the relevant part of the NEWS file
>
> CHANGES IN R 3.6.2:
>
>   NEW FEATURES:
>
> * runmed(x, *) gains a new option na.action determining _how_ to
>   handle NaN or NA in x.
>
> * dotchart() gains new options ann, xaxt, frame.plot and log.
>
>   INSTALLATION on a UNIX-ALIKE:
>
> * Detection of the C stack direction has been moved from run-time
>   to configure: this is safer with LTO builds and allows the
>   detection to be overridden - see file config.site.
>
> * Source-code changes enable installation on platforms using gcc
>   -fno-common (the expected default for gcc 10.x).
>
>   C-LEVEL FACILITIES:
>
> * installTrChar (which is nowadays is wrapped by installChar) is
>   defined in Rinternals.h.  (Neither are part of the API.)
>
>   PACKAGE INSTALLATION:
>
> * Header Rconfig.h contains the value of FC_LEN_T deduced at
>   installation which is used by the prototypes in headers
>   R_ext/BLAS.h and R_ext/Lapack.h but to avoid extensive breakage
>   this is only exposed when USE_FC_LEN_T is defined.
>
>   If a package's C/C++ calls to BLAS/LAPACK allow for the 'hidden'
>   arguments used by most Fortran compilers to pass the lengths of
>   Fortran character arguments, define USE_FC_LEN_T and include
>   Rconfig.h (possibly _via_ R.h) before including R_ext/BLAS.h or
>   R_ext/Lapack.h.
>
> * A package with Fortran source code and perhaps C (but not C++)
>   sources can request for its shared object/DLL to be linked by the
>   Fortran compiler by including a line USE_FC_TO_LINK= in
>   src/Makevars[.win] and using $(SHLIB_OPENMP_FFLAGS) as part of
>   PKG_LIBS.
>
>   The known reason for doing so is a package which uses Fortran
>   (only) OpenMP on a platform where the Fortran OpenMP runtime is
>   incompatible with the C one (e.g. gfortran 9.x with clang).
>
>   UTILITIES:
>
> * R CMD check has a new option to mitigate checks leaving
>   files/directories in /tmp.  See the 'R Internals' manual - this
>   is part of --as-cran.
>
>   Windows:
>
> * The 

Re: [Rd] switch to reference counting in R-devel

[Avraham Adler]

Agreed. Now is as good a time as any to send many,  many thanks are due to
Luke, Martin, Uwe, Duncan, the redoubtable  Professor B. and the entire
R-Core team for their seemingly countless hours of toil keeping R not only
afloat but healthy and vibrant. Your work is deeply appreciated, even if it
isn’t expressed often enough.

Thank you again!

Avi

On Tue, Dec 3, 2019 at 1:11 PM Henrik Bengtsson 
wrote:

> This is very exciting news.  Luke, thank you for all your work on this
> - I know it's been a long journey.
>
> All the best,
>
> Henrik
>
> On Tue, Dec 3, 2019 at 8:04 AM Tierney, Luke 
> wrote:
> >
> > R-devel has been switched to use reference counting by default with
> > r77508. Building with -DSWITCH_TO_NAMED goes back to the NAMED
> > mechanism.
> >
> > Best,
> >
> > luke
> >
> > On Sun, 24 Nov 2019, luke-tier...@uiowa.edu wrote:
> >
> > > Baring any unforeseen issues R-devel will switch in about a week from
> > > the NAMED mechanism to reference counting for determining when objects
> > > can be safely mutated in base C code. This is expected to have minimal
> > > impact on packages not using unsupported coding practices in their C
> > > code.
> > >
> > >
> > > The transition to reference counting has been in progress for a
> > > number of years. Some older notes on this are available at
> > > http://developer.r-project.org/Refcnt.html.  These may no longer be
> > > completely accurate but should give you an idea of what is going on.
> > >
> > > If you want to test your package under reference counting you can do
> > > so by building R with -DSWITCH_TO_REFCNT added to CFLAGS or DEFS in a
> > > config.site file.
> > >
> > > A small number of packages are still using the NAMED or SET_NAMED
> > > functions even though this has been discouraged for some  time.
> > > For now these will not produce errors but also not do anything useful.
> > > They will probably be removed before R 4.0.0 is released, so you
> > > should look at why you are using them and adjust accordingly.
> > >
> > > Best,
> > >
> > > luke
> > >
> > >
> > >
> >
> > --
> > Luke Tierney
> > Ralph E. Wareham Professor of Mathematical Sciences
> > University of Iowa  Phone: 319-335-3386
> > Department of Statistics andFax:   319-335-3017
> > Actuarial Science
> > 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> > Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
> >
> > __
> > 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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Using FORTRAN libraries and compiler options

[Avraham Adler]

If I’m not mistaken, dgemm is a BLAS call. That should be accessible from
Fortran via an external call. I think the mvtnorm package calls BLAS/LAPACK
from Fortran if that helps.

Avi

On Mon, Nov 11, 2019 at 6:40 AM Rampal S. Etienne 
wrote:

> Hello,
>
> I am using FORTRAN code with the deSolve package. However, the code
> still runs slowly. Googling tells me that there are two options to speed
> up my code:
>
> 1. Compile with option -O3
>
> 2. Use the library dgemm.
>
> I understand that this can be set in makevars. However, as I have
> limited experience with FORTRAN (never loaded libraries or set compiling
> options), I was wondering whether anyone can give me a hint on how to
> set this. I have just a single FORTRAN file (with multiple subroutines).
>
> Cheers, Rampal
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] improving the performance of install.packages

[Avraham Adler]

Exactly. Every major commit isn’t want to check that the package works.

Also, besides package development, there are other reasons why one would
install packages over themselves. For example, rebuilding from source after
changing options in Makevars[.win]. The package hasn’t been updated but
recompilation is desired.

Avi

On Fri, Nov 8, 2019 at 3:07 PM William Dunlap via R-devel <
r-devel@r-project.org> wrote:

> While developing a package, I often run install.packages() on it many times
> in a session without updating its version number.  How would your proposed
> change affect this workflow?
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Nov 8, 2019 at 11:56 AM Joshua Bradley 
> wrote:
>
> > I could do this...and I have before. This brings up a more fundamental
> > question though. You're asking me to write code that changes the logic of
> > the installation process (i.e. writing my own package installer). Instead
> > of doing that, I would rather integrate that logic into R itself to
> improve
> > the baseline installation process. This api proposal change would be
> > additive and would not break legacy code.
> >
> > Package managers like pip (python), conda (python), yum (CentOS), apt
> > (Ubuntu), and apk (Alpine) are all "smart" enough to know (by their
> > defaults) when to not download a package again. By proposing this change,
> > I'm essentially asking that R follow some of the same conventions and
> best
> > practices that other package managers have adopted over the decades.
> >
> > I assumed this list is used to discuss proposals like this to the R
> > codebase. If I'm on the wrong list, please let me know.
> >
> > P.S. if this change happened, it would be interesting to study the effect
> > it has on the bandwidth across all CRAN mirrors. A significant drop would
> > turn into actual $$ saved
> >
> > Josh Bradley
> >
> >
> > On Fri, Nov 8, 2019 at 5:00 AM Duncan Murdoch 
> > wrote:
> >
> > > On 08/11/2019 2:06 a.m., Joshua Bradley wrote:
> > > > Hello,
> > > >
> > > > Currently if you install a package twice:
> > > >
> > > > install.packages("testit")
> > > > install.packages("testit")
> > > >
> > > > R will build the package from source (depending on what OS you're
> > using)
> > > > twice by default. This becomes especially burdensome when people are
> > > using
> > > > big packages (i.e. lots of depends) and someone has a script with:
> > > >
> > > > install.packages("tidyverse")
> > > > ...
> > > > ... later on down the script
> > > > ...
> > > > install.packages("dplyr")
> > > >
> > > > In this case, "dplyr" is part of the tidyverse and will install
> twice.
> > As
> > > > the primary "package manager" for R, it should not install a package
> > > twice
> > > > (by default) when it can be so easily checked. Indeed, many people
> > resort
> > > > to writing a few lines of code to filter out already-installed
> packages
> > > An
> > > > r-help post from 2010 proposed a solution to improving the default
> > > > behavior, by adding "force=FALSE" as a api addition to
> > install.packages.(
> > > > https://stat.ethz.ch/pipermail/r-help/2010-May/239492.html)
> > > >
> > > > Would the R-core devs still consider this proposal?
> > >
> > > Whether or not they'd do it, it's easy for you to do it.
> > >
> > > install.packages <- function(pkgs, ..., force = FALSE) {
> > >if (!force) {
> > >  pkgs <- Filter(Negate(requireNamespace), pkgs
> > >
> > >utils::install.packages(pkgs, ...)
> > > }
> > >
> > > You might want to make this more elaborate, e.g. doing
> update.packages()
> > > on the ones that exist.  But really, isn't the problem with the script
> > > you're using, which could have done a simple test before forcing a slow
> > > install?
> > >
> > > Duncan Murdoch
> > >
> >
> > [[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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] New matrix function

[Avraham Adler]

Perhaps. But aren’t you looking to implementation a function which finds a
submatrix? If I’m confused, please accept my apologies.

Avi

On Fri, Oct 11, 2019 at 10:43 AM Morgan Morgan 
wrote:

> I think you are confusing package and function here. Plus some of the R
> Core packages, that you mention, contain functions that should probably be
> replaced by functions with better implementation from packages on CRAN.
>
> Best regards
> Morgan
>
> On Fri, 11 Oct 2019 15:22 Joris Meys,  wrote:
>
> >
> >
> > On Fri, Oct 11, 2019 at 3:55 PM Morgan Morgan  >
> > wrote:
> >
> >> How do you prove usefulness of a feature?
> >> Do you have an example of a feature that has been added after proving to
> >> be
> >> useful in the package space first?
> >>
> >> Thank you,
> >> Morgan
> >>
> >
> > The parallel package (a base package like utils, stats, ...) was added as
> > a drop-in replacement of the packages snow and multicore for parallel
> > computing. That's one example, but sure there's more.
> >
> > Kind regards
> > Joris
> >
> > --
> > Joris Meys
> > Statistical consultant
> >
> > Department of Data Analysis and Mathematical Modelling
> > Ghent University
> > Coupure Links 653, B-9000 Gent (Belgium)
> >
> > <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
> >
> > ---
> > Biowiskundedagen 2018-2019
> > http://www.biowiskundedagen.ugent.be/
> >
> > ---
> > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] New matrix function

[Avraham Adler]

It’s rather difficult. For example, the base R Kendall tau is written with
the naive O(n^2). The much faster O(n log n) implementation was programmed
and is in the pcaPP package. When I say much faster, I mean that my
implementation in Excel VBA was faster than R for 10,000 or so pairs.
R-Core decided not to implement that code, and instead made a note about
the faster implementation living in pcaPP in the help for “cor”. See [1]
for the 2012 discussion. My point is it’s really really difficult to get
something in Base R. Develop it well, put it in a package, and you have
basically the same result.

Avi

[1] https://stat.ethz.ch/pipermail/r-devel/2012-June/064351.html

On Fri, Oct 11, 2019 at 9:55 AM Morgan Morgan 
wrote:

> How do you prove usefulness of a feature?
> Do you have an example of a feature that has been added after proving to be
> useful in the package space first?
>
> Thank you,
> Morgan
>
> On Fri, 11 Oct 2019 13:53 Michael Lawrence, 
> wrote:
>
> > Thanks for this interesting suggestion, Morgan. While there is no strict
> > criteria for base R inclusion, one criterion relevant in this case is
> that
> > the usefulness of a feature be proven in the package space first.
> >
> > Michael
> >
> >
> > On Fri, Oct 11, 2019 at 5:19 AM Morgan Morgan  >
> > wrote:
> >
> >> On Fri, 11 Oct 2019 10:45 Duncan Murdoch, 
> >> wrote:
> >>
> >> > On 11/10/2019 6:44 a.m., Morgan Morgan wrote:
> >> > > Hi All,
> >> > >
> >> > > I was looking for a function to find a small matrix inside a larger
> >> > matrix
> >> > > in R similar to the one described in the following link:
> >> > >
> >> > >
> >> >
> >>
> https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix
> >> > >
> >> > > I couldn't find anything.
> >> > >
> >> > > The above function can be seen as a "generalisation" of the "which"
> >> > > function as well as the function described in the following post:
> >> > >
> >> > >
> >> >
> >>
> https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/
> >> > >
> >> > > Would be possible to add such a function to base R?
> >> > >
> >> > > I am happy to work with someone from the R core team (if you wish)
> and
> >> > > suggest an implementation in C.
> >> >
> >> > That seems like it would sometimes be a useful function, and maybe
> >> > someone will point out a package that already contains it.  But if
> not,
> >> > why would it belong in base R?
> >> >
> >>
> >> If someone already implemented it, that would great indeed. I think it
> is
> >> a
> >> very general and basic function, hence base R could be a good place for
> >> it?
> >>
> >> But this is probably not a good reason; maybe someone from the R core
> team
> >> can shed some light on how they decide whether or not to include a
> >> function
> >> in base R?
> >>
> >>
> >> > Duncan Murdoch
> >> >
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
> > --
> > Michael Lawrence
> > Scientist, Bioinformatics and Computational Biology
> > Genentech, A Member of the Roche Group
> > Office +1 (650) 225-7760
> > micha...@gene.com
> >
> > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Avraham Adler]

I think better stated that it is subset that relied on a “bug” that was
never trapped for until now. We’re it written “properly” this never would
have arisen. At least to the best of my understanding.

Avi

On Wed, Sep 11, 2019 at 4:34 PM Göran Broström 
wrote:

>
>
> On 2019-09-11 22:16, Avraham Adler wrote:
> > Can you write a small C function that calls LAPACK call that fro your
> > Fortran code? Yes, an extra step but maybe less traumatic than rewriting
> > parts of LAPACK directly.
>
> Yes, I know how to do that, but I find it somewhat bizarre that it is
> impossible to call a Fortran subroutine from Fortran. And rewriting
> 'dgemv' was simple: Just change character to integer and 'N' to 1. And
> rename the subroutine. The hard (tedious) part was to include all the
> LAPACK authors in my DESCRIPTION file.
>
> My guess is that the root cause is that BLAS/LAPACK is written in
> FORTRAN 77, which is said to be a subset of the current Fortran version
> but obviously isn't.
>
> Thanks, Göran
>
> >
> > Avi
> >
> > On Wed, Sep 11, 2019 at 4:08 PM Göran Broström  > <mailto:goran.brost...@umu.se>> wrote:
> >
> > Berend,
> >
> > I do not think this works with gfortran 7+. I am calling the BLAS
> > subroutine dgemv from Fortran code in my package eha, and the check
> > (with R-devel) gives:
> >
> > gmlfun.f:223:1: warning: type of ‘dgemv’ does not match original
> > declaration [-Wlto-type-mismatch]
> > & score, ione)
> >^
> > /home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type
> > mismatch in parameter 12
> >F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
> >
> > Type of a Fortran subroutine is matched against type of a C
> function?!
> > My conclusion is that it is impossible to call a BLAS subroutine
> with a
> > character parameter from Fortran code (nowadays). Calling from C
> > code is
> > fine, on the other hand(!).
> >
> > I have recently asked about this on R-pkg-devel, but not received any
> > useful answers, and my submission to CRAN is rejected. I solve it by
> > making a personal copy of dgemv and changing the character parameter
> to
> > integer, and adding Jack Dongarra, Jeremy Du Croz, Sven Hammarling,
> and
> > Richard Hanson as authors of eha. And a Copyright note, all in the
> > DESCRIPTION file. Ugly but what can I do (except rewriting the
> Fortran
> > code in C with f2c)?
> >
> > Göran
> >
> > On 2019-09-11 21:38, Berend Hasselman wrote:
> >  >
> >  > The Lapack library is loaded automatically by R itself when it
> > needs it  for doing some calculation.
> >  > You can force it to do that with a (dummy) solve for example.
> >  > Put this at start of your script:
> >  >
> >  > 
> >  > # dummy code to get LAPACK library loaded
> >  > X1 <- diag(2,2)
> >  > x1 <- rep(2,2)
> >  > # X1;x1
> >  > z <- solve(X1,x1)
> >  > 
> >  >
> >  > followed by the rest of your script.
> >  > You will get a warning (I do) that  "passing a character vector
> > to .Fortran is not portable".
> >  > On other systems this may gave fatal errors. This is quick and
> > very dirty. Don't do it.
> >  >
> >  > I believe there is a better and much safer way to achieve what
> > you want.
> >  > Here goes.
> >  >
> >  > Create a folder (directory) src in the directory where your
> > script resides.
> >  > Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes
> > an integer instead of character
> >  >
> >  > 
> >  > c intermediate for dpbtrf
> >  >
> >  >SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )
> >  >
> >  > c  .. Scalar Arguments ..
> >  >integer kUPLO
> >  >INTEGER INFO, KD, LDAB, N
> >  >
> >  > c  .. Array Arguments ..
> >  >DOUBLE PRECISION   AB( LDAB, * )
> >  >
> >  >character UPLO
> >  > c convert integer argument to character
> >  >if(kUPLO .eq. 1 ) then
> >  >UPLO = 'L'
> >  >else
> >  >UPLO = 'U'
> >  >   

Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Avraham Adler]

Can you write a small C function that calls LAPACK call that fro your
Fortran code? Yes, an extra step but maybe less traumatic than rewriting
parts of LAPACK directly.

Avi

On Wed, Sep 11, 2019 at 4:08 PM Göran Broström 
wrote:

> Berend,
>
> I do not think this works with gfortran 7+. I am calling the BLAS
> subroutine dgemv from Fortran code in my package eha, and the check
> (with R-devel) gives:
>
> gmlfun.f:223:1: warning: type of ‘dgemv’ does not match original
> declaration [-Wlto-type-mismatch]
>& score, ione)
>   ^
> /home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type
> mismatch in parameter 12
>   F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
>
> Type of a Fortran subroutine is matched against type of a C function?!
> My conclusion is that it is impossible to call a BLAS subroutine with a
> character parameter from Fortran code (nowadays). Calling from C code is
> fine, on the other hand(!).
>
> I have recently asked about this on R-pkg-devel, but not received any
> useful answers, and my submission to CRAN is rejected. I solve it by
> making a personal copy of dgemv and changing the character parameter to
> integer, and adding Jack Dongarra, Jeremy Du Croz, Sven Hammarling, and
> Richard Hanson as authors of eha. And a Copyright note, all in the
> DESCRIPTION file. Ugly but what can I do (except rewriting the Fortran
> code in C with f2c)?
>
> Göran
>
> On 2019-09-11 21:38, Berend Hasselman wrote:
> >
> > The Lapack library is loaded automatically by R itself when it needs it
> for doing some calculation.
> > You can force it to do that with a (dummy) solve for example.
> > Put this at start of your script:
> >
> > 
> > # dummy code to get LAPACK library loaded
> > X1 <- diag(2,2)
> > x1 <- rep(2,2)
> > # X1;x1
> > z <- solve(X1,x1)
> > 
> >
> > followed by the rest of your script.
> > You will get a warning (I do) that  "passing a character vector  to
> .Fortran is not portable".
> > On other systems this may gave fatal errors. This is quick and very
> dirty. Don't do it.
> >
> > I believe there is a better and much safer way to achieve what you want.
> > Here goes.
> >
> > Create a folder (directory) src in the directory where your script
> resides.
> > Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes an
> integer instead of character
> >
> > 
> > c intermediate for dpbtrf
> >
> >SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )
> >
> > c  .. Scalar Arguments ..
> >integer kUPLO
> >INTEGER INFO, KD, LDAB, N
> >
> > c  .. Array Arguments ..
> >DOUBLE PRECISION   AB( LDAB, * )
> >
> >character UPLO
> > c convert integer argument to character
> >if(kUPLO .eq. 1 ) then
> >UPLO = 'L'
> >else
> >UPLO = 'U'
> >endif
> >
> >call dpbtrf(UPLO,N,KD,AB,LDAB,INFO)
> >return
> >end
> > 
> >
> >
> > Instead of a character argument UPLO it takes an integer argument kUPLO.
> > The meaning should be obvious from the code.
> >
> > Now create a shell script in the folder of your script to generate a
> dynamic library to be loaded in your script:
> >
> > 
> > # Build a binary dynamic library for accessing Lapack dpbtrf
> >
> > # syntax checking
> >
> > SONAME=xdpbtrf.so
> >
> > echo Strict syntax checking
> > echo --
> > gfortran -c -fsyntax-only -fimplicit-none -Wall src/*.f || exit 1
> >
> > LAPACK=$(R CMD config LAPACK_LIBS)
> > R CMD SHLIB --output=${SONAME} src/*.f ${LAPACK} || exit 1
> > 
> >
> > To load the dynamic library xdpbtrf.so  change your script into this
> >
> > 
> > dyn.load("xdpbtrf.so")
> > n <- 4L
> > phi <- 0.64
> > AB <- matrix(0, 2, n)
> > AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
> > AB[2, -n] <- -phi
> > round(AB, 3)
> >
> > AB.ch <- .Fortran("xdpbtrf", kUPLO=1L, N = as.integer(n),
> >  KD = 1L, AB = AB, LDAB = 2L, INFO =
> as.integer(0))$AB
> > AB.ch
> >
> > 
> >
> > and you are good to go.
> >
> > You should always do something  as described above when you need to pass
> character arguments to Fortran code.
> >
> > All of this was tested and run on macOS using the CRAN version of R.
> >
> > Berend Hasselman
> >
> >> On 11 Sep 2019, at 15:47, Giovanni Petris  wrote:
> >>
> >> Sorry for cross-posting, but I realized my question might be more
> appropriate for r-devel...
> >>
> >> Thank you,
> >> Giovanni
> >>
> >> 
> >> From: R-help  on behalf of Giovanni
> Petris 
> >> Sent: Tuesday, September 10, 2019 16:44
> >> To: r-h...@r-project.org
> >> Subject: [R] Calling a LAPACK subroutine from R
> >>
> >> Hello R-helpers!
> >>
> >> I am trying to call a LAPACK subroutine directly from my R code using
> .Fortran(), but R cannot find the symbol name. How can I register/load the
> appropriate library?
> >>
> >>> ### AR(1) Precision matrix
> >>> n <- 4L
> >>> phi <- 0.64
> >>> AB <- matrix(0, 2, n)
> >>> AB[1, ] <- 

Re: [R-pkg-devel] .Fortran opinion

[Avraham Adler]

If you read further in Drew's posts (which I highly recommend) he says
that C++/Rcpp isn't the best for wrapping Fortran calls, and that it
is faster and cleaner to use C. I have a relatively detailed blog post
on building packages with Fortran (or raw C) code; I hope you may find
it useful in your case [1].

Thanks,

Avi

[1] 
https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/

On Sun, May 26, 2019 at 3:22 PM Neal Fultz  wrote:
>
> I think the current best practice is to wrap the Fortran code in a C
> helper, and invoke that using .Call - more information on that is available
> in Hadley's book - http://adv-r.had.co.nz/C-interface.html
>
> It shouldn't be too much work, maybe another 10-20 lines of code, most of
> which could probably autogenerated using Rcpp if you wanted to take that
> route.
>
> On Sun, May 26, 2019 at 6:31 AM Berry Boessenkool <
> berryboessenk...@hotmail.com> wrote:
>
> >
> > Recently, users of my package rdwd have provided Fortran code for a nice
> > extension of the package.
> > According to the following site, calling .Fortran() is no longer
> > recommended:
> > https://github.com/wrathematics/Romp/blob/master/README.md#fortran
> >
> > Since this is my first time using native code, I'd highly appreciate any
> > thoughts on the following question:
> > How much additional work should I put into avoiding .Fortran() for
> > long-term CRAN suitability?
> >
> > Thanks ahead,
> > Berry
> >
> > PS: In case you want a look at the (two very short) Fortran routines:
> > https://github.com/brry/rdwd/tree/master/src
> > and their call in R:
> > https://github.com/brry/rdwd/blob/master/R/readRadarFile.R#L119
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Rd] Inno Setup 6.0.2 fails before creating exe file on Windows (R-3.6.0)

[Avraham Adler]

I am working on compiling R-3.6.0 for Windows 10 64bit using rtools40
(beta 11). I had also installed the most recent update of Inno setup,
which is now 6.0.2.With that version, `make risntaller` fails at the
call to ""C:/R/Inno/iscc" R.iss > R-3.6.0.log 2>&1" and just exits,
pointing to line 175 of the makefile which is:

$(RPREFIX)-win.exe: R.iss
"$(ISDIR)/iscc" R.iss > $(RPREFIX).log 2>&1

Reinstalling Inno Setup 5.6.1 does allow the exe file to be created.

Thank you,

Avi

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

Re: [Rd] Package inclusion in R core implementation

[Avraham Adler]

On Mon, Mar 4, 2019 at 5:01 PM J C Nash  wrote:

> As the original coder (in mid 1970s) of BFGS, CG and Nelder-Mead in
> optim(), I've
> been pushing for some time for their deprecation. They aren't "bad", but
> we have
> better tools, and they are in CRAN packages. Similarly, I believe other
> optimization
> tools in the core (optim::L-BFGS-B, nlm, nlminb) can and should be moved to
> packages (there are already 2 versions at least of LBFGS that I and Matt
> Fidler
> are merging). And optim::SANN does not match any usual expectations of
> users.
>
> I'm sure there are other tools for other tasks that can and should move to
> packages
> to streamline the work of our core team. However, I can understand that
> there is this
> awkward issue of actually doing this. I know I'm willing to help with
> preparing
> "Transition Guide" documentation and scripts, and would be surprised if
> there are
> not others. R already has a policy of full support only for current
> version, so
> hanging on to antique tools (the three codes at the top are based on
> papers all
> of which now qualify for >50 years old) seems inconsistent with other
> messages.
>
> For information: I'm coordinating a project to build understanding of what
> older algorithms are in R as the histoRicalg project. See
> https://gitlab.com/nashjc/histoRicalg. We welcome participation.
>
> Best, JN
>
> On 2019-03-04 7:59 a.m., Jim Hester wrote:
> > Conversely, what is the process to remove a package from core R? It seems
> > to me some (many?) of the packages included are there more out of
> > historical accident rather than any technical need to be in the core
> > distribution. Having them as a core (or recommended) package makes them
> > harder update independently to R and makes testing, development and
> > contribution more cumbersome.
> >
> > On Fri, Mar 1, 2019 at 4:35 AM Morgan Morgan 
> > wrote:
> >
> >> Hi,
> >>
> >> It sometimes happens that some packages get included to R like for
> example
> >> the parallel package.
> >>
> >> I was wondering if there is a process to decide whether or not to
> include a
> >> package in the core implementation of R?
> >>
> >> For example, why not include the Rcpp package, which became for a lot of
> >> user the main tool to extend R?
> >>
> >> What is our view on the (not so well known) dotCall64 package which is
> an
> >> interesting alternative for extending R?
> >>
> >> Thank you
> >> Best regards,
> >> Morgan
> >>
>

I have No arguments with updating code to more correct or modern versions,
but I think that as a design decision, base R should have optimization
routines as opposed to it being an external package which conceptually
could be orphaned. Or at least some package gets made recommended and
adopted by R core.

Thank you,

Avi
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] Problem with compiling OpenBLAS to work with R

[Avraham Adler]

I believe that repo just follows the directions on my blog. Without seeing
Dr. Hodges’s code, my initial concern is the many references to Cygwin. My
method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35.
That will likely change to solely Rtools40 once R3.6 is released due to the
Msys system being built in to it.

There may be some library conflicts between Cygwin and msys2/mingw64. If
possible, my suggestion would be uninstall everything and then just install
msys2 (and add in make after you to the first msys update) and rtools35.
Then there should be no conflicting libraries.

Thanks,

Avi

On Thu, Feb 28, 2019 at 12:11 AM Kenny Bell  wrote:

> This person has had apparent success - you could follow what they did or
> just download their product (with appropriate caution downloading a random
> .exe).
>
> https://github.com/thequackdaddy/R-OpenBLAS
>
> On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess 
> wrote:
>
> > Hello!
> >
> > I'm not sure if this is the right place to post this, so apologies
> > in advance if I'm not in the right list.
> >
> > I downloaded the OpenBLAS and am following Avraham Adler's great
> > instructions.  However, when I run make, things go well to a certain
> point,
> > and then go bad:
> >
> > make
> > [snip]
> >
> > touch cygopenblas_haswellp-r0.3.5.a
> > make -j 1 -C test all
> > make[1]: Entering directory
> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test'
> > gfortran -O2 -Wall -frecursive -m64 -mavx2   -o sblat1 sblat1.o
> > ../cygopenblas_haswellp-r0.3.5.a  -L/usr/lib/gcc/x86_64-pc-msys/7.3.0
> > -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib/../lib
> > -L/usr/lib/../lib
> > -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib
> > -L/usr/lib/w32api  -lmsys-2.0
> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001088.o):fake:(.text+0x2):
> > undefined reference to `__imp_pthread_mutex_destroy'
> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001090.o):fake:(.text+0x2):
> > undefined reference to `__imp_pthread_mutex_init'
> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001091.o):fake:(.text+0x2):
> > undefined reference to `__imp_pthread_mutex_lock'
> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001094.o):fake:(.text+0x2):
> > undefined reference to `__imp_pthread_mutex_trylock'
> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001095.o):fake:(.text+0x2):
> > undefined reference to `__imp_pthread_mutex_unlock'
> > collect2.exe: error: ld returned 1 exit status
> > make[1]: *** [Makefile:134: sblat1] Error 1
> > make[1]: Leaving directory
> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test'
> > make: *** [Makefile:124: tests] Error 2
> >
> >
> > I think it has something to do with the threads/pthreads but am not sure
> > how to fix it.  Any suggestions much appreciated.
> >
> > Thanks,
> > Sincerely,
> > Erin
> >
> > Erin Hodgess, PhD
> > mailto: erinm.hodg...@gmail.com
> >
> > [[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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] registering native routines

[Avraham Adler]

https://stat.ethz.ch/pipermail/r-devel/2017-February/073755.html

On Sat, Feb 16, 2019 at 3:22 PM Charles Geyer  wrote:
>
> I just noticed that R package foo in the github repo
> https://github.com/cjgeyer/foo no longer passes R CMD check --as-cran.  The
> problem seems to be that it does not register native routines and thus the
> C routines cannot be found.  It does pass R CMD check (without --as-cran).
> The version of the package that does register native routines (package
> fooRegister) in the same repo passes with or without --as-cran.  So did I
> miss the announcement?  Is registration of native routines now mandatory
> for CRAN?
>
> Just asking because I am currently teaching about R packages in PhD level
> statistical confusing and don't want to provide erroneous info.
>
> These packages are toy packages to introduce the class to R packages.  I
> don't actually want to put them on CRAN.
>
> --
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

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

[Avraham Adler]

If it helps, the BLAS I used is compiled to use 6 threads.

On Wed, Feb 6, 2019 at 3:47 AM Berend Hasselman  wrote:

>
>
> > On 6 Feb 2019, at 10:58, Martin Maechler 
> wrote:
> >
>
> .
> >
> ---
> >
> > I summarize what has been reported till:
> >
> > Failure in these cases
> > 
> > 1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL
> >   for BLAS/LAPACK)
> > 2. (By Bill Dunlap): Microsoft R Open (MRO) 3.4.2, also using
> >   MKL with 12 cores
> > 3. (By Brad Bell)  : R 3.5.2 Fedora 28 (x86_64) pkg, OpenBLAS(?)
> > 4. (by MM) : R 3.5.2 Fedora 28 (x86_64) pkg, BLAS+Lapack =
> OpenBLAS
> >
> > Success
> > ===
> >
> > - (by MM): R-devel, R 3.5.2 patched on FC28, *self compiled* gcc
> 8.2,
> >using R's BLAS/Lapack
> > - (by Ralf Stubner): R 3.5.2 from Debian Stable (gcc 6.2) + OpenBLAS
> > - (by Berend H.)   : R 3.5.2 [from CRAN] on macOS 10.14.3 (BLAS/Lapack
> ??)
>
> R 3.5.2 from CRAN using R's BLAS/Lapack.
>
> Berend
>
> 
>
> > It would be great if this could be solved...
> >
> > Martin
> >
> >
> >
> >> I have tried passing in the gradient and turning on the trace and it
> gives nearly the exact same trace with and without the gradient.
> >[...]
> >
> > __
> > 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
>
-- 
Sent from Gmail Mobile

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

[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 

[R-pkg-devel] OpenMP & Fortran: Seemingly contradictory responses from CRAN

[Avraham Adler]

Hello.

I am at my wits end as to how to comply with CRAN regarding my
Delaporte package which uses Fortran and OpenMP [1].

Recently, it was announced [2] that going forward, OpenMP should be
linked with SHLIB_OPENMP_CFLAGS.

Moreover, I received an email from Professor Ripley, stating:

---START Prof. Ripley--
There are two issues

- Linking in R-devel is done by C or C++ even for F95 code, so PKG_LIBS
needs to contain the appropriate macro, SHLIB_OPENMP_CFLAGS for all
these packages.

- SHLIB_OPENMP_FFLAGS is preferred to SHLIB_OPENMP_FCFLAGS

There are two possibilities to correct this:

A) Make a version of the package depending on R(>=3.6.0) and submit
stating it is intended for the 3.6.0/Others area.

B) With both points changed the package should still work under R 3.5.x
as for current platforms SHLIB_OPENMP_FFLAGS, SHLIB_OPENMP_FCFLAGS and
SHLIB_OPENMP_CFLAGS have the same value.  So it could be submitted for
the main CRAN area.
---STOP Prof. Riple--

My first attempt had the following Makevars submitted the to CRAN:

PKG_FFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

Granted, this would not have had OpenMP for other reasons (FFLAGS will
only be recognized for free-form Fortran in R 3.6+) but the submission
was denied with the following note:

-START CRAN-

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: incorrect macro SHLIB_OPENMP_CFLAGS included in PKG_FFLAGS
src/Makevars: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not
in PKG_CFLAGS
-STOP CRAN-

Uwe Ligges was kind enough to clarify:

-START Prof. Ligges-
Sun, Jan 13, 12:16 PM (8 days ago)

to me, CRAN-submissions
Pls re-read Brian's comment and note that we already check with R-devel.
He daid:

" PKG_LIBS needs to contain the appropriate macro, SHLIB_OPENMP_CFLAGS "

but you have it in PKG_FFLAGS now?
(first) and then
" SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not in PKG_CFLAGS", si
please declare it there, too.
-STOP Prof. Ligges-

So, I declared CFLAGS too. However, When I passed (substituting
FCFLAGS so that OpenMP will work in R-release):

PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_FCFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

I got:

-START CRAN-
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: incorrect macro SHLIB_OPENMP_CFLAGS included in PKG_FCFLAGS
-STOP CRAN-

If I give up and focus just on R-release by passing:

PKG_FCFLAGS = $(SHLIB_OPENMP_FCFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_FCFLAGS)

I get:

-START CRAN-
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: SHLIB_OPENMP_FFLAGS is preferred to
SHLIB_OPENMP_FCFLAGS in PKG_FCFLAGS
src/Makevars: SHLIB_OPENMP_FCFLAGS is included in PKG_FCFLAGS but
not SHLIB_OPENMP_CFLAGS in PKG_LIBS
src/Makevars: SHLIB_OPENMP_FCFLAGS is included in PKG_LIBS but
linking is by C
-STOP CRAN-

If I really give up and pass Depend: R <= 3.5.2 in the DESCRIPTION,
*noting in the comments that I will submit a new R 3.6+ only version
when it is released* I still get a failure:

-START CRAN-
Flavor: r-devel-windows-ix86+x86_64
Check: whether package can be installed, Result: ERROR
  Installation failed.
  See 'd:/RCompile/CRANincoming/R-devel/Delaporte.Rcheck/00install.out'
for details.

Flavor: r-devel-linux-x86_64-debian-gcc
Check: whether package can be installed, Result: ERROR
  Installation failed.
  See '/srv/hornik/tmp/CRAN/Delaporte.Rcheck/00install.out' for details

-STOP CRAN-

Which actually was the point, to be honest. It wasn't supposed to pass R-devel.

I cannot pass JUST:

PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

AS OpenMP would not be compiled into the Fortran.

I really would like to have oe version of the package that is CRAN
compliant, but at this point, I cannot see how to do that based on the
various rejection messages I got. Maybe I'm missing something simple,
in which case, please explain. Any guidance would be much appreciated.

Thank you,

Avi

[1] https://cran.r-project.org/package=Delaporte
[2] 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2018/12/04#n2018-12-04

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

Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?

[Avraham Adler]

If you want to use .NOTPARRALLEL, that’s considered non-portable as it’s
GNU-make specific, (I got an email from Dr. Ripley this week) so you have
to add Gnu Make to the system requirements in the DESCRIPTION or find the
right sequence of targets to ensure order is maintained even in parallel
make.

Avi

On Mon, Jan 14, 2019 at 1:29 PM Paul Gilbert  wrote:

> (I didn't see an answer to this, so ...)
>
> I think using .NOTPARALLEL will usually get rid of the error but, in my
> experience, this problem is usually caused by an incorrect or incomplete
> Makefile. When not done in parallel this missing target is usually
> getting done first as a side-affect of something that happens before and
> usually finishes before it is needed. Your luck does not hold in
> parallel. The better fix is to correct your Makefile.
>
> Paul
>
> On 1/10/19 4:54 PM, Satyaprakash Nayak wrote:
> > Dear R package developers
> >
> > I published a package on CRAN last year (sundialr) which is now failing
> > with as it is not make to compile a static library with parallel make.
> >
> > In this package, I compile a static library (libsundials_all.a) from
> source
> > files of a third party. The specifics of compiling the static library can
> > be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars
> >
> > Now, I got the following error message from CRAN (actually, I was
> informed
> > of this before, but had neglected to fix it). Here is the message from
> one
> > of the CRAN maintainers ..
> >
> >
> ***
> > This have just failed to install for me with a parallel make:
> >
> > g++ -std=gnu++98 -std=gnu++98 -shared
> > -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so
> > cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack
> > -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm
> > -lquadmath -L../inst/ ../inst/libsundials_all.a
> > g++: error: ../inst/libsundials_all.a: No such file or directory
> > make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6:
> > sundialr.so] Error 1
> >
> *
> >
> > It seems the package fails to generate the static library with the
> parallel
> > make. The easiest solution I could think of for this problem was to
> force a
> > serial version of make using the .NOTPARALLEL phony command in Makevars
> and
> > Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars).
> I
> > have made this change and it seems to work on my machine and on testing
> > with TravisCI and Appveyor(https://github.com/sn248/sundialr).
> >
> > However, before I re-submit to CRAN, I wanted to get an opinion as to
> will
> > this be enough to get rid of the error with parallel make?
> >
> > Any suggestions would be very much appreciated, thank you!
> > Satyaprakash
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[Rd] Issue when building R-parched_2018-12-26

[Avraham Adler]

Hello.

Building R-patched from source on Win64 using current Rtools 3.5.0.4, I’m
getting the following notes indicating an extra left brace somewhere; or is
the problem on my end?

My installed Perl is Strawberry 5.28.0.1-64 bit.

Thank you,

Avi

(Sent from an iPhone, so my apologies if HTML also comes through)

-- Making HTML documentation --

creating doc/manual/version.texi

creating doc/manual/R-FAQ.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-admin.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-data.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-exts.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-intro.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-ints.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

creating doc/manual/R-lang.html

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

making rw-FAQ

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*/ at C:/Rtools/texinfo5/Texinfo/Parser.pm line 5441.

Unescaped left brace in regex is deprecated here (and will be fatal in Perl
5.32), passed through in regex; marked by <-- HERE in
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({
<-- HERE })?\s*(\@(c|comment)((\@|\s+).*)?)?/ at
C:/Rtools/texinfo5/Texinfo/Parser.pm line 5446.

Negative repeat count does nothing at
C:/Rtools/texinfo5/Texinfo/Convert/Plaintext.pm line 1065.

Negative repeat count does nothing at
C:/Rtools/texinfo5/Texinfo/Convert/Plaintext.pm line 1065.

Negative repeat count does nothing at
C:/Rtools/texinfo5/Texinfo/Convert/Plaintext.pm line 1065.

Negative repeat count does nothing at

[R-pkg-devel] Best practices for R package requiring Fortran 2003

[Avraham Adler]

Following the news, I've been trying to clean up my package which uses
Fortran in preparation for the changes that appear to be coming in
R-devel. The package has implicitly been relying on Fortran 2003,
since it uses iso_c_binding. In practice, is it proper that
"-std=f2003" be explicitly added to PKG_FCFLAGS (or possibPKG_FFLAGS
in 3.6.0)? Should "Fortran 2003" be listed in SystemRequirements? It
currently passes CRAN checks, but that's because all the Fortran
compilers in use have the iso_c_bindings implemented (GCC 4.5 already
had it, and it's clearly in Oracle Developer Studio 12.5).

Thank you,

Avi

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

Re: [R-pkg-devel] avoiding .mod files

[Avraham Adler]

On Tue, Nov 20, 2018 at 4:45 AM Rampal Etienne  wrote:
>
> Dear Thomas,
>
> My FORTRAN code to be used with deSolve contains a module dimmod. During
> build a file called dimmod.mod is created in the src directory. I can
> avoid this by including it in the .RBuildignore file, but when I submit
> the package to CRAN, the package is rejected because it keeps creating
> the dimmod.mod file. How do I solve this?
>
> Kind regards,
>
> Rampal Etienne

Hello, Rampal.

I use Fortran modules with my Delaporte package [1]. I clean them by
having a clean (actually two clean) routines in Makvars [2]. Perhaps
something like that would work for you.

Good Luck,

Avi

[1] https://CRAN.R-project.org/package=Delaporte
[2] https://bitbucket.org/aadler/delaporte/src/master/src/Makevars

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

Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

Fantastic!

Avi

On Sat, Sep 15, 2018 at 7:26 PM Erin Hodgess 
wrote:

> Finally got Openblas installed!  The speed up is amazing!  Thanks for your
> help and patience.
>
> Sincerely,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler 
> wrote:
>
>> No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS
>> recently. Does it work if you use the vanilla BLAS?
>>
>> Avi
>>
>> On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess 
>> wrote:
>>
>>> Hi again!
>>>
>>> I checked everything, did "make distribution" and the same thing
>>> occurred.
>>>
>>>
>>> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a
>>> SuiteSparse_config.o
>>> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file
>>> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll
>>> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o
>>> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o
>>> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o
>>> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o
>>> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack
>>> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64
>>> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR
>>> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to
>>> `cholmod_change_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to
>>> `cholmod_factor_to_sparse'
>>> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to
>>> `cholmod_free_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to
>>> `cholmod_solve'
>>> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to
>>> `cholmod_updown'
>>> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to
>>> `cholmod_spsolve'
>>> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to
>>> `cholmod_factorize_p'
>>> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to
>>> `cholmod_change_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to
>>> `cholmod_free_factor'
>>> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to
>>> `cholmod_sparse_to_dense'
>>> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye'
>>> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add'
>>> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to
>>> `cholmod_free_sparse'
>>> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to
>>> `cholmod_copy_sparse'
>>> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to
>>> `cholmod_free_sparse'
>>> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy'
>>>
>>> Does this look familiar, please?
>>>
>>> Thanks,
>>> Erin
>>>
>>> Erin Hodgess, PhD
>>> mailto: erinm.hodg...@gmail.com
>>>
>>>
>>> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler 
>>> wrote:
>>>
>>>> Try following the directions here. They have worked for me for years.
>>>> Please see the comments too.
>>>>
>>>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>>>>
>>>> Hope that helps,
>>>>
>>>> Avi
>>>>
>>>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
>>>> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> I'm building a package that needs Openblas for matrix manipulation
>>>>> speed up.
>>>>>
>>>>> I built Openblas on Windows 10.  I updated the MkRules.local,
>>>>> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>>>>>
>>>>> However, when I run "make recommended", I have trouble with the Matrix
>>>>> package build.  The components of the Cholesky all appear as
>>>>> unreferenced.
>>>>>
>>>>> Has anyone else run into this, please?  I'm working with R-3.5.1
>>>>> source.
>>>>>
>>>>> Thanks,
>>>>> Erin
>>>>>
>>>>> Erin Hodgess, PhD
>>>>> mailto: erinm.hodg...@gmail.com
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>> __
>>>>> R-package-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>
>>>> --
>>>> Sent from Gmail Mobile
>>>>
>>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS
recently. Does it work if you use the vanilla BLAS?

Avi

On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess 
wrote:

> Hi again!
>
> I checked everything, did "make distribution" and the same thing occurred.
>
>
> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a
> SuiteSparse_config.o
> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file
> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll tmp.def
> CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o
> cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o dpoMatrix.o
> dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o dtTMatrix.o
> dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o sparseQR.o
> abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack -LD:/erinm/R-3.5.1/bin/x64
> -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 -LD:/erinm/R-3.5.1/extsoft/lib
> -LD:/erinm/R-3.5.1/bin/x64 -lR
> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to
> `cholmod_change_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to
> `cholmod_factor_to_sparse'
> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to
> `cholmod_free_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to
> `cholmod_solve'
> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to
> `cholmod_updown'
> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to
> `cholmod_spsolve'
> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to
> `cholmod_factorize_p'
> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to
> `cholmod_change_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to
> `cholmod_free_factor'
> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to
> `cholmod_sparse_to_dense'
> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye'
> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add'
> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to
> `cholmod_free_sparse'
> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to
> `cholmod_copy_sparse'
> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to
> `cholmod_free_sparse'
> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy'
>
> Does this look familiar, please?
>
> Thanks,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler 
> wrote:
>
>> Try following the directions here. They have worked for me for years.
>> Please see the comments too.
>>
>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>>
>> Hope that helps,
>>
>> Avi
>>
>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
>> wrote:
>>
>>> Hello!
>>>
>>> I'm building a package that needs Openblas for matrix manipulation speed
>>> up.
>>>
>>> I built Openblas on Windows 10.  I updated the MkRules.local,
>>> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>>>
>>> However, when I run "make recommended", I have trouble with the Matrix
>>> package build.  The components of the Cholesky all appear as
>>> unreferenced.
>>>
>>> Has anyone else run into this, please?  I'm working with R-3.5.1 source.
>>>
>>> Thanks,
>>> Erin
>>>
>>> Erin Hodgess, PhD
>>> mailto: erinm.hodg...@gmail.com
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

Try following the directions here. They have worked for me for years.
Please see the comments too.

https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

Hope that helps,

Avi

On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
wrote:

> Hello!
>
> I'm building a package that needs Openblas for matrix manipulation speed
> up.
>
> I built Openblas on Windows 10.  I updated the MkRules.local,
> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>
> However, when I run "make recommended", I have trouble with the Matrix
> package build.  The components of the Cholesky all appear as unreferenced.
>
> Has anyone else run into this, please?  I'm working with R-3.5.1 source.
>
> Thanks,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] predict.glm returns different results for the same model

[Avraham Adler]

Can’t copy from my computer as gmail is blocked at work but if it helps,
the “predvars” attribute if the terms object is not the same.

Avi

On Fri, Apr 27, 2018 at 9:25 AM Hadley Wickham  wrote:

> Hi all,
>
> Very surprising (to me!) and mystifying result from predict.glm(): the
> predictions vary depending on whether or not I use ns() or
> splines::ns(). Reprex follows:
>
> library(splines)
>
> set.seed(12345)
> dat <- data.frame(claim = rbinom(1000, 1, 0.5))
> mns <- c(3.4, 3.6)
> sds <- c(0.24, 0.35)
> dat$wind <- exp(rnorm(nrow(dat), mean = mns[dat$claim + 1], sd =
> sds[dat$claim + 1]))
> dat <- dat[order(dat$wind), ]
>
> m1 <- glm(claim ~ ns(wind, df = 5), data = dat, family = binomial)
> m2 <- glm(claim ~ splines::ns(wind, df = 5), data = dat, family = binomial)
>
> # The model coefficients are the same
> unname(coef(m1))
> #> [1]  0.5194712 -0.8687737 -0.6803954  4.0838947  2.3908674  4.1564128
> unname(coef(m2))
> #> [1]  0.5194712 -0.8687737 -0.6803954  4.0838947  2.3908674  4.1564128
>
> # But the predictions are not!
> newdf <- data.frame(wind = seq(min(dat$wind), max(dat$wind), length = 5))
> unname(predict(m1, newdata = newdf))
> #> [1] 0.51947119 0.03208719 2.82548847 3.90883496 4.06743266
> unname(predict(m2, newdata = newdf))
> #> [1]  0.5194712 -0.5666554 -0.1731268  2.8134844  3.9295814
>
> Is this a bug?
>
> (Motivating issue from this ggplot2 bug report:
> https://github.com/tidyverse/ggplot2/issues/2426)
>
> Thanks!
>
> Hadley
>
>
>
> --
> http://hadley.nz
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] R Compilation gets stuck on Windows 64

[Avraham Adler]

Set the location of atlas path in mkrules.local to what you need, then edit
arc/extra/blas/makevars.win to read lopenblas_haswell-r0.2.20 instead of
the two libraries there in the atlas section. I think I described this in
my more recent instructions.

Avi

On Tue, Feb 13, 2018 at 8:18 AM Indrajit Sen Gupta 
wrote:

> In the file MkRules.local.in, I see the line: USE_ATLAS = NO which I
> believe needs to be changed to YES. But how do I specify the BLAS file 
> *libopenblas_haswell-r0.2.20.a
> *and its location?
>
> Regards,
> Indrajit
>
> On Tue, Feb 13, 2018 at 6:41 PM, Indrajit Sen Gupta 
> wrote:
>
>> I was able to compile the R from the github by running build-r-devel.bat!
>>
>> Now need to see how to compile it with BLAS.
>>
>> Regard,
>> Indrajit
>>
>> On Tue, Feb 13, 2018 at 5:45 PM, Jeroen Ooms 
>> wrote:
>>
>>> On Tue, Feb 13, 2018 at 12:22 PM, Indrajit Sen Gupta
>>>  wrote:
>>> > Hi Avraham,
>>> >
>>> > I tried with the patched version. The same error message.
>>> >
>>> > gcc -std=gnu99 -m64 -shared -s -mwindows -o R.dll R.def console.o
>>> dynload.o
>>> > editor.o embeddedR.o extra.o malloc.o opt.o pager.o preferences.o
>>> psignal.o
>>> > rhome.o rt_complete.o rui.o run.o shext.o sys-win32.o system.o
>>> dos_wglob.o
>>> > dllversion.o ../main/libmain.a ../appl/libappl.a ../nmath/libnmath.a
>>> > getline/gl.a ../extra/xdr/libxdr.a ../extra/intl/libintl.a
>>> > ../extra/trio/libtrio.a ../extra/tzone/libtz.a ../extra/tre/libtre.a
>>> > -fopenmp -L. -lgfortran -lquadmath -lRblas -L../../lib -lRgraphapp
>>> -lRiconv
>>> > -lcomctl32 -lversion -L"D:/R64/extsoft"/lib/x64 -lpcre -lz -lbz2 -llzma
>>> > -L"D:/home/ICU"/lib/x64 -lsicuin -lsicuuc -lsicudt -lstdc++
>>> >
>>> D:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> > cannot find -lRgraphapp
>>> > collect2.exe: error: ld returned 1 exit status
>>> > make[4]: *** [R.dll] Error 1
>>> > make[3]: *** [../../bin/x64/R.dll] Error 2
>>> > make[2]: *** [rbuild] Error 2
>>> > make[1]: *** [all] Error 2
>>> > make: *** [distribution] Error 2
>>> >
>>> >
>>> > Would it be possible for you to share your MkRules.local and
>>> Makefile.win
>>> > files?
>>>
>>>
>>> Hi Indrajit
>>>
>>> As somebody above already mentioned, the full build script as well as
>>> MkRules.local that we use for the CRAN releases of R for windows are
>>> available from https://github.com/rwinlib/base
>>>
>>> As is explained in the repository readme, if you have the required
>>> dependencies (rtools, miktex innosetup, strawberry perl) all you need
>>> to do is run the build-r-devel.bat script from the root of the
>>> repository.
>>>
>>> Once you got this to work, you can adapt it to your needs.
>>>
>>
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [Rd] R Compilation gets stuck on Windows 64

[Avraham Adler]

On Fri, Feb 9, 2018 at 9:29 AM, Kenny Bell  wrote:
> I suggest that you work off the build process in the  rwinlib repository so
> you are starting from something that you know works and already incorporates
> the set of dependencies you need.

Hello, Kenny.

For what it's worth I've been successfully building R+OpenBLAS on
Windows64 since 2013, which I believe predates rwinlib on github, but
I may be mistaken. Thus, I don't think I'm incorrect in saying that
the instructions I provide are also "something that you know works" :)
I did make the explicit assumption that people will successfully
follow the instructions at R Installation & Administration. Perhaps
that is too much to ask.

Thanks,

Avi

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

Re: [Rd] R Compilation gets stuck on Windows 64

[Avraham Adler]

On Fri, Feb 9, 2018 at 2:16 AM, Indrajit Sen Gupta  wrote:
> Hi Avraham,
>
> A quick question - I realized I did not have Perl installed. So I installed
> ActiveState Perl right now. Also I see I need texinfo and texi2any. I was
> able to installed texinfo from here:
> http://gnuwin32.sourceforge.net/packages/texinfo.htm. But not sure where to
> get texi2any. Can you guide me in this step?

It is in the ZIP file "texinfo5.zip" here [1]. Unzip that entire file
into a directory and use that as your texinfo directory. That works
for me.

Avi

[1] http://www.stats.ox.ac.uk/pub/Rtools/

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

Re: [Rd] R Compilation gets stuck on Windows 64

[Avraham Adler]

On Thu, Feb 8, 2018 at 9:44 PM, Indrajit Sen Gupta  wrote:
> Hi All,
>
> I am trying to compile R from source on a 64 bit Windows.

[snip]

> I had compiled earlier with MinGW and had created the file:
> *libopenblas_haswell-r0.2.20.a. *

Hello, Indrajit.

I don't see your MkRules.local attached. In any event, perhaps try
following the directions here [1]. I've been building R with OpenBLAS
on Windows 64 for years and it almost always works. In the past year
or two, rarely, it will stop with an error. But if you restart the
make process (by just typing "make" again) it finishes with no issues
and passes make check-devel. I have not tried this with R-dev, though.
R 3.4.3 Patched (2018-01-03 r74042) is the most recent I have built
successfully.

Good luck,

Avraham

[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

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

Re: [Rd] OpenBLAS in everyday R?

[Avraham Adler]

On Thu, Jan 11, 2018 at 10:38 AM, Keith O'Hara  wrote:

[snip]
>
> Perhaps another point for Juan’s list: whether OpenBLAS is the right choice 
> to pair with. The library itself hasn’t produced optimized kernels for any of 
> the Intel *Lake chips yet; might be worth considering its near- and long-term 
> future (vs something else).
>

Regarding this point, please see this thread on OpenBLAS-users [1], in
specific the third post by Jeff Hammond who says he is an employee of
Intel, where he says:

 "Skylake Xeon processors with AVX-512 are definitely going to require
code changes to perform optimally. However, the Core i[357] processors
up to and including Kaby Lake do not support AVX-512 and thus can
suffice with the existing AVX2 implementation that targets Haswell.
See https://ark.intel.com/#@Processors and look for "Instruction Set
Extensions" for full details on on specific SKUs."

I presume this holds for CoffeeLake as well, as it's pretty much a
hexacore SkyLake.

Thank you,

Avi

[1] https://groups.google.com/d/msg/openblas-users/XU6-9h-geVE/mwz2ewKrCQAJ

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

Re: [Rd] OpenBLAS in everyday R?

[Avraham Adler]

On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara  wrote:
>
> Check if libopenblas is linked against libomp or libgomp.
>
> I’d be curious to see any errors that arise when an OpenMP version of 
> OpenBLAS is linked with R.
>
> Keith
>

The one time I tried compiling OpenBLAS for Windows 64 with USE OMP =
1, I got an error. I don't recall if it was in the compilation of R or
in use. Regardless, I compile OpenBLAS without setting that flag and
it still plays nicely with all R packages, including those that use
OpenMP.

Avi

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

Re: [Rd] OpenBLAS in everyday R?

[Avraham Adler]

On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell  wrote:
> It seems like many of the multi-threaded BLASes have some sort of
> fundamental problem preventing use in the way Juan suggests:
>
>  - Dirk's vignette states that ATLAS "fixes the number of cores used at
> compile-time and cannot vary this setting at run-time", so any
> user-friendly implementation for R would have to compile ATLAS for 1-16
> threads to allow the user to switch at run-time. This might dramatically
> affect install times.
>
>  - MKL seems like it's been outright rejected in the past based on not
> being "free-enough".
>
>  - OpenBLAS causes crashes.
>
> Has anyone tried ExBLAS for use with R?
>
> On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder <
> peter.langfel...@gmail.com> wrote:
>
>> I would be very cautious about OpenBLAS in particular...  from time to
>> time I get complains from users that compiled code calculations in my
>> WGCNA package crash or produce wrong answers with large data, and they
>> all come from OpenBLAS users. I am yet to reproduce any of their
>> crashes when using MKL and ATLAS BLAS implementations.
>>
>> Just my 2 cents...
>>
>> Peter

I've been building R on Windows 64 bit with OpenBLAS for years and my
builds pass check-devel. For a while in the past it failed one check
as the tolerance was 5e-5 and with my build of OpenBLAS the error was
5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall
correctly. I provide descriptions here [1], but I haven't gone so far
as to post compiled Rblas.dlls just yet. My personal build sets 4
threads when compiling OpenBLAS itself as I'm currently on a quad-core
SandyBridge. In tests I ran a few years ago, both single and multi
threaded BLAS compile and then can be compiled into R with no issues
(on my platforms, at least). Most matrix operations performed better
with multi-threaded except for R's eigenvalue decomposition, to the
nest of my recollection.

Avi

[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

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