mjg211
Trajectory 1D system starts at t = 0, instead of (t, y) clicked
Came across this when using the phasePlaneAnalysis on a 1D function. It's not really a problem, but it might not be what you expect to happen.
Yeah it probably shouldn’t work like that - good spot!
From: Gerhard Burger [email protected] Reply-To: mjg211/phaseR [email protected] Date: Sunday, 26 August 2018 at 12:52 To: mjg211/phaseR [email protected] Cc: Subscribed [email protected] Subject: [mjg211/phaseR] Trajectory 1D system starts at t = 0, instead of (t, y) clicked (#5)
Came across this when using the phasePlaneAnalysis on a 1D function. It's not really a problem, but it might not be what you expect to happen.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/mjg211/phaseR/issues/5, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEVpA_i4mgWpvh-FhwhvPGPsU9wjvn-hks5uUovggaJpZM4WMwG5.
Still unsure on the best way to resolve this, as at present trajectory() returns a single numeric vector t, given that tlim and tstep define t for ALL initial conditions.
If trajectories can be plotting in the 1D case with different initial values of t, should it just calculate the numerical solution back to 0 so a single t can be retained, but then plot from only the chosen initial t?
Hmm, I see the problem... tlim is also xlim in the 1D case. I will think about possible solutions and try some stuff
It might be weird for 2D systems as well, if you do
trajectory(simplePendulum,
y0 = y0,
tlim = c(0, 10),
parameters = 5)
trajectory(simplePendulum,
y0 = y0,
tlim = c(5, 10),
parameters = 5)
do you expect the same starting point?
Very true; it should probably always be computing the trajectory from t=0, and then just plotting based on tlim.