Quote:
Yes, indeed, that's what I believed, and what I had written for my
recently-updated Article #556 (see earlier post in this thread).
I did read your article, but it makes only a brief reference to
RPL models.
Quote:
The reason is that no number will be displayed with 12 digits
after the decimal point. A zero before the point will always be
displayed if the mantissa is less than one.
I'll take your word for it that that's true for "Classic RPN"
models, but for RPL models, in STD display mode, a number less
than one that can be displayed with 12 or less digits (without
using scientific notation) is displayed without a zero to the left
of the decimal point. For example, 10
-12 is
displayed as .000000000001, that is, with 12 digits after the
decimal point, which is what (mis)led me to at first expect that
STD display mode would result in an "error tolerance" of
10
-12.
Quote:
My results on the HP-33S have yet to show any difference between
SCI or ENG vs. FIX. If a multiplicative accuracy factor is
defined by a display mode, then it's difficult to make any
definite distinction just by using different modes.
For the RPL models too, as far as I've noticed, using FIX, SCI, or
ENG have exactly the same affect on the error tolerance for
integration, with STD having the same effect as 11 FIX.
Quote:
This is why I believe an accuracy-factor variable "IACC"
(a la the HP-42S) would have made more sense than
FIX/SCI/ENG/ALL.
I don't like using the display mode for setting the error
tolerance either, but storing it in a reserved variable would have
the disadvantage that a user may well forget to set it. I'd rather
have it as an argument, and after all, there's no shortage of
stack levels on an RPL model.
I still wonder exactly how IERR is calculated on the RPL models.
It seems to be approximately the user-specified error
tolerance times the absolute value of the estimated integral
(assuming successful convergence).
For that matter, storing the probable maximum error in the
reserved variable IERR can be viewed as a disadvantage, as a user
may well neglect to check it, especially if IERR doesn't appear in
the current menu. But any RPL function must return exactly one
result to the stack.
Something that I wish for is a way to check how many samples were
used, which is something that I don't know of any way to check.
Come to think of it, it might be useful to be able to specify how
many samples to use, as an alternative to the iterative process of
checking until three successive estimates agree within the error
tolerance.
Quote:
Thank you for providing information that corroborates what I have
inferred from tests and the manuals.
You're welcome.
Regards,
James