similar to: random NaN in dpotri result

This isn't the help list for LAPACK, but as far as I can tell, dppsv expects a symmetric matrix input compacted as triangular, not a Choleski decomposed one. So try assigning lmat before the call to dpotrf. -pd > On 20 Dec 2014, at 22:06 , Pierrick Bruneau <pbruneau at gmail.com> wrote: > > Dear R contributors, > > Considering the following sample C code, that

Dear R contributors, Considering the following sample C code, that illustrates two possible uses of a Cholesky decomp for inverting a matrix, equally valid at least in theory: SEXP test() { int d = 2; int info = 0; double mat[4] = {2.5, 0.4, 0.4, 1.7}; double id[4] = {1.0, 0.0, 0.0, 1.0}; double lmat[3]; F77_CALL(dpotrf)("L", &d, mat, &d, &info); lmat[0] = mat[0]; lmat[1]

I give up. Maybe it is my search (Windows) but I cannot seem to find the definition of the F77_CALL or F77_NAME macros. Either there are too many matches or the search just doesn't find it. For example where is the source for: F77_CALL(dpotri) ? Thank you. Kevin

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 10 Feb 2017, at 14:53, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > Thanks to all who answered my third question. I learned something, but: > > On 2017-02-09 17:44, Martin Maechler wrote: >> >>>> On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: >>>> >>>> In my package 'glmmML'

I'm using .Call() to call C code from R under Windows (on an Intel Core 2 duo). The C code involves some very small numbers, and I think I'm losing precision using doubles. I thought I might use long doubles to see if I can get that precision back. I have a few questions: 1. Does this affect the portability to other OSs or processors? 2. I'm returning the results in a matrix. Will

> On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > 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,

Thanks to all who answered my third question. I learned something, but: On 2017-02-09 17:44, Martin Maechler wrote: > >>> On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: >>> >>> 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:

> > On 9 Feb 2017, at 16:00, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > > > 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){ > >

Hi, I am working on a UNIX machine and I am interfacing R and C with the .C function. I am trying to call LAPACK and BLAS routines, but am running into a problem where, while I am able to run the BLAS routines, I cannot run the LAPACK routines. I compile my .c file (at end of email) in the following way: [mhitczen at jlogin2 ~/Cstuff]$ R CMD SHLIB testmore.c gcc -std=gnu99

Hi all, im triyng to implement a bayesian model with R and c++. I have a strange problem. I can't reproduce the error with a small script and then i post the original one. The problem is after the line for(MCMC_iter2=0;MCMC_iter2<thin;MCMC_iter2++) For the first 34 iterations all work fine, after, all the simulations of mu_acc_P return an "nan". If i delete the line

Full_Name: Hao Yu Version: 1.4.1 OS: Windws and Linux Submission from: (NULL) (129.100.45.161) Hi, Recently we did some benchmarks regarding matrix inverse operation and found some strange things. See the following results (the package Matrix is most updated). 1. load the function Toeplitz and library(Matrix) "Toeplitz" function(x) { matrix(x[1 + abs(outer(seq(along = x),

Hello all. I'm developing a package for R holding a Gibbs sampler, which tends to have better performance when written in C than in R. During each iteration in the Gibbs sampler, I need the inverse of a symmetric matrix. For this, I wish to use lapack, as is concisely suggested in "Writing R extensions", since this will have better performance than I could ever write myself. After

Dear All, I have just updated R to the version 2.6.2 on F8 (with the official F8 rpm). However, when running as root the following command: update.packages(checkBuilt=T) I get a bunch of errors like the ones below. Any ideas? Thanks in advance, Paul ----------------------------------------------- * Installing *source* package 'nlme' ... ** libs gcc -m32 -std=gnu99 -I/usr/include/R

Hi all, I'm working out some Fortran code for which I want to compute the Choleski decomposition of a covariance matrix in Fortran. I tried to do it by two methods : 1) Calling the lapack function DPOTRF. I can see the source code and check that my call is correct, but it does not compile with: system("R CMD SHLIB ~/main.f") dyn.load("~/main.so") I get: Error in

Hi I am new to writing C code and am trying to write an R extension in C. I have hit a wall with F77_CALL(dgemm) in that it produces wrong results. The code below is a simplified example that multiplies the matrices Ab and Bm to give Cm. The results below show clearly that Cm is wrong. Am= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Bm= 1 1 1 1 1

r-devel list, I have recently written an R package that solves a linear least squares problem, and computes the multivariate normal density function. The bulk of the code is written in C, with interfacing code to the BLAS and Lapack libraries. The motivation here is speed. I ran into a problem computing the determinant of a symmetric matrix in packed storage. Apparently, there are no explicit

This is a multipart message in MIME format. --=_alternative 00812CFCCA256D66_= Content-Type: text/plain; charset="us-ascii" Two points in respect to PR#2867. First, the trivial one: (1) In Lapack.c, on lines 806 and 812, there are calls of F77_CALL(dgeqp3). But the error messages on lines on lines 809 and 815 refer to "dqeqp3", i.e., they currently have a "q"

Dear all, I am trying to compile R version 1.0.1 under Solaris on a SUNsparcUltra10. Note that I'm doing this in my home directory as I cannot do it as root. The configure script seems to run correctly and issues as the last few lines: ----------------------------------------------- ... R is now configured for sparc-sun-solaris2.7 Source directory: . Installation directory:

On 2020-07-15 14:36, Dirk Eddelbuettel wrote: > > G?ran, > > This is not an easy email to reply to because it _contains nothing > reproducible_. Thanks Dirk, Sorry about that, but my real question was (see below): "Is the problem that openblas uses C versions of blas?" That is, do I need to change F77_CALL(name)(...); to cblas_name(...); everywhere? And if so, is