Re: [Rd] stopifnot() suggestion
On Thu, 2 Mar 2006, Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Thu, 2 Mar 2006 06:45:39 + (GMT) writes:
>
>BDR> stopifnot() is not intended for use by end-users, but for tests in
>BDR> packages.
>
> and additionally for "function writers" aka 'programmeRs'.
> I think we have argued that R has stopifnot() where other
> programming languages use assert().
Languages which do not have NA, so I have never argued such.
> It can be very convenient to have one compact
>
> stopifnot( condition_A, condition_B, condition_C)
>
> statement at the beginning of your function instead of
> potentially much more verbose
>
> if(!condition_A)
> stop("bla A bla A bla bla")
> if(!condition_B)
> stop("bla B bla B bla bla")
> if(!condition_C)
> stop("bla C bla C bla bla")
>
> where the latter *would* produce more understandable error
> messages but need much more programmer's time.
>
>BDR> If the writers of package tests are not aware of the perils of
>BDR> using == or != with numbers, then it is good that they get reminded.
>
>BDR> And we do have isTRUE for use with it.
>
> indeed!
>
> I still don't see why Dan's original proposition shouldn't be
> considered for adaption.
> One of the most valid (IMO) complaints about S and R have been the
> ``uncomprehensible error messages'' that people see occasionally.
> [[Though, sometimes the error message is well understandable
> and it's just the user's lazyness to *read* and *think* .. ]]
I find that `incomprehensible'!
> An extra is.na() check in a stopifnot() in order to produce a
> much better message seems to me well worth.
Because what should happen with NA is not well-defined. In one version,
it is said that stopifnot() fails if an expression is not true. Now, if
that said TRUE, returning NA would not be an error and stopifnot should
give an error. Later on we are told it is `conceptually equivalent' to
something which behaves as it currently does. So this hangs on exactly
what is meant by `true'.
It seems to me that stopifnot() should probably throw an error unless the
logical result is TRUE, but at present it is written assuming the result
must be TRUE or FALSE (and I have just documented that). And if you
advocate it as the analogue of assert, then I think the behaviour needs to
be changed.
>
> Martin
>
>
>BDR> On Wed, 1 Mar 2006, Dan Davison wrote:
>
>>> On Wed, 1 Mar 2006, Roger D. Peng wrote:
>>>
>>>> Wouldn't it be better to do something like
>>>>
>>>> stopifnot(all(!is.na(x)), all(!is.na(y)), x, y)
>>>>
>>>> rather than have stopifnot() go checking for NAs? I agree the message
> is
>>>> strange but if having non-NA values is really a condition, then why
> not just
>>>> put it in the call to stopifnot()?
>>>>
>>>> -roger
>>>>
>>>
>>> I was thinking of a fallible R user accidentally testing the truth of an
>>> expression with NAs, rather than of a situation where you remember that
>>> there may be missing values. For example
>>>
>>>> f <- function() { x <- NA ; if(x != 4) stop("x should be 4") }
>>>> g <- function() { x <- NA ; stopifnot(x == 4) }
>>>> f()
>>> Error in if (x != 4) stop("x should be 4") :
>>> missing value where TRUE/FALSE needed
>>>> g()
>>> Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
>>> stop(paste(deparse(mc[[i + :
>>> missing value where TRUE/FALSE needed
>>>
>>> If you write the error-checking code represented by f(), you get a
> message
>>> which is very helpful in correcting your error. But someone who uses
>>> stopifnot() instead gets the output of g(). Even a user who knows the
>>> origin of the code in the error message doesn't know which of several
>>> stopifnot()s is responsible.
>>>
>>> Dan
>>>
>>>
>>>
>>>> Dan Davison wrote:
> If an expression is passed to stopifnot() which contains missing
> values,
> then the resulting error message is somewhat baffling until you are
> used to
> it, e.g.
>
>> x <- y <- rep(TRUE, 10)
>> y[7] <- NA
>> stopifnot(x, y)
> Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
> stop(paste(deparse(mc[[i + :
> missing value where TRUE/FALSE needed
>
> A minor change to stopifnot() produces the following behaviour:
>
>> stopifnot(x, y)
> Error in stopifnot(x, y) : y contains missing values
>
> My attempt at a suitable modification follows, and below that the
> original
> function definition. Is a change along these lines appropriate?
>
> ## Altered version
>
> stopifnot <- function (...) {
> n <- length(ll <- list(...))
> if (n == 0)
> return(invisible())
> mc <- match.call()
> for (i in 1:n) {
>>>>
[Rd] problem with as.table (PR#8652)
# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # [EMAIL PROTECTED] # ## There is a problem with as.table converting from a matrix with more than 26 rows (or columns) . rows past 26 are set to . This makes operations such as turning the data back into a data.frame difficult. example causing problems: b <- as.table(matrix(1:60,ncol=2)) as.integer(as.data.frame(b)[,1]) Ian Wilson --please do not edit the information below-- Version: platform = i686-redhat-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:onelocus, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] '...' passed to both plot() and legend()
Dear R-devels,
I'd like to create a plot method for a class of objects that passes
the '...' argument to both plot() and legend(), e.g.,
x <- list(data = rnorm(1000))
class(x) <- "foo"
plot.foo <- function(x, legend = FALSE, cx = "topright", cy = NULL,
...){
dx <- sort(x$data)
plot(dx, dnorm(dx), type = "l", ...)
if (legend)
legend(cx, cy, "Gaussian density", bty = "n", ...)
invisible()
}
#
plot(x)
plot(x, legend = TRUE, cex = 1.1)
However, and as expected, if I use an argument of plot() that is not
an argument of legend() an error occurs, e.g.,
plot(x, legend = TRUE, cex.lab = 1.1)
Is there any (efficient and appropriate) way that I could use the
'...' argument in this case?
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major2
minor2.1
year 2005
month12
day 20
svn rev 36812
language R
Thanks in advance for any hints,
Dimitris
Dimitris Rizopoulos
Ph.D. Student
Biostatistical Centre
School of Public Health
Catholic University of Leuven
Address: Kapucijnenvoer 35, Leuven, Belgium
Tel: +32/(0)16/336899
Fax: +32/(0)16/337015
Web: http://www.med.kuleuven.be/biostat/
http://www.student.kuleuven.be/~m0390867/dimitris.htm
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] '...' passed to both plot() and legend()
See e.g. graphics:::plot.POSIXct, which contains
axisInt <- function(x, type, main, sub, xlab, ylab, col,
lty, lwd, xlim, ylim, bg, pch, log, asp, axes, frame.plot,
...) axis.POSIXct(1, x, ...)
You could use such as wrapper for legend, in your case probably to pick
out just the arguments you want.
On Thu, 2 Mar 2006, Dimitris Rizopoulos wrote:
> Dear R-devels,
>
> I'd like to create a plot method for a class of objects that passes
> the '...' argument to both plot() and legend(), e.g.,
>
> x <- list(data = rnorm(1000))
> class(x) <- "foo"
> plot.foo <- function(x, legend = FALSE, cx = "topright", cy = NULL,
> ...){
>dx <- sort(x$data)
>plot(dx, dnorm(dx), type = "l", ...)
>if (legend)
>legend(cx, cy, "Gaussian density", bty = "n", ...)
>invisible()
> }
> #
> plot(x)
> plot(x, legend = TRUE, cex = 1.1)
>
>
> However, and as expected, if I use an argument of plot() that is not
> an argument of legend() an error occurs, e.g.,
>
> plot(x, legend = TRUE, cex.lab = 1.1)
>
>
> Is there any (efficient and appropriate) way that I could use the
> '...' argument in this case?
>
>> version
> _
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major2
> minor2.1
> year 2005
> month12
> day 20
> svn rev 36812
> language R
>
>
> Thanks in advance for any hints,
> Dimitris
>
>
> Dimitris Rizopoulos
> Ph.D. Student
> Biostatistical Centre
> School of Public Health
> Catholic University of Leuven
>
> Address: Kapucijnenvoer 35, Leuven, Belgium
> Tel: +32/(0)16/336899
> Fax: +32/(0)16/337015
> Web: http://www.med.kuleuven.be/biostat/
> http://www.student.kuleuven.be/~m0390867/dimitris.htm
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] minor oddity in pdf() help page
The following paragraph from ?pdf struck me as a bit odd: 'pdf' writes uncompressed PDF. It is primarily intended for producing PDF graphics for inclusion in other documents, and PDF-includers such as 'pdftex' are usually able to handle compression. Should that be "...and PDF-includers such as 'pdftex' are usually _un_able to handle compression" ? -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with as.table (PR#8652)
[EMAIL PROTECTED] writes: > # Your mailer is set to "none" (default on Windows), > # hence we cannot send the bug report directly from R. > # Please copy the bug report (after finishing it) to > # your favorite email program and send it to > # > # [EMAIL PROTECTED] > # > ## > > > There is a problem with as.table converting from a matrix with > more than 26 rows (or columns) . > > rows past 26 are set to . This makes operations such as > turning the data back into a data.frame difficult. > > example causing problems: > > b <- as.table(matrix(1:60,ncol=2)) > as.integer(as.data.frame(b)[,1]) You can add dimnames to b or the original matrix for a workaround. Probably the easiest fix is (in as.table.default) to replace LETTERS[seq(length = dim(x)[i])] with make.unique(LETTERS[seq(from=0, length = dim(x)[i]) %% 26 + 1], sep="") The effect would be like > make.unique(LETTERS[(0:59)%%26+1], sep="") [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" [16] "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z" "A1" "B1" "C1" "D1" [31] "E1" "F1" "G1" "H1" "I1" "J1" "K1" "L1" "M1" "N1" "O1" "P1" "Q1" "R1" "S1" [46] "T1" "U1" "V1" "W1" "X1" "Y1" "Z1" "A2" "B2" "C2" "D2" "E2" "F2" "G2" "H2" Users might prefer a different scheme, but wouldn't really deserve it... (If they want otherwise, they can just set it themselves). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] '...' passed to both plot() and legend()
You can remove the legend names, assuming there are none
that are also plot names, like this (untested):
args <- list(...)
legnams <- intersect(names(args), names(formals(legend))]
do.call("plot", replace(args, legnams, NULL))
On 3/2/06, Dimitris Rizopoulos <[EMAIL PROTECTED]> wrote:
> Dear R-devels,
>
> I'd like to create a plot method for a class of objects that passes
> the '...' argument to both plot() and legend(), e.g.,
>
> x <- list(data = rnorm(1000))
> class(x) <- "foo"
> plot.foo <- function(x, legend = FALSE, cx = "topright", cy = NULL,
> ...){
>dx <- sort(x$data)
>plot(dx, dnorm(dx), type = "l", ...)
>if (legend)
>legend(cx, cy, "Gaussian density", bty = "n", ...)
>invisible()
> }
> #
> plot(x)
> plot(x, legend = TRUE, cex = 1.1)
>
>
> However, and as expected, if I use an argument of plot() that is not
> an argument of legend() an error occurs, e.g.,
>
> plot(x, legend = TRUE, cex.lab = 1.1)
>
>
> Is there any (efficient and appropriate) way that I could use the
> '...' argument in this case?
>
> > version
> _
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major2
> minor2.1
> year 2005
> month12
> day 20
> svn rev 36812
> language R
>
>
> Thanks in advance for any hints,
> Dimitris
>
>
> Dimitris Rizopoulos
> Ph.D. Student
> Biostatistical Centre
> School of Public Health
> Catholic University of Leuven
>
> Address: Kapucijnenvoer 35, Leuven, Belgium
> Tel: +32/(0)16/336899
> Fax: +32/(0)16/337015
> Web: http://www.med.kuleuven.be/biostat/
> http://www.student.kuleuven.be/~m0390867/dimitris.htm
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
> __
> 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] minor oddity in pdf() help page
Roger D. Peng wrote: > The following paragraph from ?pdf struck me as a bit odd: > > 'pdf' writes uncompressed PDF. It is primarily intended for > producing PDF graphics for inclusion in other documents, and > PDF-includers such as 'pdftex' are usually able to handle > compression. > > Should that be "...and PDF-includers such as 'pdftex' are usually _un_able to > handle compression" ? Hmm, I think the documentation is correct but incomplete - pdftex *can* handle compression, but compression is not implemented in R's pdf output device. So it should say: "... PDF-includers such as 'pdftex' are usually able to handle compression, but R's pdf device does not utilise that feature of pdf." (I have checked a pdf generated by R, and it doesn't compress, and I was using pdflatex this morning to include a compressed pdf, so both parts are correct). There is a caveat: the PDF specs (and the postscript language standard) actually defines a few stream compression schemes - LZW and deflate are two I know of from the top of my head, I think there are more. But LZW used to be tangled up with the Unisys patent until recently when the patent expired, so most open-source softwares won't do it. deflate is implemented in zlib and ghostscript-written pdf usually have stream compression on. i.e. For some purposes such as getting smaller pdf's, it may be better to output from R postscript and use ghostscript to do ps2pdf rather than doing it directly from R, and to be pedantic, pdftex can only handle deflate encoded compression, AFAIK, for the reason I outlined above, but it is sufficient for most purposes, since most tools cannot generate LZW-compressed pdf's. HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor oddity in pdf() help page
No, it means what it actually says. If you include R's PDF in another application, the latter will usually compress *if you asked the application for compressed PDF*. On Thu, 2 Mar 2006, Hin-Tak Leung wrote: > Roger D. Peng wrote: >> The following paragraph from ?pdf struck me as a bit odd: >> >> 'pdf' writes uncompressed PDF. It is primarily intended for >> producing PDF graphics for inclusion in other documents, and >> PDF-includers such as 'pdftex' are usually able to handle >> compression. >> >> Should that be "...and PDF-includers such as 'pdftex' are usually _un_able to >> handle compression" ? > > Hmm, I think the documentation is correct but incomplete - pdftex *can* > handle compression, but compression is not implemented in R's pdf > output device. So it should say: > > "... PDF-includers such as 'pdftex' are usually able to handle > compression, but R's pdf device does not utilise that feature of pdf." > > (I have checked a pdf generated by R, and it doesn't compress, and I was > using pdflatex this morning to include a compressed pdf, so both > parts are correct). > > There is a caveat: the PDF specs (and the postscript language standard) > actually defines a few stream compression schemes - LZW and deflate > are two I know of from the top of my head, I think there are more. > But LZW used to be tangled up with the Unisys patent until recently > when the patent expired, so most open-source softwares won't do > it. deflate is implemented in zlib and ghostscript-written pdf > usually have stream compression on. i.e. For some purposes such > as getting smaller pdf's, it may be better to output from R > postscript and use ghostscript to do ps2pdf rather than doing > it directly from R, and to be pedantic, pdftex can only handle > deflate encoded compression, AFAIK, for the reason I outlined above, > but it is sufficient for most purposes, since most tools cannot > generate LZW-compressed pdf's. > > HTL > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] 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
Re: [Rd] minor oddity in pdf() help page
Okay, it might be the early morning hour---when I read it a second time it made sense. -roger Prof Brian Ripley wrote: > No, it means what it actually says. > > If you include R's PDF in another application, the latter will usually > compress *if you asked the application for compressed PDF*. > > On Thu, 2 Mar 2006, Hin-Tak Leung wrote: > >> Roger D. Peng wrote: >>> The following paragraph from ?pdf struck me as a bit odd: >>> >>> 'pdf' writes uncompressed PDF. It is primarily intended for >>> producing PDF graphics for inclusion in other documents, and >>> PDF-includers such as 'pdftex' are usually able to handle >>> compression. >>> >>> Should that be "...and PDF-includers such as 'pdftex' are usually >>> _un_able to >>> handle compression" ? >> >> Hmm, I think the documentation is correct but incomplete - pdftex *can* >> handle compression, but compression is not implemented in R's pdf >> output device. So it should say: >> >> "... PDF-includers such as 'pdftex' are usually able to handle >> compression, but R's pdf device does not utilise that feature of pdf." >> >> (I have checked a pdf generated by R, and it doesn't compress, and I was >> using pdflatex this morning to include a compressed pdf, so both >> parts are correct). >> >> There is a caveat: the PDF specs (and the postscript language standard) >> actually defines a few stream compression schemes - LZW and deflate >> are two I know of from the top of my head, I think there are more. >> But LZW used to be tangled up with the Unisys patent until recently >> when the patent expired, so most open-source softwares won't do >> it. deflate is implemented in zlib and ghostscript-written pdf >> usually have stream compression on. i.e. For some purposes such >> as getting smaller pdf's, it may be better to output from R >> postscript and use ghostscript to do ps2pdf rather than doing >> it directly from R, and to be pedantic, pdftex can only handle >> deflate encoded compression, AFAIK, for the reason I outlined above, >> but it is sufficient for most purposes, since most tools cannot >> generate LZW-compressed pdf's. >> >> HTL >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor oddity in pdf() help page
Prof Brian Ripley wrote: > No, it means what it actually says. > > If you include R's PDF in another application, the latter will usually > compress *if you asked the application for compressed PDF*. Hmm, no, I don't know about "another application", but pdftex actually tries to insert the graphic/pdf/page objects in the origin form if possible - I would have a word with the author and consider that behavior buggy if pdftex modifies graphic insertion unncessarily. i.e. the default behavior of pdftex is such that anything it generates such as the text content part will be compressed, but any externally included pdf graphics (such as from R) is preserved in their original form if possible. Even if pdftex behaves as you outlined (which I doubt), the paragraph probably can be reworded to a less ambiguous form as e.g. "PDF-includers such as 'pdftex' are usually able to generate compressed pdf from uncompressed input." . > On Thu, 2 Mar 2006, Hin-Tak Leung wrote: > >> Roger D. Peng wrote: >> >>> The following paragraph from ?pdf struck me as a bit odd: >>> >>> 'pdf' writes uncompressed PDF. It is primarily intended for >>> producing PDF graphics for inclusion in other documents, and >>> PDF-includers such as 'pdftex' are usually able to handle >>> compression. >>> >>> Should that be "...and PDF-includers such as 'pdftex' are usually >>> _un_able to >>> handle compression" ? >> >> >> Hmm, I think the documentation is correct but incomplete - pdftex *can* >> handle compression, but compression is not implemented in R's pdf >> output device. So it should say: >> >> "... PDF-includers such as 'pdftex' are usually able to handle >> compression, but R's pdf device does not utilise that feature of pdf." >> >> (I have checked a pdf generated by R, and it doesn't compress, and I was >> using pdflatex this morning to include a compressed pdf, so both >> parts are correct). >> >> There is a caveat: the PDF specs (and the postscript language standard) >> actually defines a few stream compression schemes - LZW and deflate >> are two I know of from the top of my head, I think there are more. >> But LZW used to be tangled up with the Unisys patent until recently >> when the patent expired, so most open-source softwares won't do >> it. deflate is implemented in zlib and ghostscript-written pdf >> usually have stream compression on. i.e. For some purposes such >> as getting smaller pdf's, it may be better to output from R >> postscript and use ghostscript to do ps2pdf rather than doing >> it directly from R, and to be pedantic, pdftex can only handle >> deflate encoded compression, AFAIK, for the reason I outlined above, >> but it is sufficient for most purposes, since most tools cannot >> generate LZW-compressed pdf's. >> >> HTL >> >> __ >> 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
[Rd] Named parameters in optim()
If I name the elements of the vector of initial values passed to
optim(), then it attaches the names to the final result, e.g.
> f <- function(parms) (parms[1]-1)^2+(parms[2]-2)^2
> optim(c(x=3,y=4), f)
$par
x y
0.635 2.0003241
$value
[1] 1.063637e-07
$counts
function gradient
65 NA
$convergence
[1] 0
$message
NULL
However, the vector that gets passed to f doesn't have its names attached:
> f <- function(parms) {
+ print(parms)
+ (parms["x"]-1)^2+(parms["y"]-2)^2
+ }
> optim(c(x=3,y=4), f)
[1] 3 4
Error in optim(c(x = 3, y = 4), f) : function cannot be evaluated at
initial parameters
Is this something that should be fixed, i.e. could it be fixed without
making optim() substantially slower? If not, it's at least something
that should be documented.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Named parameters in optim()
I think the cost is small, and have just added this.
On Thu, 2 Mar 2006, Duncan Murdoch wrote:
> If I name the elements of the vector of initial values passed to
> optim(), then it attaches the names to the final result, e.g.
>
> > f <- function(parms) (parms[1]-1)^2+(parms[2]-2)^2
> > optim(c(x=3,y=4), f)
> $par
> x y
> 0.635 2.0003241
>
> $value
> [1] 1.063637e-07
>
> $counts
> function gradient
> 65 NA
>
> $convergence
> [1] 0
>
> $message
> NULL
>
> However, the vector that gets passed to f doesn't have its names attached:
>
> > f <- function(parms) {
> + print(parms)
> + (parms["x"]-1)^2+(parms["y"]-2)^2
> + }
> > optim(c(x=3,y=4), f)
> [1] 3 4
> Error in optim(c(x = 3, y = 4), f) : function cannot be evaluated at
> initial parameters
>
> Is this something that should be fixed, i.e. could it be fixed without
> making optim() substantially slower? If not, it's at least something
> that should be documented.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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
Re: [Rd] Named parameters in optim()
On 3/2/2006 2:52 PM, Prof Brian Ripley wrote:
> I think the cost is small, and have just added this.
Thank you!
Duncan Murdoch
>
> On Thu, 2 Mar 2006, Duncan Murdoch wrote:
>
>> If I name the elements of the vector of initial values passed to
>> optim(), then it attaches the names to the final result, e.g.
>>
>> > f <- function(parms) (parms[1]-1)^2+(parms[2]-2)^2
>> > optim(c(x=3,y=4), f)
>> $par
>> x y
>> 0.635 2.0003241
>>
>> $value
>> [1] 1.063637e-07
>>
>> $counts
>> function gradient
>> 65 NA
>>
>> $convergence
>> [1] 0
>>
>> $message
>> NULL
>>
>> However, the vector that gets passed to f doesn't have its names attached:
>>
>> > f <- function(parms) {
>> + print(parms)
>> + (parms["x"]-1)^2+(parms["y"]-2)^2
>> + }
>> > optim(c(x=3,y=4), f)
>> [1] 3 4
>> Error in optim(c(x = 3, y = 4), f) : function cannot be evaluated at
>> initial parameters
>>
>> Is this something that should be fixed, i.e. could it be fixed without
>> making optim() substantially slower? If not, it's at least something
>> that should be documented.
>>
>> Duncan Murdoch
>>
>> __
>> 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
