A bit TRS/Microsoft-centric, for example ignores the 8-bit microcomputer BASICs, but still a good read.
The original link I got was https://shrtn.escalar.pt/gf2A but the link shortener was a little ornery, so here is the actual link (which I wayback-machined) behind it
Regarding data types: there’s actually another type, FN variables. A FN definition, as encountered, produces a variable by the given name holding the location of the variable body (stored value) of the named parameter and the location of the function body in the BASIC text.
(On activation, the original body (stored value) of the variable for the parameter is backed up on the stack and overwritten. Thus, the parameter is a true local variable, shadowing any global variable going by the same name, while reusing the global variable lookup. For this, any FN definition with parameter “X” also produces a global variable “X”, if not already defined. The limitation that function parameters can be only of type real, is really for this backup and restore mechanism.)
It is the only place I’ve seen that suggests why the Model 100 BASIC interpreter used BCD maths:
[per Tandy’s request, to reduce
rounding errors, and improve the financial calculations accuracy]
As I understand it, the design was first sold by Kyocera to NEC, who had already their successful PC-8801 8-bit computer (released in 1981) on the market. So, there was an incentive to make the BASIC of the new portable machine as compatible as possible to the existing computer, resulting in a different floating point layout with less precision for the PC-8201 and its N82 BASIC than in the other versions of the same base design (while sharing most of the ROM code otherwise; still, there are some further differences probably owed to the same desire for compatibility). – I guess, precision was a broader issue, and something that was thoroughly tackled with the Model 100, while also bringing this more in line with Microsoft’s current BASIC offerings overall.
(Also, Tandy seemed to have taken some real interest in the design, as the Model 100’s hardware, while still the same principal architecture, varies quite a bit in PCB layout and packaging from the NEC version. This was far more than a simple rebadge job of an existing machine, like with Tandy’s pocket computer offerings, and much more like translating a published reference design into a final product – similar to the CoCo.)
Note that both BCD and binary produce rounding errors, just different ones. It is not that BCD improves financial calculation accuracy, but that its rounding errors match those of mechanical calculators, the electronic calculators that imitated them and the pen and paper calculations that preceded them. The correct word is “familiar” rather than “better”.
The problem with binary floating point is the IO conversion. Floating point algorithms seem
to ignore that problem.
If it doesn’t match decimal maths (to a given number of decimal places), it’s wrong. Floating point behaviour is predictable but not intuitive. Trying to understand then explain that int(100//.8) != int(100/.8) in Python (where // is the floor division operator) is not fun.
It’s almost as fun as finding out how various BASICs implement the \ (aka DIV) integer division operator. The variation in implementations is surprising.
Hmm, I trust you’re not suggesting decimal is a more true arithmetic than binary? Both of them fail to represent 1/3 correctly, and most divisions have the same problem, so both of them need to be rounded to some extent. Converting binary to and from decimal is also often approximate, of course. With appropriate rounding the two systems will give the same answers when one is converted to the other. But I wouldn’t say that makes either of them right, or better - I agree with @jecel that we’re accustomed to certain behaviours.
That said, the simple and common case of adding up hundredths (common when handling money) is not a simple case for binary. For that reason (as I’m sure you know), commercial computers were in the past more likely to be decimal, while scientific computers were more likely to use binary. But scaling the quantities by a factor of a hundred does a lot to overcome that difficulty.
But with decimal, at one time you could have as many decimal places that you needed.
Floating point come in the one size for BASIC, good for most things but balancing your check book. Basic was your online calculator, before calculators became a $9.99 wonder. Computer
graphics (read games) was deemed more important than good math, so BASIC progressed in that direction when you had more ROM for basic.
This intrigues me: the exponent is clearly binary (range of E-38 to E38 or so) but I’m not sure if the mantissa (aka significand) is decimal or binary. The manual I found speaks of having a decimal guard digit but I wonder if that’s an approximation: approximately one decimal digit’s worth of a binary number is guard, so the remaining N-1 decimal digit representation is as accurate as it needs to be.
What’s somewhat disturbing to me is the range of the exponent: 0 to 38, both for single- and double-precision. No negative exponents!
The manual claims 7 internal digits and 6 exposed for single-precision, and 17 and 16, respectively, for double-precision.
The 6 exposed digits for single precision is very similar to early MS BASIC version, so, I guess, these are decimal digit equivalents. (Also, just 6 binary digits should be very noticeable, and this is not the case. So, yes, there’s a remarkable reserve in precision.)
In comparison, according to the manual, the Model 100 features:
Single-precision using 4 bytes for “up to six significant digits” with an exponent range of -64 to 62.
Double-precision using 8 bytes for storage “for up to 14 significant digits”, the exponent range is -64 to 62, as well.
So, as for the mantissa, the PC-8201 (and the international version PC8201A) actually features better precision (I stand corrected), but for its lack of negative exponents (and just about half the range on the positive side) it suffers in what numbers can be represented, at all, especially for fractional values. – Quite an odd choice.
I am interviewing the authors of (DEC) BASIC PLUS tomorrow. Anyone have questions they want me to ask them?
Oh rats, didn’t notice this early enough. I would have suggested: what languages affected your design? what was the intended application area? how did the language develop?
No problem. Fortunately, channels of communication with Tom Griffiths are still open.
We can tell from how BASIC PLUS evolved over time, was that the eventual goals were:
Evans Griffiths and Hart used BASIC PLUS themselves for many years thereafter. They developed mission-critical, always-up software running on PDP-11s (and later VAXen) that interfaced between real-time telephone switching systems (Western Electric) and phone company accounting systems (IBM mainframes). Their telco software was written in BASIC PLUS, with high-performance algorithms and time-critical device drivers written in assembly language. The model is vaguely like Python, where the main, control software is written in Python, and libraries that have to be fast written in C/C++
It does create a new difficulty of limiting the useful range. In Locomotive BASIC, the ability to resolve a single penny is lost somewhere north of ÂŁ42 million when amounts are multiplied by 100.
This suggests that if you’re ever working with accounts of around £42 million, you should maybe consider using something slightly bigger than an Amstrad CPC … 
I think the problem is using thrifty software from cassette tape, with ÂŁ42 million cash. 
I wonder how many people used the wrong software or hardware, for their needs in the
early days of computing, because computer with basic was the only computer around.
.