Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Pete on February 22, 2019, 03:33:22 pm

Title: What's _Float got to do, got to do with it?
Post by: Pete on February 22, 2019, 03:33:22 pm
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
  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"
  16. FOR i = 1 TO 10
  17.     x = x + .1
  18.     y = y + .01
  19.     PRINT i; x; y
  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
Title: Re: What's _Float got to do, got to do with it?
Post by: SMcNeill on February 22, 2019, 03:48:59 pm
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.
Text Only | Text with Attachments