It may work to treat % as a unit with just a value 0.01, or even simpler: a constant with that value. However that opens up a lot of options to use this constant in a wrong or unexpected way like dividing a value by % or so. So it may be best to treat it as a special syntax and limit parsing of % to the supported use cases.

Ah yes I had not thought too much about the consequences of % as a bare unit. But nevertheless it still might be that an internal representation as a unit percent could be useful. After all, since the character % is also the mod operator, the parsing of % as a unit abbreviation, if that ends up being how it is implemented, would have to be special, and could preclude its use as a bare unit in something like 10 / % (even though 10 / second is perfectly well allowed, and perhaps 10/percent could also be allowed even if it is silly). I think that percent as a unit rather than as just a numerical constant would be necessary to allow a special addition operation between a number and a Unit in percent; I don't see how we could have a different operation for adding two numbers depending on whether the second number "came from" a special constant number. The original motivation for the suggestion is that for Units with matching dimensions, it is OK to add them, and this would exactly work for percents; but it is currently disallowed to add a number and a Unit, even if the latter is unitless. So extending that operation to be defined for a number and a percent Unit (only in that order!) would not conflict with any existing operations, and produce the correct answer. I think this convention could handle a lot of cases, e.g.

10 + 40% + 50% == (10 + 40%) + 50% == 14 + 50% == 21, (successive markups) and

10 + (40% + 50%) == 10 + 90% == 19 (adding percentages before a single markup), etc.

So I guess my proposal could best be summarized as representing the percentage as a mathjs entity, which undergoes the usual operations (but has different results than a plain number in some cases), vs. the current approach that as far as I can see attempts to rewrite the parse tree to reflect what we want to interpret the percent symbol as "doing". I raise this proposal in the spirit of brainstorming, given the facts that mathjs has had significant ongoing difficulties with the current "syntax-tree rewriting" approach. Whoever attacks this issue can consider whether this alternate proposal has practical merit.

Note that as far as I can tell we currently have no unit symbols with BASE_UNIT.NONE, since the closest would be degree but mathjs has adopted the alternate convention (different for example from SI) that angle is a fundamental dimension like mass, as opposed to essentially a number. (Although I do think think the mathjs convention faces some hurdles, in that SI can fudge the distinction between hertz as "cycles per second" and "occurrences per second" whereas mathjs cannot: it defines "hertz" as "per second", so that 3 cycle / second is not equal to 3 hertz, which may come as a surprise to some users.) Anyhow, it does mean that there is a relatively open field as to how to interpret operations on "unitless units".

Uh oh!

Bad parse for adding percentages #3563

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions