RabbitLabs/calculator
Watch
5
0
Fork
You've already forked calculator
 0
Code Issues 21 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Use BIDMAS operator precedence for multi-operation expressions #32

New issue
Open
opened 2025-11-18 17:58:00 +00:00 by Vylpes · 5 comments
Vylpes commented 2025-11-18 17:58:00 +00:00
Owner
Copy link

Story Points: 3

Follow-up to #22 (multi-operation expressions).

Product decision (2026-10-05): BIDMAS / standard operator precedence is the only evaluation mode. The interim left-to-right behaviour is removed (not a toggle). No separate persistence or config is required.

User story

AS a calculator user
I WANT multi-operation expressions to follow standard BIDMAS precedence
SO THAT results match familiar maths rules (e.g. 5 + 2 * 6 → 17).

Acceptance criteria

  1. Default precedence (no toggle)
    GIVEN I evaluate a multi-operation expression with +, -, *, and /
    WHEN the expression is valid
    THEN * and / are applied before + and -, with left-to-right evaluation among operators of the same precedence (e.g. 8 / 2 + 3 → 7, 5 + 2 * 6 → 17).

  2. Left-to-right mode removed
    GIVEN the previous left-to-right behaviour (e.g. 5 + 2 * 6 → 42)
    WHEN this change is complete
    THEN that behaviour is no longer available and tests/docs do not describe it as supported.

  3. Shared evaluation
    GIVEN the same expression string
    WHEN evaluated through CLI and GUI
    THEN both surfaces return the same numeric result (shared evaluate logic).

  4. Operator scope
    GIVEN expressions using only the operators the app already supports (+, -, *, /)
    WHEN combined in one expression
    THEN BIDMAS rules apply consistently.

  5. Parentheses (out of scope here)
    GIVEN parenthesised expressions are not yet supported in the app
    WHEN this story is delivered
    THEN behaviour matches criteria 1–4 without requiring ( ) parsing.
    WHEN parentheses support is added in a future story
    THEN grouped sub-expressions must be evaluated before applying precedence to the rest (per @Vylpes).

  6. Errors unchanged
    GIVEN invalid expressions (malformed input, division by zero, etc.)
    WHEN evaluation runs
    THEN existing error handling and messages still apply (aligned with #22).

Subtasks

  • Implement BIDMAS evaluation for multi-operation expressions
  • Remove left-to-right multi-op evaluation paths
  • Update unit/integration tests for precedence examples
  • Verify CLI and GUI both use the updated evaluator
  • Update user-facing docs/comments that mention left-to-right

Notes

  • Depends on multi-operation evaluation from #22.
  • Decisions captured from planning thread.
Story Points: 3 --- Follow-up to [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22) (multi-operation expressions). **Product decision (2026-10-05):** BIDMAS / standard operator precedence is the **only** evaluation mode. The interim **left-to-right** behaviour is **removed** (not a toggle). No separate persistence or config is required. ## User story AS a calculator user I WANT multi-operation expressions to follow standard BIDMAS precedence SO THAT results match familiar maths rules (e.g. `5 + 2 * 6` → `17`). ## Acceptance criteria 1. **Default precedence (no toggle)** GIVEN I evaluate a multi-operation expression with `+`, `-`, `*`, and `/` WHEN the expression is valid THEN `*` and `/` are applied before `+` and `-`, with left-to-right evaluation among operators of the same precedence (e.g. `8 / 2 + 3` → `7`, `5 + 2 * 6` → `17`). 2. **Left-to-right mode removed** GIVEN the previous left-to-right behaviour (e.g. `5 + 2 * 6` → `42`) WHEN this change is complete THEN that behaviour is no longer available and tests/docs do not describe it as supported. 3. **Shared evaluation** GIVEN the same expression string WHEN evaluated through **CLI** and **GUI** THEN both surfaces return the same numeric result (shared `evaluate` logic). 4. **Operator scope** GIVEN expressions using only the operators the app already supports (`+`, `-`, `*`, `/`) WHEN combined in one expression THEN BIDMAS rules apply consistently. 5. **Parentheses (out of scope here)** GIVEN parenthesised expressions are not yet supported in the app WHEN this story is delivered THEN behaviour matches criteria 1–4 without requiring `(` `)` parsing. WHEN parentheses support is added in a future story THEN grouped sub-expressions must be evaluated before applying precedence to the rest (per @Vylpes). 6. **Errors unchanged** GIVEN invalid expressions (malformed input, division by zero, etc.) WHEN evaluation runs THEN existing error handling and messages still apply (aligned with [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22)). ## Subtasks - [ ] Implement BIDMAS evaluation for multi-operation expressions - [ ] Remove left-to-right multi-op evaluation paths - [ ] Update unit/integration tests for precedence examples - [ ] Verify CLI and GUI both use the updated evaluator - [ ] Update user-facing docs/comments that mention left-to-right ## Notes - Depends on multi-operation evaluation from [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22). - Decisions captured from [planning thread](https://git.vylpes.xyz/RabbitLabs/calculator/issues/32#issuecomment-23136).
Smithy-bot commented 2026-10-05 12:04:49 +01:00
Member
Copy link

Planning — needs/criteria

Context from #22: multi-operation evaluation shipped as left-to-right (no operator precedence). This issue is to add an option to follow BIDMAS / standard operator precedence instead.

Before acceptance criteria can be finalized, I need decisions on the following:

  1. Where should the option live? (CLI flag e.g. --bidmas, env/config file, interactive REPL command, GUI toggle, or a combination? Should all surfaces stay in sync?)
  2. Default when the option is off: confirm we keep today’s left-to-right behaviour for expressions like 5 + 2 * 6 → 42 (not 17).
  3. Default when the option is on: confirm standard precedence (*, / before +, -; left-to-right within the same precedence). Any need for parentheses in this story, or is that a separate follow-up?
  4. Scope of operators: only +, -, *, / as today, or should this story also cover anything else (modulo, powers, etc.)?
  5. Persistence: session-only toggle, or remembered across CLI/GUI sessions (and how)?

Draft criteria (pending your answers)

  • GIVEN BIDMAS mode is disabled (default)
    WHEN I evaluate a multi-operation expression
    THEN evaluation matches current left-to-right behaviour (regression-safe).

  • GIVEN BIDMAS mode is enabled
    WHEN I evaluate 5 + 2 * 6
    THEN the result is 17 (not 42).

  • GIVEN BIDMAS mode is enabled
    WHEN I evaluate 8 / 2 + 3
    THEN the result is 7 ((8 / 2) + 3).

Please reply on this issue; once the above is decided I can lock the acceptance criteria and move to needs/estimate.

@Vylpes

## Planning — needs/criteria Context from [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22): multi-operation evaluation shipped as **left-to-right** (no operator precedence). This issue is to add an **option** to follow **BIDMAS / standard operator precedence** instead. Before acceptance criteria can be finalized, I need decisions on the following: 1. **Where should the option live?** (CLI flag e.g. `--bidmas`, env/config file, interactive REPL command, GUI toggle, or a combination? Should all surfaces stay in sync?) 2. **Default when the option is off:** confirm we keep today’s left-to-right behaviour for expressions like `5 + 2 * 6` → `42` (not `17`). 3. **Default when the option is on:** confirm standard precedence (`*`, `/` before `+`, `-`; left-to-right within the same precedence). Any need for **parentheses** in this story, or is that a separate follow-up? 4. **Scope of operators:** only `+`, `-`, `*`, `/` as today, or should this story also cover anything else (modulo, powers, etc.)? 5. **Persistence:** session-only toggle, or remembered across CLI/GUI sessions (and how)? ### Draft criteria (pending your answers) - GIVEN BIDMAS mode is **disabled** (default) WHEN I evaluate a multi-operation expression THEN evaluation matches current left-to-right behaviour (regression-safe). - GIVEN BIDMAS mode is **enabled** WHEN I evaluate `5 + 2 * 6` THEN the result is `17` (not `42`). - GIVEN BIDMAS mode is **enabled** WHEN I evaluate `8 / 2 + 3` THEN the result is `7` (`(8 / 2) + 3`). Please reply on this issue; once the above is decided I can lock the acceptance criteria and move to **needs/estimate**. @Vylpes
Smithy-bot removed their assignment 2026-10-05 12:04:49 +01:00
Vylpes commented 2026-10-05 16:42:34 +01:00
Author
Owner
Copy link

@Smithy-bot wrote in #32 (comment):

Planning — needs/criteria

Context from #22: multi-operation evaluation shipped as left-to-right (no operator precedence). This issue is to add an option to follow BIDMAS / standard operator precedence instead.

Before acceptance criteria can be finalized, I need decisions on the following:

1. **Where should the option live?** (CLI flag e.g. `--bidmas`, env/config file, interactive REPL command, GUI toggle, or a combination? Should all surfaces stay in sync?)

2. **Default when the option is off:** confirm we keep today’s left-to-right behaviour for expressions like `5 + 2 * 6` → `42` (not `17`).

3. **Default when the option is on:** confirm standard precedence (`*`, `/` before `+`, `-`; left-to-right within the same precedence). Any need for **parentheses** in this story, or is that a separate follow-up?

4. **Scope of operators:** only `+`, `-`, `*`, `/` as today, or should this story also cover anything else (modulo, powers, etc.)?

5. **Persistence:** session-only toggle, or remembered across CLI/GUI sessions (and how)?

Draft criteria (pending your answers)

* GIVEN BIDMAS mode is **disabled** (default)
  WHEN I evaluate a multi-operation expression
  THEN evaluation matches current left-to-right behaviour (regression-safe).

* GIVEN BIDMAS mode is **enabled**
  WHEN I evaluate `5 + 2 * 6`
  THEN the result is `17` (not `42`).

* GIVEN BIDMAS mode is **enabled**
  WHEN I evaluate `8 / 2 + 3`
  THEN the result is `7` (`(8 / 2) + 3`).

Please reply on this issue; once the above is decided I can lock the acceptance criteria and move to needs/estimate.

@Vylpes

  1. Bidmas should become the default, left-to-right is removed
  2. See above
  3. Standard BIDMAS rules, so group DM and AS, and in brackets (once shipped) first
  4. All functions in the app
  5. N/A
@Smithy-bot wrote in https://git.vylpes.xyz/RabbitLabs/calculator/issues/32#issuecomment-23109: > ## [](#planning-needs-criteria)Planning — needs/criteria > > Context from [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22): multi-operation evaluation shipped as **left-to-right** (no operator precedence). This issue is to add an **option** to follow **BIDMAS / standard operator precedence** instead. > > Before acceptance criteria can be finalized, I need decisions on the following: > > 1. **Where should the option live?** (CLI flag e.g. `--bidmas`, env/config file, interactive REPL command, GUI toggle, or a combination? Should all surfaces stay in sync?) > > 2. **Default when the option is off:** confirm we keep today’s left-to-right behaviour for expressions like `5 + 2 * 6` → `42` (not `17`). > > 3. **Default when the option is on:** confirm standard precedence (`*`, `/` before `+`, `-`; left-to-right within the same precedence). Any need for **parentheses** in this story, or is that a separate follow-up? > > 4. **Scope of operators:** only `+`, `-`, `*`, `/` as today, or should this story also cover anything else (modulo, powers, etc.)? > > 5. **Persistence:** session-only toggle, or remembered across CLI/GUI sessions (and how)? > > > ### [](#draft-criteria-pending-your-answers)Draft criteria (pending your answers) > > * GIVEN BIDMAS mode is **disabled** (default) > WHEN I evaluate a multi-operation expression > THEN evaluation matches current left-to-right behaviour (regression-safe). > > * GIVEN BIDMAS mode is **enabled** > WHEN I evaluate `5 + 2 * 6` > THEN the result is `17` (not `42`). > > * GIVEN BIDMAS mode is **enabled** > WHEN I evaluate `8 / 2 + 3` > THEN the result is `7` (`(8 / 2) + 3`). > > > Please reply on this issue; once the above is decided I can lock the acceptance criteria and move to **needs/estimate**. > > @Vylpes 1. Bidmas should become the default, left-to-right is removed 2. See above 3. Standard BIDMAS rules, so group DM and AS, and in brackets (once shipped) first 4. All functions in the app 5. N/A
Vylpes removed their assignment 2026-10-05 16:42:44 +01:00
Smithy-bot commented 2026-10-06 12:18:02 +01:00
Member
Copy link

Planning — needs/criteria → needs/estimate

Thanks @Vylpes — your answers are incorporated into the issue description.

Locked decisions

  • BIDMAS is the only evaluation mode; left-to-right multi-op is removed (not optional).
  • Standard precedence: * / before + -, left-to-right within the same level.
  • Applies everywhere the app evaluates expressions (CLI + GUI).
  • Parentheses are out of scope for this story; when bracket support ships later, grouped sub-expressions evaluate first.

Acceptance criteria are in the issue body. Moving to needs/estimate for story points on the next planning pass.

## Planning — needs/criteria → needs/estimate Thanks @Vylpes — your answers are incorporated into the issue description. **Locked decisions** - BIDMAS is the **only** evaluation mode; left-to-right multi-op is **removed** (not optional). - Standard precedence: `*` `/` before `+` `-`, left-to-right within the same level. - Applies everywhere the app evaluates expressions (**CLI + GUI**). - Parentheses are **out of scope** for this story; when bracket support ships later, grouped sub-expressions evaluate first. Acceptance criteria are in the issue body. Moving to **needs/estimate** for story points on the next planning pass.
Smithy-bot changed title from Make an option to follow BIDMAS rules to Use BIDMAS operator precedence for multi-operation expressions 2026-10-06 12:18:02 +01:00
Smithy-bot commented 2026-10-09 12:04:31 +01:00
Member
Copy link

Planning — needs/estimate → needs/tests

Story point estimate for BIDMAS operator precedence (replacing left-to-right multi-op evaluation).

Acceptance criteria are specific enough to size. Breakdown:

Area Points
Refactor shared evaluate logic for operator precedence (*// before +/-, left-to-right within same precedence) 1
Remove left-to-right multi-op paths and update precedence examples in unit/integration tests 1
Regression pass on CLI + GUI surfaces; update docs/comments that still describe left-to-right (#22) 1
Total 3

Comparable to a focused change on top of #22 (which was sized at 5 for introducing multi-op evaluation). No toggle, config, or parentheses parsing in this story.

Setting Story Points: 3 on the issue body. Moving to needs/tests for QA scripts on the next planning pass.

## Planning — needs/estimate → needs/tests Story point estimate for BIDMAS operator precedence (replacing left-to-right multi-op evaluation). Acceptance criteria are specific enough to size. Breakdown: | Area | Points | |------|--------| | Refactor shared `evaluate` logic for operator precedence (`*`/`/` before `+`/`-`, left-to-right within same precedence) | 1 | | Remove left-to-right multi-op paths and update precedence examples in unit/integration tests | 1 | | Regression pass on CLI + GUI surfaces; update docs/comments that still describe left-to-right (#22) | 1 | | **Total** | **3** | Comparable to a focused change on top of [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22) (which was sized at 5 for introducing multi-op evaluation). No toggle, config, or parentheses parsing in this story. Setting **Story Points: 3** on the issue body. Moving to **needs/tests** for QA scripts on the next planning pass.
Smithy-bot commented 2026-10-10 12:05:36 +01:00
Member
Copy link

Planning — needs/tests → needs/approval

QA scripts mapped to the acceptance criteria in the issue body. Run after implementation; automated unit/integration tests should cover the same cases where practical.

Preconditions

  • Build succeeds on the target branch.
  • Multi-operation evaluation from #22 is present (baseline before this change).
  • You can run the CLI evaluator and open the GUI on the same build.

AC1 — Default BIDMAS precedence (no toggle)

ID Steps Expected
T1.1 CLI: evaluate 5 + 2 * 6 Result 17
T1.2 CLI: evaluate 8 / 2 + 3 Result 7
T1.3 CLI: evaluate 10 - 4 / 2 Result 8 (10 - 2)
T1.4 CLI: evaluate 3 * 2 + 5 * 2 Result 16 (left-to-right among same precedence: 6 + 10)
T1.5 GUI: enter the same expressions as T1.1–T1.4 Same numeric results as CLI

AC2 — Left-to-right mode removed

ID Steps Expected
T2.1 CLI: evaluate 5 + 2 * 6 Result is 17, not 42
T2.2 Search repo docs, README, and in-app/help text for “left-to-right” multi-op wording No documentation presents left-to-right as supported behaviour
T2.3 Confirm no CLI flag, config key, or GUI control enables legacy left-to-right mode No toggle or alternate evaluation mode exists

AC3 — Shared evaluation (CLI + GUI)

ID Steps Expected
T3.1 For each expression: 1 + 2 * 3, 20 / 4 - 1, 2 + 3 * 4 - 5 — run on CLI and GUI Identical results on both surfaces
T3.2 Code review (or debugger): CLI and GUI call the same shared evaluate (or equivalent) path Single implementation; no duplicated precedence logic

AC4 — Operator scope (+, -, *, /)

ID Steps Expected
T4.1 CLI: chained same-precedence ops, e.g. 24 / 4 / 2 Result 3 (left-to-right within /)
T4.2 CLI: mixed expression 6 + 3 * 2 - 4 / 2 Result 10 (6 + 6 - 2)
T4.3 GUI: repeat T4.1–T4.2 Same results as CLI

AC5 — Parentheses out of scope

ID Steps Expected
T5.1 If ( ) are not supported today: enter (2 + 3) * 4 on CLI/GUI Behaviour unchanged from pre-story (error or reject per existing rules) — not required to parse brackets in this story
T5.2 Document in test notes: when parentheses ship later, grouped sub-expressions must evaluate before outer precedence Captured for regression when bracket support lands

AC6 — Errors unchanged

ID Steps Expected
T6.1 CLI/GUI: malformed input (e.g. 1 + * 2, trailing operator) Same error handling/messages as before #22
T6.2 CLI/GUI: division by zero in a multi-op expression (e.g. 1 + 2 / 0) Same error handling/messages as today
T6.3 Single-operation and two-operation expressions still work (e.g. 3 + 4, 10 / 2) Unchanged correct results

Sign-off checklist

  • All T1–T6 cases pass on CLI and GUI (where applicable).
  • Unit/integration tests updated for precedence examples; CI green.
  • No user-facing reference to left-to-right multi-op evaluation remains.

Moving to needs/approval for your review before implementation. @Vylpes

## Planning — needs/tests → needs/approval QA scripts mapped to the acceptance criteria in the issue body. Run after implementation; automated unit/integration tests should cover the same cases where practical. ### Preconditions - Build succeeds on the target branch. - Multi-operation evaluation from [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22) is present (baseline before this change). - You can run the **CLI** evaluator and open the **GUI** on the same build. --- ### AC1 — Default BIDMAS precedence (no toggle) | ID | Steps | Expected | |----|--------|----------| | T1.1 | CLI: evaluate `5 + 2 * 6` | Result `17` | | T1.2 | CLI: evaluate `8 / 2 + 3` | Result `7` | | T1.3 | CLI: evaluate `10 - 4 / 2` | Result `8` (`10 - 2`) | | T1.4 | CLI: evaluate `3 * 2 + 5 * 2` | Result `16` (left-to-right among same precedence: `6 + 10`) | | T1.5 | GUI: enter the same expressions as T1.1–T1.4 | Same numeric results as CLI | --- ### AC2 — Left-to-right mode removed | ID | Steps | Expected | |----|--------|----------| | T2.1 | CLI: evaluate `5 + 2 * 6` | Result is `17`, **not** `42` | | T2.2 | Search repo docs, README, and in-app/help text for “left-to-right” multi-op wording | No documentation presents left-to-right as supported behaviour | | T2.3 | Confirm no CLI flag, config key, or GUI control enables legacy left-to-right mode | No toggle or alternate evaluation mode exists | --- ### AC3 — Shared evaluation (CLI + GUI) | ID | Steps | Expected | |----|--------|----------| | T3.1 | For each expression: `1 + 2 * 3`, `20 / 4 - 1`, `2 + 3 * 4 - 5` — run on CLI and GUI | Identical results on both surfaces | | T3.2 | Code review (or debugger): CLI and GUI call the same shared `evaluate` (or equivalent) path | Single implementation; no duplicated precedence logic | --- ### AC4 — Operator scope (`+`, `-`, `*`, `/`) | ID | Steps | Expected | |----|--------|----------| | T4.1 | CLI: chained same-precedence ops, e.g. `24 / 4 / 2` | Result `3` (left-to-right within `/`) | | T4.2 | CLI: mixed expression `6 + 3 * 2 - 4 / 2` | Result `10` (`6 + 6 - 2`) | | T4.3 | GUI: repeat T4.1–T4.2 | Same results as CLI | --- ### AC5 — Parentheses out of scope | ID | Steps | Expected | |----|--------|----------| | T5.1 | If `(` `)` are not supported today: enter `(2 + 3) * 4` on CLI/GUI | Behaviour unchanged from pre-story (error or reject per existing rules) — **not** required to parse brackets in this story | | T5.2 | Document in test notes: when parentheses ship later, grouped sub-expressions must evaluate before outer precedence | Captured for regression when bracket support lands | --- ### AC6 — Errors unchanged | ID | Steps | Expected | |----|--------|----------| | T6.1 | CLI/GUI: malformed input (e.g. `1 + * 2`, trailing operator) | Same error handling/messages as before [#22](https://git.vylpes.xyz/RabbitLabs/calculator/issues/22) | | T6.2 | CLI/GUI: division by zero in a multi-op expression (e.g. `1 + 2 / 0`) | Same error handling/messages as today | | T6.3 | Single-operation and two-operation expressions still work (e.g. `3 + 4`, `10 / 2`) | Unchanged correct results | --- ### Sign-off checklist - [ ] All T1–T6 cases pass on CLI and GUI (where applicable). - [ ] Unit/integration tests updated for precedence examples; CI green. - [ ] No user-facing reference to left-to-right multi-op evaluation remains. Moving to **needs/approval** for your review before implementation. @Vylpes
Smithy-bot removed their assignment 2026-10-10 12:05:40 +01:00
Vylpes removed their assignment 2026-10-10 12:41:38 +01:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release/0.1.0
develop
No results found.
Labels
Clear labels
  
blocked

   
duplicate

   
high priority
  
needs
approval

  
needs
criteria

  
needs
estimate

  
needs
tests

  
question
  
step
doing

  
step
review

  
step
testing

  
step
todo

  
step
uat

  
type
admin

  
type
alert

  
type
bug

  
type
change

  
type
defect

  
type
dependencies

  
type
development

  
type
documentation

  
type
epic

  
type
idea

  
type
incident

  
type
investigation

  
type
spike

  
type
story

  
type
tests

  
won't fix
No labels
blocked
duplicate
high priority
needs
approval
needs
criteria
needs
estimate
needs
tests
question
step
doing
step
review
step
testing
step
todo
step
uat
type
admin
type
alert
type
bug
type
change
type
defect
type
dependencies
type
development
type
documentation
type
epic
type
idea
type
incident
type
investigation
type
spike
type
story
type
tests
won't fix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
RabbitLabs/calculator#32
No description provided.