Get rid of a (float) cast in timer class

[Nicolas Blais]

Hi,

I have this following class which I use as a timer:

#include <sys/time.h>
using namespace std;

class chrono {
public:
chrono() {};
~chrono() {};

int start();
float freeze();

private:
struct timeval before_time, after_time;
struct timeval sub_chrono;
};

int chrono::start() {
return gettimeofday(&before_time, 0);
}

float chrono::freeze() {
gettimeofday(&after_time, 0);
timersub(&after_time, &before_time, &sub_chrono);

// Possible clean up required here: Remove (float) cast.
return (sub_chrono.tv_sec + (float) sub_chrono.tv_usec / 1000000);
}

Can anyone tell me if it's possible to remove the (float) cast in freeze()'s
return? I can't seem to figure out why it will return a long (timersub
gives long, that I get) without the cast when the function is a float.
Shouldn't a long divided by 1000000 give a float without the need for a
cast?

Thanks,
Nicolas.

 

[roberts.noah]

Shouldn't a long divided by 1000000 give a float without the need for a
cast?

No. Both values are integral, therefore the result is integral.
However, a long devided by 1000000.0 results in a floater. Why?
Because 1000000.0 is a floating point while without the .0 it is an
integral. Arithmatic between integral and float results in float.

I didn't look at your code to verify that this is indeed your problem -
I'm just answering the above.

 

[Neelesh Bodas]

Because 1000000.0 is a floating point while without the .0 it is an
integral. Arithmatic between integral and float results in float.

Well, to be exact, 1000000.0 is a _double_ and not a float. The result
will thus be a double and not a float.

 

[Jack Klein]

On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais

You are using a header and data types not defined by the C++ language.
Hint, anything in the "sys" directory on a POSIX system is NOT part of
standard C or C++.

Hi,

I have this following class which I use as a timer:

#include <sys/time.h>
using namespace std;

class chrono {
public:
chrono() {};
~chrono() {};

int start();
float freeze();

private:
struct timeval before_time, after_time;
struct timeval sub_chrono;
};

int chrono::start() {
return gettimeofday(&before_time, 0);
}

float chrono::freeze() {
gettimeofday(&after_time, 0);
timersub(&after_time, &before_time, &sub_chrono);

// Possible clean up required here: Remove (float) cast.
return (sub_chrono.tv_sec + (float) sub_chrono.tv_usec / 1000000);
}

Can anyone tell me if it's possible to remove the (float) cast in freeze()'s
return? I can't seem to figure out why it will return a long (timersub
gives long, that I get) without the cast when the function is a float.
Shouldn't a long divided by 1000000 give a float without the need for a
cast?

Taking you at your word that 'sub_chrono.tv_usec' has type long, then
no, dividing a long by another integer type will never produce a
floating point type.

Division, or addition, subtraction, or multiplication between two
values of integer type might cause promotion of one of the values to
the type of the other, if they are not of the same rank, but you are
still left with two integer values of the same type. Integer math
will be performed producing a value of the same integer type as the
operands.

Assuming that tv_usec is a long with a value between 0 and 999999,
dividing it by 1000000 will always result in a quotient of 0.

But you can remove the cast by changing the 1000000 to 1000000.0,
which will cause the promotion of tv_usec to double and produce a
double result, or to 1000000F, which will promote tv_used to float and
produce a float result.

But if you actually want 6 accurate digits after the decimal point,
and some number of digits in front of it, you had better change the
return type of the function to double, and use the 1000000.0 value.
Otherwise your fraction is not likely to be accurate on most common
implementations.

 

[Ian]

float chrono::freeze() {
gettimeofday(&after_time, 0);
timersub(&after_time, &before_time, &sub_chrono);

// Possible clean up required here: Remove (float) cast.
return (sub_chrono.tv_sec + (float) sub_chrono.tv_usec / 1000000);
}

Can anyone tell me if it's possible to remove the (float) cast in freeze()'s
return? I can't seem to figure out why it will return a long (timersub
gives long, that I get) without the cast when the function is a float.
Shouldn't a long divided by 1000000 give a float without the need for a
cast?

No, it will do an integer division.

To remove the cast, change it to

return ((ub_chrono.tv_sec*1000000+sub_chrono.tv_usec)/1000000);

Which could overflow a 32 bit int, so maybe assign ub_chrono.tv_sec to a
64 bit int before the multiplication.

Also consider using double rather than float.

Ian

 

[Jack Klein]

No, it will do an integer division.

To remove the cast, change it to

return ((ub_chrono.tv_sec*1000000+sub_chrono.tv_usec)/1000000);

This will return exactly the same result as the original expression
would _without_ the cast to float, baring overflow.

 

