similar to: question concerning par("plt") and par("mar")

Karline, Thank you for your help. I discovered that in addition to including clim, I needed to omit breaks. This code uses one of your other examples as a starting point and works as intended: persp3D(z = volcano, zlim = c(-60, 200), phi = 20, colkey = list(length = 0.2, width = 0.4, shift = 0.15, cex.axis = 0.8, cex.clab = 0.85), lighting = TRUE, lphi = 90, clab =

Hi, I am trying to solve a model that consists of rather stiff ODEs in R. I use the package ODEsolve (lsoda) to solve these ODEs. To speed up the integration, the jacobian is also specified. Basically, the model is a one-dimensional advection-diffusion problem, and thus the jacobian is a tridiagonal matrix. The size of this jacobian is 100*100. In the original package

Here is a demonstration of behaviour that is probably an optimization by someone far smarter than me that did not anticipate anyone wanting to do this, but for my purposes it looks more like a bug than a feature. I have tested this with R2.6.2 on Windows, no additional packages loaded (beyond the default), I have tested using the default graphics object, pdf, jpeg, and cairoDevice (ok I loaded a

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:

Dear R users, an improved version of package deSolve (version 1.3) is now available on CRAN. deSolve, the successor of R package odesolve, is a package to solve initial value problems (IVP) of: - ordinary differential equations (ODE), - differential algebraic equations (DAE) and - partial differential equations (PDE). The implementation includes stiff integration routines based on the ODEPACK

Dear R users, an improved version of package deSolve (version 1.3) is now available on CRAN. deSolve, the successor of R package odesolve, is a package to solve initial value problems (IVP) of: - ordinary differential equations (ODE), - differential algebraic equations (DAE) and - partial differential equations (PDE). The implementation includes stiff integration routines based on the ODEPACK

Hi, while working with closures in deSolve we have found unexpected behavior in R 3.1.0 and R 3.1.1 and R devel, while it was still as expected in R 3.0.3. This behavior occurs also in several functions of other packages like nls.lm from minpack.lm and even nlm in base, while some other functions worked as expected. See example below. The symptom is that super assignments (<<-) of

We are pleased to announce that the R user conference useR! 2014 is scheduled for July 1-3, 2014, and will take place at the University of California, Los Angeles. As for the predecessor conferences, the program will consist of two parts: invited lectures and user-contributed sessions (abstract submission will be available in due course). Prior to the conference, there will be tutorials on

On 8/21/20 1:34 AM, Renato Golin via llvm-dev wrote: > +1 to Eric's point. We could get into a state where we must get the > relocation right in the IR to get a good (or worse, any) lowering. > > I'd rather have a canonical representation, relocation friendly, that > we try to keep and back ends know how to lower well. > > --renato FWIW, I think that we all agree

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

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

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

Hi The main issue here is that the 'graphics' package has no real concept of going back to a previous plot (the 'grid' package has explicit support for that sort of thing). In 'graphics' you can only go forwards to the next plot; you can fake going back by creating a new plot that is like a previous plot. par(plt=, usr=) is not designed to return you to a previous

> From: "Dr. Jens Oehlschlägel" <jens.oehlschlaegel@bbdo-interone.de> > Date: Mon, 15 Jan 2001 13:58:00 +0100 > > Dear Prof. Ripley, > > I do not insist that features are bugs, so I stop sending this to r-bugs > and cc r-devel instead > > > I am replying to this from the archive: I did not actually receive a > copy. > > But it is right

Hi I'm going to try to blame user error here. par(usr) is used to reset the coordinates on the CURRENT plot. par(plt) is used to specify the location of the NEXT plot. The correct approach should be to set up the location for the next plot, start a new plot, set up coordinates on the new plot. Neither of your examples performs the "start a new plot" step. I would expect to see

IIUC, the actual requirements for the proposed pltentry(@X) constant is: 1. The returned address MUST have a constant offset at link-time from some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which symbol it is is presumed not to matter because all locally-defined symbols have constant offsets from each-other, anyhow. 2. The address is otherwise insignificant. (Therefore, coming

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

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

I found that par(tck=xx) was ignored and par(xaxs="s") gave an error in v0.61. I've made the following quick hacks in the code to get these to function. Please let me know if I'm setting myself up for trouble and... Thanks for R! ...Steve Oncley (oncley at ucar.edu) ------------------------------------------------------- A hack to get par(tck) to work: