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 / Maximum Float Number?

Author
Message
DavidAGK
AGK Developer
7
Years of Service
User Offline
Joined: 1st Jan 2014
Location:
Posted: 5th Mar 2021 15:53
Hi All,

Struggling with some odd behaviours that I think is related to maximum float values in AGK. Anyone know what the max float value is and whether there is a way of getting larger values?

Fairly sure regular integers in AppGameKit can only go to 2,147,483,647

I don't suppose there is a way to globally say you want to use larger integers and floats?


AQUILLANTO - A side-scrolling platformer with super tight controls, 3 worlds to explore, hordes of monsters and a quest... Inspired by games on the Amiga computer

FOLLOW ON TWITTER
SEE THE YOUTUBE CHANNEL

SFSW
18
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 5th Mar 2021 18:34
Not that I'm aware of. I've had to use value stacking for larger values (two variables, one for large value blocks, one for small, shared between to total a larger value). Perhaps there is another way the odd behavior could be solved? If you describe it, maybe the community could come up with a work around.
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 5th Mar 2021 22:04
According to the documentation:

Quote: "
Each type of data has a maximum and minimum value known as the range. It is important to know these ranges, especially when dealing with smaller datatypes. Below is a list of datatypes and their ranges:

INTEGER Range : -2,147,483,648 to 2,147,483,647
REAL Range : 3.4E +/- 38 (7 significant figures)

Note that whilst the range for Real numbers is very large its accuracy is limited to 7 significant figures. So you could represent 143670000.0 or 0.000053712, each has 5 significant figures, but not both in the same value 143670000.000053712 as the combined value has 18 significant figures. If you tried to store such a value it would be rounded to 143670000.0
"


So that's... 3.4 X 10^38... so +/- 34 followed by 37 zeroes... as long as you only have 7 significant figures
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
blink0k
Moderator
8
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Raven
16
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 6th Mar 2021 01:37
The "Maximum" Value is a little bit of a misnomer., as instead it's better to think of Floating Points as Significant Figure Precision.
If for example we're using a 32bit Floating Point., which IEEE 754 will be 6-9 and typically the middle of this (7) is used...
In somewhat simplified terms; you're looking at a range of ±1.18 x 10 ^ -38 to ±3.4 x 10 ^ +38 but this will ONLY be accurate to the most significant 7 Values., beyond that it will still have a value; but the further you go beyond the 7 Significant Places, the greater the Inaccuracy from Rounding Errors.

64bit Floating Points are more accurate as they have double the Significant Places., they also have a greater range (by a factor of ~9)
You'd use Floating Point Numbers specifically if you're dealing with Fractional Numbers... but are fine with limited Precision.
If you need absolute accuracy., you should always use Integers.

Fixed Point (which is an Integer variant of Decimal Representation) is actually very accurate., because the Decimal Point isn't "Floating" and the Range is more Static; but MUCH more limited.
I'd argue Fixed Point Math is actually a better approach for things like Pixel Shaders; but no GPU Architecture has ever used such an approach... no idea why, given you typically use Normalised Values; that is to say between 0.0 and 1.0... thus every value fits as a Negative Exponent; and thus with a Fixed Point approach you could have MUCH greater accuracy from a 32bit Value; or fit the 7 Significant common to 32bit FP into only 16bit.



Now if that's all gone a bit over your head don't worry... just keep in mind that AppGameKit 32bit Floating Points despite being Standard IEEE 754 Values; they are going to have lower accuracy than C/C++ Floating Points., because those Compilers actually include various tricks to retain accuracy... where-as AppGameKit doesn't., so even to 7 Significant Places; you're going to see some weird rounding errors.
I'd instead recommend keeping to 5 Significant Places as that will generally yield the best accuracy; it's why you'll see me using a truncated PI Value (3.14259) instead of the more common C/C++ Variant; as this retains accuracy.
DavidAGK
AGK Developer
7
Years of Service
User Offline
Joined: 1st Jan 2014
Location:
Posted: 8th Mar 2021 08:15
Aha! Thanks guys - think I bumped into both the most significant 7 numbers issue and just the maximum float number...

Number = 2979147995.1
Number =(Mod(Number, 278))

Results in a nonsense negative number

So after all these years.... Ali G was right.... they've not invented a computa that can add nine, nine, nine, nine, nine..... eight..... nine, nine, nine to nine, nine, nine, nine, nine

Right... I can crack back on!

Cheers guys.

AQUILLANTO - A side-scrolling platformer with super tight controls, 3 worlds to explore, hordes of monsters and a quest... Inspired by games on the Amiga computer

FOLLOW ON TWITTER
SEE THE YOUTUBE CHANNEL

Login to post a reply

Server time is: 2021-04-11 19:47:52
Your offset time is: 2021-04-11 19:47:52