473,395 Members | 1,581 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,395 software developers and data experts.

Implementing a templated "round" function?

I need to implement a function to implement the rounding of floating point
values. At the moment i have two different implementations, depending on the
type of the return value (integer or double).

// Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5)
}
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}

But then I have 2 different functions for the same functionality. To solve
this, I created a template function with 2 specialisations:

template <typename T> T round(const double x);
template <>
int round(const double x) {
return iround(x);
}
template <>
double round<double>(const double x) {
return dround(x);
}

I can add specialisations for the other data types (float, long, short,
char, signed/unsigned,...) as well. I did not add a 'default'
specialisation, because the round function is only usefull for numeric
types. At this time my function accepts only double precision floating point
values, and I would like to have equivalent functions for float, double and
long double. I did add a second template parameter S for the source type:

template <typename T, typename S>
T round(const S x) {
...
}

The problem is now how do I implement this function?

I could add a specialisation for every combination of S and T, but this is a
lot of work, and there are only 4 usefull implementations possible:
- S and T are floating point type -> implementation using floor/ceil
(dround)
- S is a floating point type and T an integer type -> implementation using
static_cast (iround)
- S is an integer type and T is an integer or floating point type -> simply
static_cast to T
- otherwise no implementation is necessary (should not compile if this is
possible, to prevent e.g. round<double>(std::complex) )

I was thinking of using only one 'default' specialisation and using
std::numeric_limits:

template <typename T, typename S>
T round(const S x)
{
if (std::numeric_limits<S>::is_integer)
// Integer type needs no rounding.
return static_cast<T>(x);

// Find rounding error.
const S round_error = std::numeric_limits<S>::round_error();

if (std::numeric_limits<T>::is_integer) {
// Integer calculation (fastest).
return (x>=0 ? static_cast<T>(x + round_error) : static_cast<T>(x +
round_error)
} else {
// Floating point calculation (slower).
return (x>=0 ? floor(x + round_error) : ceil(x + round_error)
}
}

But this will results in a performance degradation if the compiler is unable
to optimize (eliminate) the 'if' statements. And the function has also an
implementation for data types other then integer and floating point types.
Any advice on this problem?

--
Jef Driesen

Jul 22 '05 #1
6 4031
"Jef Driesen" <je********@nospam.hotmail.com> wrote in message
news:cj**********@ikaria.belnet.be...
I need to implement a function to implement the rounding of floating point
values. At the moment i have two different implementations, depending on the type of the return value (integer or double).

// Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5)
}
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}
The first function looks suspect because it loses precision. Anyway, if the
true and false clauses of operator ? are the same, you can avoid the
comparison.

Anyway, have you measured the time difference?
But then I have 2 different functions for the same functionality. To solve
this, I created a template function with 2 specialisations:

template <typename T> T round(const double x);
template <>
int round(const double x) {
return iround(x);
}
Should that be

