wrong order of operations

Problem Description

wrong order of operation in formula containing orders (bodmas)

Attach a Capx

https://copy.com/0x99QERAKyv73r8E

Description of Capx

after this and the result of a simple formula gets displayed, both should end up being the same according to order of operations

Steps to Reproduce Bug

• calculate: -x^2 (you may use 0.75 for x)
• calculate: -1*x^2
• compare both results

Observed Result

The results differ. The minus in the first formula is erroneously dragged into the power, so it calculates (-x)^2 instead of -x^2. Also refer to: http://www.wolframalpha.com/input/?i=-x%5E2

Expected Result

The results should be the same.

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer: YES

Operating System and Service Pack

win 7 64bit most recent

Construct 2 Version ID

r200

Hmm... you're right, but fixing this kind of issue can come with a big compatibility cost: there may be lots of existing projects using the form -x^y and expecting a negative result (and only working correctly in that case), and then if we fix this those projects break. It's hard to correct this in a way which only applies to future/new projects and not existing ones. I think this may have to simply remain a known issue - at least it's easy to work around.

Ashley this would be a pretty nasty bug to keep, and nobody should ever expect it to work like that, so it should really be at least documented as it is a complete false result.

Ashley this would be a pretty nasty bug to keep, and nobody should ever expect it to work like that, so it should really be at least documented as it is a complete false result.

It's the minimum that this should be in the documentation. Ashley You already made fixes that broke previous projects, I don't think that this should be an exception. I think the way these things should go is that if there's a bug to be fixed, it must be fixed. Don't leave known issues in the engine if you can help it. Please fix it.

> Ashley this would be a pretty nasty bug to keep, and nobody should ever expect it to work like that, so it should really be at least documented as it is a complete false result.

>

It's the minimum that this should be in the documentation. Ashley You already made fixes that broke previous projects, I don't think that this should be an exception. I think the way these things should go is that if there's a bug to be fixed, it must be fixed. Don't leave known issues in the engine if you can help it. Please fix it.

Exactly! I don't imagine many, if any, would support keeping this for backwards compatibility reasons.

Exactly! I don't imagine many, if any, would support keeping this for backwards compatibility reasons.

It's hard to anticipate the impact of this. If it broke say 10% of projects then a lot of people would probably get angry and wish we hadn't. Some people have projects with thousands of events and combing through them for expressions involving any power expressions that could possibly return the wrong result (often tricky when variables are used) may not be practical. Then those users don't have any good options other than to stay with older versions of C2 and miss out on all future updates. (Cue the "is this how you treat paying customers?!" posts.)

Previously we try to keep breaking changes to easily fixable things (e.g. if it breaks, change a project property back and it should keep working), or automatically fixable things (it internally checks the version when loading and applies a fix). This is a more difficult case to do that with. Still we could experiment with making the change on a beta release, but not everyone uses them.

I agree that the impact of a fix would be hard to determine, ASHLEY. However, if anyone is using such equations as this example to get the answers they need then they will have been relying on fluke rather than an understanding of maths... I'm not sure that competent game developers would fail to notice the error, and it's quite possible that this is the first time someone has actually used ^x whilst knowing what they were doing, hence why this bug has only just been spotted. But of course I could be wrong...

If any fix could break 3rd party plugins then I would immediately concede that the best course of action would be to document it clearly in the manual and move on. The implications for simple maths like trig just tickles my OCD, 'tis all, and I think that maths in C2 should be clean and logical without the need for user compensation.

i'd always use math.pow (pow in events), using ^ sometimes gives wrong results because in javascript ^ is not pow really.

i'd always use math.pow (pow in events), using ^ sometimes gives wrong results because in javascript ^ is not pow really.

If it is not in javascript, that is not an issue, the issue is that the C2 manual says it is in the context of C2, also, the issue is not the returned result itself, but the wrong order of operations, which is plain incompatible with how maths are defined.

https://www.scirra.com/manual/78/expressions

saiyadjin - there is no 'pow' expression in C2, only the ^ operator, which internally uses Math.pow. Javascript does not have a raise-to-power operator.

oh, then i saw it somewhere else probably, i was pretty sure i saw pow in here, guess i didn't after all

I agree with the others here, it may be a breaking change but bad mathematics will look worse than needing to fix old projects.

I've corrected the order of operations for the next beta. We'll see how it goes.

Awesome, thanks!

Thanks for fixing it