Preferring real outputs

[ChristopherChudzicki]

I'm encountering behavior where math.evaluate('(-8)^(1/3)') is complex. I believe that this can be configured to some extent with the predictable configuration option, which the docs describe as:

Predictable output type of functions. When true, output type depends only on the input types. When false (default), output type can vary depending on input values. For example math.sqrt(-4) returns complex('2i') when predictable is false, and returns NaN when true. Predictable output can be needed when programmatically handling the result of a calculation, but can be inconvenient for users when evaluating dynamic equations.

Question: Is there a way to prefer real outputs when evaluating, but allow complex outputs? I.e., what I'm after would be soemthing like

math.evaluate('(-8)^(1/3)') // -2 
math.evaluate('(-4)^(1/2)') // 2i

This is what I think a reasonably well-informed high-school student would expect: they know that complex numbers exist, but would be surprised that (-8)^(1/3) yields a complex root when a real root is available.

My motivation is for largely for math parsing & evaluation at https://www.math3d.org/, which is focused on real-valued functions and inputs, though I know that some users have taken advantage of its support for complex numbers, so I am hesitant to set predictable: true in the mathjs config. At the moment, I'm suggesting cbrt for people who want real-valued behavior, though I think they'll still be surprised that 1/3 powers can be complex.

[gwhitney]

Well, yes, in general pow(z, a) is defined as exp(a ln(z)), as usual in mathematics, which helps keep everything consistent, but that does does yield one of the complex cube roots of -8. I at the moment am not having any clever ideas of a consistent alternative in which you would generally get real values for multivalued expressions that potentially have a real value, so I guess I would have to recommend that for your application you write a "realpow" function that looks for the special cases where you want to display something different and behaves accordingly. Depending on your application, you might then face the problem of getting the expression parser to execute realpow instead of pow for the ^ operator. Sadly, the function correspondences for operators are hardcoded into src/expression/parse.js (and quite possibly elsewhere, like simplify()), so they're not easily modifiable from client code. I guess for that my only suggestion is to do a transform on the parse tree between parsing and evaluation.

Or a hacky approach would be to evaluate expressions twice, with predictable off and on, and return the result you think your users will like better. (Or try it with predictable off, and if you get a complex result, try with predictable on and see if you now get a real result rather than say NaN or null or undefined...)

Sorry I don't myself have anything better to suggest. It's just hard for me to come up with another configuration option like preferReal: true that I see a way of making as smoothly consistent as the existing configuration options.

[ChristopherChudzicki]

Oof, I meant to reply to this a few weeks ago. Thanks to you and @josdejong for thoughts.

I like the replacing pow idea. Re

the function correspondences for operators are hardcoded into src/expression/parse.js

This is basically the issue mentioned in #2631, right?

[gwhitney]

Well, perhaps not quite the same as #2631, depending on your interpretation of the proposal. That issue covers the bug that if you evaluate an expression in a scope that includes a (re)definition of "pow", the built-in pow is used for occurrences of '^', not the redefined one in the scope as would be expected. But in my comments above I was imagining that you would be leaving the "pow" function alone and having another function with a different name like "realpow" but wanting to "wire up" the '^' operator to "realpow" instead of "pow". In principle there's no reason that rewiring couldn't be done as well, but it's not (currently) supported and it's a different (albeit related) issue.

So yes, another alternative would be just to replace/override the "pow" function itself; that's not what I was thinking of because I wasn't sure about all the ramifications of that, for example in terms of consistency of the library (like will log(pow(x, n)) always equal n*log(x)? that sort of thing). But if you are not worried about such things and if you do that replacement globally in the mathjs object with math.import() (rather than in the scope supplied to .evaluate) then I think that bug #2631 does not bite you and you will get your version of "pow" being called when the expression parser hits a '^' operator. So that might be your path of least resistance, but then your application has to include a disclaimer "The mathematical opinions expressed by this software are those of the author, not necessarily of mathjs. " ;-) just kidding around. Just saying there are consistency reasons like the one I mentioned for the choices of what values to return in the existing functions, that's all.

[josdejong]

Hm yeah that is interesting. The function pow (and operator ^) returns the principal root by default, but you can configure it to return the real root using predictable: true. The function nthRoot which will return the real root by default. Implementing a "prefer real" behavior would indeed require a new configuration option.

See also: #851