"SINGLE" type is like a holdover of 8-bit computers such as the Radio Shack TRS-80 Color Computer 2 which had only two types: "numeric" and string. It didn't care if the "numeric" was an integer, and it had five or six digits of floating-point precision. Use "SINGLE" when the programmer must have fractional quantities but the accuracy is coarse, such as small currency values.
"DOUBLE" was invented to try to do something about "SINGLE" not going far enough, yet it is dwarfed by types subsequently invented while we made the transition from 16-bit to 32-bit and then to 64-bit. M$ BASIC PDS v7.1 and VBDOS had "CURRENCY" type but that was somewhat confusing; internally it was stored as "LONG" (or maybe 64-bit integer?) but was shown to the user having four digits of fraction precision.
"_FLOAT" was supposed to be more precise than "DOUBLE" with very large and very small numbers. However, up to 17 places for an integer, "_INTEGER64" is better. As was looked up by Steve, numbers can never be accurate like scientists want because the internal system to store the numbers is base-2, at least for a general purpose computer.
Some people are dissatisfied with the accuracy from the existing floating-point types not being good enough and that's why we're seeing a lot of "string arithmetic" libraries going around.
For example, might want to look at this thread:
https://staging.qb64phoenix.com/showthre...11#pid8811
The way floating-point numbers are stored is necessary in other programming languages to have a value which is like negative infinity or "Not A Number". Then the powers that be decided there should have been "different" NaNs... it's better not to think much about it. In M$ BASIC, "SQR(-1)" always gave out error #5. In some other programming language it could return NaN. There has to be a value that represents it although it's "Not A Number", get it? BTW this is told apart from "complex number" library, this is just an example of how BASIC could react to an "illegal" value compared to a different programming language.
"DOUBLE" was invented to try to do something about "SINGLE" not going far enough, yet it is dwarfed by types subsequently invented while we made the transition from 16-bit to 32-bit and then to 64-bit. M$ BASIC PDS v7.1 and VBDOS had "CURRENCY" type but that was somewhat confusing; internally it was stored as "LONG" (or maybe 64-bit integer?) but was shown to the user having four digits of fraction precision.
"_FLOAT" was supposed to be more precise than "DOUBLE" with very large and very small numbers. However, up to 17 places for an integer, "_INTEGER64" is better. As was looked up by Steve, numbers can never be accurate like scientists want because the internal system to store the numbers is base-2, at least for a general purpose computer.
Some people are dissatisfied with the accuracy from the existing floating-point types not being good enough and that's why we're seeing a lot of "string arithmetic" libraries going around.
For example, might want to look at this thread:
https://staging.qb64phoenix.com/showthre...11#pid8811
The way floating-point numbers are stored is necessary in other programming languages to have a value which is like negative infinity or "Not A Number". Then the powers that be decided there should have been "different" NaNs... it's better not to think much about it. In M$ BASIC, "SQR(-1)" always gave out error #5. In some other programming language it could return NaN. There has to be a value that represents it although it's "Not A Number", get it? BTW this is told apart from "complex number" library, this is just an example of how BASIC could react to an "illegal" value compared to a different programming language.