Re: [Rd] surprising behaviour of names-
Berwin A Turlach wrote:
'*tmp*' = 0
`*tmp*`
# 0
x = 1
names(x) = 'foo'
`*tmp*`
# error: object *tmp* not found
`*ugly*`
I agree, and I am a bit flabbergasted. I had not expected that
something like this would happen and I am indeed not aware of anything
in the documentation that warns about this; but others may prove me
wrong on this.
hopefully.
given that `*tmp*`is a perfectly legal (though some would say
'non-standard') name, it would be good if somewhere here a warning
were issued -- perhaps where i assign to `*tmp*`, because `*tmp*` is
not just any non-standard name, but one that is 'obviously' used
under the hood to perform black magic.
Now I wonder whether there are any other objects (with non-standard)
names) that can be nuked by operations performed under the hood.
any such risk should be clearly documented, if not with a warning issued
each time the user risks h{is,er} workspace corrupted by the under-the-hood.
I guess the best thing is to stay away from non-standard names, if only
to save the typing of back-ticks. :)
agree. but then, there may be -- and probably are -- other such 'best
to stay away' things in r, all of which should be documented so that a
user know what may happen on the surface, *without* having to peek under
the hood.
Thanks for letting me know, I have learned something new today.
wow. most of my fiercely truculent ranting is meant to point out things
that may not be intentional, or if they are, they seem to me design
flaws rather than features -- so that either i learn that i am ignorant
or wrong, or someone else does, pro bono. hopefully.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Definition of [[
On Sun, 15 Mar 2009, Wacek Kusnierczyk wrote: Stavros Macrakis wrote: Well, that's one issue. But another is that there should be a specification addressed to users, who should not have to understand internals. this should really be taken seriously. Well, the lack of such a specification is a documented bug (see the FAQ on bug reporting), and I think everyone agrees it would be useful, just not as useful as what they would have to stop doing to write it. In fact, such a document may well have a higher priority than it deserves: people who would want that sort of documentation are overrepresented in R-core compared to the general R user community. There was a panel talk at DSC2005 (yes, four years ago) on the possibilities for a joint R/S language standard. That would have provided an external stimulus and a framework for finding all the inconsistencies. It didn't really eventuate. -thomas Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Definition of [[
somewhat one the side, l = list(1) l[[2]] # error, index out of bounds l[2][[1]] # NULL that is, we can't extract from l any element at an index exceeding the list's length (if we could, it would have been NULL or some sort of _NA_list), but we can extract a sublist at an index out of bounds, and from that sublist extract the element (which is NULL, 'the _NA_list'). that's not necessarily wrong, but the item at index i (l[[i]]) is not equivalent to the item in the sublist at index i. vQ Thomas Lumley wrote: On Sun, 15 Mar 2009, Stavros Macrakis wrote: The semantics of [ and [[ don't seem to be fully specified in the Reference manual. In particular, I can't find where the following cases are covered: cc - c(1); ll - list(1) cc[3] [1] NA OK, RefMan says: If i is positive and exceeds length(x) then the corresponding selection is NA. dput(ll[3]) list(NULL) ? i is positive and exceeds length(x); why isn't this list(NA)? I think some of these are because there are only NAs for character, logical, and the numeric types. There isn't an NA of list type. This one shouldn't be list(NA) - which NA would it use? It should be some sort of list(_NA_list_) type, and list(NULL) is playing that role. ll[[3]] Error in list(1)[[3]] : subscript out of bounds ? Why does this return NA for an atomic vector, but give an error for a generic vector? Again, because there isn't an NA of generic vector type. cc[[3]] - 34; dput(cc) c(1, NA, 34) OK ll[[3]] - 34; dput(ll) list(1, NULL, 34) Why is second element NULL, not NA? And why is it OK to set an undefined ll[[3]], but not to get it? Same reason for NULL vs NA. The fact that setting works may just be an inconsistency -- as you can see from previous discussions, R often does not effectively forbid code that shouldn't work -- or it may be bug-compatibility with some version of S or S-PLUS. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names-
Thomas Lumley wrote: Wacek, In this case I think the *tmp* dates from the days before backticks, when it was not a legal name (it still isn't) and it was much, much harder to use illegal names, so the collision issue really didn't exist. thanks for the explanation. You're right about the documentation. thanks for the acknowledgement. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] miscomputation (PR#13594)
Please report bugs in packages to the package maintainer, NOT to r-bugs.
-thomas
On Sun, 15 Mar 2009 sar...@um.ac.ir wrote:
Full_Name: Majid Sarmad
Version: 2.8.1
OS: Linux / Windows
Submission from: (NULL) (194.225.128.135)
With thanks to Alberto Viglione, in HW.tests function of homtest package, there
is the following line
V2 - (sum(ni * ((ti - tauReg)^2 + (t3i - tau3Reg)^2))/sum(ni) )^0.5
which is a mistyping and leads to a miscomputation. It must be
V2 - sum(ni * ((ti - tauReg)^2 + (t3i - tau3Reg)^2) ^0.5) /sum(ni)
as it is in help file of the function:
V2 = sum[i from 1 to k] ni {(t^(i) - t^R)^2 + (t3^(i) - t3^R)^2}^(1/2) / sum[i
from 1 to k] ni
Similarly, in
V2s[i] - (sum(ni * ((ti.sim - tauReg.sim)^2 + (t3i.sim -
tau3Reg.sim)^2))/sum(ni))^0.5
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Thomas Lumley Assoc. Professor, Biostatistics
tlum...@u.washington.eduUniversity of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug Report Fwd: MANOVA Data (PR#13595)
David, 2.3.1 is a bit old to be reporting bugs -- we do ask people to check that their problem is still present in a contemporary version of R. However, your data do still give the same output in R 2.7.2 (which is not current, but was current less than a year ago). I've tidied up the code to remove all the weird characters: booth-read.table(tmp-textConnection(COUNT REWGRP COMMIT SATIS STAY 1 1 16 19 18 2 1 18 15 17 3 1 18 14 14 4 1 16 20 10 5 1 15 13 17 6 1 12 15 11 7 2 16 20 13 8 2 18 14 16 9 2 13 10 14 10 2 17 13 19 11 2 14 18 15 12 2 19 16 18 13 3 20 18 16 14 3 18 15 19 15 3 13 14 17 16 3 12 16 15 17 3 16 17 18 18 3 14 19 15 ),header=TRUE) fit-manova(cbind(COMMIT,SATIS,STAY)~REWGRP,data=booth) Now, as to the question of whether this is a bug. You don't give the SAS answers that you are happy with, just the R answers. This makes it a lot more difficult. It's possible that there is a bug in manova(), but another possibility, since you are concerned about degrees of freedom, and based on the last three letters of the name of your predictor variable, is that you wanted fit2-manova(cbind(COMMIT,SATIS,STAY)~factor(REWGRP),data=booth) summary(fit2, test=Pillai) Df Pillai approx F num Df den Df Pr(F) factor(REWGRP) 2 0.28342 0.77049 6 28 0.5995 Residuals 15 summary(fit2, test=Roy) Df Roy approx F num Df den Df Pr(F) factor(REWGRP) 2 0.31963 1.49159 3 14 0.2599 Residuals 15 summary(fit2, test=Hotelling) Df Hotelling-Lawley approx F num Df den Df Pr(F) factor(REWGRP) 2 0.36261 0.72521 6 24 0.6336 Residuals 15 Googling for the variable names and SAS, MANOVA found some programs in which REWGRP was specified as a CLASS variable, ie, a factor. Also http://my.safaribooksonline.com/9781590474174/ch11lev1sec3 has what might be the output of this code. The test statistics all match the ones in R, but the p-values are slightly different except for Wilks' lambda. So, it looks as though at least you need to specify that the variable is a factor. I will have to leave the question of whether the p-values are correct to someone with more knowledge of MANOVA. It does seem from the documentation that agreement with SAS is intended at least for the Pillai trace and Roy's largest root. We do appreciate bug reports, but it shouldn't be necessary to do all this work to find out what you think the correct answer is. -thomas On Mon, 16 Mar 2009 dvdbo...@cs.com wrote: Hi.? There appears to be a bug in R function manova.? My friend and I both ran it the same way as shown below (his run) with the shown data set. His results are shown below. we both got the same results.? I was running with R 2.3.1. I'm not sure what version he used. Thanks very much, David Booth Kent State University -Original Message- From: dvdbo...@cs.com To: kb...@ilstu.edu Sent: Sun, 15 Mar 2009 7:01 pm Subject: Re: MANOVA Data Ken, Did you notice that Wilks, Roy, etc p-values are all the same?? Pillai is almost the SAS result.? Can't figure it out.? I'll submit a bug report. What's Velleman going to talk about?? Thanks for looking at the R. Best, Dave -Original Message- From: Ken Berk kb...@ilstu.edu To: dvdbo...@cs.com Sent: Sun, 15 Mar 2009 3:45 pm Subject: Re: Fwd: MANOVA Data At 08:07 PM 3/5/2009, you wrote: Hi Ken, I've run the attached data set ( a one way MANOVA ex. from the SAS manual chapter on MANOVA) in both SAS and R and I don't get the same results.? Do you have any suggestions about how I can find out what's going on? Thanks, Dave -Original Message- From: dvdbo...@cs.com To: dvdbo...@aol.com Sent: Thu, 5 Mar 2009 5:06 pm Subject: MANOVA Data Email message sent from CompuServe - visit us today at http://www.cs.com Email message sent from CompuServe - visit us today at http://www.cs.com Hello, David My R results are clearly crap, as shown below. The degrees of freedom are clearly wrong, as is apparent when looking at the univariate anovas. SAS gives the correct answers. I don't know what to do about R. Ken COUNT??? REWGRP??? COMMIT??? SATIS??? STAY 1 1 16??? 19?? 18 2 1 18??? 15?? 17 3 1 18??? 14?? 14 4 1 16??? 20?? 10 5 1 15??? 13?? 17 6 1 12??? 15?? 11 7 2 16??? 20?? 13 8 2 18??? 14?? 16 9 2 13??? 10?? 14 10??? 2 17??? 13?? 19 11??? 2 14??? 18?? 15 12??? 2 19??? 16?? 18 13??? 3 20??? 18?? 16 14??? 3 18??? 15?? 19 15??? 3 13??? 14?? 17 16??? 3 12???
[Rd] vignette index not linked into HTML help system for package
Dear R developers, I observed that the html help page index entry Read overview or browse directory for package vignettes is missing in recent R-devel. This happened on two independent computers (WinXP Prof. SP3, German) with R-devel compiled from sources svn rev. 48125 resp. 48128 It's the same for my own and also for more prominent packages as well (e.g. grid). The vignettes and the index.html files exist and vignette() as well as browseVignettes() work as expected. I have not found anything about this in NEWS or Writing R extensions, which says: At install time an HTML index for all vignettes is automatically created from the \VignetteIndexEntry statements unless a file index.html exists in directory inst/doc. This index is linked into the HTML help system for each package. Have I missed something? Thanks a lot Thomas Petzoldt -- Thomas Petzoldt Technische Universitaet Dresden Institut fuer Hydrobiologiethomas.petzo...@tu-dresden.de 01062 Dresden http://tu-dresden.de/hydrobiologie/ GERMANY __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summer of Code, LLVM, parallelization and R
There is ongoing work on developing a byte code compiler for R. A preliminary implementation is available and the corresponding byte code engine is part of the R distribution. The initial engine has been a useful proof of concept but is in the process of being rewritten from scratch, in part with an eye to supporting parallelization at least of vectorized math operations; I expect to make signitficant progress on this over the coming summer. There are a lot of open design issues relating to changes or adjustments (e.g. via declarations) in the R language that might be needed or help in generating good code, which makes this too loosely specified to make a good SoC project at the moment. By summer 2010 it may have jelled to the point where it is reasonable to spin off projects to, for example, target lower level VMs like LLVM or JVM or .Net's VM from the higher level R VM code. Best, luke On Sun, 15 Mar 2009, Florian Gross wrote: Hi everybody, I'm currently working towards my Master's degree as a student of Computer Science at the University of Saarbrücken and highly interested in compiler construction, interpretation techniques, optimization, programming languages and more. :) Two professors of my university approached me about an interesting project just a few days ago: Developing a LLVM-based JIT compilation back-end for R. The primary goal would be the generation of parallel / vectorized code, but other ways of increasing performance might be very interesting as well. I've thought a bit about this and am now wondering if this would make sense as a project for Google's Summer of Code program -- I have seen that the R foundation was accepted as a mentoring organization in 2008 and has applied to be one again in this year. I've already taken part in the SoC program thrice (working on Novell's JScript.NET compiler and run-time environment in 2005, writing a debugger for the Ruby programming language in 2006 and working on a detailed specification for the Ruby programming language in 2007) and it has always been a lot of fun and a great experience. One thing that was particularly helpful was getting into contact with the development communities so easily. What do you folks think? Would this be of benefit to the R community? Would it be a good candidate for this year's SoC installment? :) Also, if some thinking in this direction has already been done or if you have any other pointers, please don't hesitate to reply! Thanks a lot in advance! Kind regards, Florian Gross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: l...@stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error compiling rgl package
On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote: Hi, Unfortunately I still get the same errors: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include -I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. *** Error code 3 That looks like the previous version: there's no longer a math.h in the package. Maybe you downloaded too quickly, or downloaded to the directory containing the old source and have a mix of both? Duncan Murdoch -- Mohammad Duncan Murdoch wrote: On 12/03/2009 3:16 PM, Mohammad Nikseresht wrote: Hi, I receive the following error while I try to install rgl package: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include-KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. I am using Sun studio 12. I suspect that this is an incompatibility between g++ and Sun studio CC. I would appreciate any you could share your experience with me. Brian Ripley contributed some patches that should help with this. Could you check out the source from R-forge, and confirm that it now compiles on your system? (Or wait for the tarball there to be updated to 0.84-1 in a few hours, and download that.) Thanks Brian, for the patch. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
On 3/16/2009 9:36 AM, Daniel Murphy wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? Don't assume that computations on floating point values are exact. Generally computations on small integers *are* exact, so you could change that to 3 %in% seq(from=2, to=3) and get the expected result. You can divide by 10 just before you use the number, or if you're starting with one decimal place, multiply by 10 *and round to an integer* before doing the test. Alternatively, use some approximate test rather than an exact one, e.g. all.equal() (but you'll need a bit of work to make use of all.equal() in an expression like 0.3 %in% c(.2,.3)). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summer of Code, LLVM, parallelization and R
In addition to the work Luke is doing there is Ra: http://www.milbo.users.sonic.net/ra On Sun, Mar 15, 2009 at 11:25 AM, Florian Gross florian.s.gr...@web.de wrote: Hi everybody, I'm currently working towards my Master's degree as a student of Computer Science at the University of Saarbrücken and highly interested in compiler construction, interpretation techniques, optimization, programming languages and more. :) Two professors of my university approached me about an interesting project just a few days ago: Developing a LLVM-based JIT compilation back-end for R. The primary goal would be the generation of parallel / vectorized code, but other ways of increasing performance might be very interesting as well. I've thought a bit about this and am now wondering if this would make sense as a project for Google's Summer of Code program -- I have seen that the R foundation was accepted as a mentoring organization in 2008 and has applied to be one again in this year. I've already taken part in the SoC program thrice (working on Novell's JScript.NET compiler and run-time environment in 2005, writing a debugger for the Ruby programming language in 2006 and working on a detailed specification for the Ruby programming language in 2007) and it has always been a lot of fun and a great experience. One thing that was particularly helpful was getting into contact with the development communities so easily. What do you folks think? Would this be of benefit to the R community? Would it be a good candidate for this year's SoC installment? :) Also, if some thinking in this direction has already been done or if you have any other pointers, please don't hesitate to reply! Thanks a lot in advance! Kind regards, Florian Gross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Duncan Murdoch wrote: On 3/16/2009 9:36 AM, Daniel Murphy wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? Don't assume that computations on floating point values are exact. Generally computations on small integers *are* exact, so you could change that to 3 %in% seq(from=2, to=3) and get the expected result. You can divide by 10 just before you use the number, or if you're starting with one decimal place, multiply by 10 *and round to an integer* before doing the test. Alternatively, use some approximate test rather than an exact one, e.g. all.equal() (but you'll need a bit of work to make use of all.equal() in an expression like 0.3 %in% c(.2,.3)). there's also the problem that seq(from=0.2, to=0.3) does *not* include 0.3 (in whatever internal form), simply because the default step is 1. however, 0.3 %in% seq(from=.2,to=.3, by=0.1) # FALSE so it won't help anyway. (but in general be careful about using seq and the like.) vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you really mean something like seq(from=.2,to=.3,by=.1), which gives c(0.2, 0.3). %in% tests for exact equality, which is almost never a good idea with floating-point numbers. You need to define what exactly you mean by in for floating-point numbers. What sort of tolerance are you willing to allow? Some possibilities would be for example: approxin - function(x,list,tol) any(abs(list-x)tol) # absolute tolerance rapproxin - function(x,list,tol) (x==0 0 %in% list) || any(abs((list-x)/x)=tol,na.rm=TRUE) # relative tolerance; only exact 0 will match 0 Hope this helps, -s On Mon, Mar 16, 2009 at 9:36 AM, Daniel Murphy chiefmur...@gmail.com wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error compiling rgl package
I downloaded source tarball this morning from: http://cran.at.r-project.org/ It is rgl_0.84.tar.gz but it does contain a math.h! where can I find version 0.84-1? Thanks -- Mohammad Nikseresht Duncan Murdoch wrote: On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote: Hi, Unfortunately I still get the same errors: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include -I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. *** Error code 3 That looks like the previous version: there's no longer a math.h in the package. Maybe you downloaded too quickly, or downloaded to the directory containing the old source and have a mix of both? Duncan Murdoch -- Mohammad Duncan Murdoch wrote: On 12/03/2009 3:16 PM, Mohammad Nikseresht wrote: Hi, I receive the following error while I try to install rgl package: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include-KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. I am using Sun studio 12. I suspect that this is an incompatibility between g++ and Sun studio CC. I would appreciate any you could share your experience with me. Brian Ripley contributed some patches that should help with this. Could you check out the source from R-forge, and confirm that it now compiles on your system? (Or wait for the tarball there to be updated to 0.84-1 in a few hours, and download that.) Thanks Brian, for the patch. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using and 'eval' and environments with active bindings
Thanks for the report. I meant to have R_isMissing always return
FALSE for active binding but had it returning TRUE intead. Fixed now
in R-devel.
luke
On Sun, 15 Mar 2009, Roger D. Peng wrote:
The following code produces an error in current R-devel
f - function(value) {
if(!missing(value))
100
else
2
}
e - new.env()
makeActiveBinding(x, f, e)
eval(substitute(list(x)), e)
The error, after calling 'eval' is
Error in eval(expr, envir, enclos) :
element 1 is empty;
the part of the args list of 'list' being evaluated was:
(x)
It has something to do with the change in R_isMissing in revision
r48118 but I'm not quite knowledgeable enough to understand what the
problem is. In R 2.8.1 the result was simply
eval(substitute(list(x)), e)
[[1]]
[1] 2
I can't say I know what the output should be but I'd like some
clarification on whether this is a bug.
Thanks,
-roger
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error compiling rgl package
On 3/16/2009 11:38 AM, Mohammad Nikseresht wrote: I downloaded source tarball this morning from: http://cran.at.r-project.org/ It is rgl_0.84.tar.gz but it does contain a math.h! where can I find version 0.84-1? It's on R-forge. You can download it as http://r-forge.r-project.org/src/contrib/rgl_0.84-1.tar.gz Duncan Murdoch Thanks -- Mohammad Nikseresht Duncan Murdoch wrote: On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote: Hi, Unfortunately I still get the same errors: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include -I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. *** Error code 3 That looks like the previous version: there's no longer a math.h in the package. Maybe you downloaded too quickly, or downloaded to the directory containing the old source and have a mix of both? Duncan Murdoch -- Mohammad Duncan Murdoch wrote: On 12/03/2009 3:16 PM, Mohammad Nikseresht wrote: Hi, I receive the following error while I try to install rgl package: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include-KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. I am using Sun studio 12. I suspect that this is an incompatibility between g++ and Sun studio CC. I would appreciate any you could share your experience with me. Brian Ripley contributed some patches that should help with this. Could you check out the source from R-forge, and confirm that it now compiles on your system? (Or wait for the tarball there to be updated to 0.84-1 in a few hours, and download that.) Thanks Brian, for the patch. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error compiling rgl package
rgl_0.84-1.tar.gz compiled and installed successfully on our system. Solaris 10 sparc, Sun Studio 12. Thank you very much! -- Mohammad Nikseresht Duncan Murdoch wrote: On 3/16/2009 11:38 AM, Mohammad Nikseresht wrote: I downloaded source tarball this morning from: http://cran.at.r-project.org/ It is rgl_0.84.tar.gz but it does contain a math.h! where can I find version 0.84-1? It's on R-forge. You can download it as http://r-forge.r-project.org/src/contrib/rgl_0.84-1.tar.gz Duncan Murdoch Thanks -- Mohammad Nikseresht Duncan Murdoch wrote: On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote: Hi, Unfortunately I still get the same errors: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include -I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. *** Error code 3 That looks like the previous version: there's no longer a math.h in the package. Maybe you downloaded too quickly, or downloaded to the directory containing the old source and have a mix of both? Duncan Murdoch -- Mohammad Duncan Murdoch wrote: On 12/03/2009 3:16 PM, Mohammad Nikseresht wrote: Hi, I receive the following error while I try to install rgl package: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include-KPIC -O -c Background.cpp -o Background.o math.h, line 47: Error: modf is not a member of file level. math.h, line 48: Error: modff is not a member of file level. Shape.hpp, line 58: Error: The function strncpy must have a prototype. 3 Error(s) detected. I am using Sun studio 12. I suspect that this is an incompatibility between g++ and Sun studio CC. I would appreciate any you could share your experience with me. Brian Ripley contributed some patches that should help with this. Could you check out the source from R-forge, and confirm that it now compiles on your system? (Or wait for the tarball there to be updated to 0.84-1 in a few hours, and download that.) Thanks Brian, for the patch. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
On Mon, Mar 16, 2009 at 06:36:53AM -0700, Daniel Murphy wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE As others already pointed out, you should use seq(from=0.2,to=0.3,by=0.1) to get 0.3 in the sequence. In order to get correct %in%, it is also possible to use round(), for example 0.3 %in% round(seq(from=0.2,to=0.3,by=0.1),digits=1) [1] TRUE See FAQ 7.31 http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f or http://wiki.r-project.org/rwiki/doku.php?id=misc:r_accuracy:decimal_numbers for more detail. Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error Compiling clusterSim on Solaris
Hi, I receive the following error when I try to install cluserSim package on Sparc Solaris 10 using Sun Studio 12: I have compiled and installed a 64 bit version of R. CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c clusterSim.cpp -o clusterSim.o clusterSim.cpp, line 14: Error: An integer constant expression is required within the array subscript operator. 1 Error(s) detected. *** Error code 1 make: Fatal error: Command failed for target `clusterSim.o' I would appreciate it if you could share your experience with me. Thanks -- Mohammad Nikseresht __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Petr Savicky wrote: On Mon, Mar 16, 2009 at 06:36:53AM -0700, Daniel Murphy wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE As others already pointed out, you should use seq(from=0.2,to=0.3,by=0.1) to get 0.3 in the sequence. In order to get correct %in%, it is also possible to use round(), for example 0.3 %in% round(seq(from=0.2,to=0.3,by=0.1),digits=1) [1] TRUE half-jokingly, there's another solution, which avoids rounding: 0.3 %in% (seq(0.4, 0.5, 0.1)-0.2) # TRUE vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
I have a matrix whose columns were filled with values which were functions of cvseq-seq(.2,.3,by=.1) (and a row value of mode integer). To do a lookup for cv=.3 later, I wanted to match(.3,cvseq), which gave me NA, hence my question. I thought R would match .3 in cvseq within .Machine$double.eps, but I can understand it if .3 and the second element of cvseq would not have identical bits. Besides the helpful suggestions below, I also tried cvseqf - as.factor(cvseq) match(.3,cvseq) [1] 2 which worked. In general, would it be better to go the enumeration route via as.factor or the approximation route? Thanks for the help. -Dan On Mon, Mar 16, 2009 at 8:24 AM, Stavros Macrakis macra...@alum.mit.eduwrote: Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you really mean something like seq(from=.2,to=.3,by=.1), which gives c(0.2, 0.3). %in% tests for exact equality, which is almost never a good idea with floating-point numbers. You need to define what exactly you mean by in for floating-point numbers. What sort of tolerance are you willing to allow? Some possibilities would be for example: approxin - function(x,list,tol) any(abs(list-x)tol) # absolute tolerance rapproxin - function(x,list,tol) (x==0 0 %in% list) || any(abs((list-x)/x)=tol,na.rm=TRUE) # relative tolerance; only exact 0 will match 0 Hope this helps, -s On Mon, Mar 16, 2009 at 9:36 AM, Daniel Murphy chiefmur...@gmail.com wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
The factor approach is horrifically ugly and dangerous. Even if it didn't have the extraordinarily poor behavior documented below, it simply isn't well-defined what it should do. The explicit approximation route is far far preferable in every way: more predictable, more controllable, and even (though it hardly matters usually) faster. Let's look at the extraordinarily poor behavior I was mentioning. Consider: nums - (.3 + 2e-16 * c(-2,-1,1,2)); nums [1] 0.3 0.3 0.3 0.3 Though they all print as .3 with the default precision (which is normal and expected), they are all different from .3: nums - .3 = -3.885781e-16 -2.220446e-16 2.220446e-16 3.885781e-16 When we convert nums to a factor, we get: fact - as.factor(nums); fact [1] 0.300 0.3 0.3 0.300 Levels: 0.300 0.3 0.3 0.300 Not clear what the difference between 0.300 and 0.3 is supposed to be, nor why some 0.300 are .3 and others are .3, but let's put that aside for the moment. Now let's look at the relations among the factor values: fact[1]==fact[2] [1] FALSE fact[1]==fact[4] [1] TRUE So though nums[1] nums[2] nums[3] nums[4], fact[1] compares *unequal* to fact[2] though it compares *equal* to fact[4]. Apparently R is comparing the *names* of the levels rather than the indexes in the factor. This would be weird even if it didn't lead to this very bad case. Hope this helps, -s On Mon, Mar 16, 2009 at 6:53 PM, Daniel Murphy chiefmur...@gmail.com wrote: I have a matrix whose columns were filled with values which were functions of cvseq-seq(.2,.3,by=.1) (and a row value of mode integer). To do a lookup for cv=.3 later, I wanted to match(.3,cvseq), which gave me NA, hence my question. I thought R would match .3 in cvseq within .Machine$double.eps, but I can understand it if .3 and the second element of cvseq would not have identical bits. Besides the helpful suggestions below, I also tried cvseqf - as.factor(cvseq) match(.3,cvseq) [1] 2 which worked. In general, would it be better to go the enumeration route via as.factor or the approximation route? Thanks for the help. -Dan On Mon, Mar 16, 2009 at 8:24 AM, Stavros Macrakis macra...@alum.mit.edu wrote: Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you really mean something like seq(from=.2,to=.3,by=.1), which gives c(0.2, 0.3). %in% tests for exact equality, which is almost never a good idea with floating-point numbers. You need to define what exactly you mean by in for floating-point numbers. What sort of tolerance are you willing to allow? Some possibilities would be for example: approxin - function(x,list,tol) any(abs(list-x)tol) # absolute tolerance rapproxin - function(x,list,tol) (x==0 0 %in% list) || any(abs((list-x)/x)=tol,na.rm=TRUE) # relative tolerance; only exact 0 will match 0 Hope this helps, -s On Mon, Mar 16, 2009 at 9:36 AM, Daniel Murphy chiefmur...@gmail.com wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] R with MKL
Hi
I have seen a lot of problems from people trying to compile R with
MKL. So I am writing my experience in case it helps and to ask one
question. I installed R-2.8.1.patched in Ubuntu 9.04 (gcc 4.3.3) using
MKL 10.1.1.019.
Do you use gcc and gfortran?
I configured correctly (following MKL userguide) with :
sudo ./configure --with-blas=-I/opt/intel/mkl/10.1.1.019/include
-L/opt/intel/mkl/10.1.1.019/lib/em64t -lmkl_intel_lp64
-lmkl_intel_thread -lmkl_core -liomp5 -lpthread
--with-lapack=-I/opt/intel/mkl/10.1.1.019/include
-L/opt/intel/mkl/10.1.1.019/lib/em64t -lmkl_intel_lp64
-lmkl_intel_thread -lmkl_core -liomp5 -lpthread
cited reference https://svn.r-project.org/R/trunk/doc/manual/R-admin.texi
| You are strongly encouraged to read the MKL User's Guide
| snip
| @example
| MKL= -...@{mkl_lib_path@} \
| -Wl,--start-group \
| $...@{mkl_lib_path@}/libmkl_gf_lp64.a\
| $...@{mkl_lib_path@}/libmkl_gnu_thread.a \
| $...@{mkl_lib_path@}/libmkl_core.a \
| -Wl,--end-group \
| -liomp5 -lpthread
| @end example
However, It is a little different.( -lgomp and configure line)
MKL= -...@{mkl_lib_path@} \
-Wl,--start-group \
$...@{mkl_lib_path@}/libmkl_gf_lp64.a\
$...@{mkl_lib_path@}/libmkl_gnu_thread.a \
$...@{mkl_lib_path@}/libmkl_core.a \
-Wl,--end-group \
-lgomp -lpthread
./configure --with-blas=$MKL --with-lapack=$MKL
But in order to compile had to edit src/modules/lapack/vecLibg95c.c
and comment out the include. Weird, since I am not building for Mac.
Please note the thing that ABI of fortran is different with Intel compiler
and GNU compiler.
difficult to detect the mistake.
--
EI-JI Nakama nakama (a) ki.rim.or.jp
\u4e2d\u9593\u6804\u6cbb nakama (a) ki.rim.or.jp
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] link in base help file fails.
I run R on MS Windows. In R2.9.0dev, I type ?base to get R help for package base to open. I then select .First from the list of contents, getting a page headed: Initialization at Start of an R Session. About half way down there is a sentence: The command-line flag --vanilla implies --no-site-file, --no-init-file, --no-restore and --no-environ. Under Windows, it also implies --no-Rconsole, which prevents loading the ‘Rconsole’ file. The last occurrence of the word Rconsole is in blue text and underlined, a link. On clicking on this link, I get a page headed This program cannot display the webpage with advice on Most likely causes: and What you can try. Other links work satisfactorily on that page. My internet connection is working. I presume there is a problem with this Rconsole link. sessionInfo() R version 2.9.0 Under development (unstable) (2009-03-13 r48127) i386-pc-mingw32 locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base cheers, Keith Keith Satterley Bioinformatics Division The Walter and Eliza Hall Institute of Medical Research Parkville, Melbourne, Victoria, Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Match .3 in a sequence
Got it. Thank you all. On Mon, Mar 16, 2009 at 4:39 PM, Stavros Macrakis macra...@alum.mit.eduwrote: The factor approach is horrifically ugly and dangerous. Even if it didn't have the extraordinarily poor behavior documented below, it simply isn't well-defined what it should do. The explicit approximation route is far far preferable in every way: more predictable, more controllable, and even (though it hardly matters usually) faster. Let's look at the extraordinarily poor behavior I was mentioning. Consider: nums - (.3 + 2e-16 * c(-2,-1,1,2)); nums [1] 0.3 0.3 0.3 0.3 Though they all print as .3 with the default precision (which is normal and expected), they are all different from .3: nums - .3 = -3.885781e-16 -2.220446e-16 2.220446e-16 3.885781e-16 When we convert nums to a factor, we get: fact - as.factor(nums); fact [1] 0.300 0.3 0.3 0.300 Levels: 0.300 0.3 0.3 0.300 Not clear what the difference between 0.300 and 0.3 is supposed to be, nor why some 0.300 are .3 and others are .3, but let's put that aside for the moment. Now let's look at the relations among the factor values: fact[1]==fact[2] [1] FALSE fact[1]==fact[4] [1] TRUE So though nums[1] nums[2] nums[3] nums[4], fact[1] compares *unequal* to fact[2] though it compares *equal* to fact[4]. Apparently R is comparing the *names* of the levels rather than the indexes in the factor. This would be weird even if it didn't lead to this very bad case. Hope this helps, -s On Mon, Mar 16, 2009 at 6:53 PM, Daniel Murphy chiefmur...@gmail.com wrote: I have a matrix whose columns were filled with values which were functions of cvseq-seq(.2,.3,by=.1) (and a row value of mode integer). To do a lookup for cv=.3 later, I wanted to match(.3,cvseq), which gave me NA, hence my question. I thought R would match .3 in cvseq within .Machine$double.eps, but I can understand it if .3 and the second element of cvseq would not have identical bits. Besides the helpful suggestions below, I also tried cvseqf - as.factor(cvseq) match(.3,cvseq) [1] 2 which worked. In general, would it be better to go the enumeration route via as.factor or the approximation route? Thanks for the help. -Dan On Mon, Mar 16, 2009 at 8:24 AM, Stavros Macrakis macra...@alum.mit.edu wrote: Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you really mean something like seq(from=.2,to=.3,by=.1), which gives c(0.2, 0.3). %in% tests for exact equality, which is almost never a good idea with floating-point numbers. You need to define what exactly you mean by in for floating-point numbers. What sort of tolerance are you willing to allow? Some possibilities would be for example: approxin - function(x,list,tol) any(abs(list-x)tol) # absolute tolerance rapproxin - function(x,list,tol) (x==0 0 %in% list) || any(abs((list-x)/x)=tol,na.rm=TRUE) # relative tolerance; only exact 0 will match 0 Hope this helps, -s On Mon, Mar 16, 2009 at 9:36 AM, Daniel Murphy chiefmur...@gmail.com wrote: Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get 0.3 %in% seq(from=.2,to=.3) [1] FALSE Yet 0.3 %in% c(.2,.3) [1] TRUE For arbitrary sequences, this invisible .3 has been problematic. What is the best way to work around this? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
