South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
now I am really confused.
why does floating point arithmatic use all a lot of memory and why is it slightly inaccurate?
sorry if I am being weird, alcohol.
As Cguy pointed out that floats ate calculated using log2(base 2) which is most likely why 0.2 + 0.1 is not quite 0.3 as it we would normally express it.
the reason why I asked if it using floating point/double precision numbers are similar to logs is because of the really odd answers I have been getting when using *insert language* for doing float point arithmatic.
I never knew that 1) floating point used base 2 - I need to read up on this, but I suspect it pairs number in a binary like manner, and 2) floats/double precision number are essentially scientific notation, from what I can see hence why I asked if it is similar or equal to expressing a number with a lot of decimals using a Logarithm and 3) I guess this is why standard integers should be used, especially when working with currency or time.
Correct, is pretty close to scientific notation, it’s just base 2 instead of base 10. For currency I typically use a 64-bit integer representing cents and for time a 64-bit integer for representing nanoseconds. Floating point is used for data that has a high dynamic range. I.e., the ratio of the largest to smallest number in my data is very large, and has the property that more precision is needed for smaller values than larger values.
**** you people on a Friday night...now my brain hurts reading this ****.
Correct, is pretty close to scientific notation, it’s just base 2 instead of base 10. For currency I typically use a 64-bit integer representing cents and for time a 64-bit integer for representing nanoseconds. Floating point is used for data that has a high dynamic range. I.e., the ratio of the largest to smallest number in my data is very large, and has the property that more precision is needed for smaller values than larger values.
If I may just, this would be in situations where round to the nearest second or third decimal will negate the computational error, this explains why a lot people miss this little oddity.
If I may just, this would be in situations where round to the nearest second or third decimal will negate the computational error, this explains why a lot people miss this little oddity.
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#680If I may just, this would be in situations where round to the nearest second or third decimal will negate the computational error, this explains why a lot people miss this little oddity.
This also becomes tricky when you have Invoice Lines with UnitPrice * Qty with a % based discount on the line. Then multiple lines then add VAT.
i think its pretty common in cases where there are multiples to round one down to match a solid figure.