similar to: K-means recluster data with given cluster centers

I want use survfit() and basehaz() inside a function, but it doesn't work. Could you take a look at this problem. Thanks for your help. Following is my codes: library(survival) n <- 50 # total sample size nclust <- 5 # number of clusters clusters <- rep(1:nclust,each=n/nclust) beta0 <- c(1,2) set.seed(13) #generate phmm data set Z <- cbind(Z1=sample(0:1,n,replace=TRUE),

Hi! I just started to use R recently, and would like to ask a help about automating the job. I need to use "kmeans" function with my own 300 data files, and wonder if it's possible to do it automatically. For example, > library (mva) > mydata <- read.table ("data1") > cl <- kmeans(mydata, 5, 20) and I just need to save "cl" info (i.e. the center

Can anyone help me resolve this? A part of the R function looks like this: print(is.loaded('merge_xtabs_patterns_file')) print(is.loaded('merge_xtabs_patterns_file_')) .Fortran('merge_xtabs_patterns_file_',ydim[1],ydim[2],x=as.integer(as.matrix(y)),na=as.integer(c), maxD=as.integer(maxD),lrowmem=length(rowmem),rowmem=as.integer(rowmem),

Hi there, I want to generate a random point pattern using the Neyman-Scott cluster process using spatstat package in R. After running the following procedures, why i can not see any figures? > nclust <- function(x0, y0, radius, n) {return(runifdisc(n, radius, x0, y0))} > nclust function(x0, y0, radius, n) {return(runifdisc(n, radius, x0, y0))} > X <- rNeymanScott(10, 0.2, nclust,

Hi, in quite a few programs i can not browse the filesystem when opening a "listbox"; to be more clear: for example when i do in winword Open and the listbox appears, and i try to open the pull down menu winword just quits(without an error message in wine). In another program like "Camel join" it quits as soon as i go up to the level of "my computer" with a message

This is the general outline of my code:: main(argc,argv){ ... Rf_initEmbeddedR(argc,argv); ... Test_tryEval("source(test.r)"); ... } ############# # test.r ############# ... dyn.load("toload.so") tmp <-matrix(data=1,nrow=narray*2,ncol=nclust) .Call("Init",tmp,...) while(...) { criteria <-feval(tmp) if (criteria < criteria.min)

Hi all, I worked the last 2 years on a LLVM back-end that supports clustered and non-clustered VLIW architectures. I also wrote a paper about it that is currently within the review process and is hopefully going to be accepted. Here is a small summary how I realized VLIW support with a LLVM back-end. I also used packing and unpacking of VLIW bundles. My implementations do not require any

Hi Timo, your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from MachineInstruction so I call it "MachineInstructionBundle") and pack/unpack so RegAlloc works on the bundles… I really think this is the way to incorporate VLIW support to LLVM. I guess a need for some of this to make to LLVM trunk is to have a backend

Hi Timo, I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. Furthermore, if this is something that no current targets are using, then it cannot be adopted into LLVM mainline. I think what we need is a concept of a sequence of fixed machine

I am having trouble getting a covariance matrix for each cluster which is output by kmeans(). My input looks like: > imagedat <- read.table("table", header=TRUE) > imagedat Red Green Blue 0_0 5 7 8 1_0 5 5 18 2_0 7 8 49 3_0 22 8 76 4_0 54 10 67 5_0 50 9 28 6_0 18 10 15 7_0 9 7 6

Hi Evan (and all), > I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. The approach in the patch I sent (and I believe Timo's code works similar, according to his explanations) is precisely to make "bundles" no different

Evan, Timo, Carlos (and everyone else), I have somewhat similar interest. What would you say to a some sort of a "global cycle" field/marker to determine all instructions scheduled at a certain "global" cycle. That way the "bundle"/packet/multiop can be identified at any time via a common "global cycle" value. I could see that being set first in pre-ra

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and

On Oct 24, 2011, at 2:38 PM, Carlos Sánchez de La Lama wrote: > Hi Evan (and all), > >> I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. > > The approach in the patch I sent (and I believe Timo's code works similar,

Hi Sergei, > What would you say to a some sort of a "global cycle" field/marker to > determine all instructions scheduled at a certain "global" cycle. That way > the "bundle"/packet/multiop can be identified at any time via a common > "global cycle" value. But RA would need to know about this global cycle field, right? Cause a register can be

Carlos, Absolutely. And an addition to live range detection needs to be made aware of the global cycle... and it needs to be done regardless of representation methodology. Same for any pass that would care for packets. The important observation here IMHO is that "packetization" at early stage (before RA) is tentative, and RA can change the landscape, which must be somewhat finalized

Hi all, > Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? I attached the packing and unpacking pass I used within my backend. In my solution multiple MachineInstruction are packed into one variadic "PACK"

It seems to me that the concept of insn bundles or packets is needed with different characteristics, depending where it's used. At early scheduling, when there may be no MachineInstruction objects yet, the data structure or annotation that's needed may be quite different from that needed at or near code generation and emission. I think that what Sergei is talking about fits well with

On Oct 25, 2011, at 1:59 AM, Stripf, Timo wrote: > Hi all, > >> Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? > > I attached the packing and unpacking pass I used within my backend. In my solution multiple

Hi Carlos, I am interested in your port of a MIPS-VLIW architecture. I plan to use a similar one for which there is no LLVM backend yet. Have you some example of your code? Best, Julien. On 22/10/11 11:10 , Carlos Sánchez de La Lama wrote: > Hi Timo, > > your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from