Open jbcaillau opened 2 months ago
@jbcaillau Actually, you can always give or not an extra variable to the function returned by Flow
:
If the problem is Fixed
then the variable is not used (this case should be unauthorized). If the problem is NonFixed
then the variable is used. In the case of the Goddard problem, there is a variable (the final time tf
) that we can pass to the function returned by Flow
(or not). Note that this variable is not used to compute neither the dynamics/cost nor the feedback control hence we are not compelled to pass it. In this case the variable takes the default value which is Real[]
. I understand that this can be weird but it would be strange to have to write something like that:
xf, pf = f0(t3, x3, p3, tf, tf)
There is a test where you can see that we can provide a variable (I need to add tests):
Thanks @ocots. Exactly. Two points below.
Actually, you can always give or not an extra variable to the function returned by
Flow
:If the problem is
Fixed
then the variable is not used (this case should be unauthorized).
Point 1. Yes, when the problem is Fixed
, calling a flow with a variable should not be possible.
If the problem is
NonFixed
then the variable is used. In the case of the Goddard problem, there is a variable (the final timetf
) that we can pass to the function returned byFlow
(or not). Note that this variable is not use to compute neither the dynamics/cost nor the feedback control hence we are not compelled to pass it. In this case the variable takes the default value which isReal[]
. I understand that this can be weird but it would be strange to have to write something like that:xf, pf = f0(t3, x3, p3, tf, tf)
Point 2. From the user point of view, the two particular cases when either t0
or tf
is the only variable, it is strange to force the user to write such a thing. So it is good to give the user the possibility not to add the variable t0
or tf
during the call in these two specific cases (dim $1$ variable equal to either t0
or tf
). This can easily be taken care of with a check in __variable
helper. The typical situation being the free final time case. Conversely, I would not advocate talking care of the case when the variable is a dim $2$ one and equals [ t0, tf ]
.
There is a test where you can see that we can provide a variable (I need to add tests):
Fixed
problem, (ii) to force passing a variable to a NonFixed = Variable
problemt0
or tf
, allow not to give t0
or tf
when calling a flow t0
or tf
is the (only) variable, passing Real[]
as the default when the variable is omitted does not work since the computation of the flow might actually depend on the variable (tf
in the dynamics, for instance...) so the value (of t0
or tf
) must be retrieved by __variable
Side notes:
Variable = NonFixed
, keeping NonFixed
for compatibility and homogeneity with NonAutonomous
. Conversely, I do not think relevant to add the alias NonVariable = Fixed
...Autonomous
and / or Variable
are traits and should be implemented as such (to be done)@jbcaillau top priority.
@ocots agreed. I thought you would do it, but I can take care of it: let me know. In any case, I first need to smoothen some things in https://github.com/control-toolbox/CTBase.jl/issues/166#issuecomment-2183913880
Actually I forgot. But I can take care of it.
Actually I forgot. But I can take care of it.
maybe you can. maybe not. ðŸ¤
@jbcaillau Still forgotten.
@ocots no worry. fine as is, but we ought to take care of it these days.
@ocots the function returned by
Flow
applied to anocp
should depend on the variable (when there is one, i.e. when theocp
isNonFixed
) For instance, in this case (wheretf
is variable).