# advancing time by different amounts
**URL:** https://discourse.kitware.com/t/advancing-time-by-different-amounts/447
**Category:** Pulse Physiology Engine
**Created:** [May 1, 2020, 3:50pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447 "2020-05-01T15:50:54Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 1, 2020, 3:50pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/1 "2020-05-01T15:50:54Z")
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.
---
### Author:  [@abray](https://discourse.kitware.com/u/abray)
#### Post date: [May 1, 2020, 4:39pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/2 "2020-05-01T16:39:49Z")
It should be the same
I will take a look
---
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 1, 2020, 4:42pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/3 "2020-05-01T16:42:30Z")
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.
---
### Author:  [@abray](https://discourse.kitware.com/u/abray)
#### Post date: [May 1, 2020, 5:33pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/4 "2020-05-01T17:33:09Z")
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](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…
---
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 1, 2020, 6:09pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/5 "2020-05-01T18:09:21Z")
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.
---
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 1, 2020, 6:11pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/6 "2020-05-01T18:11:56Z")
I should say, this is in java, and I’m using `SEScalarTime.toString()` to get the values.
---
### Author:  [@abray](https://discourse.kitware.com/u/abray)
#### Post date: [May 1, 2020, 6:13pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/7 "2020-05-01T18:13:30Z")
Yeah
I am seeing the same rounding error (?) in Python
I will check this out
---
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 2, 2020, 3:32pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/8 "2020-05-02T15:32:16Z")
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](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.
---
### Author:  [@bob.marinier](https://discourse.kitware.com/u/bob.marinier)
#### Post date: [May 3, 2020, 2:10pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/9 "2020-05-03T14:10:08Z")
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.
---
### Author:  [@abray](https://discourse.kitware.com/u/abray)
#### Post date: [May 5, 2020, 12:55pm UTC](https://discourse.kitware.com/t/advancing-time-by-different-amounts/447/10 "2020-05-05T12:55:53Z")
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