Enhanced keypad

[heldercorreia]

Originally reported on Google Code with ID 26

SpeedCrunch doesn't have a percent button. Wouldn't that be, at least,
interesting?

Reported by email.ajj on 2007-03-02 15:17:02

[heldercorreia]

agree, though not vital.

Reported by naught101 on 2007-04-30 07:02:14

[heldercorreia]

Good sugestion, thank you. Accepted and marked and enhancement instead of defect.

Reported by helder.pereira.correia on 2007-05-12 00:09:47

• Status changed: Accepted
• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[heldercorreia]

Reported by helder.pereira.correia on 2007-05-22 23:52:18

• Labels added: Milestone-0.8

[heldercorreia]

Shifting milestone, no time/need for this for 0.8.

Reported by helder.pereira.correia on 2007-06-23 22:17:59

• Labels added: Milestone-0.9
• Labels removed: Milestone-0.8

[heldercorreia]

Reported by helder.pereira.correia on 2007-11-03 19:39:53

• Labels added: Milestone-0.10
• Labels removed: Milestone-0.9

[heldercorreia]

Reported by helder.pereira.correia on 2007-12-12 00:15:56

[heldercorreia]

from the bison grammar file:

The percent operator is really an obnoxiousness. It is used in expressions like
12+13%. Typical pocket calculators evaluate this to 12*(1+13/100); in contrast,
Speedcrunch currently takes an even simpler approach and computes 12+13/100, which
is
almost useless. So I am much in favour of changing this.

Percent calculation is vastly used in price calculations, where traders add VAT to
net prices (+19%), or grant discounts (-5%). In conjunction with operators other than
+ and -, pocket calculators usually simply divide the tagged operand by 100, assuming
users know what they are doing.
Now let's see how this can integrate into Speedcrunch's grammar. Actually, the
percent operator introduces 3 different operations:
   - a binary operation '+%' equivalent to op1*(1+op2/100)
   - a binary operation '-%' equivalent to op1*(1-op2/100)
   - a unary postfix operation (divide by 100) used elsewhere, as in 12*13%
This shows the difficulty: One time an operand is modified, the other time an
operation, and the syntax looks very much the same. That's why it is hard for a
parser to tell the difference based on syntactical rules only.
You have to treat the + and - operation specially, which breaks the uniformity of
operation handling, and makes the parser more complex. Even worse, to distinguish
between an ordinary addition (expr+expr) and a percent addition (expr+expr%), the
parser needs a 2-element look-ahead buffer, which makes the underlying grammar
finally LR(2).
One remedy to this is making the % operator syntactically always a unary postfix
operator. Then, on reduction, the operand is merely tagged as being a percent
operand, and evaluation is postponed until operands are used in a binary operation,
or the final result is presented. This keeps the LR(1) grammar, at the cost of moving
part of the syntax information out of the parser to the actions (evaluator). And that
will make the parser harder to maintain.
The cleanest solution would be to introduce two new operations +% and -%, so the user
tells the parser directly what he/she wants. This, on the other hand, is non-standard
behaviour.
So, what shall we do, make the parser overly complex and inflexible, or, instead,
violate clean programming style by scattering syntax handling code around, or, maybe,
present a user interface not known outside of SpeedCrunch's world?
Just to complicate matters even more, the percent character is a shorthand for the
modulo operator in several program languages. Again, a parsing algorithm that can
cope with this ambiguity, would be outside of the LALR(1) scope

Reported by wolf.lammen on 2007-12-19 07:40:23

[heldercorreia]

I did not add the percent button as originally intended, but refactored the whole
keypad, with smaller keys, new operators and pixmaps.
Implemented in trunk (revision 970), will be available for 0.10.

Reported by helder.pereira.correia on 2008-01-10 03:33:33

• Status changed: Fixed