Hello, Or any of the chrono-steady-clock-based time units... I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x). It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float. When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this. Is there a way to tell milliseconds what precision floating point it is? float or double? We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible. Thank you... Regards, Michael Powell
On Fri, Aug 30, 2013 at 4:26 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this.
Is there a way to tell milliseconds what precision floating point it is? float or double?
We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible.
Hi Michael - I don't know the answer to this question (can chrono be configured to use doubles); however, I thought it might be useful to point out that when you're talking about 5 decimal digits of precision at milliseconds, you're only going to be off by a couple of tens of nanoseconds, which is likely less than the precision of any timer on the system. Brian
I should clarify, I suspect that it is being configure as doubles, but I could be mistaken. Instead I need to find out whether it's possible to set it up as single-precision float. Or does the fact that the high-resolution nature of Chrono steady-clock "long long int" preclude that? On Fri, Aug 30, 2013 at 6:34 PM, Brian Budge <brian.budge@gmail.com> wrote:
On Fri, Aug 30, 2013 at 4:26 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this.
Is there a way to tell milliseconds what precision floating point it is? float or double?
We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible.
Hi Michael -
I don't know the answer to this question (can chrono be configured to use doubles); however, I thought it might be useful to point out that when you're talking about 5 decimal digits of precision at milliseconds, you're only going to be off by a couple of tens of nanoseconds, which is likely less than the precision of any timer on the system.
Brian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Fri, Aug 30, 2013 at 6:50 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
I should clarify, I suspect that it is being configure as doubles, but I could be mistaken. Instead I need to find out whether it's possible to set it up as single-precision float. Or does the fact that the high-resolution nature of Chrono steady-clock "long long int" preclude that?
And to clarify my clarification: it's not an issue in its usage per se, but I have logs reporting what the values is/are/were type thing: they need to be accurate if precise there. So if we configured 5 (milliseconds), we expect to see 5 and not 4.99995 type thing. (Rounding here, as far as it goes, for sake of example only.)
On Fri, Aug 30, 2013 at 6:34 PM, Brian Budge <brian.budge@gmail.com> wrote:
On Fri, Aug 30, 2013 at 4:26 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this.
Is there a way to tell milliseconds what precision floating point it is? float or double?
We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible.
Hi Michael -
I don't know the answer to this question (can chrono be configured to use doubles); however, I thought it might be useful to point out that when you're talking about 5 decimal digits of precision at milliseconds, you're only going to be off by a couple of tens of nanoseconds, which is likely less than the precision of any timer on the system.
Brian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Le 31/08/13 01:26, Michael Powell a écrit :
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this. Please, could you provide an example an the output you are getting?
Is there a way to tell milliseconds what precision floating point it is? float or double? I don't see yet where the double is playing on typedef duration<boost::int_least64_t, milli> milliseconds; // at least 45 bits needed Which version are you using, V1 or V2?
We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible.
Vicente
On Sat, Aug 31, 2013 at 4:06 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 31/08/13 01:26, Michael Powell a écrit :
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this.
Please, could you provide an example an the output you are getting?
Is there a way to tell milliseconds what precision floating point it is? float or double?
I don't see yet where the double is playing on
typedef duration<boost::int_least64_t, milli> milliseconds; // at least 45 bits needed
Which version are you using, V1 or V2?
That's a good question, I don't know. I am including <boost/chrono.hpp>, and using boost::chrono::milliseconds, boost::chrono::high_resolution_clock::now to source my stopwatch/stopwatchelapsedtimer concept.
We are targeting ARM, BTW, without hardware floating point support, which is the main reason, I'd like to keep things single-precision float, if at all possible.
Vicente
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Le 31/08/13 12:26, Michael Powell a écrit :
On Sat, Aug 31, 2013 at 4:06 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 31/08/13 01:26, Michael Powell a écrit :
Hello,
Or any of the chrono-steady-clock-based time units...
I am noticing some what appear to be rounding errors outputting resulting millisecond values using the boost::chrono::milliseconds(x).
It's a design-decision, most if not all of our floating-point values are single-precision-float, don't need to be double-precision-float.
When we output the milliseconds(x).count() values, however, what I am finding is that the values are sometimes inaccurate, the same value in 3.0, for instance, output as 2.99995, stuff like this. Please, could you provide an example an the output you are getting?
Is there a way to tell milliseconds what precision floating point it is? float or double?
I don't see yet where the double is playing on
typedef duration<boost::int_least64_t, milli> milliseconds; // at least 45 bits needed
Which version are you using, V1 or V2? That's a good question, I don't know. I am including <boost/chrono.hpp>, and using boost::chrono::milliseconds, boost::chrono::high_resolution_clock::now to source my stopwatch/stopwatchelapsedtimer concept.
You are using then V1. Do you mind defining BOOST_CHRONO_VERSION 2, before including the chrono files or on the command line, so that we can see if the issue is version speciifc? Please, post a complete example. Vicente
participants (3)
-
Brian Budge
-
Michael Powell
-
Vicente J. Botet Escriba