conditionals with more than two conditions

[jchatkinson]

Is there a way to create conditionals with more than two conditions that render into a single bracket?

for example, see the image below.

f_y <= 60000 ? 1.0 : f_y<100000 ? 1.15 : 1.3

I am nesting a conditional within another as a workaround, but what I really want to do is condense this to a single bracket, with three states:

1. fy <=60000
2. 60000 < fy < 100000
3. otherwise

I've been having fun using math.js on a hobby project with structural engineering calculators (example) where i use the solver and tex functions to do the heavy lifting. This functionality would help improve the readability of the output

[dvd101x]

Cool project

Here is an idea by indexing with an array of booleans and then extracting the first value of the resultant array.

f_y = 1e5;
[1, 1.15, 1.3][[f_y <= 6e4, f_y < 1e5, f_y >= 1e5]][1]

For readability maybe assign significant variable names:

f_y = 1e5;
psi_values = [1, 1.15, 1.3];
psi_conditions = [f_y <= 6e4, f_y < 1e5, f_y >= 1e5];
psi_values[psi_conditions][1]

Maybe it's more convoluted than your initial solution.

[dvd101x]

Now I see that you are parsing your expression to latex and rendering on the webpage. The solution I was providing was only taking functionality in mind, not the readability of the latex result after parsing.

[jchatkinson]

thanks for having a look, but yes, the main point is to get a pretty print of the tex

[gwhitney]

I agree that multi-way conditionals are common in mathematical notation. If you are only using mathjs as a convenient means of generating visual representations of formulas, I suggest you check out https://www.plurimath.org/. If you are also actually using the computational aspects of mathjs and would also like it to produce nice multi-way conditionals, then a code issue and PR will be necessary to the best of my knowledge.

There are two possible ways I can think of off of the top of my head that such an enhancement could go:

(a) Somehow recognize certain nested ? : expressions as multi-way conditionals, only when rendering. I haven't thought too much about this, so I am not sure if this would be syntactically/semantically easy or hard: are all nested expressions equivalent to multi-way conditionals? only some? if so how do you recognize which ones? So there might be a relatively straightforward code change to the rendering that does this, although I should warn that right now the rendering code mostly just considers the current node in deciding how to render -- this would definitely have to either look down or up the tree when rendering to find the multi-way constructs, which is definitely a programming complication.

(b) Add an explicit multi-way 'cond' function à la Lisp, perhaps something like cond([f_y < 60000, 1], [f_y<100000, 1.15], 1.3) for the example above, where there could be arbitrarily many two-element [boolean, result] arguments before the (optional) otherwise_result argument. Full implementation of this would of course include its latex rendering, which would straightforwardly be what you want and not require any looking up or down the parse tree to render. I am a big fan of cond, but can't with certainty say whether Jos would welcome it into the mathjs expression language.

[jchatkinson]

Thanks for sharing your thoughts. In my case, I'm using mathjs both for computation and rendering tex. It avoids having to program the math twice, or in two languages.

There may be some situations where you truly do want a nested conditional, so it would likely be best to have an explicit way to do this as you note in (b). A function like cond() might work.

There is also a subtle issue of handling fallthrough in an expected way. For instance, in cond([f_y < 60000, 1], [f_y<100000, 1.15], 1.3) the second term assumes the first already evaluated to false, whereas we might want to explicitly identify the bounds of the second term as 60000 <= fy < 100000. Not sure if strictly necessary, but maybe it would simplify things by avoiding having to consider the other terms in constructing the bounds

[gwhitney]

Right, I would suggest that the tex rendering of a putative cond function should typeset just the formulas that have been entered in the mathjs expression, not try to get fancy and include the negation of the prior conditions (I don't think mathjs formula simplification is yet "smart" enough to produce 60 < f_y < 100 from not(f_y <= 60) & f_y < 100 and even if it can handle this case, I wouldn't trust it to give the "desired" results in general. I think typically in the "options listed next to a big curly brace" typesetting readers will typically "get it" that the second option only applies if the first didn't, and moreover, if the formula writer wants to be sure that the typeset version will be clear on this point, the formula cond([f_y <= 60, 1], [60< f_y < 100, 1.15], 1.3) could be used -- it won't hurt the computation other than doing one redundant check.

[gwhitney]

So at this point I'd wait to see if Jos is open to a cond function, either if he notices this discussion and responds, or possibly if you want to try to accelerate it by opening an issue proposing a cond function. If he's positive on it, a PR to implement it would not be too hard -- if you want any coaching on doing that, just let me know.

[josdejong]

Thanks for the nice discussion.

We could improve toTex for such that it outputs a single block in case of nested conditional operators, but I think we can only capture some specific cases and this will result in a hit-or-miss situation where (from and end users point of view) the nice Tex formatting in a single block works only sometimes. I think we should not move in that direction.

I do like the idea of a cond function 😄. We can think through what a good syntax would be, both for the underlying JavaScript function as well as the syntax in the expression parser. I would like the expression parser syntax to look like the Tex conditional block, or, say the pattern matching syntax of Rust, or the switch statements and object notation that we know in most programming languages. Here an idea:

match {
  f_y <= 60000: 1.0,
  f_y < 100000: 1.15,
  1.3
}

The name could be match, cond, condition, switch, or something like that.

The syntax for the underlying JavaScript function can be like the cond function that Glen mentions: cond([f_y < 60000, 1], [f_y<100000, 1.15], 1.3). I think I may like a more explicit API using objects instead of arrays though. That would also prevent having to deal with a mix of Array and Matrix which can have arbitrary size and dimensions, making the implementation easier:

match(
  { condition: f_y < 60000, value: 1}, 
  { condition: f_y < 100000, value: 1.15 },
  1.3
)

Or with a different naming:

condition(
  { case: f_y < 60000, value: 1}, 
  { case: f_y < 100000, value: 1.15 },
  1.3
)

Any thoughts?

[gwhitney]

Oops, I forgot, there is another alternative that would let you render nested conditionals as multi-line LaTeX alternatives with a single bracket right now, without any code changes. That is to pass a custom handler to the .toTex() method. You would need a handler that just checks if you are at a conditional, and if so, checks for the appropriate child conditional(s), and if they are there, synthesize all the options into the desired LaTeX code. Under any other circumstance, your handler should return nothing, and the standard LaTeX will be used. Using this facility is definitely your best way to generate your desired LaTeX output now without any PR or anything. If you need any further pointers or help getting the appropriate custom handler working, don't hesitate to post here. Sorry this possibility slipped my mind earlier.

[gwhitney]

(By no code changes, I mean no changes to the mathjs package. You will have to write the custom handler function, but it only needs to look for one kind of node, so it shouldn't be too bad to write.)