Skip to content

The fraction lexer consumes integer/integer before ^ and before a decimal point #1735

Description

@Wiljea

Two symptoms, one cause. The lexer builds an exact fraction out of integer / integer as soon as it sees one, without looking at what follows.

A power applied to the wrong thing

The display shows it directly — '3/2^2' renders as '(³/₂)↑2':

entered returns correct
3/2^2 2.25 0.75
8/2^3 64 1
12/2^2 36 3
3/2^3 3.375 0.375

1/2^2 looks right only by coincidence, since (1/2)ⁿ equals 1/2ⁿ; a numerator of 1 always hides the defect.

A decimal point arriving too late

entered returns
1/0.5 Divide by zero
1/0.25 Divide by zero
1/0.1 Divide by zero
5/0.2 Divide by zero
1/2.5 0.4
1/10.5 0.09523 80952 38

1/0 is taken as the fraction, and the .5 never gets its chance. Only denominators whose integer part is zero are affected.

Safe forms

A decimal numerator (3.0/2^2 returns 0.75), parentheses (3/(2^2) returns 0.75), or a non-integer denominator (3/2.0^2 returns 0.75). A symbolic denominator is safe too: 3/x^2 stays '3÷x↑2'.

Why the first symptom is the worse of the two

1/0.5 fails loudly. 3/2^2 silently returns a wrong number. Inside a density, a physical formula or a library entry that goes unnoticed, and the expression reads correctly to anyone checking it by eye.

Suggestion

Build the fraction only when the character after the denominator is neither ^ nor . — or build a division and let ordinary precedence apply, converting to an exact fraction afterwards.

Environment

cpp-ephemeris-trial, Linux simulator, DM42 target, built 2026-09-06.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions