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 / float bug?

Author
Message
Candiajo
10
Years of Service
User Offline
Joined: 6th Nov 2013
Location:
Posted: 25th Mar 2015 13:00
Link
Hi, just found some weird behaviour using integer and float variables, maybe someone can explain me what happens.

this code



produces this output (both windows and android)

123456792


Please let me know is there is some issue with float values or something, thankyou!
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 25th Mar 2015 14:12 Edited at: 25th Mar 2015 14:13
Link
i guess this value is out of range.
i believe agk using 32 bit floats.
http://www.appgamekit.com/documentation/principles/1_datatypes.htm

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini OS X 10.10 (Yosemite)
Back to top
Profile PM Email
Candiajo
10
Years of Service
User Offline
Joined: 6th Nov 2013
Location:
Posted: 25th Mar 2015 18:51
Link
I've thought so but I've tested with higer values and some work fine.

Examples I've tried:
111111000 ---> prints 111111000 (GOOD)
111111100 ---> prints 111111104 (FAIL)

222222000 ---> prints 222222000 (GOOD)
222222200 ---> prints 222222208 (FAIL)

333300000 ---> prints 333300000 (GOOD)
333330000 ---> prints 333329984 (FAIL)

999999.1 ---> prints 999999.125(FAIL)
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Mar 2015 21:02
Link
I think it is the printed representation that is wrong, not the actual float value that is stored. This...



...works. You would expect 123456796 if the float itself was wrong.


Weirdly, this fails:



But this is OK:



(My understanding is that integers are held internally as floats).

Quidquid latine dictum sit, altum sonatur
Back to top
Profile PM Email
Candiajo
10
Years of Service
User Offline
Joined: 6th Nov 2013
Location:
Posted: 25th Mar 2015 21:31
Link
You are right BatVink, the problem is in the PRINT representation.

This code:



returns this:
correct
333329904.000000

So the data is correctly set in the variables but fails at the PRINT command (in fact, I've seen that converting "a" to string with "str(a)" also fails, so the problem is the internal float-->string conversion).

Hope it will be fixed.

Thank for your responses!
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Mar 2015 21:49
Link
I figured the calculation will store the hard-coded value in the same way (possibly incorrectly), and compare wrong with wrong, to give a false positive outcome. So it needs another way to see if it is storing it correctly. This also works OK, so I think it proves the values are correct:



Quidquid latine dictum sit, altum sonatur
Back to top
Profile PM Email
Hockeykid
DBPro Tool Maker
16
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 25th Mar 2015 23:10 Edited at: 25th Mar 2015 23:11
Link
This actually isn't an AppGameKit bug, but rather has to do with how floats are stored in memory (floats use scientific notation). Essentially, with certain larger numbers precision can be lost. This occurs because certain values ("123456789.0" in this case) can't be represented in binary with only 32 bits. In languages like C++ this can be worked around by using a 64bit datatype such as doubles.

Integers should retain their precision, so if you can it's better to use integers. For example, using integers with values below should work:

Quote: "
111111000 ---> prints 111111000 (GOOD)
111111100 ---> prints 111111104 (FAIL)

222222000 ---> prints 222222000 (GOOD)
222222200 ---> prints 222222208 (FAIL)

333300000 ---> prints 333300000 (GOOD)
333330000 ---> prints 333329984 (FAIL)
"




Sean

Back to top
Profile PM Email
Candiajo
10
Years of Service
User Offline
Joined: 6th Nov 2013
Location:
Posted: 26th Mar 2015 15:14
Link
Oh I see, so what is a safe range for using float values?
Back to top
Profile PM
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 27th Mar 2015 13:22
Link
Does AGK2 support double float or double integer calculations?

DBPro internal commands seems to only support single float and integer (although we can specify our variables to be double float/integer, but the calculations are performed in single float/integer, which resulting in wrong values. Please correct me if I'm wrong).
Is this also the case with AppGameKit?
Back to top
Profile PM
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 27th Mar 2015 13:31
Link
AGK uses single precision 32-bit float and integers. That's in line with OpenGL. Using T2 or Pascal you can do what you like as long as you reduce the precision in any AppGameKit calls.

<<It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.>> Dijkstra
Back to top
Profile PM Website
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 27th Mar 2015 14:04
Link
I see. From your opinion, is it possible for AppGameKit developer to make internal commands so that the calculations can be performed in double integer/float, for use in Tier 1?
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-25 02:06:56
Your offset time is: 2024-04-25 02:06:56