Support mixed fractions in parser

[andy4us]

I'm using mathjs to evaluate free form text from a user. Actually input co-ordinates for a CNC. I am doing basic processing to clean up the input. However, mathjs fails on an input which is a whole number and fraction, which is common when dealing with inches and fractions. This can be tested using the "demo" on the front page of mathjs.org.

So:
-8 3/4 - causes and error
-8 - 3/4 - prints -8.75
8 + 3/4 - prints 8.75

isNumeric(-8 3/4) returns false as well

etc

As I am new to mathjs I apologise if this has been addressed before. This seems to be a defect in the parser as it is expecting an operation between the "8" and "3/4" rather than realising that this is a whole number and fraction, which to me should be a valid number.

[FSMaxB]

-8 3/4 is not a valid number in mathjs. See #693 and #370.

It looks like the reason this is currently not supported comes down to inconsistencies with implicit multiplication. x 3/4 would mean x * 3/4 whereas -8 3/4 would then mean -8 + 3/4.

[andy4us]

Whilst I agree about the comment about implied multiplication, the reality is that is that "8 3/4" meaning 8+3/4 has been around as long as the concept of implicit multiplication. This is a special case that the parser should handle, as the actual number is 8 3/4 or 8.75. In other words, 8.75 wouldn't cause an issue, but 8 3/4 would. But 8.75 == 8 3/4, so this is a problem in the parser.

8.75 (2+3) should be the same as 8 3/4 (2+3) . I don't think anyone would argue that this is 8_3/4_(2+3)

BTW, the sign between the whole and the fraction is the sign of the whole number.
That is 8 3/4 = (8+ 3/4) , but -8 3/4 = (-8-3/4)

[Nekomajin42]

@FSMaxB
How about making a difference between a fraction preceded by a number or a symbol? The former should be parsed as an addition, and the latter as a multiplication. I don't think anyone uses implicit multiplication between numbers. Am I wrong?

[FSMaxB]

ping @josdejong

[josdejong]

So far we've been very carefully with allowing implicit operations: they can easily lead to ambiguity and misinterpretations. We can certainly rethink earlier decisions.

To get a clear picture on the implications of supporting this fraction notation 8 3/4, let me put some example expressions and their meaning in a table:

Expression	Evaluated as	Remark
3/4x	(3 / 4) * x	Implicit multiplication
x 3/4	(x * 3) / 4	Implicit multiplication
8 3/4	8 + 3 / 4	Implicit addition, not yet supported
-8 3/4	-(8 + 3/4)
8 3/a	Error
8 3/4.2	Error
2*8 3/4	2 * (8 + 3/4)	This one looks odd. But it may be a bit far-fetched.
2/8 3/4	2 / (8 + 3/4)	This one looks odd. But it may be a bit far-fetched.
[1 2 3]	[1, 2, 3]	This matrix notation is not yet supported but would be cool. It would conflict with a fraction notation 8 3/4 though.

Whilst this notation could lead to weird situations, I still think it would be a really convenient one to support. For example the built in calculator of Google does support it too.

[josdejong]

@evykassirer do you have an opinion in this regard?

[evykassirer]

Anything that doesn't break existing parsing and supports new forms of input (that people will use) is a great feature in my opinion.

I don't think that Socratic needs this kind of parsing currently, but maybe it would in the future :)

[josdejong]

Thanks for your input Evy, clear.

[harrysarson]

Marking as a feature and changed issue title.

[josdejong]

I've recently done some changes in this regard, see #2370. Closing this issue. Please open a new issue if there are still related issues.