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 Windows 64 with USE O

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 considering its near- and long

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 MkRules.local attached. I

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: > http://gnuwin32.sourceforge.n

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 worth I've been successfu

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] 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(): the > predictions var

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

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

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 ha

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 M

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

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

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 calli

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

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 mentio

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 recom

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 i

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 P

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 patched should go

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

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

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

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)

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

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

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 config

Re: [Rd] Improving string concatenation

On Wed, Jun 17, 2015 at 1:25 AM, Joshua Bradley wrote: > …I work in the bioinformatics domain and write R scripts for > pipelines with calls to various programs that require a lot of parameters > to be set/varied. Seeing "paste" everywhere detracts from reading the code > (in my opinion). In that

[Rd] GCC update in Rtools?

Hello. There was a lot of discussion in March about the difficulties in having Rtools use a more recent version of GCC than 4.6.3. May we know if there has been any progress since then, or has dveleopment/testing been put on hold for the time being? Thank you, Avi __

[Rd] Has the changelog for R-devel and R-patched moved?

Hello. There used to be changelog of sorts for R-devel [1] and R-release [2]. Neither have been updated since 2015-07-24. Have these moved elsewhere, or are they no longer being updated? Thank you, Avi [1] [2]

Re: [Rd] Has the changelog for R-devel and R-patched moved?

On Tue, Sep 1, 2015 at 10:57 AM, peter dalgaard wrote: > > On 01 Sep 2015, at 16:21 , Avraham Adler wrote: > >> Hello. >> >> There used to be changelog of sorts for R-devel [1] and R-release [2]. >> Neither have been updated since 2015-07-24. Have these moved &g

[Rd] R-devel_2015-09-14 throws an error in reg-packages test

Hello. I have successfully built R on windows scores of times, and have never come across this problem. For this build, I am using the current 4.6.3 prerelease version of Rtools, Windows7 64 bit, and R-devel_2015-09-14.tar.gz When running make check, I get the following error: running code in '

[Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe

According to the MikTex bug reports [1], MikTex 2.9 has removed texi2dvi.exe last week (on 2015-09-29) as "it was not compatible (anymore) with the original shell script texi2dvi (GNU Texinfo)." I found this out the hard way as I just (unknowingly) updated MikTex this evening, and then, while build

Re: [Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe

On Fri, Oct 9, 2015 at 1:44 AM, Prof Brian Ripley wrote: > Hmm, look in MkRules.dist for the setting you failed to make Obviously > available in R-patched and R-devel only as we cannot foretell such changes. > >[snip] Yes, I see my error. For efficiency, I had copied in an old pre-filled Mkr

[Rd] Error building Tcl: R-patched_2016-07-05

I am trying to build R under 64bit Windows7. I am using a fresh install of Rtools34 and R-patched_2016-07-05. I am getting the following error: C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o tcltk.dll tmp.def init.o tcltk.o tcltk_win.o ../../../gnuwin32/dllversion.o -L../../../../Tcl/bin

Re: [Rd] Error building Tcl: R-patched_2016-07-05

OK, that makes sense. Perhaps Rtools34 should then say it should be used for a version later than 3.3.x? Then again, anyone with the question will probably find this thread. Thank you, Avi On Thu, Jul 7, 2016 at 6:33 PM, Duncan Murdoch wrote: > On 07/07/2016 5:47 PM, Avraham Adler wr

[Rd] Is it intentional that the Fortran optimization flags changefrom O3 to O2 on Windows?

When compiling R-devel (2016-08-07) on Windows (64bit) using Rtools (3.4.0), the C++ optimization flags are manually changed to -O2 from -O3. This has been the situation for years, and I believe this is to prevent certain optimizations which may cause downstream problems. In R_HOME/src/gnuwin32/fix

[Rd] Setting Gnu++11 when compiling R-devel on Windows

Recently, there have been changes to R-devel to make it more compatible with GCC 6.x, which is great. Unfortunately, Windows still uses a toolset based on GCC 4.9.3. When compiling R release or R-patched, one can have GCC called with -std=gnu++11 by having it in the CXXFLAGS in one's HOME/.R/Makev

Re: [Rd] optim(…?=, =?utf-8?Q?method=‘L-BFGS-B’) stops with an error message while violating the lower bound

I believe the code can be found here: http://users.iems.northwestern.edu/~nocedal/lbfgsb.html. Specifically, lbfgsb.f in version 3.0 starts: This is a modified version of L-BFGS-B. Minor changes in the updated c code appear preceded by a line comment as follows c c c-jlm-jn c c Major c

Re: [Rd] unlicense

A number of years ago I asked here for the ISC to be added and was told you have to ask CRAN, not Rd. Good luck, Avi On Fri, Jan 13, 2017 at 3:22 PM Charles Geyer wrote: > I would like the unlicense (http://unlicense.org/) added to R > > licenses. Does anyone else think that worthwhile? > > >

[Rd] Unexpected EOF in R-patched_2017-01-30

Hello. When trying to unpack today's version of R-patched, I get the following error: C:\R>tar -xf R-patched_2017-01-30.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now I got the same error for R-

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard wrote: > >> On 31 Jan 2017, at 18:56 , Avraham Adler wrote: >> >> Hello. >> >> When trying to unpack today's version of R-patched, > > From which source? The files from cran.r-project.org seems OK, bo

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

Avi On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler wrote: > >>>>> Avraham Adler > >>>>> on Tue, 31 Jan 2017 16:07:20 -0500 writes: > > > On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard > wrote: > >> > >>> On

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler wrote: > Or the file was corrupted during download? > > Here are the md5sum s from the server itself for the last three snapshots: > > 388b607afe732c92442dbb49845fe377 /ftp/R/R-patched_2017-01-31.tar.gz > 7daea59067454311818df1c75971a485

Re: [Rd] Registration of native routines

On Tue, Feb 14, 2017 at 11:25 AM, Prof Brian Ripley wrote: > Registration of 'native routines' (entry points in compiled code loaded into > R) has been available for over 14 years, but few packages make use of it > (less than 10% of those on CRAN with compiled code). > > Registration has similar b

[Rd] R-devel 2017-02-15: repeated line in /src/gnuwin32/MkRules.dist

Hello. Unless I am mistakedn, it seems that lines 49 and 72 are copies of each other and only one should be necessary to set the whether or not Windows is 32- or 64-bit. If it were my guess, I'd say lines 48 & 49 are redundant. Thanks, Avi __ R-devel@

Re: [Rd] Wish List: Extensions to the derivatives table

Hi. Unless I'm misremembering, log, exp, sin, cos, and tan are all handled in deriv3. The functions listed are specially coded slightly more accurate versions but can be substituted with native ones for which deriv/deriv3 will work automatically. I believe that if you write your functions using

Re: [Rd] Registration of native routines

I believe Dr. Ripley said that the UseDynLib doesn't address the middle two points of the list. I experimented with the Delaporte package timing calls using both methods, and they were within 1~2 microseconds of each other using microbenchmark. Since the more complicated way is now expressly prefe

Re: [Rd] R 3.4.0

Perhaps the darkness is so stupid it forgot to update the year? Avi On Fri, Mar 17, 2017 at 12:24 PM wrote: > Your dates are for 2016 :-) in your email and developer.r-project.com > > Best, > > luke > > On Fri, 17 Mar 2017, Peter Dalgaard wrote: > > > R 3.4.0 "You Stupid Darkness" is now schedul

[Rd] TEXINFO error when building R-3.4.0

Hello. I am trying to build 64 bit R-3.4.0 (specifically R-patched_2017-04-23) on Windows 64 and have run into an issue with building the html files. I am using Rtools34 version 1962, the texinfo zip from unzipped into C:\R\texinfo, and Strawberry perl 5.24.

Re: [Rd] TEXINFO error when building R-3.4.0

The fault was mine. -I/C:/R/texinfo should have been -IC:/R/texinfo Thank you, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Philosophy behind converting Fortran to C for use in R

Hello. This is not a question about a bug or even best practices; rather I'm trying to understand the philosophy or theory as to why certain portions of the R codebase are written as they are. If this question is better posed elsewhere, please point me in the proper direction. In the thread about

[Rd] Solaris SPARC testbed

I've looked at some package testing results and I'm not seeing Solaris SPARC. Has that test-bed been deprecated for package testing? Thanks, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Duncan's retirement: who's taking over Rtools?

On Thu, Sep 28, 2017 at 11:27 AM, Joris Meys wrote: > Dear dev team, > > I was sorry to see the announcement of Duncan about his retirement from > maintaining the R Windows build and Rtools. Duncan, thank you incredibly > much for your 15 years of devotion and your impressive contribution to the >

Re: [Rd] Duncan's retirement: who's taking over Rtools?

On Thu, Sep 28, 2017 at 11:47 AM, David Smith via R-devel wrote: > The Microsoft R team is willing and able to produce builds for R on Windows > going forward. As Duncan noted, we've been doing this already for some time > for MRAN. I'd love to hear thoughts from this community on what that migh

Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?

[Sent offlist accidentally] What concerns me first and foremost is that the licensure would have to be ironclad (including for commercial use like vanilla R now) as well as ensuring that R remains completely FLOSS. Anything “added” to R has to be a no-strings-attached gift to R. Also, I would thi

Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?

On Mon, Oct 30, 2017 at 12:45 PM, Cohn, Robert S wrote: > I think the thing that is missing is a simple way for end users on windows to > replace blas/lapack libraries with MKL-a package that you install that puts > the libraries in the right place. > > Microsoft provides something for their dis

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 cannot vary this sett

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

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: [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] From .Fortran to .Call?

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

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

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?

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

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 found

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 [ https://github.com/r-windows/rtools-packages/tree/master/mingw-w6

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: [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 (variable

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

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

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

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

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

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

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

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 apologi

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

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 C

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 on

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] 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, fr

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

[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] 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 https://cran.r-project.org/bi

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

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 tru

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 t

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

[Rd] Failing lm-tests due to extra 0 in scientific notation?

Hello. I've compiled R on Windows many times, and this is the first time I've seen this error. While running make check-all (and using testInstalledBasic("both")), the lm-tests routines fail, and, as far as I can tell, the diff is failing because in one file, answers are coming back like this "3.1

Re: [Rd] Failing lm-tests due to extra 0 in scientific notation?

e reference." I apologize for any unintentional implications. Avi On Wed, Jan 7, 2015 at 1:24 AM, Avraham Adler wrote: > Hello. > > I've compiled R on Windows many times, and this is the first time I've > seen this error. While running make check-all (and using > testI

Re: [Rd] New version of Rtools for Windows

Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr. Murdoch.For reference, I run Windows 7 64bit, and I am trying to build a 64 bit version of R-3.1.2. As we discussed offline

Re: [Rd] New version of Rtools for Windows

ppreciated. Thank you! Avi > -- > On Thu, Jan 8, 2015 2:01 PM GMT Henric Winell wrote: > >>On 2015-01-08 14:18, Avraham Adler wrote: >> >>> Very timely, as this is how I got into the problem I posted about >>> earlier; maybe s

Re: [Rd] New version of Rtools for Windows

The stack probing fix is for passing "make check", when you finish make. > > -- > On Thu, Jan 8, 2015 6:14 PM GMT Avraham Adler wrote: > >>On Thu, Jan 8, 2015 at 10:48 AM, Hin-Tak Leung >> wrote: >>> >>> The r.dll crash is

Re: [Rd] New version of Rtools for Windows

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch wrote: > On 09/01/2015 10:56 AM, Henric Winell wrote: >> On 2015-01-08 02:31, Duncan Murdoch wrote: >> >>> On 07/01/2015 5:20 PM, Jeroen Ooms wrote: On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch wrote: > > This version includes o

Re: [Rd] Request for help with UBSAN and total absense of CRAN response

Hello, Dirk. I have no experience with UBSAN etc., but as you mention not being able to recreate the CRAN errors, it reminds me of the time I had trouble getting my pacakge approved for CRAN as it passed all tets but Win32, and I have a Win64 setup and could not test it. Have you tried submitting

[Rd] Building rinstaller using R-devel (3.2.0-to-be) halts when trying to copy html files

As the build process, especially for Windows, is changing significantly for R 3.2.0, I am trying to build R-devel in preparation. When running `make rinstaller`, I get the following error: cp -p ../../../etc/x64/Makeconf R-devel/etc/x64 mkdir -p R-devel/doc cp -p ../../../doc/CRAN_mirr

Re: [Rd] Building rinstaller using R-devel (3.2.0-to-be) halts when trying to copy html files

On Mon, Jan 26, 2015 at 8:36 PM, Duncan Murdoch wrote: > On 26/01/2015 5:12 PM, Avraham Adler wrote: >> As the build process, especially for Windows, is changing >> significantly for R 3.2.0, I am trying to build R-devel in >> preparation. When running `make rinstaller`

  1   2   >