Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Operator Precedence

Author
Message
SashaW
10
Years of Service
User Offline
Joined: 15th Nov 2013
Location:
Posted: 15th Nov 2013 05:52
Hi All,

Just started programming with AppGameKit and noticed that operator precedence doesn\'t work as described in Hands On AppGameKit BASIC. Multiplication and division have equal priority and should be evaluated from left to right.

The expression 12-5*12/10-5 (Activity 3.9 in the book) should give the result 1 but I get 2 as the divide seems to be taking precedence over the multiply.

Have I missed something here?
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 15th Nov 2013 09:55 Edited at: 15th Nov 2013 10:01
That's a bug in Basic, as far as I can see.

It doesn't matter if the divide is first. The result is still 1. AGKPascal gives the correct answer - AGKBasic doesn't.

Multiply first:

12 * 5 = 60
60 / 10 = 6
12 - 6 = 6
6 - 5 = 1

Divide first:

12 / 10 = 1.2
5 * 1.2 = 6
12 - 6 = 6
6 - 5 = 1

I can't see any way of rearranging the formula to yield 2.

Got it!

The constant literals MUST be in float notation:

value2# = 12.0-5.0*12.0/10.0-5.0

This produces the correct result. So this is a warning to make damned sure you stick .0 on the end of everything involving division if the result is to be correct.

So this is actually incorrect in the book. It's also an example of how Basics loose typing can trip you up.

-- Jim - When is there going to be a release?
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 15th Nov 2013 11:52
If the expression is evaluated by performing the division before the multiplication then that is a bug in AGK. Arithmetic operators of equal priority are meant to be evaluated left to right. Having to use floating point just to get the correct answer isn't really an acceptable option, in my opinion.
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Nov 2013 12:52
Quote: "The constant literals MUST be in float notation:

value2# = 12.0-5.0*12.0/10.0-5.0

This produces the correct result. So this is a warning to make damned sure you stick .0 on the end of everything involving division if the result is to be correct."

That holds true in any programming language as far as I know; division of two integers yields a truncated integer remainder.

Quote: "It's also an example of how Basics loose typing can trip you up."

Definitively, there really should at least be an option to use strict typing to avoid these ridiculously hard-to-debug issues.


"Why do programmers get Halloween and Christmas mixed up?"
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 15th Nov 2013 14:38
Alistair - it's not precedence. It's a type issue.

In the original post, since all integers are apparently integers we get an integer divide so that 12 / 10 is 1. With loose typing you have to force the type of a constant. This produces really obscure bugs, because when you look at it it looks fine. Rudolpho is spot on.

In a big program you could stare at it for hours. It's not a bug, it's a language failure. Grown-up languages will either warn, promote, or reject constructs like this.

-- Jim - When is there going to be a release?
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 15th Nov 2013 19:06
JimHawkins - I know 12/10 gives 1 as a result, but if the expression was evaluated as it should have been with the multiplication being performed before the division then we would have 60/10 and an integer result wouldn't be a problem.

The fact that DBPro gives the correct result when using integers (and it also gives an integer result when dividing two integers) should highlight the fact that there is a problem with AGK's evaluation of the expression. Not executing equal priority operators on a left to right basis isn't standard, so if that is what AppGameKit does it should be prominently documented somewhere.

I don't know the exact mechanism AppGameKit uses to evaluate an expression but if it uses reverse Polish notation, the multiplication should be executed first.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 15th Nov 2013 19:36
AGK does seem to be processing division before multiplication. At least in the case of the OP equation.

Since I never trust any compiler/computer to actually evaluate equations in the expected manner, I always use parenthesis to make sure that things get evaluated the way that I want them. I do the same in logical operations as well. After more than 30 years of programming, I have learned that some things just don't follow the rules as expected. So I always try to make sure I provide enough information so that it works the way I want.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 16th Nov 2013 00:35
I think you will find that in most languages multiply and divide have equal precedence. The issue then becomes, where operators have equal precedence, should the order then be evaluated left to right after the sub-fragment is evaluated? That would be normal practice.

This may be an evaluation stack issue, because parsing left to right the multiply is first on the stack and the divide becomes top of stack and is resolved first. This could be solved by parsing the expression right to left.

But, as AL wisely says, not relying on compilers if you can use brackets is good advice!

-- Jim - When is there going to be a release?
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 16th Nov 2013 02:44
Yep, It's normal for operators of the same precedence to evaluate left to right.

Unfortunately this appears to be legacy issue steaming AGK's DarkBASIC classic roots. The AppGameKit compiler and probably most of the VM are based upon DarkBASIC classic. As such, it has inherited many of the behaviors of DBC.

From memory, in DBC they used a very literal interpretation of BODMAS in the expression evaluation. So divisions always occurs before mults as well as additions over subtractions. This caused more than few hiccups when moving legacy DB code across to Dbpro, since that compiler treats them equally. There's a long discussion about in the deep dark souls of the boards from the Dbpro WIP stuff (like 2001/2002 era).

doubt they'll change it now, so bracket if you really want to ensure the order.

AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 16th Nov 2013 12:00
Oh well, another correction to add to the next edition of Hands On AppGameKit BASIC!
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 16th Nov 2013 17:11
Yup, it should definitely suggest using parenthesis to organize math and logic.

My husband is of the same mind that you always use parenthesis because you just cannot be sure of what the compiler/processor will do.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 16th Nov 2013 17:57
Ancient Lady - Thanks for the tip. I guess I am more used to languages that have big thick manuals that tell you everything to expect but I must admit the hobbyist stuff is definitely more fun!
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 16th Nov 2013 18:43 Edited at: 16th Nov 2013 18:43
I couldn't find anything in the AppGameKit help about operator precedence in AppGameKit Basic. Nor about order of evaluation. If / has higher precedence than * that should be noted, as should the actual order. Is this right-to-left order, which would be highly unusual?

It would be handy to have a separate integer divide operator as Visual Basic does (or Pascal). In VB 3 / 2 produces 1.5, where as 3 \ 2 produces 1.

-- Jim - When is there going to be a release?

Login to post a reply

Server time is: 2024-05-03 11:11:51
Your offset time is: 2024-05-03 11:11:51