wrong order of operations

Bugs will be moved here once resolved.

Post » Sat Mar 28, 2015 9:54 pm

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
Visual Novel 'Engine' in 100 Events
if you ever have to choose between buying Construct 2 on scirra.com or on Steam, read this: Review
B
20
S
9
G
1
Posts: 786
Reputation: 3,729

Post » Wed Apr 01, 2015 12:53 pm

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.
Scirra Founder
B
362
S
216
G
75
Posts: 23,063
Reputation: 180,303

Post » Thu Apr 02, 2015 2:13 pm

@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.
https://www.scirra.com/forum/viewtopic.php?t=152506

And that is why you shall respect the bug reports guidelines, not only giving a capx is making the bug reproductible in one click in a situation they can work with (less time wasted trying to reproduce vague instructions) but also it helps filtering false positives.

Game design is all about decomposing the core of your game so it becomes simple instructions.
B
42
S
17
G
17
Posts: 2,097
Reputation: 15,863

Post » Thu Apr 02, 2015 3:35 pm

Aphrodite wrote:@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.
B
107
S
28
G
15
Posts: 1,196
Reputation: 17,538

Post » Fri Apr 03, 2015 10:29 am

glerikud wrote:
Aphrodite wrote:@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.
B
62
S
15
G
56
Posts: 2,138
Reputation: 36,348

Post » Sat Apr 04, 2015 12:31 pm

Colludium wrote: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.
Scirra Founder
B
362
S
216
G
75
Posts: 23,063
Reputation: 180,303

Post » Sat Apr 04, 2015 2:29 pm

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.
B
62
S
15
G
56
Posts: 2,138
Reputation: 36,348

Post » Sat Apr 11, 2015 6:20 am

i'd always use math.pow (pow in events), using ^ sometimes gives wrong results because in javascript ^ is not pow really.
Sea Monsters template - Isometric
Also includes 40 pages PDF of optimizations and "how-to" for your games, and how the "sea monsters" template was built. Follow link for details :)

sea-monsters-templates-and-assets_t162705
B
30
S
10
G
11
Posts: 603
Reputation: 8,290

Post » Sat Apr 11, 2015 10:25 am

saiyadjin wrote: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
https://www.scirra.com/forum/viewtopic.php?t=152506

And that is why you shall respect the bug reports guidelines, not only giving a capx is making the bug reproductible in one click in a situation they can work with (less time wasted trying to reproduce vague instructions) but also it helps filtering false positives.

Game design is all about decomposing the core of your game so it becomes simple instructions.
B
42
S
17
G
17
Posts: 2,097
Reputation: 15,863

Post » Sat Apr 11, 2015 10:55 am

@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.
Scirra Founder
B
362
S
216
G
75
Posts: 23,063
Reputation: 180,303

Next

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 3 guests