By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,058 Members | 1,209 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,058 IT Pros & Developers. It's quick & easy.

Get rid of a (float) cast in timer class

P: n/a
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.

--
FreeBSD 7.0-CURRENT #2: Sat Nov 26 10:55:30 EST 2005
nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A
PGP? (updated 16 Nov 05) : http://www.clkroot.net/security/nb_root.asc

Nov 29 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a

Nicolas Blais wrote:
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.

Nov 29 '05 #2

P: n/a

roberts.n...@gmail.com wrote:
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.


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

Nov 29 '05 #3

P: n/a
On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais
<nb*****@videotron.ca> wrote in comp.lang.c++:

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 29 '05 #4

P: n/a
Ian
Nicolas Blais wrote:
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
Nov 29 '05 #5

P: n/a
On Tue, 29 Nov 2005 18:24:48 +1300, Ian <ia******@hotmail.com> wrote
in comp.lang.c++:
Nicolas Blais wrote:
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);


This will return exactly the same result as the original expression
would _without_ the cast to float, baring overflow.
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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 29 '05 #6

P: n/a
Jack Klein wrote:
On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais
<nb*****@videotron.ca> wrote in comp.lang.c++:

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.


Thank you for your explanation! I understand better my problem (and the
solution it requires)
--
FreeBSD 7.0-CURRENT #2: Sat Nov 26 10:55:30 EST 2005
nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A
PGP? (updated 16 Nov 05) : http://www.clkroot.net/security/nb_root.asc

Nov 29 '05 #7

P: n/a
Jack Klein wrote:
On Mon, 28 Nov 2005 22:46:49 -0500, Nicolas Blais
<nb*****@videotron.ca> wrote in comp.lang.c++:

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.

--
FreeBSD 7.0-CURRENT #2: Sat Nov 26 10:55:30 EST 2005
nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A
PGP? (updated 16 Nov 05) : http://www.clkroot.net/security/nb_root.asc

Nov 29 '05 #8

P: n/a
Nicolas Blais wrote:

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.

--
Karl Heinz Buchegger
kb******@gascad.at
Nov 29 '05 #9

P: n/a

Nicolas Blais wrote:
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

Nov 29 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.