similar to: A limitation for polyroot ? (PR#880)

Hi, All: Is there a simple way to detect complex conjugates in the roots returned by 'polyroot'? The obvious comparison of each root with the complex conjugate of the next sometimes produces roundoff error, and I don't know how to bound its magnitude: (tst <- polyroot(c(1, -.6, .4))) tst[-1]-Conj(tst[-2]) [1] 3.108624e-15+2.22045e-16i

I'd just like to report a possible R bug--or rather, confirm an existing one (bug #751). I have had some difficulty using the polyroot() function. For example, in Win 98, R 1.1.1, > polyroot(c(2,1,1)) correctly (per the help index) gives the roots of 1 + (1*x) + (2*x^2) as [1] -0.5+1.322876i -0.5-1.322876i However, > polyroot(c(-100,0,1)) gives the roots of [1] 10+0i -10+0i

I have found that the polyroot() function in R-1.1.1(both solaris and Win32 version) gives totally incorrect result. Here is the offending code: # Polyroot bug report: # from R-1.1.1 > sort(abs(polyroot(c(1, -2,1,0,0,0,0,0,0,0,0,0,-2,5,-2,0,0,0,0,0,0,0,0,0,1,-2,1)))) [1] 0.8758259 0.9486499 0.9731015 1.5419189 1.7466214 1.7535362 1.7589484 [8] 2.0216317 2.4421509 2.5098488 2.6615572

In a bug report from Nov.28 2000, Li Dongfeng writes: ----- I have found that the polyroot() function in R-1.1.1(both solaris and Win32 version) gives totally incorrect result. Here is the offending code: # Polyroot bug report: # from R-1.1.1 > sort(abs(polyroot(c(1,-2,1,0,0,0,0,0,0,0,0,0,-2,5,-2,0,0,0,0,0,0,0,0,0,1,-2)))) [1] 0.8758259 0.9486499 0.9731015 1.5419189 1.7466214 1.7535362

Dear useRs, I need to compute zero of polynomial function fitted by lm. For example if I fit cubic equation by fit=lm(y~x+I(x^2)+i(x^3)) I can do it simply by polyroot(fit$coefficients). But, if I fit polynomial of higher order and optimize it by stepAIC, I get of course some coefficients removed. Then, if i have model y ~ I(x^2) + I(x^4) i cannot call polyroot in such way, because there is

Is there an easy way to compare complex numbers? Here is a small example: > (z1=polyroot(c(1,-.4,-.45))) [1] 1.111111-0i -2.000000+0i > (z2=polyroot(c(1,1,.25))) [1] -2+0i -2+0i > x=0 > if(any(identical(z1,z2))) x=99 > x [1] 0 # real and imaginary parts: > Re(z1); Im(z1) [1] 1.111111 -2.000000 [1] -8.4968e-21 8.4968e-21 > Re(z2); Im(z2) [1] -2

[I thought I'd submitted this bug report some time ago, but it's never showed up on the bug tracking system, so I'm submitting again.] qr.solve() gives incorrect results when dealing with complex matrices or with qr objects that have been computed with LAPACK=TRUE, whenever the b argument has more than one column. This bug flows from qr.coef(), which has a similar problem. I believe

If I have matrics as follows: > a <- c(1,1,0,0) > b <- c(4,4,0,0) > c <- c(3,5,5,6) How can I use R code to solve the equation ax^2+bx+c=0. thanks! yuying shi [[alternative HTML version deleted]]

Hi, I'm responding to a post about finding roots of a cubic or quartic equation non-iteratively. One obviously could create functions using the explicit algebraic solutions. One post on the subject noted that the square-roots in those solutions also require iteration, and one post claimed iterative solutions are more accurate than the explicit solutions. This post, however, is about

El problema del módulo es que pierde el signo. En tu caso sale igual porque has invertido el signo del coeficiente en el polinomio (en realidad se me pasó a a mí advertir que el término independiente debe ir con signo negativo): .> polyroot(z=c(0.5,0,0,0,0,1)) [1] 0.7042902+0.5116968i -0.2690149+0.8279428i -0.2690149-0.8279428i [4] 0.7042902-0.5116968i -0.8705506+0.0000000i .> .>

On two laptops running 32-bit kubuntu, I have found that svd(), invoked within R 2.9.1 as supplied with the current ubuntu package, returns very incorrect results when presented with complex-valued input. One of the laptops is a Dell D620, the other a MacBook Pro. I've also verified the problem on a 32-bit desktop. On these same systems, R compiled from source provides apparently

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

Mirando los comentarios, realmente lo que deseo es encontrar la raíz real de (-0.5)^(1/5) la cual debería ser -0.87055056329. José me hace caer en cuenta que además de no encontrar la raiz real, tampoco da todas las raiz complejas. Habría alguna manera de que tuviera en cuenta? > ------------------------------ > > Message: 6 > Date: Thu, 15 Oct 2015 11:25:39 +0200 > From: José

Dear R people: Is there a way to perform simple polynomial multiplication; that is, something like (x - 3) * (x + 3) = x^2 - 9, please? I looked in poly and polyroot and expression. There used to be a package that had this, maybe? thanks, Erin -- Erin Hodgess Associate Professor Department of Computer and Mathematical Sciences University of Houston - Downtown mailto: erinm.hodgess at

To R-helpers, R offers the polyroot function for solving mentioned equations iteratively. However, Dr Math and Mathworld (and other places) show in detail how to solve mentioned equations non-iteratively. Do implementations for R that are non-iterative and that solve mentioned equations exists? Regards, Mads Jeppe

Here is a relatively simple script (with comments as to the logic interspersed): # Some of these libraries are probably not needed here, but leaving them in place harms nothing: library(tseries) library(xts) library(quantmod) library(fGarch) library(fTrading) library(ggplot2) # Set the working directory, where the data file is located, and read the raw data

Should both parts of a complex number be printed to the same precision? The imaginary part of 0 looks a bit odd when log10(real/imag) >=~ getOption("digits"), but I'm not sure it is awful. Some people might expect the same number of significant digits in the two parts. > 1e7+4i [1] 10000000+0i > 1e7+5i [1] 10000000+0i > 1e10 + 1000i [1] 1e+10+0e+00i >

Hi, > 1e10+5i [1] 1e+10+0e+00i > Im(1e10+5i) [1] 5 maybe little better... --- R-3.5.1.orig/src/main/complex.c 2018-03-26 07:02:25.000000000 +0900 +++ R-3.5.1/src/main/complex.c 2018-07-10 12:50:42.523874767 +0900 @@ -381,6 +381,7 @@ r->i = fround(pow10 * x->i, digits)/pow10; } else { digits = (double)(dig); + if(digits < 1) digits=1; /* a little better */

Hi, with small matrices eigen works as expected: > eigen(cbind(c(1,4),c(4,7)), only.values = TRUE) $values [1] 9 -1 $vectors NULL > eigen(cbind(c(1,4),c(4,7))) $values [1] 9 -1 $vectors [,1] [,2] [1,] 0.4472136 -0.8944272 [2,] 0.8944272 0.4472136 > eigen(cbind(c(1,-1),c(1,-1))) $values [1] -3.25177e-17+1.570092e-16i -3.25177e-17-1.570092e-16i $vectors

Full_Name: Kirk Hampel Version: 2.4.1 OS: Windows Submission from: (NULL) (144.53.251.2) Given an AR(p) model, the last p SE's are wrong. The source of the bug is that the C code (ver 2.4.0) assumes *npsi is the length of the psi vector (which is n+p), whilst the predict.ar function in R passes out as.integer(npsi), where npsi <- n-1. Some R code following reproduces the error. Let p=4,