When advancing time in Pulse, does the amount of time affect the behavior? E.g., is advancing by 100 milliseconds 10x the same as advancing by 1 second?
I also noticed that sometimes when I advance the time and then ask pulse for the current time, it’s not quite what I advanced by (e.g., advancing by 0.1s and then asking for the current time will give me something like .0088 seconds). This isn’t a problem, I just want to understand what’s going on.
It should be the same
I will take a look
I didn’t mean to imply that I had observed a difference. I was just wondering. I suppose if advancing the time does not always advance the full amount, then that difference could accumulate over time? But that’s just a difference in the amount of time run, not the result after a given amount of time.
We have a specific step size (0.02s)
If you give us a factor of that, which you did, then the current time should be 0.01s not 0.0088s
If you give us a time that is not a factor of our time step, we do track the time not processed and add it to the next time step, so all the time steps will occur… eventually…
https://gitlab.kitware.com/physiology/engine/-/blob/3.x/src/cpp/cpm/controller/Controller.cpp#L1135
It seems weird to me that you did not get the correct sim time…
Sorry, I mis-spoke on the exact numbers – I’m advancing by 0.1s each time. Here’s how it comes out after each step:
+0.1: 0.1
+0.1: 0.19999999999999998 <-- rounding error?
+0.1: 0.27999999999999997 <-- this is where it’s really off
+0.1: 0.4000000000000001 <-- it’s corrected itself, like you said it would
This probably isn’t an issue for me, but if it’s unexpected, then maybe there really is an issue.
I should say, this is in java, and I’m using SEScalarTime.toString() to get the values.
Yeah
I am seeing the same rounding error (?) in Python
I will check this out
I wonder if the issue is that 0.1, 0.2, etc. are not exactly representable as doubles, and by the time we get to 0.3 it’s low (exact value is 2.99999999999999988897769753748E-1 according to https://www.binaryconvert.com/result_double.html?decimal=048046051), so pulse decides that it hasn’t reached the next 0.02 increment yet, so it rounds down to the previous 0.02 increment (which is why it’s off by ~0.02s). This could potentially be avoided by putting in some threshold that says if it’s within some epsilon that it still counts as the next increment.
If the double representation is indeed the issue, perhaps another solution is to use an arbitrary precision number representation so that the time can be represented exactly. In Java this would be BigDecimal (I understand there are several C++ equivalents). This could even just be used internally to avoid the issues we’re seeing, with pulse still returning a double when the time is requested for compatibility with existing code.
Hey Bob
I like your reasoning!
I think I have a few ideas
I don’t want to round off and lose any time, but I think I can make my comparison a bit better than >= with an epsilon