Implements support for variable duration solutions

[moorepants]

Fixes #19

This PR allows a user to pass in a symbol as the node interval value instead of a float and then specify instance constraints in terms of node index instead of time. This adds the node interval value as a free optimization variable (as the last element) and the resulting constraint equations and Jacobian takes into account the variable interval. I demonstrate it on the pendulum swing up problem.

• Allow user to set bounds on the node time interval.
• Update parse_free to deal with having h as the last term.
• Make example problem for variable duration.
• Show how to use this in the documentation examples.

[moorepants]

@tjstienstra, if you're interested in reviewing this, it is much appreciated. I've only tried it out on the example pendulum problem here, nothing more complicated yet.

[moorepants]

If you have any comments on the API for the instance constraints, I'd be interested. The basic idea is that if you have fixed duration problems you give something like x(1.23) where the argument is time and then I find the nearest node index. If you have a variable duration, then you give x(4) as the 4th node as the argument. I'm not sure this is the best approach.

[moorepants]

Variable duration pendulum swing up solution:

[tjstienstra]

If you have any comments on the API for the instance constraints, I'd be interested.

I would have a preference not to use round brackets substituting t for indices. That may not just be confusing at first, especially since we normally find the index for the supplied time value, but it will also cause problems for possible future features.

The closest solution would be to use a multiple of h, e.g. 4*h when selecting the fifth node.

[tjstienstra]

One of my main curiosities is also what would the API look like if variable time steps were supported?

[tjstienstra]

Why not use the create_objective_function?

[moorepants]

I wanted to write it out to see how the new variable affected the equations and did not know if create_objective_function() supported h as a symbol.

[tjstienstra]

Not yet but we can easily make it support it (will have to check ones more). But I think that the only difference is that we should change the default keyword argument to an integer (bit nicer if someone doesn't specify it) and we have to multiply the objective with the node_time_interval and remove it from the functions where it manually multiplies the solution with the node time interval.

[moorepants]

I'll let you update it after I merge this. Or I could merge in changes onto this branch if you want.

[moorepants]

I would have a preference not to use round brackets substituting t for indices.

I suspect I could support something like theta[0] but that could take considerably use more work. I'm using (or abusing) SymPy Function behavior. I guess you could create an sympy.Indexed.

The closest solution would be to use a multiple of h, e.g. 4*h when selecting the fourth node.

I originally wrote it like this and then realized it was much simpler to ask the node number from the user, so switched to it.

[moorepants]

One of my main curiosities is also what would the API look like if variable time steps were supported?

I guess the API wouldn't really change other than free being made longer with all the h values. We could have a flag fixed_interval_size or something.

[tjstienstra]

I suspect I could support something like theta[0] but that could take considerably use more work.

Yeah, that was the other thing I thought of.

The closest solution would be to use a multiple of h, e.g. 4*h when selecting the fourth node.

I originally wrote it like this and then realized it was much simpler to ask the node number from the user, so switched to it.

I would prefer the additional difficulty, because it is clearer and mathematically correct. t=4h for the fifth node.

Another solution is to create a boolean keyword argument to interpret supplied time values as indices.

[tjstienstra]

One of my main curiosities is also what would the API look like if variable time steps were supported?

I guess the API wouldn't really change other than free being made longer with all the h values. We could have a flag fixed_interval_size or something.

I was more thinking toward supplying an iterable as node_time_interval, which may include multiples of h.

[moorepants]

I was more thinking toward supplying an iterable as node_time_interval, which may include multiples of h.

I'm not sure why you'd want to do that. What is the reason that you'd want to specify unequal proportional spacing? Wouldn't it mean you are trying to guess where the solution is stiff (smaller spacing in stiff areas) without knowing the solution?

[tjstienstra]

I was more thinking toward supplying an iterable as node_time_interval, which may include multiples of h.

I'm not sure why you'd want to do that. What is the reason that you'd want to specify unequal proportional spacing? Wouldn't it mean you are trying to guess where the solution is stiff (smaller spacing in stiff areas) without knowing the solution?

If a problem is partially reusable then we could start iterating to improve the solution. A bit like what pycollo does only then way simpler. In several problems you know where you want a bit higher resolution and where you do not need that many points.

[moorepants]

I see, yes, if you have a sense of the solution you could proportional time to reflect that.

[moorepants]

I switched to integer multiples of the time interval symbol.