[Nicolas Blais]

On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais

You are using a header and data types not defined by the C++ language.
Hint, anything in the "sys" directory on a POSIX system is NOT part of
standard C or C++.


Taking you at your word that 'sub_chrono.tv_usec' has type long, then
no, dividing a long by another integer type will never produce a
floating point type.

Division, or addition, subtraction, or multiplication between two
values of integer type might cause promotion of one of the values to
the type of the other, if they are not of the same rank, but you are
still left with two integer values of the same type. Integer math
will be performed producing a value of the same integer type as the
operands.

Assuming that tv_usec is a long with a value between 0 and 999999,
dividing it by 1000000 will always result in a quotient of 0.

But you can remove the cast by changing the 1000000 to 1000000.0,
which will cause the promotion of tv_usec to double and produce a
double result, or to 1000000F, which will promote tv_used to float and
produce a float result.

But if you actually want 6 accurate digits after the decimal point,
and some number of digits in front of it, you had better change the
return type of the function to double, and use the 1000000.0 value.
Otherwise your fraction is not likely to be accurate on most common
implementations.

Thank you for your explanation! I understand better my problem (and the
solution it requires)

 

[Nicolas Blais]

On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais

You are using a header and data types not defined by the C++ language.
Hint, anything in the "sys" directory on a POSIX system is NOT part of
standard C or C++.

Taking you at your word that 'sub_chrono.tv_usec' has type long, then
no, dividing a long by another integer type will never produce a
floating point type.

Division, or addition, subtraction, or multiplication between two
values of integer type might cause promotion of one of the values to
the type of the other, if they are not of the same rank, but you are
still left with two integer values of the same type. Integer math
will be performed producing a value of the same integer type as the
operands.

Assuming that tv_usec is a long with a value between 0 and 999999,
dividing it by 1000000 will always result in a quotient of 0.

But you can remove the cast by changing the 1000000 to 1000000.0,
which will cause the promotion of tv_usec to double and produce a
double result, or to 1000000F, which will promote tv_used to float and
produce a float result.

But if you actually want 6 accurate digits after the decimal point,
and some number of digits in front of it, you had better change the
return type of the function to double, and use the 1000000.0 value.
Otherwise your fraction is not likely to be accurate on most common
implementations.

I've fixed my class with your help:

#include <ctime>
#include <sys/time.h> // Must try to get rid of this as it could be
BSD/Linux specific
using namespace std;

class chrono {
public:
chrono() {};
~chrono() {};

int start();
double freeze();

private:
struct timeval before_time, after_time;
struct timeval sub_chrono;
};


int chrono::start() {
return gettimeofday(&before_time, 0);
}

double chrono::freeze() {
gettimeofday(&after_time, 0);
timersub(&after_time, &before_time, &sub_chrono);

return (sub_chrono.tv_sec + sub_chrono.tv_usec / 1000000.0);
}

Now you mentionned that using <sys/time.h> breaks portability. Before I
resorted to <sys/time.h>, I actually had a class that used <ctime>, but
unfortunatly I wasn't able to get better than .2 digits precision (such as
45.99). With <sys/time.h>, I'm able to get .5 digits precision (such as
45.98676).

Of course, I would rather have my code work on most machines instead of only
the ones I'm working on. Does anyone have a suggestion for using <ctime>
with the same precision as <sys/time.h> ?

Thanks,
Nicolas.

 

[Karl Heinz Buchegger]

Now you mentionned that using <sys/time.h> breaks portability. Before I
resorted to <sys/time.h>, I actually had a class that used <ctime>, but
unfortunatly I wasn't able to get better than .2 digits precision (such as
45.99). With <sys/time.h>, I'm able to get .5 digits precision (such as
45.98676).

That most likely was a leftover from 'float'.
Now that you have switched to double you got more presicion.

As a rule of thumb:

You should not use 'float' unless you
* you know what you do
* have the knowledge to fight that beast
* are willing to fight that beast
* have a very, very, very good reason
Use double instead.

 

[KeithSpook]

Now you mentionned that using <sys/time.h> breaks portability. Before I
resorted to <sys/time.h>, I actually had a class that used <ctime>, but
unfortunatly I wasn't able to get better than .2 digits precision (such as
45.99). With <sys/time.h>, I'm able to get .5 digits precision (such as
45.98676).

Of course, I would rather have my code work on most machines instead of only
the ones I'm working on. Does anyone have a suggestion for using <ctime>
with the same precision as <sys/time.h> ?

You may want to take a look at Boost.Date_Time
(http://www.boost.org/doc/html/date_time.html). It has decent
precision and portability.

~KS