Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Iphone Bug IOS

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward on Friday October 27, 2017 @01:43PM (#55445755)

    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: (Score:3, Interesting)

      by Anonymous Coward

      Math is hard.
      In Windows, open the calculator and do this:
      Take the square root of 4
      Subtract 2
      You should get 0, but you don't.

      The calc app does some sort of weird floating point math (despite the fact that the square root of 4 is exactly 2 and no floating point math is needed) and comes up with an answer of

      -1.068281969439142e-19

      Math is hard

      • by H3lldr0p ( 40304 )

        Someone skipped the day(s) they were teaching about how to do significant digits in Numerical Methods.

        Like they had to skip a lot of days because that was the follow up conversation we had after each major section. As in how to tell what is and what isn't a good answer to the math we were just given to do.

      • Re: (Score:2, Informative)

        by bjohnso5 ( 1476817 )
        The Win10 calculator just gave me this result: -8.1648465955514287168521180122928e-39
      • by sexconker ( 1179573 ) on Friday October 27, 2017 @02:34PM (#55446333)

        It gets even weirder than that!

        4 @ - 2 = -8.1648465955514287168521180122928e-39 (@ is the shortcut for clicking the square root key)
        4 y .5 - 2 = 1.0605907030850721689734498566293e-38 (y is the shortcut for clicking the "x to the power of y" key)
        4 y ( 1 / 2 ) - 2 = -8.1648465955514287168521180122928e-39 (y is the shortcut for clicking the "x to the power of y" key)

        It even shows "0.5" after you type the closing parenthesis when doing 4 y ( 1 / 2 ). Yet the result differs compared to 4 y .5 - 2 (or 4 y 0.5 - 2).

        WTFOOK MS?

      • by hey! ( 33014 ) on Friday October 27, 2017 @03:52PM (#55446977) Homepage Journal

        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.

        • by Misagon ( 1135 )

          You don't round to display in a calculator in the first place. What you get in the calculator display should reflect the true value in the accumulator.

          Also, if sqrt(4.0) does not produce exactly 2.0 then there is something wrong with that code. 4.0 and 2.0 are powers of two, so there should not be any rounding when using IEEE floating point math.

    • For small values of 6 this is accurate.
    • by hawguy ( 1600213 )

      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?

      You didn't have a GUI keyboard with animated keys.

      This is why I still keep my trusty HP-15C calculator on my desk -- for when I need to do some quick arithmetic, it's still easier to use the calculator than my computer or worse (as this example shows), a phone.

      • I'm using Mathdroid, which you can get from the fdroid repo. It is easily my most used mobile app. Scrollback buffer, variable support, hitting a bare operator automatically inserts the last answer in front, etc.

        Actually, it works better than any of the linux calculators I got from a distro, ever. HP-15C is nice, and I'd probably use something similar if I didn't have Mathdroid.

    • by nine-times ( 778537 ) <nine.times@gmail.com> on Friday October 27, 2017 @02:24PM (#55446221) Homepage

      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.

      • by cheesybagel ( 670288 ) on Friday October 27, 2017 @02:28PM (#55446261)

        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.

        • Typical Apple. Form over function.

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

          They already made smartphones which couldn't make phone calls

          I'm not sure what this is referring to. The iPod touch? If so, that's not really a fair criticism. It's not meant to be a smartphone.

          • by tsqr ( 808554 )

            They already made smartphones which couldn't make phone calls

            I'm not sure what this is referring to. The iPod touch? If so, that's not really a fair criticism. It's not meant to be a smartphone.

            He's probably referring to the "You're holding it wrong" issue that resulted in Apple shipping cases to iPhone 4 owners to mitigate an antenna problem.

          • by Paradise Pete ( 33184 ) on Friday October 27, 2017 @04:03PM (#55447069) Journal

            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.

        • 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.

          They also don't grow, or even sell, apples.

        • by v1 ( 525388 ) on Friday October 27, 2017 @03:30PM (#55446827) Homepage Journal

          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?

        • by Anonymous Coward on Friday October 27, 2017 @03:33PM (#55446851)

          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.

      • by dacut ( 243842 ) on Friday October 27, 2017 @03:46PM (#55446943)

        How does this happen?

        It explains how it happened in the summary...

        I think the "this" refers to "shipping an obviously untested product."

        Part of the problem is that we (collectively) just don't get how complex software is. Sure, a good software engineer who sits down and thinks through the implications of a change will do so, but in the modern rush to market that's a rare happening. In this case, I'm guessing something like the following happened:

        • "Hey, we're getting usability reports about widgets accidentally being double tapped while an app is being swapped in. What can we do to fix this?"
        • "We would need to do this in the UIKit. Maybe some visual indication it's been tapped with a lockout period?"
        • "Ok, great. We need this by next Friday to get it into the next iOS build."
        • "That's tight, but we'll manage."
        • Builds, tests... "Ok, let's see what apps use this. Calculator..." tapping deliberately "Right, looks good, results are correct. Ready to ship."

        That said, much as we (software engineers) don't like it, there's something to be said for shipping quickly and, sometimes, before things are ready. Users reward this behavior, and shipping quickly can mean the difference between a product or company that succeeds vs. one that fails. The saying is "you can't shine shit," but I've seen countless examples otherwise (and the Mythbusters disproved this in, well, a literal sense). I hate it; despite it, in fact. Push back against it. But it's hard to argue when there's a throng of consumers ready to spend their money on it.

        So, we're relegated to having to be judicious in what we push back against. Is it safety critical? Will someone get maimed or killed by this? If it's running on an iPhone, the answer is probably no. For Apple here, the main result is a bit of embarrassment -- a calculator that seems to give wacky results. A civil engineer using this for estimating should see this kind of issue immediately (and is unlikely to use the iOS calculator for final documents). Someone trying to split their restaurant bill, maybe not, it's an acceptable risk. The Excel 2007 multiplication bug [slashdot.org] was probably more serious because that's an application that is more likely to be used in civil engineering. If you're writing software that could lethally irradiate someone [wikipedia.org] and encounter shady practices, immediately raise flags and alert everyone who will listen.

        Ok, so we're not going to manually test everything on a smart phone before a new OS is released. What can we do? Push for more automation. Making aesthetic judgements automatically might still be a bit difficult, but we ought to be able to simulate key misregistrations. A quick check would be to do this in software to see the effect of a change while you're hacking away on your laptop, but a robot providing millions of taps and swipes on actual hardware would be even more insightful. This would be daunting for most startups trying to make the next Zynbookwitter on shoestring VC funding, but child's play for the likes of Apple or Google.

    • It isn't a problem with it doing the math. It is a problem of capturing the key press. Being that the button decided to do some fancy animations I expect it just prevented the next plus button from being registered.

      • Re: (Score:3, Funny)

        by fahrbot-bot ( 874524 )

        It isn't a problem with it doing the math. It is a problem of capturing the key press. Being that the button decided to do some fancy animations I expect it just prevented the next plus button from being registered.

        It takes courage to provide an input buffer.

    • Because they are morons. i.e. OSX 10.10.5's Calculator app:

      Enter: 88.02

      Press: +/-
      Will show: -88.02000000000001

      Press: +/-
      Will show: 88.02000000000004

      This isn't rocket science just basic Computer Science. Apparently these morons haven't figured out what a sign bit is. Maybe they should talk to their iOS division ...

      --
      WhereTF is the default Calculator App on iPad??? You shipped one with iOS.

    • Did your app have buttons that fade out when you press them? No? Go back and do it again.
    • You'd have to RTFA to find out. Or I'll help you: there is a little animation and so the second "+" doesn't register. It's as if you hit "1 + 23".

      Every input device on planet earth has some maximum rate at which it can process events. If yours is slow, that's a performance problem -- in this case it looks like it was pretty crappy because the animation had to complete before you could enter the next thing.

  • by aix tom ( 902140 ) on Friday October 27, 2017 @01:44PM (#55445777)

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

  • by iggymanz ( 596061 ) on Friday October 27, 2017 @01:46PM (#55445795)

    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.

    • by AmiMoJo ( 196126 )

      Nah, it's just standard Apple quality control. Remember when the alarm clock stopped working? Multiple times? Over multiple years?

      Apple Maps, the iPhone 4 antenna, Macbook thermal paste... Apple is just as prone to fuck ups as everyone else, it's just that theirs tend to be hilarious for some reason.

      • To me, nothing tops GotoFail. Though, I still believe that was intentional since their explanation of patching caused it doesn't fail spectacularly like they claim. But it does mean, their development and QA process is shitty.
    • Would you prefer no feedback that the keypress registered? Physical keys give audible and tactile feedback. Just because they were doing it wrong doesn't mean it was the wrong thing to do.

      • Well, given that the feedback in this case is a button animation, I must be looking at the screen in order to see it... so the digits on the calculator display changing might give me some clue that my input was registered. Beyond that, the haptic feedback already provided by the phone does a fine enough job of letting me know my input was received.
        • Haptic feedback tells you that you pressed *a* button (if you leave it turned on). iPhone users are more likely to look at their typing finger than at the number display to see which button they pressed.

          I know my main Android keyboard lights up the key in addition to the haptic feedback, and it has never prevented my continued typing.

    • iOS is actually usually very good at prioritizing input and feedback, this seems to me like an anomaly that will get fixed. On the other hand, priority is never given to input on Android. Feedback to input can take forever sometimes.

      I've seen text input slow to a crawl, letters skipped, cursor jumping everywhere, words doubling all of a sudden, it's insane. Not to mention 3 or 4 different autocorrect engines running at the same time. And even with all that autocorrect going on sometimes errors are completel

    • by green1 ( 322787 )

      Which is exactly why the first thing I do on any computing device (be it a desktop, laptop, tablet, phone, or watch) is to turn off animations, or where that's impossible, speed them up as much as will be allowed. Makes everything feel far more responsive, and makes things actually work.

      Animation is not required in a UI. And no, to those who intentionally misinterpret this, that doesn't mean you don't need feedback of actions taken, just that it doesn't need to be animated. The button turning a different co

  • Animation is cancer (Score:2, Interesting)

    by Anonymous Coward

    GUI animation is the absolute cancer. It's everywhere, on desktop, in applications, on websites.
    Really feels like everything returned to the 90's web state full of animated GIFs, blinking text and endless pop-ups.
    If you're a developer, please don't be a jerk and get rid of all the animated crap, please.

  • by Anonymous Coward
    Only LUDDITES want LUDDITE accurate numbers! Modern app appers want appy numbers that let them app apps while apping other apps!

    Apps!
  • by SuperKendall ( 25149 ) on Friday October 27, 2017 @01:48PM (#55445827)

    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.

    • I expect it was a seemingly basic tweak to the existing Calculator code from iOS v. 1.0 . And it probably passed the initial Smoke test, and if they did see that problem, they probably figured that they just messed up their typing. I see it more of a fail in QA then in core architecture. These blocking events were probably put way back in 2007 or earlier, well before apple guidelines were in effect for the iPhone.
      Remember the original iPhone didn't allow custom Apps. Steve Jobs wanted everyone to make

    • I found it more depressing that my old iPad 2 originally not even had an calculator.
      I downloaded a free one and needed to block its access to the internet on cellular, so it stopped displaying advertisement.

      I guess the fix for the current iPhone is the same: download a third party calculator app. It is probably more functional complete anyway.

  • CPU time and network time should be better spent on the really important stuff that computers are supposed to do: check for app and o/s updates.

  • by Kenja ( 541830 ) on Friday October 27, 2017 @01:53PM (#55445905)
    Bug status : rejected.
    • by 93 Escort Wagon ( 326346 ) on Friday October 27, 2017 @02:55PM (#55446541)

      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.

  • New Apple (Score:5, Funny)

    by DarthVain ( 724186 ) on Friday October 27, 2017 @01:55PM (#55445921)

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

  • ... if apple had stuck to it's skeuomorphic design principles.

  • Does that mean my iphone is working correctly or incorrectly by Apple standards.
    • I just tried it too. You have to go out of your way to do things fast enough to beat the animation, and even then if you type 1+2+3 fast enough, it will just show "23" on the screen so you'll know there was an error.

      It's not like the display shows 1, then 2, then 3 but still adds 1+23. It's a minor annoyance I suppose, and should be fixed in an update, but not at all worthy of an article on Slashdot.

  • If I try this with the calculator on my Android phone, I get “+ Error: Too Few Arguments" as soon as I hit the first +. Guess what is my favourite calculator app.

  • I'm happy Apple is taking so many innovative, brave, bold moves. Their emphasis on UI, and animation, is transforming the calculator industry.

  • gmail (Score:5, Interesting)

    by Misagon ( 1135 ) on Friday October 27, 2017 @02:14PM (#55446113)

    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.

  • I pretty much never use the stock calculator app on my phones since they don't do RPN. A good HP 48G emulator is usually one of my first downloads after getting a new device.
  • Did they bury the QA team with Jobs?

  • by timholman ( 71886 ) on Friday October 27, 2017 @02:45PM (#55446457)

    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.

  • All those people were just typing the numbers wrong.
  • the other day i was trying to add my bills together and ended up at 90,000 some dollars and was like "man that better be some fast internet"
  • Another "change for the sake of change" bug created because someone wanted to be all cutesy with the calculator. Previous version worked just fine.
  • by hey! ( 33014 ) on Friday October 27, 2017 @04:11PM (#55447099) Homepage Journal

    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.

  • by AbRASiON ( 589899 ) * on Friday October 27, 2017 @05:09PM (#55447415) Journal

    Why nerds like us who are "sperglords" disable animation and flashy bullshit in applications and operating systems, ever since windows XP.

    I've been abused countless times for it, but at the end of the day, the goddamn computing device should keep up with ME. Not the other way round. I'm extremely fast on the keyboard, I know endless shortcuts, I can get things done quickly, but I need responsive tools.

    But nope, we're just "sperglords" and neck beards who should stop complaining....

You knew the job was dangerous when you took it, Fred. -- Superchicken

Working...