If You Type 1+2+3 Into Your iPhone's Calculator on iOS 11, You Probably Won't Get 6 (qz.com)

A reader shares a report: If you've upgraded your iPhone's operating system to iOS 11, try this: Go to the calculator app and quickly type 1+2+3. You likely won't get 6. You might get 23, or 24, or 16, or 32, or something else, depending on what buttons you tap and in what order, and, obviously, none of which is the right answer. It seems to be because of a new animation in the calculator app, where a button briefly fades to white when you press it. The result is that if you press an operator button (i.e., the plus sign) before the short animation finishes, the app ignores it. So, 1 + 2 + 3 accidentally gets read as 1 + 23.

Comments

First CS assignment.

[Anonymous Coward]

After a basic hello world intro, I had to write a calculator to add subtract multiply and divide in the first week of college. Had mine worked like apples Iâ(TM)d have likely failed. How does this happen?

Re:First CS assignment.

[nine-times]

How does this happen?

It explains how it happened in the summary:

It seems to be because of a new animation in the calculator app, where a button briefly fades to white when you press it. The result is that if you press an operator button (i.e., the plus sign) before the short animation finishes, the app ignores it. So, 1 + 2 + 3 accidentally gets read as 1 + 23.

It's not doing math wrong. It does a brief animation when you press a button, and it doesn't necessarily read the next button you press while the animation is happening. Therefore, if you press the calculator buttons too quickly, it won't register all the things you pressed. Based on the buttons you do press, it does the math correctly.

So if you press "1+2+3" it might miss the second "+" and register "1+23" and give you "24" as an answer.

Re:First CS assignment.

[cheesybagel]

Typical Apple. Form over function.

They already made smartphones which couldn't make phone calls, so I guess this is just one more instance in that vein.

Re:First CS assignment.

[v1]

As a developer I can see exactly how something like this can happen, and I've had variations of it happen to me numerous times over the years. This is a case of the person writing the app making assumptions about how the user interface behaves, and these assumptions turning out to be wrong OR the interface not behaving as documented. (more likely the latter)

The person that wrote the app was probably "safe to assume" that taps on the screen will be buffered during animations and other gui actions. So the app waits for you to tap, and the user taps a coordinate on the screen and your app is notified of this. You look at the location on the screen, figure out the user pressed "2, remember it, and tell the gui to do the fade on the "2" to indicate the press was accepted. Then you go back to waiting for another tap.

If in the meanwhile, the gui is displaying the fading of the "2", the user taps "3", the interface should buffer the tap, and it can either notify the app immediately (during the animation) of the new tap, OR it can wait until the animation is done and then notify the app.

I don't know which approach the gui takes. If it notifies immediately, I would expect the app to tell the gui to stop the "2" animation and start the "3" animation, as this leads to better response time. SOME apps I've seen just linearly buffer and the app won't be notified of the "3" until the "2" is done animating. In those cases you can mash a bunch of keys and then look at the screen as they are animated one at a time until all keys are animated. This is generally considered poor design but I still see it from time to time.

So what went wrong here? There's several possibilities, depending on what the gui supports.
- the gui always disables tap detection while the specific sort of animation used on the "2" is being done
- the developer used an animation api that specifically does not buffer taps when there was a buffering api available he should have used
- the application told the gui to disable buffering during the animation (or neglected to indicate it wanted buffering, if it's not the default action)
- a bug in the app caused it to not buffer taps made while the gui was still rendering an animation

There are probably a few other possibilities but that's the 99% of it. Could be a bug in the API, could be a documentation problem with the API, could be the developer used the wrong API, or used the right API in the wrong way, or got all the information he needed but just bumbled it and lost it in this specific circumstance. There's just no way to know who to blame, and I wouldn't care to take a bet either way.

But really... a user interface bug in a calculator app makes front page news on slashdot? Must be a slow news day?

Re: First CS assignment.

[BronsCon]

When AC says Honda, I'm assuming he means the in-dash navigation and radio. Imagine, for a moment, that you think you hear sirens, but you don't see flashing lights, so you decide to turn the radio down to hear them better. You can't really wait for a safe place to pull over to do that, since you may end up impeding an emergency vehicle before then, so you're stuck fumbling with the damn infotainment system and waiting for it to animate every... single... button... press... before... it... will... do... anything... else.

By the time you've turned the damn thing down enough to hear, the ambulance or fire truck is up your ass, because you had to take your eyes off the road (and your rear-view mirror) to look for the spot on the screen to touch for volume in the first place.

Can we just have fucking physical knobs and buttons back, please?

Re:First CS assignment.

[Anonymous Coward]

Typical Apple. Form over function.

It's actually the other way around - this happened for functional reasons. UIKit-based animations have an option to disable user interaction during an animation. This is switched on by default, and it has been since the very first version of the iPhoneOS SDK. It had to be switched on by default because otherwise, users who were used to double-clicking to activate things with mouse-based interfaces would trigger actions twice when double-tapping on buttons (and yes, if you watch non-technical people, absolutely loads of them double-click and double-tap even when they don't have to). Auto-disabling user interaction during animations is the smartest default.

All that's happened here is that somebody in Apple forgot to switch that option off, and it's the kind of thing that's easily missed during testing. After all, despite what people say, this isn't new to iOS 11 - the bug has been present for a couple of years now and it's only just been noticed.

Re:First CS assignment.

[hey!]

This isn't a math problem. It's basic programming; you don't rely on tests of equality between the results of floating point calculations and integer quantities.

What's going on here is that the sqrt function yields a floating point number that's close to the integer 2, and that's rounded for display down to 2. The round for display routine clearly chooses not to round if the difference is large relative to the amount. For example take the number 1000, and add .00000000001. It will display 1000.00000000001. Now do the same with 1,000,000; it will display 1,000,000 even though internally the number is 1,000,000.00000000001.

It's not an entirely unreasonably way of doing it, although most people would tend to round to a fixed number of digits.

Re:First CS assignment.

[Paradise Pete]

It's a bug. A stupid bug, but I'm sure it wasn't intentional and that they'll fix it.

Of course it's a bug, but how do you not see it within the first five minutes of testing? When I saw this earlier I thought the claim must be ridiculous, but it's actually more difficult to avoid this problem than it is to demonstrate it. I like my Apple stuff and I get a new iPhone every year, but iOS 11 and Mac OS High Sierra are rife with small disappointments and annoyances like this.

Re:First CS assignment.

[DontBeAMoran]

I have the Win10 Creators Edition and the calculator gave me this result: "I'm sorry Dave, I can't do that".

I knew Win10 was crap, but come on. My name's not Dave!

You're typing it wrong.

[aix tom]

Although I wonder if the fix would be just to be brave enough to just remove the calculator. Maths is an outdated technology anyway...

the rise of the eyecandy tards

[iggymanz]

UI and software quality is falling because of the emphasis on appearance rather than function, hence Unity and GNOME 3 and this article's stupidity.

Lesson: Blocking UI is really bad

[SuperKendall]

It's pretty funny really, because Apple makes a big deal about how app developers are not supposed to block UI, and about how to make animations interruptible. The fix will probably be pretty simple...

The calculator issue is really bad though. Even just moderately fast pressing of buttons yields input blocking depending on what you are doing.

New Apple

[DarthVain]

Here is a 1200$ super computer that fits into your pocket! Unfortunately it can't do math.

Re:Gimmicky animation is such a waste of CPU...

[rudy_wayne]

CPU time and network time should be better spent on the really important stuff that computers are supposed to do: porn.

fixed that for you.

gmail

[Misagon]

Reminds me of gmail.com's login form which has a similar bug.

If you type username and then Return, the Return does not immediately switch focus to the password field - it only starts an animation and passes focus to the password field when the animation is done.
So, if you type your password too fast, the first few characters will not end up in the password field (or not at all, if your password is short).

Bugs the hell out of me. The older login form did not have this bug.

Reminds me of the TI debacle of the early 80's

[timholman]

Texas Instruments had a similar screwup in the early 80's. After capturing a huge chunk of the U.S. calculator market (TI and HP were the brands to buy), Texas Instruments released a series of lower-cost scientific calculators where the keys were not properly debounced . It was practically impossible to type in a long equation without having multiple double or triple press errors.

I tossed mine in disgust, tried out one of the new Sharp scientific calculators just hitting the market, and never looked back. Texas Instruments basically handed over their share of the scientific calculator market to Sharp and Casio in the space of two years.

At least Apple has the advantage of being able to fix this in a software update.

Re:Unable to reproduce.

[93 Escort Wagon]

I have an iPhone 6S on iOS 11.1 beta - and this bug is damn easy to reproduce. Why on earth does a freaking animation get precedence over a button push? More importantly, why is it even blocking at all?

I'm old enough to remember typing on remote CRT terminals which were connected to a central computer over a 300 baud line (or maybe it was 110? This was back ~ 1980-1981). Back then, if you typed reasonably fast you could get ahead of the terminal's display by a few characters... but even way back then, this was a solved problem, those additional characters didn't get lost.

Re:Windows Calculator

[Obfuscant]

How strange.

Not strange at all. That is zero within "eps", and is because they are using the Intel or AMD math processor for the square root. WE look at "4" and know the square root is exactly two because we learned that. The CPU goes through a standard algorithm for determining the square root of a number, and because of the inherent imprecision of floating point math with a limited number of bits, the answer is not identical to zero because the square root of 4 is not identical to 2.

Interesting historical note:

[hey!]

This is similar in a way to the bug behind the famous Therac-25 incident. The Therac-25 as a medical radiation machine which had software which was supposed to prevent patients receiving dangerous doses of radiation. However it turned out the operators entered configuration command far faster than testers did, creating a race condition that could result in the machine delivering over 100x the safe dosage.

The bug never showed up in testing because the testers never got as fast at input as the operators, and in any case the specific keystroke combination that caused it was rare.