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 / AGK2 Division Error

Author
Message
aviles22
10
Years of Service
User Offline
Joined: 1st Dec 2013
Location: New Jersey, USA
Posted: 6th Sep 2014 16:53
Link
For some reason when 2 integer variables are = 0 AppGameKit produces an error when they are divided.

ex.
NUM1 = 0
NUM2 = 0

NUM3 = NUM1 / NUM2

Is this a bug?
Back to top
Profile PM Email
29 games
19
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 6th Sep 2014 17:11
Link
I've just a run a quick test and I'd say it's that AGk doesn't like the divide by 0.

It likes 0/1 but not 1/0.

Purple Complex: An Arcade Style First Person Tactical Shooter - full game available now
Hover Car Race Challenge Accepted! - full game available now
Back to top
Profile PM Email
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 6th Sep 2014 17:33
Link
Open your calculator and try both types mentioned by 29 games

Basically if it is 1/0 or 0/0 you should do something like

if a = 0 and b = 0 result = "Cannot Perform this request"

Or default the result to NUM3 = 0

Also for 1 / 0 but then you need to decide if one of the two is 1 or 0 and whether you want to keep the order or not... or simply...

if a = 1 and b = 0 result = 0
NUM3 = 0
else
NUM3 = NUM1 / NUM2
endif

Back to top
Profile PM
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 6th Sep 2014 17:45 Edited at: 6th Sep 2014 17:46
Link
Yeah, division by 0 is not an AppGameKit bug but a mathematical error. Anything divided by 0 would become infinite, as numbers grow when divided by a value less than 1. You cannot divide by 0 in any programming language that I know of. Maybe someone with more programming experience will prove me wrong here but that's beside the point.

Back to top
Profile PM Website
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 6th Sep 2014 20:34
Link
Dividing by zero is a MAJOR error. The result is infinity. No computer on earth has an infinite number of bits.

You must test if you are about to do this, and avoid it.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Impetus73
13
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 6th Sep 2014 21:53
Link
Dividing by 0 can cause a bluescreen, and freeze the computer. Be glad, that the compiler complains!

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Back to top
Profile PM Email
swissolo
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 7th Sep 2014 04:59
Link
Does it throw a divide by 0 type error? If not there is a bug of some sort.

Back to top
Profile PM
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 7th Sep 2014 05:31 Edited at: 7th Sep 2014 05:38
Link
AGK v1 has a failsafe for this and simply reports 1 / 0 = 0
I think Paul would consider this a bug.

But... I wouldn't mind the compiler reporting this, however if it were to happen at run time... it could be an issue. Imagine if you're dividing by something like frame time and frame time reports back as 0. That shouldn't cause a crash. The engine would be safer just reporting 0 for division by 0.

Napland Games - Shape Time - Wordspionage - dFenz Facebook
Back to top
Profile PM Email Website
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 7th Sep 2014 11:02
Link
Quote: "Imagine if you're dividing by something like frame time"

Just curious, why would you ever divide anything by the frame time? Don't you always only use it to multiply?

Back to top
Profile PM Website
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 7th Sep 2014 11:55
Link
Dividing by a literal zero should be a compile-time error.

No compiler can predict a run-time error involving variables. It's a fundamental of programming to avoid this - either by explicitly testing the divisor for zero or enclosing it in an exception trap.

I don't think the run-time system should just return a default. That just encourages sloppy programming.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
aviles22
10
Years of Service
User Offline
Joined: 1st Dec 2013
Location: New Jersey, USA
Posted: 7th Sep 2014 13:27
Link
I divided by zero in Vb.net and never had a problem. Also no problems in C#. Not a big deal and very easy to test before dividing, I just never had an error when dividing by zero in other languages.

Quote: "
Just curious, why would you ever divide anything by the frame time? Don't you always only use it to multiply? "


I was trying to find the winning percentage from totalgames to wins.
When the totalgames = 0 and wins = 0:

perc = 100 * (wins / totalgames)

Produced the error. I've had many situations where dividing by zero was encountered.
Back to top
Profile PM Email
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 7th Sep 2014 13:55
Link
Quote: "Just curious, why would you ever divide anything by the frame time? "

You can divide 1.0 by the frame time to determine the current FPS

The result from ScreenFPS() is averaged over several frames so does not produce the same result.
Back to top
Profile PM Email
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 7th Sep 2014 18:06
Link
Floating point division by 0 will produce 1.#INF and the program will continue. Integer division by 0 produces an exception and crashes the program. I'll add a check to the integer division routine and make it produce a runtime error instead, like with array bounds checking.
Back to top
Profile PM Email
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 7th Sep 2014 20:39
Link
That's the same as Visual Basic: symbolic infinity with floats and exception with integers.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 7th Sep 2014 21:25
Link
Quote: "AGK v1 has a failsafe for this and simply reports 1 / 0 = 0"


I wouldn't like that personally. 0 is the complete opposite of the real result and you don't get notified of the problem. All other languages - including mainframe languages - that I'm aware of report an error.



Quote: "I divided by zero in Vb.net and never had a problem. Also no problems in C#."


VBA gives you a runtime error 11 - cannot divide by zero
VB.NET gives me 1.#INF, which means "too big for a double"

Maybe you ignored the spurious result?


Having to check for a /0 is a pain and seems like "too much code for something so simple" but it's a necessary evil and you only need to put it wherever there is a possibility.

ten-net consulting limited
Back to top
Profile PM Email
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Sep 2014 00:57 Edited at: 8th Sep 2014 00:58
Link
Floating point operations have a variety of "strange" results. Integer operations don't. Hence exceptions on integer divide.

If you think this is going to happen often it's better to use an explicit test rather than a try..except trap, because exceptions have a lot of overhead. I discovered this in a Genetic Programming system I wrote: evolving nodes can often produce divide by zero; exceptions were several thousand times slower than a test. (In this case, the division operator caused the result to be one - because that can then be reduced to a NOP).

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-11-25 09:25:22
Your offset time is: 2024-11-25 09:25:22