similar to: calling Lapack and BLAS routines from C

Hi all, I have a C function, say Cfun, that calls Lapack's DGEMM routine and I need to create a shared library to use Cfun inside R. The C file is the following #include<stdio.h> #include<R.h> #include<R_ext/Lapack.h> void Cfun(double *res, double *X, int *n, int *q) { char *ptr_TRANSA, TRANSA='T', *ptr_TRANSB, TRANSB='N'; ptr_TRANSA=&TRANSA;

Dear all, I need to calculate tr(xyxy) fast for matrices x and y. Inspired by the R-source code, I've created the following functions (I am *new* to writing external C-functions, so feel free to laugh at my code - or, perhaps, suggest changes): #include <Rinternals.h> #include <R_ext/Applic.h> /* for dgemm */ static void matprod(double *x, int nrx, int ncx, double *y, int

Not an expert in programming either, but to me it seems like you've forgotten to initialize the variable "tr". It just picks up garbage from allocated memory previously initialized by other processes. Med venlig hilsen Frede Aakmann T?gersen > -----Oprindelig meddelelse----- > Fra: r-help-bounces at stat.math.ethz.ch > [mailto:r-help-bounces at stat.math.ethz.ch] P?

Hi, I was wondering if I could use the matprod function from array.c in my own C routine. I tried the following as a test /* my_matprod.c */ # include <Rinternals.h> /* for REAL, SEXP etc */ # include <R_ext/Applic.h> /* array.c says need for dgemm */ /* following copied from array.c */ static void matprod(double *x, int nrx, int ncx, double *y, int nry, int ncy, double *z)

I have ported some R code to C to make it faster. I can perform .Call("foobar",....) once and it works fine. Absolutely correct answer. If I put a loop inside foobar and run the main code routine more than 100 times, it crashes R. Or if I call .Call("foobar"....) seperately more than two tims it crashes R. For the most part I am doing matirx multiplies using EXP

I've looked at the code for matrix multiplies in R, and found that it can speeded up quite a bit, for multiplies that are really vector dot products, and for other multiplies in which the result matrix is small. Here's my test program: u <- seq(0,1,length=1000) v <- seq(0,2,length=1000) A2 <- matrix(2.1,2,1000) A5 <- matrix(2.1,5,1000) B3 <- matrix(3.2,1000,3) A4 <-

Tim Northover wrote on 06/19/2018 08:54 PM: >>> Why are you passing that argument in the first place? The compiler >>> completely ignores it. >> >> CLS stands for cacheline size. It is an important parameter >> for optimization of the generated code, at least with gcc/g++. >> -DCLS=n should have the same importance like for example -DNDEBUG. > > The

On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <brucehoult at sifive.com> wrote: > Furthermore .. in the articles you reference, the -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) is passed when compiling the user's program -- one doing extensive blocked matrix operations -- and not when building the *compiler*. It's worse. At least in the first case, the code looks like it wouldn't even

Hello, I am trying to profile a function of OpenMx (http://openmx.psyc.virginia.edu) for CPU time. My operating system is OS X 10.10. OpenMx contains C++ and Fortran code. I have read the section regarding profiling compiled code in the manual (https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Profiling-compiled-code). This section and this post (http://blog.fellstat.com/?p=337)

Hi, I'm just following your messages the overhead that the code for dealing with possible NA/NaN values brings. When I was setting up part of the matrixStats package, I've also though about this. I was thinking of having an additional logical argument 'hasNA'/'has.na' where you as a user can specify whether there is NA/NaN:s or not, allowing the code to avoid it or not.

Tim Northover via llvm-dev wrote on 06/19/2018 07:55 PM: > On Tue, 19 Jun 2018 at 18:22, U.Mutlu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I think such "reserved" names like CLS that can be passed to the compiler(s), >> should be avoided as identifiers for naming variables, constants, enum >> members, macros etc. > > Why are you passing

hello, I create a package which includes C code and Lapack. But when I run " R CMD check ". an error message, "/usr/bin/ld: cannot find -lfrtbegin " occurs. could you tell me what is the problem? the detailed message is as follows: [credsim@confsys ~/src]$ R CMD check var * checking for working latex ... OK * using log directory '/home/credsim/src/var.Rcheck' *

hello, everybody, I create a package by myself named "var" on Linux system. I attach a C code which uses "R_ext/Lapack.h" in directory "src". But when I carry out " R CMD check var", it shows > wxt0124() Error in .C("wxt1221", PACKAGE = "var") : C function name not in DLL for package var Execution halted Could you tell me what is

Hello all, I tryied to use the disconnect time policy using NT usrmgr, but it didn't work. Does anyone have a clue? Thanks Using: Debian 3.0 Kernel 2.4,27 Samba 3.0.22 Ldap 2.1.30-2 -- ___________________________________________________________________________________________________ Atenciosamente, Daniel Felipe Martin GetNet - Tecnologia em Captura e Processamento de Transa??es

This is not the correct group to post this question. Sorry, but I subscribe nowhere else. What is the BLAS routine to multiply a matrix by a scalar? Thanks. -- Mehmet Balcilar, PhD Assistant Professor Manas University College of Economics & Administrative Sciences Department of Economics Prospect Tinctik 56 Bishkek Kyrgyzstan Tel: +996 (312) 54 19 42 +996 (312) 54 19 43 +996

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

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

In practical terms, failing tests are not preventing anyone from using an optimized BLAS/LAPACK implementation they trust. Building R with dynamically linked BLAS on Unix is supported, documented and easy for anyone who builds R from source. It is also how Debian/Ubuntu R packages are built by default, so R uses whichever BLAS is installed in the system and the user does not have to build

I'd like to build R using my optimized blas and lapack libraries. It seems know matter what I do, the configure script uses the blas supplied with the source. My blas and lapack libraries are in /usr/local/atlas/lib. How can I get configure to use these? [[alternative HTML version deleted]]

Hello, This simple SVD calculation (commands are copied immediately below) crashes on my Ubuntu machine (R 2.13.0). However it worked fine with R.12 and Ubuntu 10.04, and it also works fine on my Windows 7 machine with R 2.13, so I suspect there's a problem with (my?) Ubuntu and / or R. I'm using the R distribution that is accessible with Ubuntu's repositories manager, I am not