Re: [Rd] I wish xlim=c(0, NA) would work. How about I send you a patch?
The following seems to work well, and I don't think it'll break anything.
The only problem I see is if someone says xlim=c(min=9, max=0), which should
give an error/warning message, but won't.
Michael
---
plot.default=
function (x, y = NULL, type = "p", xlim = NULL, ylim = NULL,
log = "", main = NULL, sub = NULL, xlab = NULL, ylab = NULL,
ann = par("ann"), axes = TRUE, frame.plot = axes, panel.first = NULL,
panel.last = NULL, asp = NA, ...)
{
localAxis <- function(..., col, bg, pch, cex, lty, lwd) Axis(...)
localBox <- function(..., col, bg, pch, cex, lty, lwd) box(...)
localWindow <- function(..., col, bg, pch, cex, lty, lwd)
plot.window(...)
localTitle <- function(..., col, bg, pch, cex, lty, lwd)
title(...)
xlabel <- if (!missing(x))
deparse(substitute(x))
ylabel <- if (!missing(y))
deparse(substitute(y))
xy <- xy.coords(x, y, xlabel, ylabel, log)
xlab <- if (is.null(xlab))
xy$xlab
else xlab
ylab <- if (is.null(ylab))
xy$ylab
else ylab
xlim <- if (is.null(xlim))
range(xy$x[is.finite(xy$x)])
else if( length(xlim)==1 & names(xlim)=="min" ) {
c(xlim,range(xy$x[is.finite(xy$x)])[2]) }
else if( length(xlim)==1 & names(xlim)=="max" ) {
c( range(xy$x[is.finite(xy$x)])[1], xlim) }
else xlim
ylim <- if (is.null(ylim))
range(xy$y[is.finite(xy$y)])
else if( length(ylim)==1 & names(ylim)=="min" ) {
c( ylim,range(xy$y[is.finite(xy$y)])[2]) }
else if( length(ylim)==1 & names(ylim)=="max" ) {
c( range(xy$y[is.finite(xy$y)])[1], ylim) }
else ylim
dev.hold()
on.exit(dev.flush())
plot.new()
localWindow(xlim, ylim, log, asp, ...)
panel.first
plot.xy(xy, type, ...)
panel.last
if (axes) {
localAxis(if (is.null(y))
xy$x
else x, side = 1, ...)
localAxis(if (is.null(y))
x
else y, side = 2, ...)
}
if (frame.plot)
localBox(...)
if (ann)
localTitle(main = main, sub = sub, xlab = xlab, ylab =
ylab,
...)
invisible()
}
--
View this message in context:
http://r.789695.n4.nabble.com/I-wish-xlim-c-0-NA-would-work-How-about-I-send-you-a-patch-tp4562269p4589316.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] I wish xlim=c(0, NA) would work. How about I send you a patch?
Sorry, the previous had a bug and was quite ugly. This is a bit better:
--
function (x, y = NULL, type = "p", xlim = NULL, ylim = NULL,
log = "", main = NULL, sub = NULL, xlab = NULL, ylab = NULL,
ann = par("ann"), axes = TRUE, frame.plot = axes, panel.first = NULL,
panel.last = NULL, asp = NA, ...)
{
localAxis <- function(..., col, bg, pch, cex, lty, lwd) Axis(...)
localBox <- function(..., col, bg, pch, cex, lty, lwd) box(...)
localWindow <- function(..., col, bg, pch, cex, lty, lwd)
plot.window(...)
localTitle <- function(..., col, bg, pch, cex, lty, lwd)
title(...)
xlabel <- if (!missing(x))
deparse(substitute(x))
ylabel <- if (!missing(y))
deparse(substitute(y))
xy <- xy.coords(x, y, xlabel, ylabel, log)
xlab <- if (is.null(xlab))
xy$xlab
else xlab
ylab <- if (is.null(ylab))
xy$ylab
else ylab
xlim <- if (is.null(xlim))
range(xy$x[is.finite(xy$x)])
else if( length(xlim)==1 ) {
xlim.in=xlim
xlim = range(xy$x[is.finite(xy$x)])
xlim[pmatch( names(xlim.in),c("min","max") )] = xlim.in
xlim
} else xlim
ylim <- if (is.null(ylim))
range(xy$y[is.finite(xy$y)])
else if( length(ylim)==1 ) {
ylim.in=ylim
ylim = range(xy$y[is.finite(xy$y)])
ylim[pmatch( names(ylim.in),c("min","max") )] = ylim.in
ylim
} else ylim
dev.hold()
on.exit(dev.flush())
plot.new()
localWindow(xlim, ylim, log, asp, ...)
panel.first
plot.xy(xy, type, ...)
panel.last
if (axes) {
localAxis(if (is.null(y))
xy$x
else x, side = 1, ...)
localAxis(if (is.null(y))
x
else y, side = 2, ...)
}
if (frame.plot)
localBox(...)
if (ann)
localTitle(main = main, sub = sub, xlab = xlab, ylab =
ylab,
...)
invisible()
}
--
--
View this message in context:
http://r.789695.n4.nabble.com/I-wish-xlim-c-0-NA-would-work-How-about-I-send-you-a-patch-tp4562269p4589400.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How does .Fortran "dqrls" work?
Hi, all.
I want to write some functions like glm() so i studied it.
In glm.fit(), it calls a fortran subroutine named "dqrfit" to compute least
squares solutions
to the system
x * b = y
To learn how "dqrfit" works, I just follow how glm() calls "dqrfit" by my
own example, my codes are given below:
> qr <-
> matrix(c(4.17,5.58,5.18,6.11,4.50,4.61,5.17,4.53,5.33,5.14,2.3,1.7,1.3,1.7,1.7,1.6,1,1.7,1.7,1.7),ncol=2)
> qr
[,1] [,2]
[1,] 4.17 2.3
[2,] 5.58 1.7
[3,] 5.18 1.3
[4,] 6.11 1.7
[5,] 4.50 1.7
[6,] 4.61 1.6
[7,] 5.17 1.0
[8,] 4.53 1.7
[9,] 5.33 1.7
[10,] 5.14 1.7
> n=10
> p=2
> y <- c(4.81,4.17,4.41,3.59,5.87,3.83,6.03,4.89,4.32,4.69)
> ny=1L
> tol=1e-07
> coefficients=double(p)
> residuals=double(n)
> effects=double(n)
> rank=integer(1L)
> pivot=1:n
> qraux=double(n)
> work=double(2*n)
>
>
>
> fittt<-.Fortran("dqrls", qr =qr, n = n,
+ p = p, y = y, ny = ny, tol = tol,
coefficients=coefficients,
+ residuals = residuals, effects = effects,
+ rank = rank, pivot = pivot, qraux = qraux,
+ work = work, PACKAGE = "base")
>
> fittt$coefficients
[1] 0 0
but when i use lm() which also calls "dqrls" internally to fit this model,
it gives reasonable result.
> lm(y~qr)
Call:
lm(formula = y ~ qr)
Coefficients:
(Intercept) qr1 qr2
11.1766 -0.8833 -1.2628
when I change the coefficients to be c(1,1), the output from "dqrls",
fittt$coefficients also equals to c(1,1). That means the .Fortran("dqrls",
qr=qr,n=n,p=p,...) did nothing to the coefficients! I don't know why, is
there anything I did wrong or missed? How can I get the result from "dqrls"
as what lm() or glm() gets from "dqrls"?
Thanks in advance. Best Regards.
--
View this message in context:
http://r.789695.n4.nabble.com/How-does-Fortran-dqrls-work-tp4588973p4588973.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of R in C#
Jeff Abrams microsoft.com> writes:
>
> I have a C# program that requires the run of a logistic regression. I have
downloaded the R 2.11 package, and
> have added the following references to my code:
>
> STATCONNECTORCLNTLib;
> StatConnectorCommonLib;
> STATCONNECTORSRVLib;
>
> In my code I have:
> StatConnector scs = new STATCONNECTORSRVLib.StatConnectorClass();
> scs.Init("R");
>
> The init step returns the below error which seems to indicate a connection
failure.
>
> System.Runtime.InteropServices.COMException was unhandled
> Message="Exception from HRESULT: 0x80040013"
> Source="Interop.STATCONNECTORSRVLib"
> ErrorCode=-2147221485
>
> Any ideas?
>
> Jeff Abrams
> Research Engineer
> Auction Analytics, Microsoft
>
> [[alternative HTML version deleted]]
>
>
For those who say this is not an R issue, it is... I believe this is a issue
with the R registration within Windows. I have all the requisite .dll's in the R
install file, and have the R_USER and R_HOME environment variables, yet I am
still seeing this issue. I can use other .dll's in this way, so this is NOT a
COM issue. It is an R problem. Any thoughts would be helpful.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of R in C#
I cleaner alternative would be to use Rserve. You can use IKVM to compile
the Rserve java API to a .NET assembly. Alternatively you can implement
the protocol in C# (as I did).
On Wed, Apr 25, 2012 at 6:50 AM, Joel wrote:
> Jeff Abrams microsoft.com> writes:
>
> >
> > I have a C# program that requires the run of a logistic regression. I
> have
> downloaded the R 2.11 package, and
> > have added the following references to my code:
> >
> > STATCONNECTORCLNTLib;
> > StatConnectorCommonLib;
> > STATCONNECTORSRVLib;
> >
> > In my code I have:
> > StatConnector scs = new STATCONNECTORSRVLib.StatConnectorClass();
> > scs.Init("R");
> >
> > The init step returns the below error which seems to indicate a
> connection
> failure.
> >
> > System.Runtime.InteropServices.COMException was unhandled
> > Message="Exception from HRESULT: 0x80040013"
> > Source="Interop.STATCONNECTORSRVLib"
> > ErrorCode=-2147221485
> >
> > Any ideas?
> >
> > Jeff Abrams
> > Research Engineer
> > Auction Analytics, Microsoft
> >
> > [[alternative HTML version deleted]]
> >
> >
>
>
> For those who say this is not an R issue, it is... I believe this is a
> issue
> with the R registration within Windows. I have all the requisite .dll's in
> the R
> install file, and have the R_USER and R_HOME environment variables, yet I
> am
> still seeing this issue. I can use other .dll's in this way, so this is
> NOT a
> COM issue. It is an R problem. Any thoughts would be helpful.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jonathan Shore
http://tr8dr.wordpress.com/
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] delayedAssign changing values
For the amusement of the listserver:
Making use of the counter-intuitive assignment properties of delayedAssign, a
co-worked challenged me to construct a delayedAssign of 'x' that causes 'x' to
change its value _every_ time it is evaluated. The example below does this;
each time 'x' is evaluated it is updated to be the next value in the Fibonnacci
sequence.
cmd <- parse(text=
"delayedAssign(\"x\", {
x <- y[1]+y[2]
y[1] <- y[2]
y[2] <- x
eval(cmd)
y[1]
})")
y <- c(0,1)
eval(cmd)
for (i in 1:20) print(x)
[1] 1
[1] 1
[1] 2
[1] 3
[1] 5
[1] 8
[1] 13
[1] 21
[1] 34
[1] 55
[1] 89
[1] 144
[1] 233
[1] 377
[1] 610
[1] 987
[1] 1597
[1] 2584
[1] 4181
[1] 6765
Cheers, Robert
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of McGehee, Robert
Sent: Wednesday, April 25, 2012 5:19 PM
To: r-devel@r-project.org
Subject: [Rd] delayedAssign changing values
I'm not sure if this is a known peculiarity or a bug, but I stumbled across
what I think is very odd behavior from delayedAssign. In the below example x
switches values the first two times it is evaluated.
> delayedAssign("x", {x <- 2; x+3})
> x==x
[1] FALSE
> delayedAssign("x", {x <- 2; x+3})
> x
[1] 5
> x
[1] 2
The ?delayedAssign documentation says that "after [evaluation], the value is
fixed and the expression will not be evaluated again." However, this appears
not to be true. Is this a bug, or just a good way to write extremely obfuscated
code?
Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Direct: (617)392-8396
This e-mail, and any attachments hereto, are intended fo...{{dropped:14}}
__
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] delayedAssign changing values
On Apr 25, 2012, at 5:18 PM, McGehee, Robert wrote:
> I'm not sure if this is a known peculiarity or a bug, but I stumbled across
> what I think is very odd behavior from delayedAssign. In the below example x
> switches values the first two times it is evaluated.
>
>> delayedAssign("x", {x <- 2; x+3})
>> x==x
> [1] FALSE
>
>> delayedAssign("x", {x <- 2; x+3})
>> x
> [1] 5
>> x
> [1] 2
>
> The ?delayedAssign documentation says that "after [evaluation], the value is
> fixed and the expression will not be evaluated again." However, this appears
> not to be true.
It is actually true, the value is not evaluated twice: your evaluation of "x"
has modified the value of "x" (hence it is no longer a promise) so what you get
in the next evaluation is the value that you have set as a side-effect of the
promise evaluation. However, the forced value of the promise it still the value
returned by the evaluated expression. YOu can see that it is the case by simply
adding a function with side-effect (like cat) into your expression.
> Is this a bug, or just a good way to write extremely obfuscated code?
>
That is a good question and I don't know the answer. The docs don't say which
value will be fixed so it could be either way, but intuitively I would expect
the promise evaluation to override side-effects.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange bug in my package
On 25.04.2012 10:58, ONKELINX, Thierry wrote:
Dear all,
I get a bug in the examples of my AFLP package on R-forge
(https://r-forge.r-project.org/R/?group_id=1027) but only on the Linux version.
The windows version compiles. The Mac version skips the examples and compiles.
The strange thing is that the packages compiles on my Ubuntu 10.10 machine with
R 2.15.0. Therefore I can't reproduce the error.
I don't see any error on the R-forge check results.
Uwe Ligges
I have traced the problem at
residuals(outliers(data))
outliers(data) gives an AFLP.outlier object (S4) and I have defined
setMethod("residuals", signature(object = "AFLP.outlier"),
function(object, ...){
object@Residual
}
)
setMethod("resid", signature(object = "AFLP.outlier"),
function(object, ...){
object@Residual
}
And the NAMESPACE is
importFrom(stats, hclust, princomp, residuals, resid)
exportPattern(".")
Any suggestions are welcome.
Best regards,
Thierry
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie& Kwaliteitszorg / team Biometrics& Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more than
asking him to perform a post-mortem examination: he may be able to say what the
experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure
that a reasonable answer can be extracted from a given body of data.
~ John Tukey
* * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en
binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is
door een geldig ondertekend document.
The views expressed in this message and any annex are purely those of the
writer and may not be regarded as stating an official position of INBO, as long
as the message is not confirmed by a duly signed document.
__
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] delayedAssign changing values
It is really strange that the delayedAssign is evaluated in the environment
it is called from, and thus can have side effects.
so
x=2
y=3
delayedAssign("x", {y <- 7; y+3})
gives
> x
[1] 10
> y
[1] 7
Both x and y changed.
More intuitive would have been the behavior
x=2
y=3
delayedAssign("x", local({y <- 7; y+3}) )
> x
[1] 10
> y
[1] 3
which only changes x.
Or, at least that should be the default behavior
Michael
--
View this message in context:
http://r.789695.n4.nabble.com/delayedAssign-changing-values-tp4588108p4590242.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] delayedAssign changing values
On Apr 26, 2012, at 11:59 AM, ghostwheel wrote:
> It is really strange that the delayedAssign is evaluated in the environment
> it is called from,
Not quite, it is evaluated in the environment you specify - and you have
control over both environments ... see ?delayedAssign
> and thus can have side effects.
> so
> x=2
> y=3
> delayedAssign("x", {y <- 7; y+3})
>
> gives
>> x
> [1] 10
>> y
> [1] 7
>
> Both x and y changed.
> More intuitive would have been the behavior
> x=2
> y=3
> delayedAssign("x", local({y <- 7; y+3}) )
>> x
> [1] 10
>> y
> [1] 3
> which only changes x.
> Or, at least that should be the default behavior
>
That is questionable - I think it is more logical for both environments to be
the same as default. Just think if it -- the point here is to access lazy
evaluation which is exactly what it does - lazy evaluation takes place in the
original environment, not in another one.
Cheers,
Simon
> Michael
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/delayedAssign-changing-values-tp4588108p4590242.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> 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] delayedAssign changing values
Simon Urbanek wrote
>
>> More intuitive would have been the behavior
>> delayedAssign("x", local({y <- 7; y+3}) )
>> which only changes x.
>
> That is questionable - I think it is more logical for both environments to
> be the same as default. Just think if it -- the point here is to access
> lazy evaluation which is exactly what it does - lazy evaluation takes
> place in the original environment, not in another one.
>
I think I finally understand. My intuition just came from looking at
?delayedAssign.
But delayedAssign came to replace delay(), which "creates a promise to
evaluate the given expression".
When one thinks of delay(), what you said makes sense, you just delay
executing a certain expression in the parent frame.
I think, though, that with the current way it is described and called,
delayedAssign should by default only have the side effect of changing the
variable, i.e. use eval.env=new.env().
The manual states:
This function is invoked for its side effect, which is assigning a promise
to evaluate value to the variable x.
I think that is a nice clear side effect - changing a variable when it is
evaluated...like a delayed "<<-".
Otherwise it seems to me that delayedAssign could cause debugging
nightmares. Luckily, it currently doesn't seem to widely used to cause
them
But you are right that it might be a bit strange that assign.env and
eval.env are different. Maybe that is why there are two different parameters
- to make the side effects clearer?
I tried to find anywhere uses of delayedAssign which make positive use of
side effects other than the assignment, and couldn't find any. Does anyone
know of such a use?
P.S. the end of ?delayedAssign contains this cryptic code:
e <- (function(x, y = 1, z) environment())(1+2, "y", {cat(" HO! "); pi+2})
(le <- as.list(e)) # evaluates the promises
Which I think is another way to create a promise, other than delayedAssign.
But it is really unclear why it sits there at the bottom of the document.
There should probably be more explanation of what this is
--
View this message in context:
http://r.789695.n4.nabble.com/delayedAssign-changing-values-tp4588108p4591137.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] delayedAssign changing values
On Apr 27, 2012, at 00:10 , ghostwheel wrote:
>
> Simon Urbanek wrote
>>
>>> More intuitive would have been the behavior
>>> delayedAssign("x", local({y <- 7; y+3}) )
>>> which only changes x.
>>
>> That is questionable - I think it is more logical for both environments to
>> be the same as default. Just think if it -- the point here is to access
>> lazy evaluation which is exactly what it does - lazy evaluation takes
>> place in the original environment, not in another one.
>>
>
> I think I finally understand. My intuition just came from looking at
> ?delayedAssign.
> But delayedAssign came to replace delay(), which "creates a promise to
> evaluate the given expression".
> When one thinks of delay(), what you said makes sense, you just delay
> executing a certain expression in the parent frame.
>
> I think, though, that with the current way it is described and called,
> delayedAssign should by default only have the side effect of changing the
> variable, i.e. use eval.env=new.env().
That's not possible. It involves evaluating an expression, and there is no
limit to what side effect this can have.
>
> The manual states:
> This function is invoked for its side effect, which is assigning a promise
> to evaluate value to the variable x.
>
> I think that is a nice clear side effect - changing a variable when it is
> evaluated...like a delayed "<<-".
> Otherwise it seems to me that delayedAssign could cause debugging
> nightmares. Luckily, it currently doesn't seem to widely used to cause
> them
Just don't do that, then However, lazy evaluation _per se_ does cause
nightmares, or at least surprising behavior. My favorite one (because it
actually involves a relevant piece of statistics) is
loglike <- function(x,n) function(p) dbinom(x, n, p, log=TRUE)
n <- 10
x <- 7
ll <- loglike(x, n)
x <- 1
curve(ll) # max at 0.1
which has the issue that x (and n too) is not evaluated until the ll function
is called, at which time it may have been changed from the value it had when ll
was created.
>
> But you are right that it might be a bit strange that assign.env and
> eval.env are different. Maybe that is why there are two different parameters
> - to make the side effects clearer?
> I tried to find anywhere uses of delayedAssign which make positive use of
> side effects other than the assignment, and couldn't find any. Does anyone
> know of such a use?
>
They'll have to be rather contrived, but printing is one, and perhaps
maintaining a count of function calls could be another.
> P.S. the end of ?delayedAssign contains this cryptic code:
>
> e <- (function(x, y = 1, z) environment())(1+2, "y", {cat(" HO! "); pi+2})
> (le <- as.list(e)) # evaluates the promises
>
> Which I think is another way to create a promise, other than delayedAssign.
> But it is really unclear why it sits there at the bottom of the document.
> There should probably be more explanation of what this is
It's actually the _normal_ way to create a promise, namely binding actual
arguments to formal arguments. It is just that some trickery is used in order
to make the situation visible.
I agree that the example looks a bit out of place, though. Perhaps there ought
to be a help page on lazy evaluation and a reference to it? (Any volunteers?)
--
Peter Dalgaard, Professor,
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
