(2.0) Parameter-by-parameter continuation using featurizing

[KalelR]

Hey, this is a new PR, following up on #69. Sorry I took so long, made all of this a bit unnecessarily complicated. I came back to this now as I need this continuation for two projects I'm working on. On the previous PR, we were discussing whether it was better to match the attractors found for different parameters using the clouds of features or the attractors themselves. There were good points for using the features, one of them being that there would be no need for reconstructing the attractors. This is true for matching, but, importantly, not for seeding. We need the attractors to sample ics from them to use them as seeds for the attractor-finding algorithm in the subsequent parameter. Thus, since we need the attractors anyway for seeding (which is the heart of the continuation!), then we might as well use them for matching! If the user then wants to match via features, they can just extract the features in their matching function.

In summary, this PR thus implements continuation for AttractorsViaFeaturizing very similarly to how it is implemented for AttractorsViaRecurrences. The only big difference is that the ics sent to continuation must be pre-generated and stored in a StateSpaceSet, contrary to the sampler function that the AttractorsViaRecurrences version needs. This is because basins_fractions requires the ics in this way to be able to extract the attractors after grouping the features. Again, the attractors are needed for seeding, so this is necessary.
After attractors are found, initial conditions are sampled from them and sent together with the pre-generated ics for basins_fractions on the next parameter. The ics are all put together for extracting features and grouping them.

Let me know what you think!

I compared this algorithm with the recurrences one for the magnetic pendulum example in the documentations. Here is a comparison

with the recurrences on the left and the featurizing on the right for 1000 ics per parameter. I think the curves for featurizing are smoother because the pre-generated ics are fixed. For recurrences, new ics are generated for all parameters, which probably causes the bigger fluctuations.

[Datseris]

thanks, i will review this after Tuesday.

[Datseris]

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

[KalelR]

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

The attractors are extracted as usual in extract_attractors, defined in https://github.com/KalelR/Attractors.jl/blob/28f662a29972c3b826bbaaa63b2cc44efce4e97f/src/mapping/grouping/attractor_mapping_featurizing.jl#L180.

[Datseris]

Sure, seems fine with me. I have some comments on the docs.

[awage]

Hello, I'm free from academic duties! I will review the code tomorrow.

[awage]

Hi Kalel! I am not sure to get the point of sampling the attractors point. The thing that puzzles me is that you add these extra ics to the pool of predefined initial conditions. How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.

The matching is done the usual way. So what is the advantage over the previous matching continuation?

The code is fine. It's just that I don't see the benefits right now over the previous method.

[Datseris]

How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.

It is the same as the seeding part of our original Recurrences continuation, the one we described in our 2023 paper.

The featurizing mapper did not so far seed initial conditions from found attractors when moving to the next parameter. With this PR it does. This makes it more likely that if an attractor continues to exist, it will be found during the continuation.

[awage]

Ok, I see more clearly the context. The code is good to go!

@KalelR @Datseris: I have an idea to factorize a bit the code. But it is a breaking change. A new type called AttractorsFindAndMatch can generalize the interface. Then we dispatch on the type of mapper depending if its recurences or featurizing. There some code in common that can be refactored. What do you think?

[Datseris]

@awage have you seen #130 ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

[awage]

@awage have you seen #130 ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

Wow! I l'll catch up.

[Datseris]

See #132

[KalelR]

Now with PR #132 and the correction at PR #146 this code is obsolete, correct? Shall we close this and PR #69 ?

[Datseris]

Yeap.