feigenbaum constant, find.period differentiate

[kmclaren-trinity]

find.period cant differentiate between slowly converging fixed points and close periodic points

An orbit that oscillate about a fixed point and slowly converges (i.e. eventually fixed point) may be classified as a periodic point. Similarly, an periodic orbit/cycle of {c+delta, c-delta} may be classified as a fixed point if delta is small enough. (2*delta<epsilon) This means we can't approximate feigenbaum constant very well.

potential solutions:

• A large initIters and a smaller epsilon

• increasing the default for numTries and decreasing the default for Iters. Effectively, checking if the orbit has converged to a cycle or fixed point more often. this would reduce the number of false fixed points by catching cycles before they get too close. Checking less often, though would reduce the number of false periodic by allowing fixed points to fully converge before we test them.

• some more sophisticated method to differentiate converging oscillation and cycles

• avoid unnecessary computation. we can avoid computing anything past the first chaos. once we find one inf, from that point to the end is one phase for chaos. Also we can use the knowledge about period doubling to only look for the current or the next period. i.e. if we are in the period 2 phase, only check for period 2 or 4.

• we could vary epsilon with max period- a larger epsilon for smaller periods and a smaller epsilon for larger periods.

[kmclaren-trinity]

~related, dscurve always uses default arguments for find.period, even when user specified ones are given.~ now fixed, added a do.call

[kmclaren-trinity]

This is currently implemented. its effect is untested. Potential solution: before testing for periodicity, first check if the function has converged.

Take a sample of the next maxPeriod points, iterate a high power of two, take a second sample of the next maxPeriod points. Then we can test for convergence by looking at the magnitude of abs(firsSample- secondSample))

It should be very low if the function has converged. currently we reuse epsilon, should it have its own, smaller tolerance?

[kmclaren-trinity]

Also, find.period only checks one full period. it should check multiple periods out. i.e. for 2 periodic instead of comparing points 1,2 to points 3,4, also compare to points 5,6, points 7,8,...

Find.period checks proper names names, but apply fixes the names to x,y. This wont be a problem, but is unnecesary. (dsmodel line 441)

[kmclaren-trinity]

~New(?) issue: narrow crosses intervals.~

~i.e. period 1 interval is 0-3.01, period 2 interval is 2.99-3.4~

~I beleive the problem is in recur narrow~ fixed

[kmclaren-trinity]

Runtime is starting to become an issue. Searching for higher periodicity will require an increasing amount of iterations to be computed. The fourth bullet point is looking more neccesary.

Alternatively, we can wait to compute further iterations until after previous ones fail. i.e. wait to compute four iterations until we know the point is not fixed.

[kmclaren-trinity]

how long does it take for points to converge? in test case 183, line 28-40, it seems like 4000 iterations is not enough. going an additional 128 causes points to move a bit more.