similar to: Bug in seq() (PR#13849)

Hi everyone, I've tried the below on R 1.9.1 and the 2004-08-30 builds of R 1.9.1 Patched and R 2.0.0 on Windows 2000, and the results are consistent. > seq(0.5, 0, by = -0.1) [1] 0.5 0.4 0.3 0.2 0.1 0.0 > seq(0.7, 0, by = -0.1) [1] 7.000000e-01 6.000000e-01 5.000000e-01 4.000000e-01 3.000000e-01 2.000000e-01 1.000000e-01 -1.110223e-16 Is this really the intended behaviour?

I came across this: shouldn't the last value be a more exact zero? It did not do that with 1 - sum( rep(0.1, 10) ) > 1 - cumsum( rep(0.1, 10) ) [1] 9.000000e-01 8.000000e-01 7.000000e-01 6.000000e-01 5.000000e-01 4.000000e-01 3.000000e-01 2.000000e-01 [9] 1.000000e-01 1.110223e-16 > version _ platform

Hello everyone, I am using the following program to get the p-value of some numbers (column 'LR' of the data.dat file). I want to write the 1st and 2nd column of the output file (data.out) as an integer while the program change them. Could anybody please tell me how I can write the code which writes the values of the first two columns as integer? For your convenience, I have attached the

Hi, I'm having trouble with the "which" or the "seq" function, I'm not sure. Here's an example : > lat=seq(1,2,by=0.1) > lat [1] 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 > which(lat==1) [1] 1 > which(lat==1.1) [1] 2 > which(lat==1.2) [1] 3 > which(lat==1.3) [1] 4 > which(lat==1.4) [1] 5 > which(lat==1.5) [1] 6 >

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

I have the following output from pretty(): > pretty(c(-.1, 1)) # note 2nd element [1] -2.000000e-01 -2.775558e-17 2.000000e-01 4.000000e-01 6.000000e-01 [6] 8.000000e-01 1.000000e+00 > as.character(pretty(c(-.1, 1))) [1] "-0.2" "-2.77555756156289e-17" "0.2" [4] "0.4" "0.6"

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hello, I'm working on using the LLVM JIT for a little project of mine, amazing work first off! I have a question about optimization passes. I initially have this function I've created, in python it looks like this: OS_end = 50OS_start = 0OS_timestep = 1birth_rate = .3population = 30.0for time in range(OS_start, OS_end, OS_timestep): births = birth_rate * population deaths = 0.1

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but

Hi Brent, Looking at your code I can see at least one reason why some of the store operations remain in the output since you are (through x, y, and z) writing in memory which exists outside of your function (p). Constant propagation also seems to work in the first few lines, *y = *x +1 (%3) is stored directly. The strange thing to me is that the same doesn't happen for *z = *x + 2. Here

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

Hi everyone, I have a simple problem but don´t know how to solve it. I read in a table from a text file that looks like that: -3,932200E-01 -2,000000E-01 4,999995E-02 -3,932099E-01 -1,000000E-01 3,999996E-02 -3,932000E-01 0,000000E+00 3,999996E-02 -3,931899E-01 -1,000000E-01 4,499996E-02 -3,931800E-01 -1,000000E-01 4,499996E-02 -3,931699E-01

Hi LLVMers, I would like to ask a question regarding aliasing. Suppose I have the following program: double f(double** p ) { double a,b,c; double * x = &a; double * y = &b; double * z = &c; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } LLVM can tell that the three pointers do not alias each other so can perform the constant folding at compile time.

Hello! I have two matrices of equal dimension ll and lu that I want to do a ks.test on corresponding rows in these matrices (dim(ll) is [1] 101 100). If I do e.g. > ks.test(ll[50,],lu[50,]) just for testing, it displays a lot of numbers, and some more info: [116] -3.000000e-02 -4.000000e-02 -4.000000e-02 -3.000000e-02 -4.000000e-02 [121] -3.000000e-02 -4.000000e-02 -3.000000e-02 -2.000000e-02

Hi all, R> seq(-.4, .8, length=7) [1] -4.000000e-01 -2.000000e-01 5.551115e-17 2.000000e-01 4.000000e-01 [6] 6.000000e-01 8.000000e-01 Well that may not be a "bug", but it has this unfortunate consequence: R> pretty(c(-.4,.8)) [1] -4.000000e-01 -2.000000e-01 5.551115e-17 2.000000e-01 4.000000e-01 [6] 6.000000e-01 8.000000e-01 And thus my plot axes look funny

Full_Name: Martha Nason Version: 2.0.1 OS: Windows XP Submission from: (NULL) (137.187.154.154) I am running simulations using fisher's test on 2 x c tables and a very small p.value from fisher's test (<2.2e-16) is returned as a negative number. Code follows. > set.seed(0) > nreps.outer <-7 > pvalue.fisher <- rep(NA,nreps.outer) > > population1 <- c(