What's _Float got to do, got to do with it?

[Pete]

What's _Float but a second hand assignment...

Oh well, there goes my music career.

Anyway, playing around with another post with the age old question about binary vs base 10 counting. I found it interesting that _FLOAT could cure a simple problem like adding .1 to itself in a 1 to 10 loop, but couldn't hand .01 added to itself or decimals with more places.

Code: QB64: [Select]

1. PRINT "Unassigned Variables"
2. FOR i = 1 TO 10
3.     x = x + .1
4.     y = y + .01
5.     PRINT i; x; y
6. NEXT
7.  
8. gy = 13.7926
9. ey = 13.4951
10. PRINT "gy - ey ="; gy - ey; "should = .2975"
11.  
12. PRINT "--------------------------------------"
13. x = 0: y = 0
14. PRINT "Assigned Variables using _FLOAT"
15. DIM x AS _FLOAT, gy AS _FLOAT, ey AS _FLOAT
16. FOR i = 1 TO 10
17.     x = x + .1
18.     y = y + .01
19.     PRINT i; x; y
20. NEXT
21.  
22. gy = 13.7926
23. ey = 13.4951
24. PRINT "gy - ey ="; gy - ey; "should = .2975"
25.  

By the way, yes, I already know how to make a routine that corrects these addition/subtraction issues, so no need to reply in that regard.

So to me, _FLOAT only appears useful to express decimals to greater places. Any other use?

Also, I wonder if it is time we consider making a math function to properly carry out calculations for the tool box? There are several methods that could be discussed. I posted one here: https://www.qb64.org/forum/index.php?topic=1089.msg102827#msg102827

Pete

[SMcNeill]

It’s mainly just an issue of precision.

Take 1/3 in decimal as an example...

In single-digit precision (not SINGLE), it might be represented as 0.3.
In double-digit precision, it might be represented as 0.33.
In hexa-digit precision, it might be 0.333333.

So to multiple by 10, with each precision method, we’d get:
3
3.3
3.33333

If we’re rounding for monetary values, the 3 is WRONG, the 3.3 is wrong, and the 3.33 would be right...

The more decimal places you use, the less the margin of error becomes — but it never goes away completely.  Even with hexa-digit precision, 1 / 3 * 100000 would end up becoming 333333.0 — which is 33 “cent” off the correct total.

DOUBLE offers more precision than SINGLE, so you have a smaller margin of error.  -FLOAT offers an even greater precision and even smaller margin of error...

BUT...

In the end, both still have a margin of error due to rounding/numeric representation.

The only way to truly avoid the issue is to use integer values, or (yuck) string math.