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.

Sign up for GitHub

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

Jump to bottom

variable named E blocks .-operators #3422

Closed
gwhitney opened this issue Mar 17, 2025 · 4 comments · Fixed by #3425 · May be fixed by #3423
Closed

variable named E blocks .-operators #3422

gwhitney opened this issue Mar 17, 2025 · 4 comments · Fixed by #3425 · May be fixed by #3423

Comments

@gwhitney
Copy link
Collaborator

Describe the bug
If a variable happens to be named E, then you cannot implicitly multiply it by a constant and then apply an operator that starts with . unless you insert whitespace.

To Reproduce

const eval = math.evaluate
const scope = {E: [1, 2]}
eval('3E', scope)  // [3, 6]
eval('E.*2', scope)  // [2, 4]
eval('3E.*2', scope)  // SyntaxError: Digit expected, got "." (char 2)
eval('3E .*2', scope)  // [6, 12]

Discussion
I understand that we don't want fractional exponential notation e.g. 3E.7 but there does not seem to be any reason to disallow a bona fide operator that happens to start with . after an expression that happens to end in E or e.
gwhitney added a commit to gwhitney/mathjs that referenced this issue Mar 18, 2025
@gwhitney
test: add test for josdejong#3422
7ee5387
@gwhitney gwhitney mentioned this issue Mar 18, 2025
Draft
@josdejong
Copy link
Owner

True, technically it is possible to allow a number right after E. However, to prevent confusion I think it is a good think to not allow implicit multiplication. To me it would be a bit confusing to see the following two similar looking expressions evaluate but do something totally different:

3E2     # evaluated as 3 * 10 ^ 2
3E2.5   # evaluated as 3 * E * 2.5 (currently throws an error)

I think it doesn't hurt to be a little bit conservative here and prevent notations that are easy to mis-read?

@gwhitney
Copy link
Collaborator Author

Sorry I think I wasn't clear. I completely agree we don't want 3E2.5. That's just too confusing. What I think we should allow is one of the per-element dot operators: I don't see any reason to ban E=[1,2]; 3E.*[2,1], which currently reports a syntax error. It seems completely unambiguous to me, and it is interpreted as 3*E .* [2,1] in the initial refactor (just tokenization systematization) #3423 successfully while passing all existing unit tests. Isn't that an improvement?

@josdejong
Copy link
Owner

Ah, yes I agree that 3E.*[2,1] should work and parse the operator .*.

josdejong added a commit that referenced this issue Mar 19, 2025
@josdejong
fix: #3422 parse dot operators after an implicit multiplication with …
35cb34a 
…symbol E
@josdejong josdejong mentioned this issue Mar 19, 2025
Merged
@josdejong
Copy link
Owner

I made a fix in #3425, can you have a look at it Glen?

gwhitney pushed a commit that referenced this issue Mar 19, 2025
@josdejong
fix: #3422 parse dot operators after an implicit multiplication with …
e5bb646 
…symbol E (#3425)
gwhitney added a commit to gwhitney/mathjs that referenced this issue Mar 19, 2025
@gwhitney
test: add test for josdejong#3422
35c9518
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@josdejong @gwhitney