-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in operators precedence #79
Comments
This looks right. For r1 you have -2^2 which is 4 (-2 * -2). But in r2 you have -(2^2) or -(2 * 2) which is -4. Right? |
No, exponentiation comes first (see https://en.wikipedia.org/wiki/Order_of_operations) than division, the only r2 is right. |
If r1 were A*e^(0-u^2/2) I would agree. But as written, the "-" sign is not an operator. It is setting the value to be -u, not -(u^2).
results in:
Did I write my C# correctly? If not, can you make corrections? I did this in an xUnit test. |
There's no reason to have (-u)^2, this would always be a positive number. |
Can you write C# code that behaves like you expect? I would expect Jace to behave exactly like C#. |
I have it in CalcPad, and it was rendered the same as r2. I was expecting the same from Jace - the point is the minus sign, Jace is an intepreter and I was expecting the same behaviour as others, like CalcPad.
|
I have not used CalcPad, but I "assume" you typed in that and that it interpreted -u^2 as -(u^2). |
In CalcPad I type in exacly in the way I showed you. |
Thanks for reporting the CalcPad issue/question. I didn't even think to double check with Excel. So Excel matches what C# does. |
Ok, but in general there aren't language specific operations order, they're common to every language. Today I learned that some behaviours even in basic math can be decided by-design, as it seems CalcPad does (I mean as interpreter, it is written in C# as well).
but Excel results confused me. |
@johnnyontheweb is correct. There is already an issue and a PR for this bug: |
I read the explanation on Operations order? #154 It doesn't really matter to me (because I reviewed all our code and we don't support such items and do move people down a "use parentheses path") IF one were to work to make this change, I would do it incrementally. And I would have a way to set this when Jace is started - Precedence.Legacy or Precedence.Wolfram, for example, and start with Legacy as the default? The nature of Jace is that these expressions can be stored in a database. So the Jace user (developer) can't review everything to put in the parentheses. They would need to have a way to keep it in line with the expressions that might already be stored. |
Maybe using an option for legacy, that by default is false (=no legacy). |
How do you plan to solve the matter so it works with Excel? |
IMHO there's no need to mantain the same syntax as Excel. Excel users would have the mentioned option/flag to set. |
Hi all, the PR #63 is merged into our maintained fork of Jace.NET, sonic. Thank you @FabianNitsche for contributing the fix. We had the same issue in production and your PR resolved it. If anyone is in need of a NuGet package which contains that fix, you're welcome to give sonic a shot. |
@vlow: thanks for the credit and taking over Jace! I will check out sonic. |
Hi,
I encountered a strange bug. I have this:
and I get
I'm not an expert, but I think there's an error in operator precedente evaluation for r1 - this should give 1.35 as well as r2.
regards
The text was updated successfully, but these errors were encountered: