Although my original question is more general, in order to keep things more comprehensive, I'm formulating below just its partial case, - I expect that a solution/ answer for it will serve as an answer for the more general question.
Question:
to integrate a function f(x)=(...(((x^x)^x)^x)...^x)^x (... powered x n times) on the interval (0,1) ?
Thanks a lot for any ideas!
P.S.: please, do not try to solve the problem mathematically or to simplify an expression (e.g., to approximate the result with a Taylor expansion, whatever), since it's not the main topic (however, I've tried to choose such an example, which should not have any simple transformations)
P.S.2: Original question (which does not require an answer here, since it's expected that an answer for posted question is valid for original one):
if it's possible in R to create a function with an arbitrarily long expression (avoiding "manual" defining). For example, it's easy to set up manually a given function for n=5:
f<-function(x) {
((((x^x)^x)^x)^x)^x
}
But what if n=1'000, or 1'000'000 ?
It seems that simple looping is not appropriate here...
Copied from Rhelp: You should look at:
# ?funprog Should have worked but didn't. Try instead ...
?Reduce
There are several examples of repeated applications of a functional argument. Also composition of list of functions.
One instance:
Funcall <- function(f, ...) f(...) # sort of like `do.call`
Iterate <- function(f, n = 1)
function(x) Reduce(Funcall, rep.int(list(f), n), x, right = TRUE)
Iterate(function(x) x^1.1, 30)(1.01)
#[1] 1.189612
Related
Sorry in advance if the question is stupid/was answered somewhere else/... I could not find any nice solution.
Based on the idea of power series I have
A) a vector of real coefficients of lengths n which comes from an other loop and which can be rather long, but lets assume it is simple, for instance,
a<-1:10
and
B) a real center, e.g.
c<-3
I would like to define the polynomial (in my example)
a[1]+a[2]*(x-3)+ a[3]*(x-3)^2+ .... + a[10]*(x-3)^9
as a function. Unfortunately
1) the function as.polynomial(a) only allows center 0 (as far as I understand) so I cannot use it and
2) the list of coefficients can be long, too long to do it by hand
3) I might later ever need a multivariable version.
I would prefer to use a loop to define this "finite power series" but I do not know how loops and sums of functions can be realized in a clean fashion (and I did not find it either).
Something like (very naive)
t<-function(x) 0
for(i in 1:length(a))
{t<-function(x) {t(x) + a[i]*(x-c)^(i-1}}
Thanks so much for your help.
i think this works
my_polynomial = function(x) {
sum(sapply(seq_along(a), function(ii) a[ii] * (x - c) ^ (ii - 1L)))
}
Just for the future reference. To change the center using the package polynom use change.origin
For example:
change.origin(as.polynomial(a),3)
"R passes promises, not values. The promise is forced when it is first evaluated, not when it is passed.", see this answer by G. Grothendieck. Also see this question referring to Hadley's book.
In simple examples such as
> funs <- lapply(1:10, function(i) function() print(i))
> funs[[1]]()
[1] 10
> funs[[2]]()
[1] 10
it is possible to take such unintuitive behaviour into account.
However, I find myself frequently falling into this trap during daily development. I follow a rather functional programming style, which means that I often have a function A returning a function B, where B is in some way depending on the parameters with which A was called. The dependency is not as easy to see as in the above example, since calculations are complex and there are multiple parameters.
Overlooking such an issue leads to difficult to debug problems, since all calculations run smoothly - except that the result is incorrect. Only an explicit validation of the results reveals the problem.
What comes on top is that even if I have noticed such a problem, I am never really sure which variables I need to force and which I don't.
How can I make sure not to fall into this trap? Are there any programming patterns that prevent this or that at least make sure that I notice that there is a problem?
You are creating functions with implicit parameters, which isn't necessarily best practice. In your example, the implicit parameter is i. Another way to rework it would be:
library(functional)
myprint <- function(x) print(x)
funs <- lapply(1:10, function(i) Curry(myprint, i))
funs[[1]]()
# [1] 1
funs[[2]]()
# [1] 2
Here, we explicitly specify the parameters to the function by using Curry. Note we could have curried print directly but didn't here for illustrative purposes.
Curry creates a new version of the function with parameters pre-specified. This makes the parameter specification explicit and avoids the potential issues you are running into because Curry forces evaluations (there is a version that doesn't, but it wouldn't help here).
Another option is to capture the entire environment of the parent function, copy it, and make it the parent env of your new function:
funs2 <- lapply(
1:10, function(i) {
fun.res <- function() print(i)
environment(fun.res) <- list2env(as.list(environment())) # force parent env copy
fun.res
}
)
funs2[[1]]()
# [1] 1
funs2[[2]]()
# [1] 2
but I don't recommend this since you will be potentially copying a whole bunch of variables you may not even need. Worse, this gets a lot more complicated if you have nested layers of functions that create functions. The only benefit of this approach is that you can continue your implicit parameter specification, but again, that seems like bad practice to me.
As others pointed out, this might not be the best style of programming in R. But, one simple option is to just get into the habit of forcing everything. If you do this, realize you don't need to actually call force, just evaluating the symbol will do it. To make it less ugly, you could make it a practice to start functions like this:
myfun<-function(x,y,z){
x;y;z;
## code
}
There is some work in progress to improve R's higher order functions like the apply functions, Reduce, and such in handling situations like these. Whether this makes into R 3.2.0 to be released in a few weeks depend on how disruptive the changes turn out to be. Should become clear in a week or so.
R has a function that helps safeguard against lazy evaluation, in situations like closure creation: forceAndCall().
From the online R help documentation:
forceAndCall is intended to help defining higher order functions like apply to behave more reasonably when the result returned by the function applied is a closure that captured its arguments.
I would like to use optim() to optimize a cost function (fn argument), and I will be providing a gradient (gr argument). I can write separate functions for fn and gr. However, they have a lot of code in common and I don't want the optimizer to waste time repeating those calculations. So is it possible to provide one function that computes both the cost and the gradient? If so, what would be the calling syntax to optim()?
As an example, suppose the function I want to minimize is
cost <- function(x) {
x*exp(x)
}
Obviously, this is not the function I'm trying to minimize. That's too complicated to list here, but the example serves to illustrate the issue. Now, the gradient would be
grad <- function(x) {
(x+1)*exp(x)
}
So as you can see, the two functions, if called separately, would repeat some of the work (in this case, the exponential function). However, since optim() takes two separate arguments (fn and gr), it appears there is no way to avoid this inefficiency, unless there is a way to define a function like
costAndGrad <- function(x) {
ex <- exp(x)
list(cost=x*ex, grad=(x+1)*ex)
}
and then pass that function to optim(), which would need to know how to extract the cost and gradient.
Hope that explains the problem. Like I said my function is much more complicated, but the idea is the same: there is considerable code that goes into both calculations (cost and gradient), which I don't want to repeat unnecessarily.
By the way, I am an R novice, so there might be something simple that I'm missing!
Thanks very much
The nlm function does optimization and it expects the gradient information to be returned as an attribute to the value returned as the original function value. That is similar to what you show above. See the examples in the help for nlm.
Suppose you have a function f<- function(x,y,z) { ... }. How would you go about passing a constant to one argument, but letting the other ones vary? In other words, I would like to do something like this:
output <- outer(x,y,f(x,y,z=2))
This code doesn't evaluate, but is there a way to do this?
outer(x, y, f, z=2)
The arguments after the function are additional arguments to it, see ... in ?outer. This syntax is very common in R, the whole apply family works the same for instance.
Update:
I can't tell exactly what you want to accomplish in your follow up question, but think a solution on this form is probably what you should use.
outer(sigma_int, theta_int, function(s,t)
dmvnorm(y, rep(0, n), y_mat(n, lambda, t, s)))
This calculates a variance matrix for each combination of the values in sigma_int and theta_int, uses that matrix to define a dennsity and evaluates it in the point(s) defined in y. I haven't been able to test it though since I don't know the types and dimensions of the variables involved.
outer (along with the apply family of functions and others) will pass along extra arguments to the functions which they call. However, if you are dealing with a case where this is not supported (optim being one example), then you can use the more general approach of currying. To curry a function is to create a new function which has (some of) the variables fixed and therefore has fewer parameters.
library("functional")
output <- outer(x,y,Curry(f,z=2))
TRUE/FALSE if clauses are easily and quickly done in R. However, if the argument gets more complex, it also gets ugly very soon.
For instance:
I might want to execute different operations for a row(foo) dependent on the value in one cell (foo[1]).
Let the intervals be 0:39 and 40:59 and 60:100
Something like does not exit:
(if foo[1] "in" 40:60){...
In fact, I only see ways of at least two if clauses and two else statements and the action for the first interval somewhere at the bottom of the code. With more intervals(or any other condition) it is getting more complex.
Is there a best practice (for this purpose or others) with a simple construction and nice design to read?
Not totally sure, but I would suggest to use something like:
f <- approxfun(0:100,c(rep(1,40),rep(2,20),rep(3,41)),method="c")
fac <- f(foo)
tapply(foo,fac,FUN,...)
where you can use any function FUN.
Not totally following your question. Are you looking for a switch statement? Have a look at this example:
ccc <- c("b","QQ","a","A","bb")
for(ch in ccc)
cat(ch,":",switch(EXPR = ch, a=1, b=2:3), "\n")