Im running an optimisation routine using optim in R and im telling the programme what i want returned. for example, if i put return(op1$par), it will return all 4 of my variable values. Thats fine, and if i run return(op1), I obviously get all the information from the optimisation routine (par, value, convergence etc). However, in this format, the par values arent accessible in the output, it simply details that there are 4 values.
Now what i need is to the get the parameter values and the convergence information at the same time. R wont let me call this return(op1$par, op1$convergence) so im looking for the best way to get these two entities in one run?
I should specify that im writing this to a file for 1000s of iterations and not just looking to call it up once on screen.
Cheers
Try something like this:
return(c(Parameters=op1$par, Convergence=op1$convergence))
The names Parameters and Convergence are only for identifying what are the parameters and what is the convergence, since this result will be a vector.
By design, a function can return only one object (or else assignments like a <- fn(b) would get confusing; which thing do you assign?). But that object can be a vector, or a list (which is what optim does). So wrap your arguments in something like
return(c(par=op1$par, convergence=op1$convergence))
or more generally (for objects of different types),
return(list(par=op1$par, convergence=op1$convergence))
Related
I am still not very good at using R’s standard debugging tools, and I often find that neither the error nor the traceback tell me enough to figure out what is going on. I would like to change R’s default behavior on error to provide more information.
Specifically, I would always like the call, including the formals, the expression assigned to each formal (the default expression if the default is the expression assigned), and the value of each of the argument expressions as evaluated in place, all returned in a format that makes it unambiguous which expression has been matched to which formal and which values go with which expression. Since the values might be large or of unexpected or evanescent type, I’d like them to be returned in a format, such as a str(), that makes intelligent choices about truncation and correctly identifies promises and other object types that tend to evaluate themselves into something else before you see them.
And finally, I’d like all these things, together with the return value of each call, for every function on the call stack from the error back to (and including) some piece of code that I wrote. It seems to me that the natural structure would be a single R object, a list of lists, one list per call (perhaps tidied, broom-like, into a tibble with some list columns) that I could single-step through in the obvious way.
I apologize if I have described some standard R debugging tool that I just haven't learned how to use properly yet. Is this even possible? If it is, could it be implemented via R's available error handlers, or would it need some package-scale coding project?
I would most prefer a solution that changes the default error response to this, but if that is impracticable, I'd accept a solution that requires that I rerun a code chunk with a wrapper or something similar.
It seems like ltrace is showing more parameters then the functions provide, take for instance this
getauxval(31, 0x7ffe5ee5a5c0, 0, 0x7066732e6d657473) = 0x7f4f747cd030
Why are there 4 parameters there, two integers two memory locations rather than one parameter which is all Linux's getauxval seems to support? What's the right way to read the output of ltrace?
I've stumbled upon the same question. After some research and comparison with the source file, I found out that these arguments are the values of the stack variables at the time the function is called. So If you expect (know) your function to have only 1 argument, this will be the first parameter, everything after that are the variables on the function stack
I am currently trying to optimise the speed of a physical model computation. The specificity of this model is that it uses hundreds of input parameters, all stored in a big named vector:
initialize = c("temperature"=100, "airpressure"=150, "friction"=0.46)
The model, while iterating hundreds of times, needs to access the parameters, possibly updates them, etc.:
compute(initialize['temperature'], initialize['airpressure'])
initialize['friction'] <- updateP(initialize['friction'])
This is the logic. However I wonder if this is really efficient to work like this. What happens behind an indexation by name, is it fast? Some ideas to change this logic:
define each parameter as an independent variable in the environment?
(but how to pass a a large number of them as argument of a function?
have a list of parameters instead of a named vector?
access each parameter by its index in the vector, like this:
compute(initialize[1], initialize[2])
If I go with this last solution, of course I will loose the readability of the code (which parameter is actually initialize[1]?). So a way to go could be to define their positions first:
temperature.pos <- 1
airpressure.pos <- 2
compute(initialize[temperature.pos], initialize[airpressure.pos])
Of course, why didn't I try this and tested the speed? Well, it would take me hours to transform every location of parameters call in the script, that's why I ask before doing it.
And maybe there is a even more clever solution?
Thanks
Is it possible to create a Taylor diagram from already calculated correlation and standard deviation values?
I am doing model evaluation, and I have already the correlation and standard deviations values.I understand that there is already a package plotrix where by giving the observation and the modeled values, the diagram is created. However for the type of work that I am doing, it is easier to start by giving already the correlation and standard deviation values.
Is there any way I can do this in R?
There's no reason it shouldn't be possible, but the authors didn't seem to allow for that when they wrote the function. The function is a bit long and complex, but the part that does the calculation is at the top. It is possible to swap out that code and replace it to allow for the passing of summary statistics. Now, keep in mind what i'm about to do is a hack and i've only tested it with versions 3.5-5 of plotrix. Other version may not work.
Here will will create a new function taylor.diagram2 that takes all the code from taylor.diagram but adds in an extra if statement to check for a list of summarized data as the first argument
taylor.diagram2<-taylor.diagram
bl<-as.list(body(taylor.diagram))
cond<-list(
as.name("if"),
quote(is.list(ref) & missing(model)), #condition
quote({R<-ref$R; sd.r<-ref$sd.r; sd.f<-ref$sd.f}), #if true
as.call(c(as.symbol("{"), bl[3:8]))) #else
bl<-c(bl[1:2], as.call(cond), bl[9:length(bl)]) #splice in new code
body(taylor.diagram2)<-as.call(bl) #update function
Now we can test the function. First, we'll do things the standard way
#test data
aref<-rnorm(30,sd=2)
amodel1<-aref+rnorm(30)/2
#standard behavior function
taylor.diagram2(aref,amodel1, main="Standard Behavior"))
#summarized data
xx<-list(
R=cor(aref, amodel1, use = "pairwise"),
sd.r=sd(aref),
sd.f=sd(amodel1)
)
#modified behavior
taylor.diagram2(xx, main="Modified Behavior")
So the new taylor.diagram2 function can do both. If you pass it two vectors, it will do the standard behavior. If you pass it a list with the names R, sd.r, and sd.f, then it will do the same plot but with the values you passed in. Also, the model parameter must be empty for the modified version to work. That means if you want to set any additional parameter, you must use named parameters rather than positional arguments.
I wrote a function in R - called "filtre": it takes a dataframe, and for each line it says whether it should go in say bin 1 or 2. At the end, we have two data frames that sum up to the original input, and corresponding respectively to all lines thrown in either bin 1 or 2. These two sets of bin 1 and 2 are referred to as filtre1 and filtre2. For convenience the values of filtre1 and filtre2 are calculated but not returned, because it is an intermediary thing in a bigger process (plus they are quite big data frame). I have the following issue:
(i) When I later on want to use filtre1 (or filtre2), they simply don't show up... like if their value was stuck within the function, and would not be recognised elsewhere - which would oblige me to copy the whole function every time I feel like using it - quite painful and heavy.
I suspect this is a rather simple thing, but I did search on the web and did not find the answer really (I was not sure of best key words). Sorry for any inconvenience.
Thxs / g.
It's pretty hard to know the optimum way of achieve what you want as you do not provide proper example, but I'll give it a try. If your variables filtre1 and filtre2 are defined inside of your function and you do not return them, of course they do not show up on your environment. But you could just return the classification and make filtre1 and filtre2 afterwards:
#example data
df<-data.frame(id=1:20,x=sample(1:20,20,replace=TRUE))
filtre<-function(df){
#example function, this could of course be done by bins<-df$x<10
bins<-numeric(nrow(df))
for(i in 1:nrow(df))
if(df$x<10)
bins[i]<-1
return(bins)
}
bins<-filtre(df)
filtre1<-df[bins==1,]
filtre2<-df[bins==0,]