[Rd] Possible bug in cut.dendrogram when there are only 2 leaves in the tree ?
Hello, I noticed a behavior ot the cut() function that does not seem right. In a dendrogram with only 2 leaves in one cluster, if you cut() at a height above this cluster, you end up with 2 cut clusters, one for each leaf, instead of one. But it seems to work fine for dendrograms with more than 2 objects. For instance: library(stats) m <- matrix(c(0,0.1,0.1,0),nrow=2, ncol=2) dd <- as.dendrogram(hclust(as.dist(m))) #plot(dd) print(cut(dd, 0.2)) # 2 clusters in $lower m2 <- matrix(c(0,0.1,0.5,0.1,0,0.5,0.5,0.5,0),nrow=3, ncol=3) dd <- as.dendrogram(hclust(as.dist(m2))) print(cut(dd, 0.2)) # here 2 clusters in $lower, as expected So the question is: is it expected behavior that the whole tree is not reported in the $lower if it is itself under the threshold ? Thank you, Karl FORNER [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trojan at current development version?
Hi, is it possible, that the current development version for Windows ( http://cran.at.r-project.org/bin/windows/base/R-2.13.0dev-win.exe) is infected by a trojan/virus. My antivir-program (www.avira.com) seems to find a trojan in open.exe at bin\i386. Best regards, Andreas [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trojan at current development version?
On Jan 28, 2011, at 09:47 , Andreas Mayr wrote: > Hi, > > is it possible, that the current development version for Windows ( > http://cran.at.r-project.org/bin/windows/base/R-2.13.0dev-win.exe) is > infected by a trojan/virus. My antivir-program (www.avira.com) seems to find > a trojan in open.exe at bin\i386. We have seen false positives before (accidental mismatch between virus signatures and legitimate programs). But presumably, the Windows maintainers will double-check, just in case. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trojan at current development version?
On 28.01.2011 13:49, peter dalgaard wrote: On Jan 28, 2011, at 09:47 , Andreas Mayr wrote: Hi, is it possible, that the current development version for Windows ( http://cran.at.r-project.org/bin/windows/base/R-2.13.0dev-win.exe) is infected by a trojan/virus. My antivir-program (www.avira.com) seems to find a trojan in open.exe at bin\i386. We have seen false positives before (accidental mismatch between virus signatures and legitimate programs). But presumably, the Windows maintainers will double-check, just in case. Oh yes, we got such reports before. People reported to Avira and it went away. Now it is there again. Hopeless, I assume. Duncan: Perhaps we can add at the download page that Avira reports open.exe to be infected from time to time. Best wishes, Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with S4 objects: trying to use a "link-glm" as a class in an object definition
On 01/27/2011 08:51 PM, Paul Bailey wrote: > Hi, > > I'm trying to make a new S4 object with a slot for a "link-glm" object. R > doesn't like me have a slot of class "link-glm" > >> class(make.link("probit")) > [1] "link-glm" Tell the S4 system that you'd like to use this 'old' class setOldClass("link-glm") and things should be ok. Martin >> setClass("a",representation(item="link-glm")) > [1] "a" > Warning message: > undefined slot classes in definition of "a": item(class "link-glm") >> fa <- function() { > + new("a",item=make.link("probit")) > + }> >> fa() > Error in validObject(.Object) : > invalid class "a" object: undefined class for slot "item" ("link-glm") > > # and a link-glm looks like a list to me, so I thought I would tell R it is a > list and see what happens > >> setClass("b",representation(item="list")) > [1] "b" >> fb <- function() { > + new("b",item=make.link("probit")) > + } >> fb() > Error in validObject(.Object) : > invalid class "b" object: invalid object for slot "item" in class "b": got > class "link-glm", should be or extend class "list" > > Any advice? > > Regards, > Paul Bailey > Ph.D. candidate > Department of Economics > University of Maryland > > ## raw code # > setClass("a",representation(item="link-glm")) > fa <- function() { > new("a",item=make.link("probit")) > } > fa() > setClass("b",representation(item="list")) > fb <- function() { > new("b",item=make.link("probit")) > } > fb() > ### > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trojan at current development version?
Uwe Ligges statistik.tu-dortmund.de> writes: > > > On 28.01.2011 13:49, peter dalgaard wrote: > > > > On Jan 28, 2011, at 09:47 , Andreas Mayr wrote: > > > >> Hi, > >> > >> is it possible, that the current development version for Windows ( > >> http://cran.at.r-project.org/bin/windows/base/R-2.13.0dev-win.exe) is > >> infected by a trojan/virus. My antivir-program (www.avira.com) seems to > >> find > >> a trojan in open.exe at bin\i386. > > > > We have seen false positives before (accidental mismatch between virus signatures and legitimate > programs). But presumably, the Windows maintainers will double-check, just in case. > > Oh yes, we got such reports before. People reported to Avira and it went > away. Now it is there again. Hopeless, I assume. > > Duncan: Perhaps we can add at the download page that Avira reports > open.exe to be infected from time to time. > > Best wishes, > Uwe > Another note for the paranoid is that the MD5 sum for the binary is posted, so you can at least check consistency. On the other hand, if someone managed to compromise an entire CRAN mirror, they could also post MD5 sums for their nastified version ... you could always go check the MD5 sums on another CRAN mirror (or on the main page), which would make the attacker work much harder ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of depends, suggests, etc
The situation I am talking about is essentially the one in your example. If package [Bar] is not installed on the machine where R CMD chedk is running, then putting Suggests: Bar in the DESCRIPTION file causes R CMD check to fail, with the error message * checking package dependencies ... ERROR Package required but not available: Bar Thus, for purposes of running R CMD check, anything listed in Depends, Suggest, or Imports is required to be installed. However, I'd like to be able to talk about the package in the Rd file (even if it is not installed locally), and have a link generated (which will only work if the package is installed), but not actually use or require package Bar for anything in my own package. Kevin On 1/27/2011 4:31 PM, ken.willi...@thomsonreuters.com wrote: But suppose I want to write something like: "this package is 10 million times better than my other package [Foo] because that one will eat your children" - or "in contrast to the package [Bar], this package is for continuous data, while that one is for discrete data, so they don't interoperate". It wouldn't make sense to Depend or Suggest or Import the [Foo] or [Bar] package, but if I didn't, the doc-building process will (apparently - I haven't tried it myself) warn about the link being broken. I can think of several different ways to address this if there isn't an existing way (e.g. create a generic SeeAlso dependency field; use a different syntax for citing packages that aren't dependencies of one sort or another, etc.), but obviously they'd need the blessing of the people maintaining the tools& specs. -- Ken Williams Senior Research Scientist Thomson Reuters Phone: 651-848-7712 ken.willi...@thomsonreuters.com http://labs.thomsonreuters.com On 1/27/11 4:12 PM, "Prof Brian Ripley" wrote: On Thu, 27 Jan 2011, Kevin R. Coombes wrote: Hi, I'm putting together an R package. In explaining how it works (in the Rd files), I want to refer to another package. The other package is not used anywhere in the actual code nor in the examples. So, there is no reason to include the other package in the Depends, Suggests, or Imports lines of the DESCRIPTION file. People will be able to use my package without actually installing the other package. However, "R CMD check" warns about "Missing link(s)" when it is checking the cross references in the Rd files. What is the preferred way to make this warning go away? Follow the 'Writing R Extensions' manual. There is a 3-item bullet point in ยง1.1.1 following 'The general rules are' and your claims contradict the third point. Thanks in advance, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ReferenceClasses examples {method}
Dear r-devel-list, dear John Chambers, I'm trying to learn OOP-possibilities in R and I was going through the documentation 'ReferenceClasses {methods}' (great work, by the way...). Reading associated Examples, something bothers me : it seems to me that there are errors in 'edit' and 'undo' methods. I think that : - 'undo' should update 'edits' field with : length(edits) <<- length(edits) - 1 #(and not - 2) - and for coherence, 'edit' should store modifications in an 'append'-style : edits <<- c(edits,list(backup)) #as opposed to c(list(backup),edits) I hope I'm not wrong and this hasn't been previously reported (I didn't find anything about it) Best regards. PS: I first posted this message on help-list. David Winsemius suggested me devel-list would probably be more appropriate and was right about that. Sorry if you read it again. PPS: please associate my address when responding because I didn't subscribe to r-devel-list (I'm still far from being able to follow all its discussions...) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ReferenceClasses examples {method}
Hi Marc, Sort of one out of two, but very helpful. On 1/28/11 11:01 AM, Marc Carpentier wrote: Dear r-devel-list, dear John Chambers, I'm trying to learn OOP-possibilities in R and I was going through the documentation 'ReferenceClasses {methods}' (great work, by the way...). Reading associated Examples, something bothers me : it seems to me that there are errors in 'edit' and 'undo' methods. I think that : - 'undo' should update 'edits' field with : length(edits)<<- length(edits) - 1 #(and not - 2) Nope. There are actually two logical choices here, but that is not either of them. Notice that the line before that is: edit(prev[[1]], prev[[2]], prev[[3]]) which invokes the $edit() method to effect the undo, _and_ which adds that edit to the $edits list. One could just leave things that way, but we decide to hide our undo from Wikileaks by removing both the edits. - and for coherence, 'edit' should store modifications in an 'append'-style : edits<<- c(edits,list(backup)) #as opposed to c(list(backup),edits) Well, that's a bit debatable, but it does expose a bug, for sure. The current order might be acceptable, but $undo() is then removing the wrong end of the $edits list, as would have been obvious if the example had done two edits and then removed one. In the current version the first backup is the most recent edit (and indeed is used to reset the data), but then the wrong elements of $edits are removed. Given that, I agree that the opposite order of keeping the backup list is better. Less copying, for one thing. Attached is a corrected and slightly expanded version of that part of the example. Anyone is encouraged to try it out; if no further problems arise, I'll commit its essentials. I hope I'm not wrong and this hasn't been previously reported (I didn't find anything about it) Best regards. PS: I first posted this message on help-list. David Winsemius suggested me devel-list would probably be more appropriate and was right about that. Sorry if you read it again. And indeed r-devel was the right place. Thanks John PPS: please associate my address when responding because I didn't subscribe to r-devel-list (I'm still far from being able to follow all its discussions...) mEditor <- setRefClass("matrixEditor", fields = list( data = "matrix", edits = "list"), methods = list( edit = function(i, j, value) { ## the following string documents the edit method 'Replaces the range [i, j] of the object by value. ' backup <- list(i, j, data[i,j]) data[i,j] <<- value edits <<- c(edits, list(backup)) invisible(value) }, undo = function() { 'Undoes the last edit() operation and update the edits field accordingly. ' prev <- edits if(length(prev)) prev <- prev[[length(prev)]] else stop("No more edits to undo") edit(prev[[1]], prev[[2]], prev[[3]]) ## trim the edits list length(edits) <<- length(edits) - 2 invisible(prev) } )) xMat <- matrix(1:12,4,3) xx <- mEditor$new(data = xMat) xx$edit(2, 2, 0) xx$data xx$edit(1,3, -1) xx$data xx$edits xx$undo() xx$edits xx$data xx$undo() xx$data __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel