Conversation
|
Confirming that this builds fine; is there a specific test case you have been running to verify? (And/or are there any examples that need updating?) I now see |
|
I used One final question is whether The questions here are:
|
|
Also tested this build on some code similar to the example. I tried the test case above (range [0, 0.2], step size 0.0133), and h is correctly adjusted. |
|
I didn't notice that, but round off will most certainly make the algorithm do that. In your case h=0.0099999 will give 20 intervals and 21 output points and h=0.0100001 will give 19 intervals and 20 points. Is this a problem do you think? Perhaps a better choice would be to provide a buffer in the rounding so that a user that tries your example will get a consistent result? I'll do that. As an alternative, and this is one of my questions above, I could easily change the algorithm to enforce returning exactly |
|
The last commit has two minor changes:
|
|
I've tested the latest build. I agree it's good to go! |
|
Noting here that we'll want to bump the version when merging #124. |
Summary
This is a fix for the PR in #99:
IntegrateOrbits()returning time series that DO NOT include the final time point.Details
The patch condenses the previous patch from PR #99 to only changes relevant to the
tfinalissue. Specifically, the features are:noutis provided, the algorithm computes a new step size that allows a uniform integral stride of some step size equal or smaller than the provided step size while providing exactlynoutpoints in the return.