4 ms·
Maybe, though in the paper (not the article): > We no longer receive bug reports about inaccurate results, as we occasionally did for the 2014 floating-point-b
by dgacmu 2y ago
Maybe, though in the paper (not the article):
> We no longer receive bug reports about inaccurate results, as we occasionally did for the 2014 floating-point-based calculator
(with a footnote: This excludes reports from one or two bugs that have now been fixed for many months. Unfortunately, we continue to receive complaints about
incorrect results, mostly for two reasons. Users often do not understand the
difference between degrees and radians. Second, there is no standard way
to parse calculator expressions. 1 + 10% is 0.11. 10% is 0.1. What’s 10% + 10%?)
When you have 3 billion users, I can imagine that getting rid of bugs that only affect 0.001% of your userbase is still worthwhile and probably pays for itself in reduced support costs.
- Aardwolf 2y ago> 1 + 10% is 0.11. I know adding % has multiple conventions, but this one seems odd, I'd interpret 1 + 10% as "one plus 10 percent of one" which is 1.1, or as 1 + 10 / 100 which happens to be also 1.1 here The only interpretation that'd make it 0.11 is if it represents 1% + 10%, but then the question of 10% + 10% is answered: 0.2 or 20%. Or maybe there's a typo and it was supposed to say "0.1 + 10%"
- BoiledCabbage 2y ago1 + 10% could parse like the following: (1+10)% Which is 11% or 0.11
- jtbayly 2y agoI’m confused. Why would 1 + 10% obviously be 0.11? I expected 1.1 (which is what my iOS calculator reported, when I got curious). I do understand the question of parsing. I just struggle to understand why the first one is confidently stated to correctly result in a particular answer. It feels like a perfect example itself of a problem with unclear parsing.