Re: 2button, 1op RPN calculator, again

This explanation conflates accuracy with precision. This is not so unusual:
Mathematica does it too.
Here is a precise (14 decimal digits) value for pi: 3.1400000000000 .  You
may observe that it
is, however, NOT accurate.

For the Wang calculator to carry 14 decimal digits does not provide any
accuracy guarantee.  Judging from
the blurb below,  6.0 * 8.0 -48.0  would cancel out the significant digits,
leaving only roundoff
in the result.  Thus the remaining number would have no "accuracy". All
digits would be "error".

If we were to use eml to compute the difference between 48  computed two
different ways, there is no
assurance that we would get zero. In fact, it would be surprising if it
came out zero.
Consider, in Maxima, which has numerical routines for log and exp, but
prefers exact values when possible...

f(x,n):= if n=0 then x else exp(f(log(x), n-1));

f(z,3)  returns z.

f(123,3) returns 123

f(123.0,3) returns 122.9999999999999

f(1.23,3) returns 4.911201805224289*10^-17*%i+1.23

The idea that carrying 14 digits gets you 11 correct ones is plausible if
you are
poking at a calculator with your fingers. It doesn't work if you are doing
huge numbers of operations sight unseen.  There is a whole area of study,
numerical error analysis, sadly mostly unstudied by people who should know
more about it.

RJF





On Tue, May 5, 2026 at 2:12 PM Henry Baker <[email protected]> wrote:

> Hi Richard:
>
>
>
> Re accuracy:
>
>
>
> While an undergraduate at MIT in the late 1960's, I often used the Wang
>
> calculators which were sprinkled about some of the MIT libraries.
>
>
>
> As pointed out below, these machines *multiplied* by using logs,
>
> addition and exponentiation. In essence, they were digital slide
>
> rules!
>
>
>
> These Wang calculators were likely the *last* calculators ever made
>
> without using sophisticated integrated circuits.
>
>
>
> https://www.oldcalculatormuseum.com/wang360.html
>
>
>
> "The 300-series machines calculate to a full 14 digits of accuracy, but
> only display 10 digits. This makes the machine quite accurate. ***Since
> the Wang calculators used logarithms to perform multiplication and
> division,*** and even though Dr. Wang's log-generating circuit produced
> very accurate results, many logarithms are transcendental numbers
> which can never be represented with 100% accuracy no matter how many
> digits they are calculated out to. Because of the use of logarithms
> for multiplication and division operations, the previous-generation
> LOCI-2 could come up with results which would be slightly off. An
> example would be multiplying 6 by 8. The LOCI-2 would give an answer
> of 47.99999999. While 47.99999999 is technically useful as a
> reasonably accurate answer, such a result was generally considered
> incorrect by most calculator users. To make the 300-series more
> intuitive, these machines got the benefit of a special circuit that
> provided a round off function, which would cause such 6 x 8 to yield
> 48.0000000, which made the 300-series machine much more useful to
> non-technical (such as business and financial) users. This round-off
> function operated based on the non-displayed 11th digit (remember, the
> machines calculate to 14 digits of accuracy internally) of results."
>
>
>
>
>
> -----Original Message-----
> From: Richard Fateman <[email protected]>
> Sent: May 5, 2026 10:29 AM
> To: Stavros Macrakis <[email protected]>
> Cc: Henry Baker <[email protected]>, Barton Willis via Maxima-discuss <
> [email protected]>
> Subject: Re: [Maxima-discuss] 2button, 1op RPN calculator, again
>
>
> This is just a curiosity.  I thought I'd point out its uselessness
> for encoding computation of scientific use.
>
> What is the precision and accuracy of eml?
>
> If it is not specified, it should be clear that it is useless.
>
>  If it is specified, then examples for which the result
> is arbitrarily incorrect can be devised.
>
> If eml were used (say) for plotting, the picture could be arbitrarily
> wrong.
>
> Maybe the original author addresses this?
> RJF
>
> On Tue, May 5, 2026 at 1:12 PM Stavros Macrakis <[email protected]>
> wrote:
>
>> It has to have some way of entering other inputs if you want to denote
>> anything but constants. Or maybe you pre-push the inputs onto the stack, in
>> general multiple instances of them so that they'll be available at the
>> right place.
>>
>> On Tue, May 5, 2026 at 12:14 PM Henry Baker <[email protected]> wrote:
>>
>>> I just realized that this calculator doesn't have any 'regular' buttons
>>> at all; the only 2 buttons are the parentheses '(' and ')'.
>>>
>>> The '(' button pushes '1' onto the stack; the ')' replaces the top 2
>>> elts of the stack with the single object eml(x,y), where x,y were the top
>>> two elements of the stack.
>>>
>>> Clearly '(' increments the stack length by 1, while ')' decrements the
>>> stack length by 1, so we have a *parenthesis language*, and only properly
>>> paired parentheses are allowed.
>>>
>>> The stack comes initialized with a single object '1', because *every*
>>> legal computation has to start with a push, and the only constant that can
>>> be pushed onto the stack is a '1', so we needn't bother with that first
>>> push instruction at all !
>>>
>>> The number of legal instruction sequences of length 2n is Catalan(n) =
>>> binomial(2*n,n)/(n+1).
>>>
>>> This means that the fraction of legal instruction sequences approaches
>>> zero as the length of the sequence grows, so the bit efficiency of ANY
>>> RPN-type representation isn't going to be particularly good.
>>>
>>>
>>>
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss