similar to: Clipping using par(plt=..., xpd=FALSE) inconsistencies

I'm having some confusion over the coordinate system after using pairs. I'm not interested in the content of the actual pairs plot, although the number of pairs seems to matter a bit. I'm purely interested in knowing where my points will be plotted on the device. However, after using pairs, the par information (omd, fig, plt, and usr) don't reflect what points does. For example:

Hi list, I wanted to plot an image with a colorbar to the right of the plot, but set my own axis labels (text rather than numbers) to the image. I have previously accomplished this with two calls to image(), but the package 'fields' has a wrapper function, image.plot(), which does this task conveniently. However, I could not add axes to the original image after a call to image.plot(); I

I ran into this issue when trying to modify a subplot (subplot function in the TeachingDemos package), but here is a more minimal example of the issue (I don't know that it is serious enough to call a bug): This code works how I expect: dev.new() hist(rexp(100)) par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1)) box() # show new plt region points(c(0,1), c(0,1), pch=16, col='red', cex=3)

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: MM> This is not a bug in the very strict sense, MM> but for consistency, MM> I feel that MM> abline() MM> should obey par("xpd") setting, even by ...-argument. MM> The following code shows how lines() ``works'' and abline() does not :

Paul, I was trying to make a minimal self contained example, but I guess I went too far on the minimizing. The original problem came from code more like: library(TeachingDemos) hist(rexp(1000), main='') abline( v=1, col='red') sp.par <- subplot(hist(rnorm(100), main=''), x='topright') op <- par(sp.par[c('usr', 'plt')]) abline(v=0,

Hello, I have a function that changes par("plt") to plot a colorkey, and upon returning resets the original value. Unfortunately this changes the size of the plots when I change the layout. A simplified example: par(mfrow = c(1, 1)) plt <- par("plt") # .... # change par(plt) and create colorkey par(plt = plt) # resets the default

Hi, I posted over at R-help, and didn't get a response, but perhaps that was the wrong forum for this question. I'm having some confusion over the coordinate system after using pairs. I'm not interested in the content of the actual pairs plot, although the number of pairs seems to matter a bit. I'm purely interested in knowing where subsequent points will be plotted on the

Hello everybody, Is it possible to coax legend() into displaying more than one simbol per line in legend? I have a graph like the one attached to this mail; I would like to reorganize the legend in such a way that the duplicate text would be omitted, i.e., the first line would read <square> <triangledown> "increasing frequency" and the second one would read <circle>

hello, I have a graph and i use qgraph package to calculate centrality parameters. Now I want to know the maximum value of shortest path for each vertex with discarding the Inf value in short pathes. For this I use the ShortestPathLengths of centrality function in qgraph. but when I want to get the maximum the result is wrong. here is my code: cen<-centrality(Q)

Hard to follow data analysis without data. Try making your example reproducible [1][2][3] and post in plain text (a setting in your emailer). Read the Posting Guide mentioned in the footer to avoid other posting pitfalls. [1] http://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example [2] http://adv-r.had.co.nz/Reproducibility.html [3]

Hi all, We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT). The PLT is a data structure used for dispatching position-independent function calls to appropriate functions where the address of the function is not known statically. Right now, if a call is made to a function, it may be lowered to a direct call to the function itself or

On 01/29/2013 07:58 PM, Nadav Rotem wrote: > > On Jan 29, 2013, at 12:51 AM, Tobias Grosser <tobias at grosser.es > <mailto:tobias at grosser.es>> wrote: > >> >> # ignore assumed dependences. >> for (i = 0; i < 4; i++) { >> tmp1 = A[3i+1]; >> tmp2 = A[3i+2]; >> tmp3 = tmp1 + tmp2; >> A[3i] = tmp3; >> } >>

Hi R-users, I'm quite new to R and trying to learn the basics. I have a following problem concerning the convertion of array object into data frame. I have made following data sets tmp1 <- rnorm(100) tmp2 <- gl(10,2,length=100) tmp3 <- as.data.frame(cbind(tmp1,tmp2)) tmp3.sum <- tapply(tmp3$tmp1,tmp3$tmp2,sum) tmp3.sum <- as.data.frame(tapply(tmp1,tmp2,sum)) and I want the

On Jan 29, 2013, at 12:51 AM, Tobias Grosser <tobias at grosser.es> wrote: > > # ignore assumed dependences. > for (i = 0; i < 4; i++) { > tmp1 = A[3i+1]; > tmp2 = A[3i+2]; > tmp3 = tmp1 + tmp2; > A[3i] = tmp3; > } > > Now I apply for whatever reason a partial reg2mem transformation. > > float tmp3[1]; > > # ignore assumed

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui > Song via llvm-dev > Sent: Thursday, August 20, 2020 10:18 PM > To: Leonard Chan <leonardchan at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT

Consider the following C code: typedef __attribute__(( ext_vector_type(2) )) float float2; typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) float float2_align2; void foo(void) { const float * p; size_t offset; float2 tmp = *((float2_align2 *)(p+offset)); } When compiled with clang ‹emit-llvm I get: define void @foo() { entry: %p = alloca float*, align 4

> On Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a

On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the responses! I’m going to see if I can summarize the concerns and ideas people have (for my own clarity) and see where we can go on from there. Folks seem to be on board with the idea of introducing some new IR entity that (after linking) *could* be a reference into the PLT, but some

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

On 01/28/2013 12:58 PM, Pekka Jääskeläinen wrote: > Hi, > > Attached is a patch which uses a simple "parallel_loop" metadata attached > to the loop branch instruction in the loop latch for skipping > cross-iteration > memory dependency checking in the LoopVectorizer. This was briefly > discussed > in the email thread "LoopVectorizer in OpenCL C work group