You are not logged in. Please login or register.
Hi
I am confused here. Just check out the below execution:
irb(main):008:0> 0.29*100
=> 29.0
irb(main):009:0> a = 0.29*100
=> 29.0
irb(main):010:0> a.to_i
=> 28
irb(main):011:0> (29.0).to_i
=> 29
What is wrong here ?
a.to_i gives 28 , while (29.0).to_i gives 29
Am i being stuppid asking this.. I am not sure, but I am confused with this. Please explain.
Ruby follows the IEEE standard, which, although the fastest method available, isn't entirely reliable. You will get the same error in almost any language that follows the standard.
You'd be better off avoiding floating point numbers where possible, and if you do have to convert float to integer, you'd be better off converting it to string first and then integer.
irb(main):009:0> a = 0.29*100
=> 29.0
irb(main):010:0> a.to_i
=> 28
irb(main):011:0> a.to_s.to_i
=> 29That sounds silly, but that's more reliable I guess.
I disagree that you should avoid floating point numbers, they are an essential tool for mathematics. You just need to appreciate that, as in any real life measurement, floating point numbers have a degree of accuracy (or a degree of inaccuracy if you like). It's like the following pitfall:
"I have 31 sheets of card, all seemingly identical. I want to know how thick each one is. I measure them and the total thickness is 17 millimeters. Therefore the thickness of each is 17/31 = 0.548387096774194 mm."
Do you see how this is a ridiculous claim to make? There is no way we can claim to know the thickness of the sheets of cardboard to 20 (or whatever) places, and at this degree of precision there would be massive variation between sheets.
So, don't avoid floating point numbers, just be aware when converting them to integers that you may get unpredictable results. The unpredictability can be minimised by using .round instead of .to_i though:
>> (0.29*100).to_i
=> 28
>> (0.29*100).round
=> 29
Hi Max. I'm sorry I didn't make myself clearer. By "avoiding floating point numbers where possible", I meant such cases as financial transactions, where you can actually use integers to better effect. I know it's not possible to avoid floats in the vast majority of cases but when you're counting money, you can always convert dollars to cents and then you don't run the risk of these errors.
If you need precise mathematics with floats use BigDecimal.