   why don't ceil and floor return ints?
  Why don't the ceil and floor functions in cmath return ints? Also, what are the rules for casting floats to ints? Does it always round to 0? Is it implementation defined?   
  My guess for the first part is because there are integral values expressible as floats that are not expressible as ints. When converting a float to an integral type, the conversion truncates: discards the fractional part. If the truncated value can't fit in the integral type, the results are undefined.   ;Quote:Why don't the ceil and floor functions in cmath return ints? Why should they? The input is a floating point type, why should the function assume you want an integer type out of it, just because the result will be an integral value? It is more useful to preserve the type of the result for subsequent calculations.   ;  Given that the calculations required to perform ceil/floor are [generally] all floating ops, converting the result for outputting an int would just be an extra step that the client may not require (ie, the client may want a float and have to convert back).On some platforms the conversion from float to int can be more expensive than the actual ceil/floor calculation as it requires a load-hit-store cycle through L1 cache (or L2, I can't remember off the top of my head), so not doing it is a performance benefit.Having said that, when the cmath standard was created, the platforms I know of that do this weren't around anyway.   ;  The range of a float is many many times greater than the range of an int![wow] You want to put the result in an integer but that doesn't mean that someone else does. For someone else, the value may not necessarily fit in an int. Having it convert twice (float to int to float) as per your line of thinking would be bad enough, but the fact that you'd lose the actual value due to overflow is pretty much the nail in the coffin for that idea.[dead]Therefore ceil etc just do one thing. If you know that your value is within the range of an int then you can choose to convert it as well.   ;  I guess because they are mathematical functions, not casting functions. Sin/cos etc. return floats, too, even though the result is always in [-1..1], and the parameters to them are not radians, but floating point numbers.   ;  My guess is the OP's question (worry) is more like this:Is it guaranteed, that the return value is rounded precisely?I mean (floor(5.2) == 5.0) == true ?or floor(5.2) == 4.9999999999999999999999999999999999999999999999999999999999999999?   ;Quote:Original post by szecsMy guess is the OP's question (worry) is more like this:Is it guaranteed, that the return value is rounded precisely?I mean (floor(5.2) == 5.0) == true ?or floor(5.2) == 4.9999999999999999999999999999999999999999999999999999999999999999?In any reasonable and commonly used floating floating point representations, integers (to some range, of course) can be exactly represented.For example, the IEEE 754 format can store any integer up to 2b, where b is the precision of the mantissa. After that, you lose lower order bits when the exponent grows, and, for example, you can only store even numbers from 2b to 2b+1, and divisors by four from 2b+1 to 2b+2, and so on.   ;Quote:Original post by szecsIs it guaranteed, that the return value is rounded precisely?Yes.Also, the only integers that can't be represented exactly in IEEE 754 format are those whose approximation can't have a fractional part anyway.   ;  Thanks,I know it's guaranteed.I just guessed that was the OP's question (or a part of it).But we may never find it out...   