If I remember right, Atari Basic had 4 byte floats and Commodore Basic has 4 byte floats. The extra precision mattered for some programs, but the small size made the Atari Basic faster.
CBM had 5 byte floats I think you meant--edit: maybe it was 6. 5 byte mantissa and 1 byte exponent??
CBM BASIC was a Microsoft product and I think more or less what all the Microsoft BASICs did was convert everything to floats internally--even when not really needed. For example the index in a FOR I=1 to 10 was dealt with internally (and slowly) as a float--including the operation to increment it by 1 or the STEP value.
If Atari BASIC didn't do that it would have made things faster in many situations. Apple's Integer BASIC was faster because it didn't support floats at all, if you could deal with the almost C-style strings IIRC.
CBM had 5 byte floats, but when they were copied into the floating point "registers", they were expanded into a 6 or 7 byte representation for speed. It was 8 bits of exponent, 1 bit sign, and 31 bits of mantissa (with one extra implicit bit since the leading bit is always 1).
It's true there was very little performance gain to using BASIC integer variables, since they'd be converted to floats internally almost always. The one real advantage of integers is that a DIMed array of ints was more compact than an array of floats.
I'm pretty sure Netflix queues used to work this way. For the DVD-by-mail service, I think.
Basically, the web page had a text field next to each movie, and you could type in numbers, then submit a form, and it would reorder your queue.
The obvious thing to do was swap "1" and "2" to flip the order of the top two items. But you could just set the second one to "0.5" and leave the first at "1". When you submitted the form, it would renumber them all with integers.
We could add an imaginary part to line numbers. If you do a GOTO 200 + 20i, you’ll jump to a line that’s above the program in the imaginary axis and continue running from there.
With FOCAL, though, they were more like modules rather than floating point values; you could address blocks of code ("groups") by, for lack of a better expression, the integer portion of the number, with the fractional portion being the line number within that group.
I get, on VICE in PAL mode, 212 jiffies and 256 jiffies respectively.
The reason for this nonsense is that Commodore BASIC does the math in floating point, and converts it to integer after the fact. You can speed this up with
which gives me 244 jiffies, but still slower, because even though K% is now already an integer and it costs "less" since it is now in a variable instead of being converted from BASIC text, it still requires a roundtrip to the floating point accumulator.
The implementation issue with integers in Commodore BASIC 2 was that they were still stored in a 5 byte format, while actually using just the first two bytes. Meaning, unlike with other implementations of MS BASIC, they occupied 7 bytes in memory (with two leading bytes for the identifier), just like floating point variables, and there was no improvement on memory usage with integers.
Atari BASIC used 48-bit BCD floats and the routines were not well optimized, making it one of the slowest at the time(later retrohobbyists have made various patches as well as faster BASIC implementations). It was also Microsoft-incompatible which made it an odd duck among the microcomputer BASICs.
Atari BASIC's tokenization scheme should have made it faster than others. But it suffered from some poor implementation details which made it perform quite poorly.
