GNOME Bugzilla – Bug 369503
Problems with 'arithmetic precedence mode'
Last modified: 2006-12-08 16:52:22 UTC
Arithmetic precedence mode causes quite a few problems for documentation. The words themselves is a tongue twister. The name is too complex. (I can't figure out what it's meant to mean, and I have a maths degree.) It seems one way it works like a 'classic' calculator, one number displayed at a time, and the other way it displays whole calculations. I think that's a simpler way to describe the concept that in terms of precedence. Additionally, having this as another 'mode' orthogonal to the 4 function modes means that the calculator has 4x2 modes in total. I don't see how to cover this in the manual when some operations seem to be quite different.
Adding Calum Benson, the gcalctool HCI person, for his thoughts on this.
Calum, what are your thoughts on this? Thanks.
Simplification is always good. The most obvious simplification would be to turn on arithmetic precedence mode all the time, and lose the option altogether-- do we have any evidence that our public couldn't handle that? Another option might be to turn off APM for "Simple" mode, but on for Advanced/Scientific/Financial modes. But then we might get complaints that the same calculation (e.g. 2+2*2) provides different answers in (say) Simple and Advanced modes, which is why we provide the explicit option in the first place. Third option is just better wording-- perhaps replacing the single checkbox menu item with two explicit radiobutton menu items. The HIG recommends doing this anyway if the two states aren't natural opposites, which arguably they aren't in this case. Quite what those two wordings would be is anyone's guess, though... maybe our qualified mathematician could help here? :) ("Left-to-right Precedence" vs. "Arithmetic Precedence", maybe?)
Thanks Calum. Option #1 is currently out because the arithmetic precedence mode still has some nasty bugs in it. For example bug #371669 and bug #381037, both of which only fail in AOP mode and both of which have been found recently. Unfortunately the author of the AOP code is busy on other things at the moment, and won't be able to address these problems in a timely manner. I simply don't like option #2, so let's not go there. ;-) I'm open to option #3. You're the HCI guy here, and I'll take your lead. It sounds like you would like to see the single View->Use Arithmetic Precedence checkbox (default is checked) being replaced with two radio button menu items: View->Left-to-right Precedence View->Arithmetic Precedence with the latter being the one that is initially selected. Correct? If so, then I'll start looking at a patch for that. Joachim, would that met your needs?
Having two distinct names for the two modes will be an improvement, because it makes it clearer to describe. I would also suggest moving most of the items in the 'View' menu to the 'Calculator' menu, as they don't just affect the visual display but the whole working of the calculator. The 'Calculator' menu won't suffer from extra entries ;) The question of how to present the two different modes remains. From my brief glance at it, many operations behave quite differently, so one section on, say, exponentials, really needs writing twice. I think it's clearer to split a section cleanly rather than have sentences, examples, or tables that try to explain both -- but I'm open to suggestions. Is the long-term goal to have only Arithmetic Precedence mode?
Rich: yes, that's the idea... the hard part is obviously picking good names for the two modes. I'm very open to suggestions there. Joachim: Hmm, I guess you could argue for some of those functions either way... the main criterion for something being on the View menu is that it changes the display of the *data*, but not its content-- what happens to other controls in the window isn't really a consideration (at least as far as the HIG is concerned). That said, we are in the unfortunate situation where changing modes does sometimes require the current data to be lost--albeit with an alert first. (ISTR I suggested less destructive ways of handling this in another bug report, but either they weren't possible to implement or I'm just mis-remembering...) So... I dunno. I always say that if something's hard to describe then it's probably hard to use, so if it would make the docs significantly clearer then perhaps we should consider moving them. But personally, I think everything that's currently on the View menu has a right to be there, even if moving them would make the Calculator menu look better :)
> Is the long-term goal to have only Arithmetic Precedence mode? Yes. Unfortunately we are not there yet. Knowing this, is it still worth changing the "Arithmetic Precedence" checkbox to two radio buttons? As for how to describe things like Exponential in the online Help: I'm open to help from experienced documentation writers. I went in there and made that double table entry (one for each mode) because the bugs against the documentation have been open for months and something needed to be done. If you'd like to go in and improve it, please feel free. (Personally I would have like to see Sami (the author of the arithmetic precedence mode implement expontial handling the same way that the non-arithmetic precedence mode did it, but that didn't happen.)
(In reply to comment #7) > > Is the long-term goal to have only Arithmetic Precedence mode? > > Yes. Unfortunately we are not there yet. Knowing this, is it still worth > changing the "Arithmetic Precedence" checkbox to two radio buttons? Yes. It will make it much simpler to have a name instead of having to say "non-Arithmetic Precedence". > As for how to describe things like Exponential in the online Help: > > I'm open to help from experienced documentation writers. I went in > there and made that double table entry (one for each mode) because > the bugs against the documentation have been open for months > and something needed to be done. I don't know if I count as experienced... :) Advantages of splitting a section into two rather than keeping it mixed: - the reader is probably working in one mode only, so doesn't have to keep filtering out irrelevant information - simpler to write - when we eventually have only Arithmetic Precedence mode, simpler to update the manual :) (In reply to comment #6) > So... I dunno. I always say that if something's hard to describe then it's > probably hard to use, so if it would make the docs significantly clearer then > perhaps we should consider moving them. But personally, I think everything > that's currently on the View menu has a right to be there, even if moving them > would make the Calculator menu look better :) To my mind, they are 'modes' and they affect the entire way the calculator works, not just the display of data. But moving them won't affect docs, it was only a passing thought while we were on the topic of items in that menu :)
Created attachment 77973 [details] [review] Patch to fix the problem.
Changes checked into CVS HEAD. Closing as FIXED. Thanks.