6 digit significant limit?

Does anyone know WHY floats are limited to six significant digits? Perhaps this was a design of Blitz3D to increase gaming performance but why have such a limiting limit in BlitzPlus which is MUCH more geared towards apps.

I have heard that floats keep more than 6 significant digits internally but that really doesn't help because at some point you (or at least I do) have to get at that value and do something with it.

The program I am currently writing takes a lot of floating point calculations and converts them to integer values but not by using Int, Floor, or Ceil. It multiplys them by 10,000 to cause the 4 MSD's (MostSigDigit's) of the decimal part to be part of the integer. It then prints out this information to the screen and to another computer via serial cable in different formats depending on if the number is supposed to be metric, inch, or neither.

It appears that I may be losing accuracy do to rounding/clipping caused by the 6 digit limitation. I need numbers that are accurate to 4 decimal places (.0001)and when they also contain 2 integer digits (12.), that leaves no extra digits (6digits=12.0001) left to solve mathematical functions that I apply to it.

  12.3456  a number with only 6 digits
+ 12.3456
---------
  24.6912

  12.345653  what it would be with 2 extra digits
+ 12.345670
-----------
  24.691323
a=24.691323

  12.3456 53  what it would be if Blitz is clipping extra digits
+ 12.3456 70
--------- --
  24.6912 03
a=24.6912

  12.3457 53  what it would be if Blitz is rounding extra digits
+ 12.3457 70
--------- --
  24.6914 00
a=24.6914

As you can see, I could get 24.6912, 24.6913, or 24.6914 as a result depending on what goes on inside of Blitz. Clipping the extra digits goes under. Rounding the extra digits may make it go under or higher.


I just don't see why BlitzPlus has to only use 6 digits.


Running this sample code:

A# = 12.345653
B# = 12.345670

C# = A# + B#

Print A#
Print B#
Print C#

WaitKey
End

produces this result:
12.3457
12.3457
24.6913

So it appears that Blitz keeps the actual numbers internally (otherwise the answer should have been 24.6914) but the results shown to me on the screen (which I told you above I need to get to) are not the actual values (they are rounded).

This makes debugging difficult as well since the debugging variable pane also rounds the numbers to 6 digits.

Since I am concerned that the numbers are accurate to 4 decimal places, I can't tell WHY the numbers are what they are. For instance, "Did Blitz just round them up/down or did my math calculations actually give that result?" I don't know which it is.


I would really like to see BlitzPlus return at least 8 significant digits.

It might be how floats are stored in computers, I dont know what it is but I always hear people talking about floating point precision and such.

Function float_string(float_val#)
	whole=Int(float_val)
	Print whole
	Write "."
	
	For l=1 To 10
		float_val=10.*(float_val-Float(whole))
		whole=Floor(float_val)
		Write whole
	Next
End Function

Print float_string(1.23456789)
While Not (KeyHit(1))
Wend

This is a limit of using standard 32 bit floats, not a blitz specific limitation as such, unless you count not supporting doubles as a blitz limitation. Blitz max.....

Floats are single precision, which is about seven digits.
Displayed values, or floats converted to strings, are rounded to six digits.

A# = 12.345653
B# = 12.345670

C# = A# + B#

So A and B are rounded to 12.3457 when displayed. C will be very close to 24.691323 and will display as 24.6913 with six digit rounding.

This doesn't change A,B, or C. It is only the display which is rounded. But note that floats rarely have the exact value you wish they had.

x# = 0.1   ; x is not exactly 0.1 as there is no such floating point number.

Print x          ; Looks good so far.

x = 1024.0 * x
Print x          ; Still looks good.

x = x - 102.0
Print x          ; Hoping for 0.4, but we are disillusioned.

WaitKey : End