JuliaDynamics / ChaosTools.jl

Tools for the exploration of chaos and nonlinear dynamics
https://juliadynamics.github.io/DynamicalSystemsDocs.jl/chaostools/stable/
MIT License
188 stars 36 forks source link

Store UPOs in a set & test possibly wrong #334

Closed JonasKoziorek closed 3 months ago

JonasKoziorek commented 3 months ago

Previously UPOs in periodicorbits and davidchacklai algorithms were stored in a RBTree. This worked OK, however I noticed that sometimes duplicates occur even though they shouldn't. I could not trace down the bug, it seemed that rarely the equality == in the RBTree implementation just didn't work. I was testing and benchmarking other alternatives and my best solution is to use Set with linear search for duplicates. It's not ideal but it benchmarks better than before both in time and number of allocations. Furthermore it's more readable and clean than the previous code with VectorWithEpsRadius.

Also, I noticed that in this test file: https://github.com/JuliaDynamics/ChaosTools.jl/blob/850e1f4668ac06fe0473f3110ce5edd105ad85d6/test/periodicity/periodicorbits.jl#L1-L10 the publication fixed points might be incomplete. I found 2 more for period 2 and 3 more for period 3.

DL SD publication

The test can stay like this for now, but I think that it is needed to find some analytically know UPOs in literature and introduce some systematic testing for all the UPO algorithms.

Datseris commented 3 months ago

Have a look at the "extra" points you found in more detail: They are 2-pi duplicates due to the symmetry of the map. They aren't more, its all about whether you make your grid go up to 2-pi or stop before 2-pi so that you don't get the duplicates. The exception here is the fixed point at (pi, 0), which must be a fixed point of all orders because it is fixed point of order 1. I don't know why schlemmer diakonos algorithm doesn't find that one... But sure, finding analytic UPOs would be nice, but it is unlikely, besides some super contrived cases where I am not sure that we would care about (that means: testing only these contrived cases would be a mistake; testing a chaotic map is really what we actually care about). For the standard map, for order 2 and 3 you can see visually where the UPOs should be due to the KAM islands. I take this as good as analytic knowledge.

Using Set is a better option yes. The more you re-use existing code the better.

JonasKoziorek commented 3 months ago

All currently implemented algorithms work for both stable and unstable orbits / periodic points.

Datseris commented 3 months ago

@JonasKoziorek you now have admin access rights to ChaosTools.jl, you can branch from origin instead of using your own fork. Personally I find this easier to work with, but you can do however you prefer with your own fork or origin.