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

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

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

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

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

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

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

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. H

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

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

Re: [Rd] Advice debugging M1Mac check errors

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

Re: [Rd] Segmentation fault early in compilation of revision 85514

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

[Rd] Segmentation fault early in compilation of revision 85514

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

"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 P

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

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

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

y 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 ente

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

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

[Rd] R-devel 83314 fails datetime3 on Windows

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 +

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

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

Re: [Rd] Parser bug? A comma too much.

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,

Re: [R-pkg-devel] No package called 'scales' (r-oldrel-windows)

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

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

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

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

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, Juli

Re: [Rd] Improved LP/MIP solver

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

Re: [Rd] Improved LP/MIP solver

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

Re: [Rd] string concatenation operator (revisited)

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

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

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

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

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)

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

-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

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

isq, 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,

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

ing 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

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

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 fin

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

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

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

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

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

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

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

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

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

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

Re: [Rd] svd for Large Matrix

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

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

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

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

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

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

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

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

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

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

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 [

Re: [Rd] Faster sorting algorithm...

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

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

2 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’

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

it.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

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

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

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

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

Re: [Rd] [External] use of the tcltk package crashes R 4.0.1 for Windows

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:

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

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

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

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

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

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

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

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

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

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,

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

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

Re: [Rd] Rtools and R 4.0.0?

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

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

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

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

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 Ad

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

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" argume

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

e 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: > &g

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

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

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

or. 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 > > >

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

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

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

Re: [Rd] R 3.6.2 is released

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

Re: [Rd] R 3.6.2 is released

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

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

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

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

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

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

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

Re: [Rd] New matrix function

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

Re: [Rd] New matrix function

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

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

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

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

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

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

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

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

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

Re: [Rd] Package inclusion in R core implementation

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 >

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

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

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

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

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

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

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

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 $

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

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:

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

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

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

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

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

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

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

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 >

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

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

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

parse.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

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

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

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

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():

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

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

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

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

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

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

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

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

Re: [Rd] OpenBLAS in everyday R?

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

Re: [Rd] OpenBLAS in everyday R?

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

Re: [Rd] OpenBLAS in everyday R?

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

  1   2   >