Power of 2 problem

[jwa1974]

Test Environment (required)

• Platform: MEGA65
• ROM Release: 920418, 920421
• Core Commit: aaf4542

Describe the bug
Some powers of 2 result in inexact numbers (2^23 = 8 388 608.1, 2^26 = 67 108 865, ...).

To Reproduce
Steps to reproduce the behavior:

1. Do a PRINT 2^23 (as an example)
2. The result will be printed as 8388608.1

Expected behavior
The above should result in 8 388 608. In BASIC v2 (as a reference), the numbers are correct (scientifically notated numbers are rounded as expected as well).

Screenshots

Additional context
None.

[dansanderson]

This is consistent with how our float implementation biases high while the BASIC 2 implementation biases low. We're reaching a point of diminishing returns on trying to get them to behave similarly, especially how they engage with the float printing routine, which rounds differently from internal math. (The ".1" is not doubled at 2^24, even if you do it as a separate operation like 2^23*2.)

I'll leave the issue open for a bit, but I'm not sure this is something we will fix.

[jwa1974]

I do understand there is a trade-off involved in all this. However, it could pose a problem for a user/developer - expecting a "solid" result for these calculations. I mean, it is not obvious there is a difference between printing 2^23 and 22...22 (x23).

Perhaps, if we don't want to correct this, future documentation should perhaps give an explanation as to why it behaves the way it does?

Is it just the output that differs? The internal calculation is doing as it should?

[dansanderson]

Correct, the .1 is introduced in the binary-float to decimal conversion for printing purposes. The internal math is as accurate as floating point math can be, which is inherently limited. That's the general expectation: floating point math is inherently inaccurate. 2^23 = 8388608.1, 2^23*2 = 16777216 (not 16777216.2).

I'm playing a bit fast and loose with the term "bias" but that's the main difference here: at some point, a previous MEGA65 ROM developer made changes to the floating point math that caused it to lean high where previous CBM BASICs lean low. In the grand scheme of things it's an arbitrary difference—both are inaccurate—but it has caused these little noticeable differences in some cases. I've tried to fix the cases that cause problems for small numbers. But it's too difficult to undo the original change, and the underlying principle of floating point math being inaccurate (sometimes in unintuitive ways) will never change.