similar to: svd(X, LINPACK=TRUE) alters its input

Full_Name: Pierre Legendre Version: 2.1.1 OS: Mac OSX 10.4.3 Submission from: (NULL) (132.204.120.81) I am reporting the mis-behaviour of the function 'eigen' in 'base', for the following input matrix: A <- matrix(c(2,3,4,-1,3,1,1,-2,0),3,3) eigen(A) I obtain the following results, which are incorrect for eigenvalues and eigenvectors 2 and 3 (incorrect imaginary portions):

Hello, Like QR decomposition, I am looking for decomposition to get U and V matrix of SVD decomposition (according to LINPACK, X = UDV'). Do you know if there is a function which could calculate this decomposition? Look forward to your reply, Haleh

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

Hi, I understand that the glm.fit calls LINPACK fortran routines instead of LAPACK because it can handle the 'rank deficiency problem'. If my data matrix is not rank deficient, would a glm.fit function which runs on LAPACK be faster? Would this be worthwhile to convert glm.fit to use LAPACK? Has anyone done this already?? What is the best way to do this? I'm looking at very

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

After fixing princomp(), recently, {tiny negative eigen-values are possible for non-negative definite matrices} Fritz Leisch drew my attention to the fact the not only eigen() can be funny, but also svd(). Adrian Trappleti found that the singular values returned can be "-0" instead of "0". This will be a problem in something like sd <- svd(Mat) $ d

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

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

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

Lately I'm getting this error quite a bit: Error in La.svd(x, nu, nv) : error code 1 from Lapack routine 'dgesdd' I'm running R 2.5.0 on a 64 bit Intel machine running Fedora (8 I think). Maybe the 64 bit platform is more fragile about declaring convergence. I'm seeing way more of these errors than I ever have before. From R-Help I see that this issue comes up from time to

What''s the best way to go about writing a generator that can add text into an existing file? The point in the file is marked with a unique token, I want to insert a few lines after the line with the token on it. Is this possible/easy/already done by someone? Thanks

Thanks; definitely a bug. I've submitted it to the bug tracker at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17831 Best, luke On Mon, 15 Jun 2020, Raimundo Neto wrote: > Dear R developers, > > I've run into a weird behavior of the numericDeriv function (from the stats > package) which I also posted on StackOverflow (question has same title as > this email,

Hi, I was stumped by this. The two S4 objects below looked exactly the same: > a1 An object of class "A" Slot "aa": integer(0) > a2 An object of class "A" Slot "aa": integer(0) > str(a1) Formal class 'A' [package ".GlobalEnv"] with 1 slots ..@ aa: int(0) > str(a2) Formal class

Dear R developers, I've run into a weird behavior of the numericDeriv function (from the stats package) which I also posted on StackOverflow (question has same title as this email, except for the version of R). Running the code bellow we can see that the numericDeriv function gives an error as the derivative of x^a wrt a is x^a * log(x) and log is not defined for negative numbers. However,

Dear all As far as I could trace, looking at the function C function numeric_deriv, this unwanted behavior comes from the inner most loop in, at the very end of the function, for(i = 0, start = 0; i < LENGTH(theta); i++) { for(j = 0; j < LENGTH(VECTOR_ELT(pars, i)); j++, start += LENGTH(ans)) { SEXP ans_del; double origPar, xx, delta; origPar = REAL(VECTOR_ELT(pars, i))[j];

#I am trying to understand how R fits models for contrasts in a #simple one-way anova. This is an example, I am not stupid enough to want #to simultaneously apply all of these contrasts to real data. With a few #exceptions, the tests that I would compute by hand (or by other software) #will give the same t or F statistics. It is the contrast estimates that R produces #that I can't seem to

Dear R-help members, Apologies - I am posting on behalf of a colleague, who is a little puzzled as STATA and R seem to be yielding different survival estimates for the same dataset when treating a variable as ordinal. Ordered() is used to represent an ordinal variable) I understand that R's coxph (by default) uses the Efron approximation, whereas STATA uses (by default) the Breslow. but we