-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New definition of complete_state for ProjectedDynamicalSystems #209
Comments
where did you see this docstring? please provide versions. The docstring i read says something diferent: complete_state produces the state for the original system from the projected state. complete_state can always be a function that given the projected state returns a state in the original space. However, if projection isa AbstractVector{Int}, then complete_state can also be a vector that contains the values of the remaining variables of the system, i.e., those not contained in the projected space. In this case the projected space needs to be lower-dimensional than the original. |
We should add a check in the source code that |
This is the same docstring. I just quoted the first two sentences. We are on the same page. What I think should be changed are these two sentences. If There is a check in the original source code: line 76 in length(complete_state(y)) == dimension(ds) ||
error("The returned vector of complete_state must equal dimension(ds)")
remidxs = nothing The problem is that |
the requirement is that the function takes a vector from the projected state and returns a vector in the original space. This is also what the docstring says. So M cannot be "any" integer, it has to be the dimension of the projected state. Feel free to make a PR that makes it clearer, but for me it is clear the way it is! |
to my knowledge there is no way to test, nor enforce, what is the input to a function. We can't check whether the user provided function |
The docstring is clear (I changed the name of the issue). My point is that we do not have to restrict the input the dimension of the projected space. I have an example of mapper that tracks states on 2D space. The dynamical systems is N dimensional (coupled Kuramotos). I need to define the initial state of the mapper on the original space, not on the projected space. The attractors can be defiined on this 2D space so there is no problem. Right now it is not possible because of the sanity check of I will draft a small PR so can understand better what I mean. |
I have a system of n kuramoto oscillators described in DOI:10.1103/PhysRevLett.127.194101. The stable states of this system are called twisted states: In order to track these states I set up a specific projection onto the function proj_fun(y)
@. model(x, p) = x*p[1]+p[2]
N = length(y)
p0 = [0.5, 0.5]
xdata = 1:N
unwrap!(y)
# this is the lsq fit:
fit = curve_fit(model, xdata, y, p0)
p = fit.param
p[1] = p[1]/(2π/N)
p[2] = 0.
return p
end So I have a projection function Now, suppose I want to explore the fractions or basins of a subspace of
I am doomed because I don't now the if the dynamical system starts at the state This is an unusual case because I need to feed directly the initial conditions to the original dynamical system, not to the projection. This is why I proposed in the PR to be less restrictive about the Maybe I am missing something, but yet I don't know how to achieve this using the current API. Of course I can try to track the attractors directly in the original phase space Nevertheless I could compute a basin on a two dimensional subspace using a trick, these basins are very cool: |
Why don't you use the featurizer approach...? Seems like exactly the type of case featurizing was developed for. The features will be C and q
|
so you don't use a projected system at all. |
Well, I would say that this is a case where projected system is not something you can use. Notice that for your particular example the complete state is actually simple: just make |
When you have a hammer everything looks like a nail. I am always using the recurrence method even if it doesn't apply. I will try the featurizer and see how well it does for this system. Thanks! |
When defining a
ProjectedDynamicalSystem
, the user must define a functioncomplete_state
that must returns a vector of the same dimension than the original dynamical system. Such that:The docstring says:
In the previous example this is not true, since the projected space is a 2D space and the complete_state function only takes the first dimension of the input vector y.
In fact the complete_state function can be a crazy input
y
, the only requisite is to return a valid vector on the original phase space.I propose a minor change in the docstring and small modification of the source code:
The change introduces a small overhead in the computation of the initial state. Maybe there is a better solution. Maybe a special error definition if the case arises that
complete_state(y) != dimension(ds)
The text was updated successfully, but these errors were encountered: