similar to: bug in pretty() (PR#1032)

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

Full_Name: Jeremiah Cohen Version: 2.9.0 OS: Windows XP Submission from: (NULL) (129.59.230.235) I believe there is a bug in the seq() function for certain values of the "from" argument. Here are examples: > seq(-.2, .1, .1) [1] -0.2 -0.1 0.0 0.1 > seq(-.3, .1, .1) [1] -3.000000e-01 -2.000000e-01 -1.000000e-01 5.551115e-17 1.000000e-01 > seq(-.4, .1, .1) [1] -0.4 -0.3

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

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;

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?

There seems to be a widespread assumption that the way for package foo to require package bar is via `require(bar)'. It isn't! That returns a logical which is in the vast majority of cases unchecked. So if the package is really required, the code will fail without a warning if the package is unavailable. You may as well call library() and let it do the checking. (In a few cases you

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.

Hi, This is (presumably?) a bug in R 1.7.0 under Windows. I have not tested it on other systems. Attachment of packages is case sensitive but not library(), resulting in multiple loadings of the same package if the library name is spelled differently. The following example loads the `tools' package, once as `tools' and once as `Tools'. This behavior is the same with all packages and

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

Dear R-users, What command do I need to use to detach a library? (without restart the R session). Thanks, Agus -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

Dear R team, I had a strange problem that appeared suddenly, and which I'd like to to mention in case it is of interest (although I suspect that I may have unwittingly done something dumb: if so please accept my apology) > library(ctest) ## or any package other than "oz" that I tried Error in as.character(table) : Object ".Dyn.libs" not found > traceback() [1]

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.

Hi Everyone, We have just upgraded to R-1.2.1, and I note, in contrast to R-1.1.1, that ctest is now loaded automatically. The mechanism for this is to create a .First function in base: .First <- function() { require("ctest", quietly=TRUE) } Now I don't want ctest, but I find that simply putting if (length(grep("ctest", search()))) detach(package:ctest) into