Numeric_cast from int to float

Hi, I am using boost::numerical_cast to cast different numerical types in my code. Everything always seems to work as I expected except for a small thing: I always thought that the conversion from int to float could raise an exception when the int can not be properly represented as a float. However, this is not what I am gettingn in version 1.33.1. For example, in my opinion, casting -2147483647 to a float should be raising an exception but boost::numerical_cast always says that the conversion is valid and well-formed. Obviously, my boost version is a little outdated, but I can not upgrade at this time due to several constraints. My question is: is this behavior either a bug (even in newer versions of boost) or a feature? Thank you in advance. -- Hermann Rodrigues hermann@csr.ufmg.br Centro de Sensoriamento Remoto / UFMG http://www.csr.ufmg.br/dinamica

Hi,
I always thought that the conversion from int to float could raise an exception when the int can not be properly represented as a float.
Well, in this case, even casting 2 should raise an exception :|
However, this is not what I am gettingn in version 1.33.1. For example, in my opinion, casting -2147483647 to a float should be raising an exception but boost::numerical_cast always says that the conversion is valid and well-formed.
Obviously, my boost version is a little outdated, but I can not upgrade at this time due to several constraints.
My question is: is this behavior either a bug (even in newer versions of boost) or a feature?
It's more the consequences of the IEEE float representation. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher

I always thought that the conversion from int to float could raise an exception when the int can not be properly represented as a float.
Well, in this case, even casting 2 should raise an exception :|
But the IEEE spec says that every integer less than 2^24 can be exactly represented as a single precision floating point number... (http://en.wikipedia.org/wiki/Floating_point) So, I am still confident that converting integers greater that 2^24 to float using boost::numeric_cast must raise an exception. Has this behavior changed in the newer versions of Boost? Best. -- Hermann Rodrigues hermann@csr.ufmg.br Centro de Sensoriamento Remoto / UFMG http://www.csr.ufmg.br/dinamica

2009/1/26 Hermann Rodrigues
I always thought that the conversion from int to float could raise an exception when the int can not be properly represented as a float.
Well, in this case, even casting 2 should raise an exception :|
But the IEEE spec says that every integer less than 2^24 can be exactly represented as a single precision floating point number... (http://en.wikipedia.org/wiki/Floating_point)
Sorry, I may confuse with something else. At least, if you try 2.6, it will print as 2.5999...
So, I am still confident that converting integers greater that 2^24 to float using boost::numeric_cast must raise an exception. Has this behavior changed in the newer versions of Boost?
Best.
No, I don't think so, and I don't think it should raise an exception either. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher

So, I am still confident that converting integers greater that 2^24 to float using boost::numeric_cast must raise an exception. Has this behavior changed in the newer versions of Boost?
To be more accurate, this would mean testing the value in the numerical cast, as there are no ASM instruction to do this on the usual platforms. The cost that this would induce is probably too high a price to pay. I think the best course of action would be to write your own cast for this specific use. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher

On Mon, Jan 26, 2009 at 4:13 PM, Matthieu Brucher
So, I am still confident that converting integers greater that 2^24 to float using boost::numeric_cast must raise an exception. Has this behavior changed in the newer versions of Boost?
To be more accurate, this would mean testing the value in the numerical cast, as there are no ASM instruction to do this on the usual platforms. The cost that this would induce is probably too high a price to pay. I think the best course of action would be to write your own cast for this specific use.
I agree with you that testing the value in numeric_cast is a bad thing. But I think that numeric_cast is not delivering what it advertises. For me a well formed cast is always one where A can be converted to B and back to A without any lose in the representation. Unfortunately, with the current implementation A (an integer) can be converted to B (a float) but the resulting value can not be casted back to an integer representing A. Maybe It is a good idea to provide an additional implementation of a function similar to numeric_cast (say strict_numeric_cast) behaving like that. Best. -- Hermann Rodrigues hermann@csr.ufmg.br Centro de Sensoriamento Remoto / UFMG http://www.csr.ufmg.br/dinamica

AMDG Hermann Rodrigues wrote:
I agree with you that testing the value in numeric_cast is a bad thing. But I think that numeric_cast is not delivering what it advertises. For me a well formed cast is always one where A can be converted to B and back to A without any lose in the representation. Unfortunately, with the current implementation A (an integer) can be converted to B (a float) but the resulting value can not be casted back to an integer representing A.
numeric_cast is doing exactly what it is supposed to. It makes sure that the source value is within the range of the destination type. If it required reversibility, then conversion from double to float would almost always fail, for example.
Maybe It is a good idea to provide an additional implementation of a function similar to numeric_cast (say strict_numeric_cast) behaving like that.
In Christ, Steven Watanabe

Hi Hermann,
Hi,
in my opinion, casting -2147483647 to a float should be raising an exception
numeric_cast<> checks for "range" errors, ie overflow, but not for loose of significant precision. This is like so by design, and AFAICT the documentation is very clear about that. Loose of precision is not checked because (a) it is not trivial to do so *generically* and (b) looseless numeric conversions are less popular (that is, *that* should be a different function as it has a significantly different overhead) Having said that, the *policy* based conversion utility that is used by numeric_cast could be extended with an *additional* precision_check policy (to be called if the range check suceeds) that could be used to implement a "looseless_numeric_cast<>". Do you have a concrete idea about how such a policy could be implemented *generically*? HTH Fernando Cacciola http://scisoft-consulting.com http://fcacciola.50webs.com
participants (4)
-
Fernando Cacciola
-
Hermann Rodrigues
-
Matthieu Brucher
-
Steven Watanabe