similar to: The old Fortran underscore problem

Dear R Developers, I should have had the Design library running in R by now but have kept putting off changing some calls to LINPACK routines to use those builtin to R. Specifically I call dqrsl1 and dqr. Would it be an easy task to put those in the next release of R? If not I'll finally bite the bullet and get back into reading LINPACK documentation (which I have but haven't examined

Hi everybody. I'm studying the Harrell's book on regression modeling strategies, and I'd like to replicate the examples using R (instead of S+). So how's going the porting of the hmisc and design libraries? Are there available, though in beta version? TIA, Stefano Calza -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read

Hello, I'm trying to install a package that requires a Fortran compiler (Hmisc) using R CMD INSTALL. I downloaded the package source onto my Desktop, unzipped it, and then typed: R CMD INSTALL /Users/brianbeckage/Desktop/Hmisc * Installing *source* package 'Hmisc' ... ** libs g77 -fno-common -g -O2 -c cidxcn.f -o cidxcn.o g77 -fno-common -g -O2 -c cidxcp.f -o cidxcp.o g77

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

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

Dear developers, I am trying to reproduce the results of applying opt -O3 to a source file in the form of LLVM IR. I want to get the same IR by manually ordering the passes used by O3 and passing them to opt. To illustrate what I am doing on an example, as an input I use linpack benchmark from the LLVM test suite[1]: 1. First I produce the intermediate representation using clang: clang -O3

I think this has to do with how the pass manager is populated when we give -O3 vs when we give particular pass names. Some passes have multiple createXYZPass() methods that accept arguments too. These methods call non-default pass constructors, which in turn cause the passes to behave in a different manner. eg: Pass *llvm::createLICMPass() { return new LegacyLICMPass(); } Pass

The first one failed on a diff: ******************** TEST (simple) 'sse.expandfft' FAILED! ******************** Execution Context Diff: /home/rkotler/llvmpb3/build/projects/test-suite/tools/fpcmp: Compared: 1.139094e-07 and 1.159249e-07 abs. diff = 2.015500e-09 rel.diff = 1.738626e-02 Out of tolerance: rel/abs: 1.600000e-02/0.000000e+00 ******************** TEST (simple)

I'm getting three failures. TEST-FAIL: exec /home/rkotler/llvmpb3/build/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft TEST-RESULT-exec-time: user 0.3200 TEST-RESULT-exec-real-time: real 0.3172 TEST-FAIL: exec /home/rkotler/llvmpb3/build/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.stepfft TEST-RESULT-exec-time: user 0.4000

man for `qr` says that the function uses LINPACK's DQRDC, while it in fact uses DQRDC2. ``` The QR decomposition of the matrix as computed by LINPACK or LAPACK. The components in the returned value correspond directly to the values returned by DQRDC/DGEQP3/ZGEQP3 ```

Hello. I am trying to invert a matrix, and I am finding that I can get different answers depending on whether I set LAPACK true or false using "qr". I had understood that LAPACK is, in general more robust and faster than LINPACK, so I am confused as to why I am getting what seems to be invalid answers. The matrix is ostensibly the Hessian for a function I am optimizing. I want to get

I'm probably misunderstanding something in "Writing R Extensions" version 1.0.0. In the chapter on the R API, section 4.7, it is stated that the functions listed in R_ext/Linpack.h are available to users' Fortran code. I am developing a developing a library of ode solvers, based on lsoda and ddassl, and which in turn call some routines from linpack and double precision blas. I

Ordinary functions should not alter their inputs but in R-2.15.2 svd(LINPACK=TRUE,X) does. (It worked in 2.15.0 but not in 2.15.1 or 2.15.2 and became deprecated in 2.15.2.) > X <- matrix(c(1,2,3, 5,7,11, 13,17,19), 3, 3) > X [,1] [,2] [,3] [1,] 1 5 13 [2,] 2 7 17 [3,] 3 11 19 > svd(X, LINPACK=TRUE)$d [1] 31.9718214 2.3882717 0.3143114 Warning message:

I have a series of question about methods and generics. The questions are interspersed in some text which explains what I want to do, how it works now and why I do not understand well why it works. Questions are written Q1 and so on up to Q9 and always start a new line. The concrete problem is this: it has become customary after a meta-analysis to quote various statistics to give a picture of the

I forgot to mention that you can also run "make TEST=simple report" which will generate a nice report. Do you know why these tests fail ? You can step into the test directory and run 'make TEST=simple' from there. It will save you some time. On Dec 12, 2012, at 4:04 PM, reed kotler <rkotler at mips.com> wrote: > I'm getting three failures. > > TEST-FAIL:

when I create the report, there are no failures in it. so maybe these are being filtered for known failures. On 12/12/2012 05:03 PM, reed kotler wrote: > The first one failed on a diff: > ******************** TEST (simple) 'sse.expandfft' FAILED! > ******************** > Execution Context Diff: > /home/rkotler/llvmpb3/build/projects/test-suite/tools/fpcmp: Compared: >

Under Ubuntu dapper, after installing packages gcc and g77, under platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 2.1 year 2005 month 12 day 20 svn rev 36812 language R I get an error when trying to update.packages('Hmisc'): gcc -I/usr/lib/R/include -fPIC -g -O2 -c ranksort.c -o ranksort.o In file included

I use the 'make TEST=simple' as a pre-commit test. I think that everybody should run these tests before committing to LLVM. On Dec 12, 2012, at 5:06 PM, reed kotler <rkotler at mips.com> wrote: > when I create the report, there are no failures in it. so maybe these are being filtered for known failures. > > On 12/12/2012 05:03 PM, reed kotler wrote: >> The first

Just after R-0.63.0 came out I reported a problem to the list. I was unable to get ./configure to complete it's job, because it couldn't find a working fortran. It stopped after trying to test for underscore in subroutine names. This was especially perplexing, since I could still configure the older version (I had 62.2) with no error messages. I tried suggestions of B.D. Ripley and