Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decimals and Fractions #61

Open
edpickup opened this issue Jan 24, 2018 · 3 comments
Open

Decimals and Fractions #61

edpickup opened this issue Jan 24, 2018 · 3 comments

Comments

@edpickup
Copy link

edpickup commented Jan 24, 2018

In the specification you say

If a sequence of characters could be interpreted as an decimal or a fraction, then fraction should have precedence.

Can you clarify how the following sequence should be parsed:
5.5/45
Is the correct way to parse this as 5. then 5/45?
How about the example
5/5.5
Should this be parsed as 5/5 (fraction) and 5 (decimal)

How should a compounded fraction such as 3/5/4 be parsed? Is reading that as 3/5 (fraction) and 4 (decimal) the correct response?

I'm probably over thinking this but wanted to check.

@m8pple
Copy link
Contributor

m8pple commented Jan 24, 2018

A common mis-conception when humans think about lexing is the temptation to look ahead.
So we see something like:

5.5/45

and can see the fraction coming along. However, that is because we are cursed
with semantic understanding, pattern recognition, and (possibly) free will.

From the lexers point of view, it is taking an extremely narrow view of things,
and only ever looks at one character at a time.

So the lexer's view is:

  • 5 : Could be starting a decimal or a fraction.
  • 5. : Cannot possibly be a fraction, as a fraction has a sequence of decimal digits, then /. Only
    possible interpretation is decimal with fractional part.

Which leads to your interpretation:
> Is the correct way to parse this as 5. then 5/45?
Yes, that is correct.

So your original interpretation:

Is the correct way to parse this as 5. then 5/45?
is not correct. As soon as we hit the . it cannot be a fraction,
so the only valid derivation is a decimal. (see comment below).

For the second example of 1/2.3, the lexer is going to move along
as follows:

  • 1 : Could be starting a decimal or a fraction
  • 1/ : Could be decimal 1 and unimportant /, or fraction 1/?
  • 1/2 : 1/2 is a legal fraction, so the shorter match 1 is no longer acceptable. However, could still
    be 1/2?.
  • 1/2. : Must be the fraction 1/2, then an unimportant character .

Notice that the lexer doesn't get to the final 3 before making the decision, as
it only ever looks character by character.


Notice that this is different to how it would be lexed in C, as C has no concept of
a literal (constant) fraction. So in the case of C, the characters 1/2.3 would actually
be lexed as something like Integer[1] OpDivide Float[2.3]. So C does not support
fractions, but it does support the idea of numeric constants and operators.

@edpickup
Copy link
Author

I think I must be missing something, as based on the worked through example, wouldn't the lexer's response to 5.5/45 be as follows

  • 5 : Could be starting decimal or fraction
  • 5. : Could be decimal 5 and unimportant . or decimal 5.?
  • 5.5 : Could be decimal 5.5 or '5.5?'
  • 5.5/ : Must be decimal 5.5 then an unimportant character /

I ask as this is currently how my program appears to lex 5.5/45

@m8pple
Copy link
Contributor

m8pple commented Jan 24, 2018

Gah - yes, I misread your original text when I quoted it, probably
confirmation bias on my part.

You're right, your original answer doesn't actually follow my derivation
that appears above it.

So the derivation as I gave it is sufficient to determine it is not a fraction, and then
your derivation continues it all the way throught to say where exactly the decimal
number ends.

I'll correct my previous comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants