add a √ character to the pool of operators

[bmansfie]

Not a character typically available from standard keyboards. I'm using this library as a backend for a calculator and it makes a lot more sense to use an operator here rather than function names like nthRoot() and sqrt(). Especially nthRoot is much less intuitive. My cursory testing has shown that the changes function as desired.

There is a precedence problem though between the unary square root operator and the n root operator.

√4√4 results in √(4√4) instead of the desired (√4)√4. It's a narrow case and it isn't obvious to me how to fix it inside of your precedence system so I'm ignoring it for the moment in favor of more pressing defects in my own code base.

[josdejong]

Thanks for your PR Brandon, nice idea to add support for √ to do things like √4.

I'm not sure about using √ for nthRoot too, it may be too ambiguous. I suppose we enter nthRoot(8,3) as 3√8 and not as 8√3?. √4√4 should indeed work like (√(4))*(√(4)). People may be surprised to find that 3√8 is not evaluated as a regular multiplication 3 * √(8) but as nthRoot.

An alternative solution would be to only support notations like √4 and √(4) for sqrt, and √(8,3) for nthRoot but I don't know whether that would be satisfying your application.

[bmansfie]

It may be that users would prefer 3√8 to be 3*√8. I won't know until I get a real user base and they voice their preferences. Some users may find that particular ambiguity confusing, removing the unary operation entirely and making people use 2√9 as if it was a direct inversion of the ^ operator might be preferable for habit's sake. I'm sort of winging it with small test user reports on individual bits of functionality, so far this is going over much better than the full function names.

…

On Sat, Dec 31, 2016 at 5:14 AM, Jos de Jong ***@***.***> wrote: Thanks for your PR Brandon, nice idea to add support for √ to do things like √4. I'm not sure about using √ for nthRoot too, it may be too ambiguous. I suppose we enter nthRoot(8,3) as 3√8 and not as 8√3?. √4√4 should indeed work like (√(4))*(√(4)). People may be surprised to find that 3√8 is not evaluated as a regular multiplication 3 * √(8) but as nthRoot. An alternative solution would be to only support notations like √4 and √(4) for sqrt, and √(8,3) for nthRoot but I don't know whether that would be satisfying your application. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#767 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AK3mLufoTXL3FXFDWAoPAN9fTzuL2UI4ks5rNkc1gaJpZM4LWpZL> .

[josdejong]

Shall we give this a bit more thought and see whether you can collect more feedback from your users on this subject?

[bmansfie]

That's fine, I just thought I would submit back to you what I is, so far, a useful tweak. If you want to wait a bit for it to potentially settle down I'm fine with that. I'm looking at probably at least a month before I'll know anything more. Brandon

…

On Tue, Jan 3, 2017 at 12:37 PM, Jos de Jong ***@***.***> wrote: Shall we give this a bit more thought and see whether you can collect more feedback from your users on this subject? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#767 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AK3mLnLTqBAn2_wHUZEjrwKcaOE5J-NTks5rOqOQgaJpZM4LWpZL> .

[josdejong]

Thanks for the feedback! No time pressure on my side - it's an open source project :D

[infusion]

I like the idea of adding unicode symbols as actual operators. But I'm against 3√8 being pow(8,1/3)! I would see it as syntactical sugar for a square-root with literal. Even √(123 + 888) looks pretty strange, since the top-line you normally would have is not there as an indicator.

[josdejong]

Thanks for sharing your thoughts @infusion , I agree with you, I think 3√8 would be confusing.

[josdejong]

Any news on this?

I'm still in for using √ as an alias for sqrt, but not for using it like 3√8.

[infusion]

3√8 is clear in the way that it means 3*sqrt(8) I think, especially since it is a quite common form to write in math when factored out 3*3. I would prefer the following syntax:

• Allow "√const", meaning sqrt(const)
• Disallow "√expression"
• Allow "expr√const", meaning expr*sqrt(const)
• Parser SHOULD bind the const to the sqrt symbol. (√4)√4should be incorrect syntax, but √4√4 is ok.

[josdejong]

I agree with you @infusion .

I'm not sure what you mean with your fourth bullet, shouldn't (√4)√4 be interpreted as an implicit multiplication (√4) * √4?

[infusion]

"√4√4 results in √(4√4) instead of the desired (√4)√4." from the initial message of the PR. It was just an expression that I second that behavior.

[josdejong]

ehhh, so you also want to interpret √4√4 as (√4)*(√4) and not as √(4 * √4) too? In that case we're on the same page.

I would give √ a very high precedence, the same as factorial ! and transpose ', and higher than multiplication and power. That will result in the desired behavior.

(See reference docs on operator preference: http://mathjs.org/docs/expressions/syntax.html#precedence)

[FSMaxB]

Then what does √4! mean?

[josdejong]

We have to decide whether √ or ! has highest precedence. Both is fine with me, I have a slight preference for giving √ the highest precedence, i.e. evaluate it as (√4)!. We should look around and see what other calculators/math applications do in this case, see if there is already a standard behavior there.

[FSMaxB]

I personally would also give √ higher precedence.

List of other calculators I've tested:

• gnome-calculator: ! has higher precedence.
• google: ! has higher precedence (used sqrt instead of √)
• wolfram-alpha: √ has higher precedence, but when typing (without typing enter) it randomly does one or the other
• android calculator (LineageOS): √ has higher precedence

Needs more samples!

[josdejong]

Just to add to the list:

• Qalculate! gives ! highest precedence

[harrysarson]

Could √ be treated as a function rather than an operator. Then parenthesis are required and no one has to worry about operator precidence? People would write √(9) rather than √9.

[infusion]

ehhh, so you also want to interpret √4√4 as (√4)*(√4) and not as √(4 * √4) too? In that case we're on the same page.
Right :)

Personally, I would bind only the first symbol after √ to it. That means √x! is either an error for real results or uses the gamma function (I'm not sure of the behavior of math.js there.

@harrysarson I like the idea of treating it as a function, even if it would be nice to be able to write √123 intuitively.

[josdejong]

Could √ be treated as a function rather than an operator. Then parenthesis are required and no one has to worry about operator precidence? People would write √(9) rather than √9.

I like that Idea @harrysarson . I think though that people really want to be able to just enter √9 too, and that it will feel really counter-intuitive if you can't. I like the option of implementing it as a unary operator √ most (having high precedence, higher than !).

[gwhitney]

I plan to update/reimplement this on current mathjs, according to the precedence and other details as discussed.

[josdejong]

👍 thanks Glen

[gwhitney]

Best-laid plans and all that -- that was over a year ago. Can't say I know when/whether I'd get back to this, but it would still be a good change.