Enhanced keypad

[Former user]

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

[naught101]

``` agree, though not vital. ```

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

[Former user]

``` 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

[Former user]

Reported by `helder.pereira.correia` on 2007-05-22 23:52:18 - Labels added: Milestone-0.8

[Former user]

``` 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

[Former user]

Reported by `helder.pereira.correia` on 2007-11-03 19:39:53 - Labels added: Milestone-0.10 - Labels removed: Milestone-0.9

[Former user]

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

[Former user]

``` 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

[Former user]

``` 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`