From: Nick B. <n.j...@el...> - 2010-02-22 19:59:35
|
Not top of your hit list, this one, I have to admit... But I did notice that the values of nsec in instances of the RealTime class don't ever get normalised. So that means that the nsec property could wrap after repeated arithmetic manipulation, producing a wrong answer. How about you normalise the value on construction and in the copy constructor? Perhaps not 100% safe, but not a huge processing overhead and even more likely good FAPP (for all practical purposes). Want a patch? Or don't you care? :) Nick/. |
From: D. M. M. <mic...@ro...> - 2010-02-22 20:57:41
|
On Monday 22 February 2010, Nick Bailey wrote: > Want a patch? Or don't you care? :) I wonder if this explains one or more recurring, obscure, difficult to repeat timing problems we have. Worth a look at that patch, certainly, if you please. -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2010-02-22 21:11:00
|
On Mon, Feb 22, 2010 at 7:30 PM, Nick Bailey <n.j...@el...> wrote: > Not top of your hit list, this one, I have to admit... But I did notice that > the values of nsec in instances of the RealTime class don't ever get > normalised. So that means that the nsec property could wrap after repeated > arithmetic manipulation, producing a wrong answer. > > How about you normalise the value on construction and in the copy constructor? I'm not quite sure I follow ("normalise" in what sense?) The values are wrapped in the constructor to ensure the absolute value of nsec is never greater than one second, and all arithmetic operations use this constructor to return their values. What cases does this miss? Chris |
From: Nick B. <n.j...@el...> - 2010-02-24 15:00:09
|
On Monday 22 Feb 2010 21:10:53 you wrote: > On Mon, Feb 22, 2010 at 7:30 PM, Nick Bailey <n.j...@el...> wrote: > > Not top of your hit list, this one, I have to admit... But I did notice > > that the values of nsec in instances of the RealTime class don't ever get > > normalised. So that means that the nsec property could wrap after > > repeated arithmetic manipulation, producing a wrong answer. > > > > How about you normalise the value on construction and in the copy > > constructor? > > I'm not quite sure I follow ("normalise" in what sense?) The values > are wrapped in the constructor to ensure the absolute value of nsec is > never greater than one second, and all arithmetic operations use this > constructor to return their values. What cases does this miss? > > > Chris It misses the cases when I have a caffeine deficit. Sorry Chris! I was just glancing at the file to find out how to convert RealTime to a double, and I should have read it more carefully. I think the no-args constructor put the wrong idea into my head while I was looking for a toDouble method or something like that. And sorry to raise Michael's hopes about killing obscure timing bugs. I need (1) more coffee and (2) to give fewer C lectures to the first years! Nick/. PS: in the end I went for real_time_val/RealTime(1, 0) to get a double, as it avoids touching your core code. Just as well, eh? N/. |