About a year ago I ended up with a floating point value that was something like 1.0000000000078 when it should have been 1. Tore my hair out for hours trying to get the piece of crap embedded vendor locked device to just make it 1.
It's almost like some useless person created a variable with a distinct set unlikely to be higher than the hundreds as a floating point - when it obviously should have been an int.
Nah, it makes sense to use a floating point number here, since unless the test is marked out of a factor of 100 then there will likely be a fractional value as the final percentage. The mistake was not rounding the final displayed value.
The issue here lies in how it calculates each correct answer value, which is set at 1/15. This approach introduces an approximation error. When you sum all these values together, the total doesn't quite reach 1.
the pedantic answer is that, from a rigorous perspective, 99.9999999999999% isn't the same as 100% because the decimals don't repeat forever. but a more practical answer would be that they are the same number. because of how computers (usually) round numbers, the stuff showing up after the 8th decimal place is (usually) junk that can be ignored.
well 0.9999... is actually 1 because
This is muuuch better demonstrated by
1/3 = .33... 2/3 = .66... 3/3 = 0.99...
"Repeating" matters in approximations
Yes, but 0.99999999999999999999 isn't 0.999... and therefore not 1, so it's still wrong.
The software is wrong yes. I just had to share this information.
your 4th line reads as 10x^2 - x^2 = 9
You know I didn't mean it like that, but you are technically right.
First thing that came to mind was this video by SingingBanana.
Great maths channel and he is a frequently on numberphile as well.
0.999... is lim(1), not 1.
What?
1 is a constant so lim(1) = 1
it's almost like computers are not that accurate when calculating floating point numbers
About a year ago I ended up with a floating point value that was something like 1.0000000000078 when it should have been 1. Tore my hair out for hours trying to get the piece of crap embedded vendor locked device to just make it 1.
It's almost like some useless person created a variable with a distinct set unlikely to be higher than the hundreds as a floating point - when it obviously should have been an int.
Nah, it makes sense to use a floating point number here, since unless the test is marked out of a factor of 100 then there will likely be a fractional value as the final percentage. The mistake was not rounding the final displayed value.
Penmanship counts
Blame the font
The issue here lies in how it calculates each correct answer value, which is set at 1/15. This approach introduces an approximation error. When you sum all these values together, the total doesn't quite reach 1.
edit: It's actually 1/19 for each question
(1/19)*19 = 0,9999999991
But then the score should be 126.666666666667%.
Looks like a floating point error
Heh, our WMS does this. Picking through a batch and we go from 19% complete to 22.573729384674829273747% complete.
Just be glad you didn't get an, "100% required to pass" error
19.0000000000f/19.0000000000f
Is that actually mathematically the same number
the pedantic answer is that, from a rigorous perspective, 99.9999999999999% isn't the same as 100% because the decimals don't repeat forever. but a more practical answer would be that they are the same number. because of how computers (usually) round numbers, the stuff showing up after the 8th decimal place is (usually) junk that can be ignored.
an interesting example of this idea in practice has to do with the irrational number π, which nasa only approximates to 15 decimal places because that's more than enough for most of the calculations they do (the linked page gives a better and more detailed explanation).
Thank you for the very informative comment and article :)
Presumably because only God can be perfect
Computer: "You still suck, puny fleshbag."
Welcome to the secret robot Internet https://www.smbc-comics.com/comic/2013-06-05