Asciimath-related mathjs expression extension proposals

[gwhitney]

By now there is a fairly well established Asciimath convention for representing mathematical typography (not exactly mathematical calculation) that would suggest some further additions/features to the mathjs expression language, not to mention quite a few issues/discussions over the years for such features. So I am creating this discussion to collect such proposals that rely only on the 7-bit ASCII character set (I will create another discussion for Unicode extensions to the mathjs expression language). This can be used to survey the possibilities and hopefully at some point select those worthy of implementation and decide against others.

Notation	Meaning	AsciiMath?	Issue	Comments
P => Q <=> R	P implies Q if_and_only_if R	yes	#2660	Note that <=> on boolean values would be identical to ==. Also if we want a simplified notation for anonymous functions (e.g., to use in map) one attractive option would be x => x+1 ala JavaScript; on the other hand, the more AsciiMath consistent notation for that would be x |-> x+1. Otherwise a perfectly sensible proposal.
$	US dollar unit	no	#2673	Currently mathjs does not have built-in currency units, and as the "conversion" between them varies over time, they seem outside the scope of mathjs
r /_ theta	r*(cos(theta) + i*sin(theta))	consistent	#2698	Apparently used by engineers; seems sensible notation for polar representation of complex numbers.
x && y || z	x and y or z	no	#2722	Not clear it adds much as a built in.
|x|	abs(x)	yes	#3044	Multiply requested; a parsing nightmare with a|b being bitwise OR, and even without, is |a|b|c| parsed as abs(a)*b*abs(c) or abs(a * abs(b) *c) -- those are semantically quite different? I see two options for making this parseable: (A) Only interpret | with whitespace or string boundary immediately adjacent on exactly one side as an absolute value bar; if the whitespace or string start is on the left, then it is an "open absolute" and if whitespace or string end is on the right, it is a "close absolute". Thus the ambiguous expression above would be disambiguated as either |a| b |c| or |a |b| c|. All other | (with whitespace on both sides or neither) would be bitwise OR. Another option here would be to disallow | without any adjacent whitespace or string boundary, so bitwise OR must be set off by whitespace on both sides. (B) Follow F# and use ||| for bitwise OR (since it is infrequently used), freeing up | for absolute value. That change would still leave |a|b|c| ambiguous, so either a whitespace-based rule would be needed, or simply adopt the rule that absolute values always close as soon as possible. In other words, this expression would be disambiguated as abs(a)*b*abs(c), so if you want the other interpretation you must add parens:|(a|b|c)|. --- With | so common in mathematical notation and bitwise OR a relatively uncommonly-used operation, I would recommend serious consideration of one of these proposals or some other parseable scheme along these lines. Personally I like (B). Note also that in (B) bitwise AND is presumably &&&, potentially freeing single & for another worthwhile use.
||v||	norm(v)	no		Although oddly enough it is not in AsciiMath, double vertical bar is a very standard mathematical notation for norm. And as in mathjs the norm of a scalar is synonymous with its absolute value, this might actually provide an alternative (C) for the above: all double vertical bars would be interpreted as norm/abs, all single ones as bitwise or. One of the strategies from above would be adopted to break ||a||b||c|| ambiguity. If the final call is that single | must be kept as bitwise OR, I think this option (C) becomes my favorite.
sum_(i=1)^5 i^2	sum(range(1,5) .map(_(i)=i^2)	yes	#3075	Deserves another look as it exactly corresponds to an AsciiMath notation frequently used by mathematicians.
prod_(i=1)^5 i^2	product(range(1,5) .map(_(i)=i^2)	yes	#3075	Ditto.
x ?? y	nullish coalesce per JavaScript	no	#3353	For more consistency with JavaScript, rather than motivated by AsciiMath.
a ++ b or maybe a .+ b or a && b	concat(a, b)	no	#3401	An operator for concatenation was lost when that meaning of add was removed.
a += x and a *= x etc.	a = a + x or a = a*x etc.	no	#2721	Would be new for more consistency with JavaScript. The -= instance of this pattern is nearly in conflict with the below is congruent to meaning from AsciiMath, but perhaps the presence or absence of the (mod m) part disambiguates sufficiently, because if you meant that you wanted to subtract the remainder of y mod m from x you would write x -= y % m and if you meant that you wanted to subtract y from x and reduce the result mod m, you could write x = (x - y) % m, or possibly we could allow (x -= y) %= m, and I really don't know what else you would write for this. So I think that leaves things clear for the (mod m) suffix to mean that the preceding -= is the logical operator of congruence, not a mutating assignment operator, if we want to maximize AsciiMath consistency.
x -= y (mod m)	(x - y) % m == 0	yes		New for consistency with AsciiMath.
|_ x _|	floor(x)	yes		New, for consistency with AsciiMath
|~x~|	ceil(x)	yes		Ditto, but note that this would be a real parsing headache with | being bitwise OR and ~ being bitwise not: you would need to disambiguate w|~x|~y~| between w * ceil(bitwiseOr(x, bitwiseNot(y))) and bitwiseOr(w, bitwiseNot(x)*ceil(y)). Maybe as ceiling is a significantly less-used function than floor and ~ is not that high up in a lot of fonts, so this doesn't really look like a ceiling bracket, better to just skip this one.
|-x-|	round(x)	no		New but just brainstorming that it seemed to complete the trio of rounding directions. But could also have ambiguities with bitwise OR of the negation of x, so if the AsciiMath for ceil is not implemented, I would definitely not recommend adding this new thing. On the other hand, if bitwise OR is tripled, then all of these | digraphs become much easier to parse.
x |-> x+1	_(x) = x+1	yes		New for consistency with AsciiMath.
f'(x)	derivative(f, x)	yes		Ditto, but might be difficult to parse given that ' is also allowed for string quotes, and used for the conjugate transpose of a matrix. Maybe this would make it just too overloaded?
a uu b nn c	setUnion(a, setIntersect(b))	yes		New for consistency with AsciiMath. I personally haven't seen this much, but it would make working with sets in mathjs much easier.
a /_\ b	setSymDifference(a, b)	yes		Ditto, but the use of backslash here would probably be a pain and as symmetric difference is not that common an operation, perhaps not worth the trouble...
v o. w	dotMultiply(v,w)	yes		New for consistency with Asciimath. However, supporting this would mean disallowing whitespace after the . object accessor notation, because otherwise this would be ambiguous with v * o.w. But I would actually be fine with that, as I find obj. key to be pretty unreadable (and conversely if there is going to be whitespace there, obj .key to be much better). But it would be a breaking change.
v xx w	cross(v, w)	yes		Haven't seen this much, but very handy if you are doing 3d vector calculations.
A ox B	kron(A,B)	yes		Ditto for matrix calculations.

Please feel free to propose additional possibilities for this table or discuss any of the particular proposals above. Thanks!

[gwhitney]

Here's another proposal sufficiently different from the table above that I thought I should give it a separate entry: consider adopting some form of Civet unary function shorthand. This needs a special character to stand for that argument. Civet uses &, so if bitwise AND were tripled, that would be available to match. Even if not, $ is also available. The gist of the idea is that an expression like $+1 means the function _(x) = x+1. The function wrapper lifts to just inside the first enclosing function call or assignment.

If more easy ways to write functions are desired, Civet also has a concept of a placeholder character that makes a function call into a shorthand for a new function. Say for mathjs bare _ were the placeholder. Then log(10, _) becomes shorthand for the function b(x) = log(10, x). This notation could help with some of the mapping/broadcasting issues that have been discussed elsewhere. Now mathjs might not want to give up bare _ as a valid identifier even to this noble cause. Civet uses . but that has a lot of meanings and could be confusing in our context, although still worth considering. If we use & for the unary function shorthand above, or decide against unary function shorthand, then $ is available for this and looks sensible. If $ is taken by unary function shorthand, then ? is available and looks sensible -- a single bare ? as a function argument is distinguishable from any valid use of ternary.

The difference between the unary function shorthand and the placeholder notation is that the unary function shorthand is stopped/contained by a function call, whereas the placeholder incorporates the first enclosing function call into the definition of the function it generates, and it can only occur inside a function call. To summarize this with examples say the unary function shorthand symbol is & and the placeholder is $. Then & + 1 is a(x) = x+1, $ + 1 is illegal, sin($+1) is b(x) = sin(x+1), and sin(& + 1) is the (non-useful) sin(a(x) = x+1). The unary function shorthand is mostly useful with functions like map etc that take function arguments.

[gwhitney]

Here's another one, from the discussion in #3374: n!!. Right now, this is parsed as (n!)!, which is not very useful: since n! grows very quickly, (n!)! overflows the range of number as produces Infinity for all n > 5. The usual mathematical meaning of n!! is to multiply n by the numbers smaller than it by successive even numbers, i.e. n!! = n(n-2)(n-4).... The mathjs package should change to this standard double factorial.

[gwhitney]

A comment in the function parseStart in src/expression/parse.js suggests <> as an alias for !== that people might try. Mathjs could just support that as a direct alias, "support" it as a symbol that throws an error during parsing saying "use !==", or support it as x <> y serving as an abbreviation of x < y or x > y, which is in some cases subtly different from just x !== y. Or we can just delete the comment. I think we should take care of the comment one way or another; I guess the abbreviation for either inequality is what I would recommend, to be consistent with <= and >=.