similar to: compiling R-0.64.0 on DEC osf4.0

Full_Name: Tim Middelkoop Version: 0.64.0 OS: IRIX 6.3 on O2 Submission from: (NULL) (128.119.88.192) Various IRIX complile issues src/nmath/pnt.c IRIX cc does not like double negatives Makeconf,config.site,etc/Makeconf f77 pic hack, should change Makeconf.in or other... change -PIC with -KPIC enjoy, tim... === diff -ru orig/R-0.64.0/src/nmath/pnt.c R-0.64.0/src/nmath/pnt.c ---

(1) ...need to speed up a monte-carlo sampling...any suggestions about how I can get R to use all 8 cores of a mac pro would be most useful and very appreciated... (2) spent the last few hours trying to get pnmath to compile under os- x 10.5.4... using gcc version 4.2.1 (Apple Inc. build 5553) as downloaded from CRAN, xcode 3.0... ...xcode 3.1 installed over top of above after

Hi, Just downloaded the R-0.62.4 of R and tried to install it. With the standard procedure : ./configure make At the end of the compilation I got the following message : ld: ../lib/libunix.a(system.o): main: multiply defined fort: Severe: Failed while trying to link. *** Exit 1 Stop. *** Exit 1 Stop. *** Exit 1 Stop. *** Exit 1 Stop. I attach the printout after the ./configure and make

> > After some intense debugging, I found the problem. One block in > > the file > > triggered a very rare bug in the LPC coefficient quantizer caused > > by > > insufficient floating point precision. There is a snippet to > > compute the > > log(base 2) of a number: > > > > floor(log(cmax) / M_LN2) > > > > It turns out on at

> Also, Kai has been kind enough to send me a copy of his file which > has a > problem only on -8, which I'll be looking into soon. After some intense debugging, I found the problem. One block in the file triggered a very rare bug in the LPC coefficient quantizer caused by insufficient floating point precision. There is a snippet to compute the log(base 2) of a number:

Ok guys, as requested, I will add more info so that you understand why a simple vector operation is not possible. It's not easy to explain in few words but let's see. I have a huge amount of points over a 2D space. I divide my space in a grid with a given resolution,say, 100m. The main loop that I am not sure if it's mandatory or not (any alternative is welcomed) is to go through EACH

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: ---------------------------------------------------------------------- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include

help(qt) states that: "ncp non-centrality parameter delta; currently except for rt(), only for abs(ncp) <= 37.62" so I would expect that calling qt with non-centrality parameter exceeding 37.62 should fail, instead e.g. calling > mapply(function(x) qt(p = 0.9, df = 55, ncp = x),35:45) gives: [1] 40.21448 41.35293 42.49164 43.68862 44.82945 45.97048 47.11170 48.25310 [9]

Hello all, I have a *.csv file that looks like this (actual file is orders of magnitude larger): Site taxa no.ind forest LMA 1 forest LCY 1 forest SCO 1 meadow LMA 2 meadow LCY 1 meadow PNT

Dear list, I have been using the Rmath library for quite a while: in the current instance, I am calling dnt (non-central t density function) repeatedly for several million. When the argument is small, I get the warning message: full precision was not achieved in 'pnt' which is nothing unexpected. (The density calls pnt, if you look at the function dnt.) However, to have this happen a

Hi again ! Thanks for the info on updating the config.site file which I have done. I have also added -lm in the Makeconf manually because this is needed explicitly for DEC cc. However, there are still a few problems when linking some of the files as you can see from the enclosed log. Ciao, Andreas ------------------------------------------------------- R-0.63.3>make make[1]: Entering

I have some slight problems getting R to run smoothly on our alpha... What might be the reason for the following error message? > postscript() Error in PS(file, old$paper, old$family, old$bg, old$fg, old$width, old$height, : unable to start device PostScript I have compiled R-1.1.1 and it starts without complaint. -- +------------------------------------------------------- |

I'm using the 'pnt' C function from Rmath library in some C-code. How can I catch the warning message: "full precision was not achieved in 'pnt'" in R. I call the function using the .C(). (options(warn=-1) didn't work) Thanks in advance -- Maarten van Iterson Center for Human and Clinical Genetics Leiden University Medical Center (LUMC) Research Building,

#include <float.h> should define DBL_MIN and FLT_MIN, as well as DBL_MIN_EXP and FLT_MIN_EXP (such that 10eFLT_MIN_EXP is a valid float) This is a standard header file. But gcc now hides it away (mine was in /usr/lib/gcc-lib/i386-linux/<compiler-version>/include/ ) BTW - any corrections for my surf.chimie.uqam.ca/~kruus/vorbis/ stuff? Erik Kruus <kruus@on2.com> --- >8

I am compiling R-0.90.0 on alpha-dec-osf4.0 and it stops by giving the following message: cc: Error: ../../../R/src/main/gram.y, line 1365: In this declaration, parameter 1 has a different type than specified in an earlier declaration of this function. SEXP mkString(const char *s) -----^ cc: Error: ../../../R/src/main/gram.y, line 1365: In this declaration, the type of "mkString" is not

I am compiling R-0.90.0 on alpha-dec-osf4.0 and it stops by giving the following message: cc: Error: ../../../R/src/main/gram.y, line 1365: In this declaration, parameter 1 has a different type than specified in an earlier declaration of this function. SEXP mkString(const char *s) -----^ cc: Error: ../../../R/src/main/gram.y, line 1365: In this declaration, the type of "mkString" is not

Full_Name: Albrecht Gebhardt Version: 0.90.0 OS: osf4.0 Submission from: (NULL) (143.205.61.73) I had to apply the following patch to be able to compile on an alpha with DU 4.0E: ############################################### --- ./src/main/gram.y.mkString-patch Tue Nov 23 12:16:29 1999 +++ ./src/main/gram.y Tue Nov 23 12:16:59 1999 @@ -56,7 +56,8 @@ SEXP mkFloat(char *); SEXP

This patch allows MSVS to use M_LN2 const defined in math.h -------------- next part -------------- A non-text attachment was scrubbed... Name: mathln2.patch Type: application/octet-stream Size: 963 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130904/14cd34db/attachment.obj

Matt Zimmerman <mdz@debian.org> wrote: > 0.9. As I said, I was using an 8-bit sample, Ah, that didn't quite register with me. I'm using a CD-style 44.1kHz/stereo/16-bit test file. > to avoid dealing with endian issues in the file format. I don't > know whether any of those exist or not. I don't think so. 0.9 works fine on i386 (little) and sparc (big), and

On Sat, May 19, 2001 at 06:42:22PM -0400, Matt Zimmerman wrote: > I think this could be fixed by changing the (data_len > 0) test to be > (data_len > 0 && total_error_X > 0). Yes, this appears to have worked. I can now correctly encode and decode both my 8kHz/8-bit/mono sample, and a 44.1kHz/16-bit/stereo sample on Debian/alpha. Attached is a patch which combines this fix