search for: dgemv

Followup: I have checked my package nleqslv which uses dgemv only from Fortran, on Kubuntu 18.04 with the development version of R. No errors or problems. Berend > On 12 Sep 2019, at 08:57, Berend Hasselman <bhh at xs4all.nl> wrote: > > > I have tried what I proposed in a virtual Kubuntu 18.04 which uses gfortran 7.4. > I used the l...

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

...ns, & antrs, antevents, size, & totsize, eventset, riskset, & nn, antcov, covar, offset, & beta, gamma, & loglik, h1, h2, h11, h21, h22, & score) ..... C call dcopy(nn, offset, ione, score, ione) call dgemv(trans, nn, antcov, one, covar, nn, beta, ione, one, & score, ione) ..... return end ----------------------------------------------------------------- gmlfun is called directly by .Fortran, and in my original code gmlfun was gmlfun1. Now gmlfun is just a wrapper that calls gmlfun1...

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

Sorry for cross-posting, but I realized my question might be more appropriate for r-devel... Thank you, Giovanni ________________________________________ From: R-help <r-help-bounces at r-project.org> on behalf of Giovanni Petris <gpetris at uark.edu> Sent: Tuesday, September 10, 2019 16:44 To: r-help at r-project.org Subject: [R] Calling a LAPACK subroutine from R Hello R-helpers!

...hich uses gfortran 7.4. I used the latest development version of R. It worked just as on macOS. Berend > On 11 Sep 2019, at 22:07, G?ran Brostr?m <goran.brostrom at 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 mis...

...r 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 <goran.brostrom at 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: n...

...an external BLAS. This can be broken if for example the code assumes that terms with a zero factor are always zero and do not need to be computed - whereas x*0 can be NaN. This is checked in the test suite." The version of BLAS that comes with R contains patched versions of DGBMV, DGEMM, and DGEMV. The patch has been in place since 2010. Presumably R blas and reference BLAS have been divergent ever since. I guess this should be reported upstream as a BLAS bug. Recalling the previous thread on openblas, I note that openblas does pass the regression test. Martyn CC: Lejeczek, who reported...

Hello, I am in the process of writing an R extension for parallelized MCMC, with heavy use of compiled code (C++). I have been getting my feet wet by implementing a simple matrix-vector multiplication function in C++ (which calls a BLAS level 2 function dgemv), and comparing it to the '%*%' operator in R (which apparently calls a BLAS level 3 function dgemm). Interestingly, I cannot replicate the performance of the R native operator, using either '.C' or '.Call'. The relative times are 17 (R), 30 (.C), and 26 (.Call). In other w...

...per_numeric.o] ld: Unsatisfied symbol "ztrsm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "dgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "main" in file <no file> ld: Unsatisfied symbol "alloca" in file CHMfactor.o ld: Unsatisfied symbol "dpotrf" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zpotrf&q...

...per_numeric.o] ld: Unsatisfied symbol "ztrsm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "dgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "main" in file <no file> ld: Unsatisfied symbol "alloca" in file CHMfactor.o ld: Unsatisfied symbol "dpotrf" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zpotrf&q...

In my package 'glmmML' I'm using old C code and linpack in the optimizing procedure. Specifically, one part of the code looks like this: F77_CALL(dpoco)(*hessian, &bdim, &bdim, &rcond, work, info); if (*info == 0){ F77_CALL(dpodi)(*hessian, &bdim, &bdim, det, &job); ........ This usually works OK, but with an ill-conditioned data

On 11/09/2019 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: > > <code> > # dummy code to get LAPACK library loaded > X1 <- diag(2,2) > x1 <- rep(2,2) > # X1;x1 > z <-

...IFICANT USER-VISIBLE CHANGES: [...........] * Matrix products now consistently bypass BLAS when the inputs have NaN/Inf values. Performance of the check of inputs has been improved. Performance when BLAS is used is improved for matrix/vector and vector/matrix multiplication (DGEMV is now used instead of DGEMM). One can now choose from alternative matrix product implementations via options(matprod = ). The "internal" implementation is unoptimized but consistent in precision with other summation in R (uses long double accumulators). &...