template <>
int round<int>(const double x) {
template <>
double round<double>(const double x) {
return dround(x);
}

I can add specialisations for the other data types (float, long, short,
char, signed/unsigned,...) as well. I did not add a 'default'
specialisation, because the round function is only usefull for numeric
types. At this time my function accepts only double precision floating point values, and I would like to have equivalent functions for float, double and long double. I did add a second template parameter S for the source type:

template <typename T, typename S>
T round(const S x) {
...
}

The problem is now how do I implement this function?

I could add a specialisation for every combination of S and T, but this is a lot of work, and there are only 4 usefull implementations possible:
- S and T are floating point type -> implementation using floor/ceil
(dround)
- S is a floating point type and T an integer type -> implementation using
static_cast (iround)
- S is an integer type and T is an integer or floating point type -> simply static_cast to T
- otherwise no implementation is necessary (should not compile if this is
possible, to prevent e.g. round<double>(std::complex) )

I was thinking of using only one 'default' specialisation and using
std::numeric_limits:

template <typename T, typename S>
T round(const S x)
{
if (std::numeric_limits<S>::is_integer)
// Integer type needs no rounding.
return static_cast<T>(x);

// Find rounding error.
const S round_error = std::numeric_limits<S>::round_error();

if (std::numeric_limits<T>::is_integer) {
// Integer calculation (fastest).
return (x>=0 ? static_cast<T>(x + round_error) : static_cast<T>(x +
round_error)
} else {
// Floating point calculation (slower).
return (x>=0 ? floor(x + round_error) : ceil(x + round_error)
}
}

But this will results in a performance degradation if the compiler is unable to optimize (eliminate) the 'if' statements. And the function has also an
implementation for data types other then integer and floating point types.
Any advice on this problem?


It's worthwhile to check the assembly to see if your compiler does the
optimization.

Anyway, you can put the numeric_limits::is_integer into the function or
class template argument list. Here is the idea:

template <typename T, typename S>
inline
T round(const S x) {
return generic_round<T, S,T::is_integer>(x);
}

template <typename T, typename S, bool is_integer>
inline
T generic_round(const S x);

template <typename T, typename S>
inline
T generic_round<T,S,true>(const S x) {
const S round_error = std::numeric_limits<S>::round_error();
return T(x + round_error);
}

etc
Jul 22 '05 #2

"Siemel Naran" <Si*********@REMOVE.att.net> wrote in message
news:CS*********************@bgtnsc05-news.ops.worldnet.att.net...
"Jef Driesen" <je********@nospam.hotmail.com> wrote in message
news:cj**********@ikaria.belnet.be...
I need to implement a function to implement the rounding of floating point values. At the moment i have two different implementations, depending on the
type of the return value (integer or double).

// Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5)
}
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}


The first function looks suspect because it loses precision.


IIRC the floating point representation of integer numbers is exact. If you
are talking about a possible under/overflow in the conversion from double to
int, you are correct. In the final code I will probably add code to prevent
under/overflows:

const R minimum = std::numeric_limits<int>::min();
const R maximum = std::numeric_limits<int>::max();
if (x < minimum)
return minimum;
else if (x > maximum)
return maximum;
Anyway, if the true and false clauses of operator ? are the same,
you can avoid the comparison.
This is a typo. The last "+0.5" should become "-0.5" in both functions.
Anyway, have you measured the time difference?
Yes I did and dround is (1.89 times) faster than iround, unless I
static_cast the result of dround to int (factor 0.73).
But then I have 2 different functions for the same functionality. To solve this, I created a template function with 2 specialisations:

template <typename T> T round(const double x);
template <>
int round(const double x) {
return iround(x);
}
Should that be

template <>
int round<int>(const double x) {


Another typo. But it don't think my syntax was incorrect.
template <>
double round<double>(const double x) {
return dround(x);
}

I can add specialisations for the other data types (float, long, short,
char, signed/unsigned,...) as well. I did not add a 'default'
specialisation, because the round function is only usefull for numeric
types. At this time my function accepts only double precision floating

point
values, and I would like to have equivalent functions for float, double

and
long double. I did add a second template parameter S for the source type:
template <typename T, typename S>
T round(const S x) {
...
}

The problem is now how do I implement this function?

I could add a specialisation for every combination of S and T, but this is a
lot of work, and there are only 4 usefull implementations possible:
- S and T are floating point type -> implementation using floor/ceil
(dround)
- S is a floating point type and T an integer type -> implementation
using static_cast (iround)
- S is an integer type and T is an integer or floating point type ->

simply
static_cast to T
- otherwise no implementation is necessary (should not compile if this is possible, to prevent e.g. round<double>(std::complex) )

I was thinking of using only one 'default' specialisation and using
std::numeric_limits:

template <typename T, typename S>
T round(const S x)
{
if (std::numeric_limits<S>::is_integer)
// Integer type needs no rounding.
return static_cast<T>(x);

// Find rounding error.
const S round_error = std::numeric_limits<S>::round_error();

if (std::numeric_limits<T>::is_integer) {
// Integer calculation (fastest).
return (x>=0 ? static_cast<T>(x + round_error) : static_cast<T>(x + round_error)
} else {
// Floating point calculation (slower).
return (x>=0 ? floor(x + round_error) : ceil(x + round_error)
}
}

But this will results in a performance degradation if the compiler is

unable
to optimize (eliminate) the 'if' statements. And the function has also an implementation for data types other then integer and floating point types. Any advice on this problem?


It's worthwhile to check the assembly to see if your compiler does the
optimization.


MSVC7.1 does the optimization. I don't know about other compilers.
Anyway, you can put the numeric_limits::is_integer into the function or
class template argument list. Here is the idea:

template <typename T, typename S>
inline
T round(const S x) {
return generic_round<T, S,T::is_integer>(x);
}

template <typename T, typename S, bool is_integer>
inline
T generic_round(const S x);

template <typename T, typename S>
inline
T generic_round<T,S,true>(const S x) {
const S round_error = std::numeric_limits<S>::round_error();
return T(x + round_error);
}

etc


Looks interesting to me.
Jul 22 '05 #3
> // Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5)
}
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}
Why do you think the 1st version is integer calculation and is fast? It is
floating point calculation just as the 2nd version is.

What's more, on the 80x86 platform the first version will be actually a lot
slower than the second.

Have you profiled them?

Cheers,
Marcin

But then I have 2 different functions for the same functionality. To solve
this, I created a template function with 2 specialisations:

template <typename T> T round(const double x);
template <>
int round(const double x) {
return iround(x);
}
template <>
double round<double>(const double x) {
return dround(x);
}

I can add specialisations for the other data types (float, long, short,
char, signed/unsigned,...) as well. I did not add a 'default'
specialisation, because the round function is only usefull for numeric
types. At this time my function accepts only double precision floating point values, and I would like to have equivalent functions for float, double and long double. I did add a second template parameter S for the source type:

template <typename T, typename S>
T round(const S x) {
...
}

The problem is now how do I implement this function?

I could add a specialisation for every combination of S and T, but this is a lot of work, and there are only 4 usefull implementations possible:
- S and T are floating point type -> implementation using floor/ceil
(dround)
- S is a floating point type and T an integer type -> implementation using
static_cast (iround)
- S is an integer type and T is an integer or floating point type -> simply static_cast to T
- otherwise no implementation is necessary (should not compile if this is
possible, to prevent e.g. round<double>(std::complex) )

I was thinking of using only one 'default' specialisation and using
std::numeric_limits:

template <typename T, typename S>
T round(const S x)
{
if (std::numeric_limits<S>::is_integer)
// Integer type needs no rounding.
return static_cast<T>(x);

// Find rounding error.
const S round_error = std::numeric_limits<S>::round_error();

if (std::numeric_limits<T>::is_integer) {
// Integer calculation (fastest).
return (x>=0 ? static_cast<T>(x + round_error) : static_cast<T>(x +
round_error)
} else {
// Floating point calculation (slower).
return (x>=0 ? floor(x + round_error) : ceil(x + round_error)
}
}

But this will results in a performance degradation if the compiler is unable to optimize (eliminate) the 'if' statements. And the function has also an
implementation for data types other then integer and floating point types.
Any advice on this problem?

--
Jef Driesen

Jul 22 '05 #4
"Jef Driesen" <je********@nospam.hotmail.com> wrote in message
"Siemel Naran" <Si*********@REMOVE.att.net> wrote in message
"Jef Driesen" <je********@nospam.hotmail.com> wrote in message
// Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5) }
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}
Anyway, have you measured the time difference?
Yes I did and dround is (1.89 times) faster than iround, unless I
static_cast the result of dround to int (factor 0.73).


Sorry, I'm a bit confused. I thought dround is slower. Are you saying that
dround is faster, but if you cast the return from double to int, then it is
slower?

IIRC the floating point representation of integer numbers is exact. If you
are talking about a possible under/overflow in the conversion from double to int, you are correct. In the final code I will probably add code to prevent under/overflows:

const R minimum = std::numeric_limits<int>::min();
const R maximum = std::numeric_limits<int>::max();
if (x < minimum)
return minimum;
else if (x > maximum)
return maximum;


Anyway, these checks will make iround slower, right? Maybe then dround is
better?
Jul 22 '05 #5
> > > > // Integer calculation (fast)
> int iround(const double x) {
> return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5) > }
> // Floating point calculation (slow)
> double dround(const double x) {
> return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
> } Anyway, have you measured the time difference?
Yes I did and dround is (1.89 times) faster than iround, unless I
static_cast the result of dround to int (factor 0.73).


Sorry, I'm a bit confused. I thought dround is slower. Are you saying

that dround is faster, but if you cast the return from double to int, then it is slower?
In my previous post I swapped the time values by accident. But my
conclusions where still correct. A small example:

const double x = 1.5;
double a = dround(x); // Relative time is 0.73
int b = iround(x); // Relative time is 1.00
int c = static_cast<int>(dround(x)); // Relative time is 1.89

If the result needs to stay in floating point format, dround is faster. If
the result needs a static_cast to integer, iround is faster. I need this
conversion from double to int in many of my image processing applications,
where calculations are performed on floating point numbers (to prevent
under/overflows, integer divisions,...) but the final result should be an
integer type (often unsigned char).
IIRC the floating point representation of integer numbers is exact. If you are talking about a possible under/overflow in the conversion from

double to
int, you are correct. In the final code I will probably add code to

prevent
under/overflows:

const R minimum = std::numeric_limits<int>::min();
const R maximum = std::numeric_limits<int>::max();
if (x < minimum)
return minimum;
else if (x > maximum)
return maximum;


Anyway, these checks will make iround slower, right? Maybe then dround is
better?


Of course, but if I do add these checks to iround, I should add them also in
the code above when casting the result of dround to int.
Jul 22 '05 #6
> > // Integer calculation (fast)
int iround(const double x) {
return (x>=0 ? static_cast<int>(x + 0.5) : static_cast<int>(x + 0.5)
}
// Floating point calculation (slow)
double dround(const double x) {
return (x>=0 ? floor(x + 0.5) : ceil(x + 0.5)
}
Why do you think the 1st version is integer calculation and is fast? It is
floating point calculation just as the 2nd version is.

What's more, on the 80x86 platform the first version will be actually a

lot slower than the second.

Have you profiled them?


The first version is indeed slower than the second version one, because of
the (slow) cast from double to int. But in my applications (image
processing) I need to store the results of my calculations as integers. If I
use the second version, I need a static_cast anyway. In this case it's
faster to use the first function .
Jul 22 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

36
by: Andrea Griffini | last post by:
I did it. I proposed python as the main language for our next CAD/CAM software because I think that it has all the potential needed for it. I'm not sure yet if the decision will get through, but...
81
by: Matt | last post by:
I have 2 questions: 1. strlen returns an unsigned (size_t) quantity. Why is an unsigned value more approprate than a signed value? Why is unsighned value less appropriate? 2. Would there...
1
by: Ioannis Vranos | last post by:
I was checking .NET multithreading lately, and my book mentions that the thread scheduler provides quantoms of a time to each thread in "round robin" fashion. Is there any on line reference...
29
by: Vol | last post by:
I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from -pi to pi? or I have to use some if ... else? I know in Matlab, we use...
4
by: Bob | last post by:
I have an Access application where I need to automatically forward emails to a group of 12 salespeople as soon as they arrive. The first email needs to go to the first salesperson on the list, the...
2
by: =?Utf-8?B?aGVyYmVydA==?= | last post by:
how do I code generic functions to return the next item in an enumeration a) sorted by name, b) sorted by value c) sorted by declaration in a round-robin style ? for example the enum is Enum...
94
by: Samuel R. Neff | last post by:
When is it appropriate to use "volatile" keyword? The docs simply state: " The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock...
11
by: moltendorf | last post by:
Hey everyone, as I have been by far pleased with some of the top helpers on this forum, I have decided to send another one your way. Even though I am personally having minimal issues with this...
2
by: bips2008 | last post by:
The code seems to work fine in other browser but in IE it throws this error. This is very urgent for me and any help would be greatly appreciated For your convienence i have posted the code for the...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.