PC-1211, PC-1250, etc. TVM

[robve]

(06-12-2024 12:45 PM)dm319 Wrote:  

(06-12-2024 12:29 AM)robve Wrote:  Working in non-IEEE754 is a pain. Some things just don't work out numerically as we're stuck with 10 digits to store in variables (internal calculations are 12 digits).

I'm curious - can you elaborate on this? In C I am presuming you are using binary rather than decimal. When you mean IEEE754 do you mean floating point binary or decimal? I've always thought doing maths stuff in binary is a pain as we generally view the results in decimal, which makes it hard to determine accuracy in terms of the number of decimal points.

It's about the internals. IEEE754 binary representations and operations must meet a set of requirements to ensure accuracy and to support +/-0 +/-inf and subnormals, guard and sticky bits/digits. That is not the case for 10 or 12 BCD vintage calculators (they may use one to three guard digits, but not consistently). Also, repeated internal rounding is not beneficial, actually it is "evil". Rounding problems lead to all sorts of numerical problems, hence IEEE754 offers a set of rounding flags to control this. IEEE754 also defines decimal representations that must meet this set of requirements. IEEE754 operations in an implementation must be correctly rounded. When considering implementations, implementing IEEE754 surely takes more effort. I did this in Z80 for Forth850 to support IEEE754 single precision with all requirements including rounding modes (but statically) except for subnormals (maybe sometime...).

To determine accuracy, I don't tend to think in the number of decimal places, but epsilon relative or absolute error. Decimal places do offer a quick insight, but it is useless otherwise. A silly example is 1.499999999 and 1.500000000 which only differ in 1E-9 but share no common digits except the first 1. Now 1.499999999 and 1.49999999 are further apart (9E-9).

One benefit of BCD is for accurate financial calculations perhaps, because amounts such as $0.01 are represented exactly whereas it is not in binary float (it's not 0.01 exactly but 0.010000000000000000208 in double precision). This matters for long running sums and in accumulation loops and when comparing totals. On the other hand, why people claim this but don't scale amounts by a factor 100 to avoid this is beyond me.

- Rob