well 0.9999... is actually 1 because
x = 0.9999...
10x = 9.9999...
10x (9.9999...) - x (0.9999...) = 9
9x = 9
x = 1
so 0.9999... is 1
Welcome to /c/SoftwareGore!
This is a community where you can poke fun at nasty software. This community is your go-to destination to look at the most cringe-worthy and facepalm-inducing moments of software gone wrong. Whether it's a user interface that defies all logic, a crash that leaves you in disbelief, silly bugs or glitches that make you go crazy, or an error message that feels like it was written by an unpaid intern, this is the place to see them all!
Remember to read the rules before you make a post or comment!
Community Rules - Click to expand
These rules are subject to change at any time with or without prior notice. (last updated: 7th December 2023 - Introduction of Rule 11 with one sub-rule prohibiting posting of AI content)
You should also check out these awesome communities!
well 0.9999... is actually 1 because
x = 0.9999...
10x = 9.9999...
10x (9.9999...) - x (0.9999...) = 9
9x = 9
x = 1
so 0.9999... is 1
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.
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.
19.0000000000f/19.0000000000f
Just be glad you didn't get an, "100% required to pass" error
Presumably because only God can be perfect
Computer: "You still suck, puny fleshbag."
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 :)