similar to: make check on DU4 with R-1.1.0 snapshot

Hi, I just run a ./configure --enable-R-shlib; make; make check; with a recent (11.6.2001) R-devel snapshot on Tru64 4.0F (with libcxml): make check stops in base-Ex.R at: > ###--- >>> `plot.window' <<<----- Set up World Coordinates for Graphics Window> > ## alias help(plot.window) > > ##___ Examples ___: > > ##--- An example for the use

[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

I was reading the API reference for the libvirt, when I came across the function? virDomainMigrate and virDomainMigrate2. I am unable to find the difference between the two. Can someone please tell the difference in the application of the two? -- Abhishek

Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.000000e+00 1.253990e-201 1.589622e-171

Hello, I would like to ask what I am doing  wrong and what is the best approach to resolve this situation: First of all I start virtual machine by virDomainCreateXML. In my application I use libvncclient library that sends mouse events to this running domain. I had some troubles with coordinates of mouse cursor but all problem was solved when I added <input type='tablet'

I've now done two rebuilds of R-1.7.0 on NetBSD 1.6, one with the --without-zlib configure option, and one without. Both builds use the recently-installed gcc-3.2.3 compiler. As before, the one built normally gets a segment violation, whereas the one built with the --without-zlib option works. The odd thing is that neither uses shared libraries for zlib: % ldd /usr/local/lib/R/bin/R.bin

Using the 64-bit Solaris compilers make check dumps core in La_rs at 73 F77_CALL(dsyev)(jobv, uplo, &n, rx, &n, rvalues, work, &lwork, &info); I can't reproduce it easily, but example(eigen) occasionally stops with Error: abs(sm - V %*% diag(lam) %*% t(V)) < 60 * Meps is not TRUE which might be connected. The tiny rounding errors in example(eigen) aren't

hi all- I am doing some research, have never used R before until today and need to understand the following program for a project. if some one could PLEASE help me understand this program ASAP i would GREATLY appreciate it (any syntax/ statistic comments would be great) PLEASE PLEASE HELP!! THANKYOU!!! -on a side note, it seems to me that R doesnt include the pv, and it was calculated

On 12-Feb-06 benphalan at gmail.com wrote: > Full_Name: Ben Phalan > Version: 2.2.1 > OS: Win XP > Submission from: (NULL) (131.111.111.231) > > > I have noticed that floor returns the wrong number when there are more > than 15 > decimal places: > >> floor(6.999999999999999) > [1] 6 >> floor(6.9999999999999999) > [1] 7 > > There is a

Dear R-devel, [I'm not sure if this is appropriate for R-devel. If not, I'm more than happy to move it to R-help.] As those of you who saw my post on R-help know, I've been trying to build R-patched on a dual Opteron box running Scyld Beowulf, using the PGI 6.1 compilers. The build went fine, but I couldn't get it to pass make check-all. Jennifer Lai, who reported success with

I am attaching a patch to R-0.63's configure.in file which will enable R to detect and use some special math libraries on linuxppc and mklinux. The patch provides tests for these libraries and enable/disable switches for them as well. One library is the libmoto math library which must be used in conjunction with libm (it only replaces some of libm's functions). The other is a RISC

I am attaching a patch to R-0.63's configure.in file which will enable R to detect and use some special math libraries on linuxppc and mklinux. The patch provides tests for these libraries and enable/disable switches for them as well. One library is the libmoto math library which must be used in conjunction with libm (it only replaces some of libm's functions). The other is a RISC

Zapping a vector of small numbers to zero would cause problems when printing the results of summary(). For example, if zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then print(summary(2.220446e-16), digits = 7) would print Min. 1st Qu. Median Mean 3rd Qu. Max. 0 0 0 0 0 0 The same problem can also appear when

Isn?t that the correct outcome? The user can change the number of digits if they want to see small values? -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On Dec 17, 2023, at 12:11?AM, Steve Martin <stevemartin041 at gmail.com> wrote: > > ?Zapping a vector of small numbers to zero would cause problems when > printing the results of summary().

I was quite suprised to discover that applying `zapsmall` to a scalar value has no apparent effect. For example: > y <- 2.220446e-16 > zapsmall(y,) [1] 2.2204e-16 I was expecting zapsmall(x)` to act like > round(y, digits=getOption('digits')) [1] 0 Looking at the current source code, indicates that `zapsmall` is expecting a vector: zapsmall <- function (x, digits =

Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > I think what's been missed is that zapsmall works relative to the absolute > largest value in the vector. Hence if there's only one > item in the vector, it is the largest, so its not zapped. The function's > raison d'etre isn't to replace absolutely small values, > but small values relative to the largest.

>>>>> Serguei Sokol via R-devel >>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: >> I think what's been missed is that zapsmall works relative to the absolute >> largest value in the vector. Hence if there's only one >> item in the vector, it is the largest, so its

--=-=-= Included below are: 1) Diffs to to remove HDF5 from R 2) Diffs to pass thru --with-* options to a module's configure script during "R INSTALL". (To reiterate a plea for this capability...) This applies only to Unix, the Windows (mingw32 in my case) build approach of passing in make variables like *-CFLAGS and *-LDFLAGS works fine. The only hitch

Le 18/12/2023 ? 11:24, Martin Maechler a ?crit?: >>>>>> Serguei Sokol via R-devel >>>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > >> I think what's been missed is that zapsmall works relative to the absolute > >> largest value in the vector. Hence if

I think what's been missed is that zapsmall works relative to the absolute largest value in the vector. Hence if there's only one item in the vector, it is the largest, so its not zapped. The function's raison d'etre isn't to replace absolutely small values, but small values relative to the largest. Hence a vector of similar tiny values doesn't get zapped. Maybe the line