unit("m ^ (1)") throws an error

[mlameiCT]

The issues section is used only for bug reports. Please use the Discussions section to ask questions and share ideas and suggestions.

Describe the bug
wrapping the power in brackets brakes unit() parser

To Reproduce

• try unit("m ^ (1)")

will throw:

SyntaxError: In "km ^ (1)", "^" must be followed by a floating-point number

[josdejong]

The parser of the function unit is quite limited. It is best to use math.parse("m ^ (1)").

[gwhitney]

Suggest moving this to a discussion rather than an issue, as it seems unlikely that there will be any action on this in the near-to-medium future. But it does raise a bigger-picture question as to why should there be any difference between math.parse('2 m^(1)') and math.unit(2, 'm^(1)')? It seems to me that in the long run, we should strive to make the two ways of creating a unit work as similarly as possible, or there should be only one way to create the unit, not two as we have now,

[josdejong]

Ideally we can use the main parser for creating units too. But it should be limited to allowing to parse units, and not arbitrary expressions 🤔. For the time being, we can look into extending the parser of Unit to allow brackets if that's simple, or see if we can improve the error message explaining that you can use parse.

On a side note: I would love to start using the library https://github.com/ericman314/unitmath instead of the internal Unit class. In that case, we will simply have a different (limited) parser that we cannot take out.

[gwhitney]

On a side note: I would love to start using the library https://github.com/ericman314/unitmath instead of the internal Unit class. In that case, we will simply have a different (limited) parser that we cannot take out.

I don't mean for this issue to turn into a discussion of that aspect of things, adopting unitmath instead of internal Unit, but is there a discussion thread specifically for that effort? If not, should one be created? I am unclear on the roadmap for that adoption (and fear that internal Unit and unitmath have diverged significantly since their point of maximum similarity), especially on issues like whether the mathjs parser will stop parsing units altogether, and instead at the appropriate points in its parsing attempt it will ask the unitmath parser whether there is a valid unit at this point in the string. That would seem to me to be the appropriate separation of concerns, but then indeed unitmath would have to handle internal brackets and so on.

But on the other hand that parsing separation seems impossible if we want mathjs to allow a=2; u = 5 m^a. So then the division line between mathjs and an external unit class becomes murky to me, which is why I currently feel like I need to defer any unit-related PRs to Jos, as I am not sure what would or would not jeopardize the conceptual project of splitting off a unit module.

[josdejong]

The discussion on UnitMath can be found here: #2739

There hasn't been any activity on it for quite some time though. The library is a bit different from Unit.js indeed, and integration wasn't trivial if I remember well.

So, for now, let's continue making small improvements in the Unit.js class like the inputs from Adriano Fantini.

I think there is no need to overengineer this: if adding bracket support to the unit parser is simple to do I think we can do that, otherwise let's try to improve the documentation on the limitations of the unit parser. So that is a short term solution.