calculator

From: Abraham Nemeth 356-5353 (anemeth@ece.eng.wayne.edu)
Date: Tue Sep 13 1994 - 11:56:19 PDT


September 13, 1994

     Greetings to members and friends of the R&D Committee. I have
downloaded and looked at the "Ultimate Calculator." As you will
remember, this is a shareware calculator that Mr. Jaquiss sent
to Tim and which Tim made available to anyone who is interested.
This is intended to be a preliminary report of what I found and
what I think.

     My first reaction: How uncanny it is that the UCALC and the
NFBCALC are so similar. Both use infix notation. The factorial
operator, which was present from the very beginning in the
NFBCALC, is a new addition to this latest upgrade of UCALC.
UCALC has a precision of 18 digits compared to the 15-digit
precision of the NFBCALC. Furthermore, the magnitude range of
UCALC is far greater than the magnitude ranhe of NFBCALC. This
is due to the fact that the author used a later version of C than
I did in compiling his program. If I were to recompile the source
program for NFBCALC using the latest version of the C program, the
precision and magnitude range of the result would equal that of
UCALC.

     UCALC supports more functions directly than does NFBCALC.
For example, UCALC supports the cotangent, secant, and cosecant
operations, which NFCCALC does not. In my opinion, this is
trivial. Anyone who uses trig functions on a calculator knows that
the cotangent is the reciprocal of the tangent, that the secant
is the reciprocal of the cosine, and that the cosecant is the
reciprocal of the sine. Thus, by combining the reciprocal operation
with the sine, cosine, or tangent operations on the NFB calulator
one will get the values of the other functions almost just as
fast.

     There are some features of UCALC from which NFBCALC could
benefit. One such feature is the ability to set the precision of
displayed numbers. NFBCALC always displays a number with full
precision; UCALC permits the user to set the precision to any
desired number of digits. Another valuable feature of UCALC is that
it permits the user to define his own functions and then use them
in subsequent calculations. Still another feature of UCALC is its
ability, upon request, to log a session with the calculator.
NFBCALC doest not have this feature.

     The next issue I would like to raise is a philosophical one.
When I designed NFBCALC, I took the point of view that the
calculator that results should have the same capabilities and the
same limitations as a stand-alone, hand-held calculator despite the
fact that it is being operated on a PC computer platform where there
are many opportunities to endow it with capabilities that no
hand-held calculator ever had. For example, suppose that I am the
proud oner of a hand-held calculator capable of 12-digit precision.
I enter a number and make a mistake in the tenth digit. My
hand-held calculator requires me to press the "clear entry"
button and reenter the number from the beginning. On a computer,
it is possible to arrange for backspacing over the mistake and
resume entering the number from the last correct digit. Which
approach should I take? There are many other situations which
pose a similar dilemma.

     My guess is that Mr. Jaquiss brought this calculator to Tim's
attention because it is touted as a graphing calculator. Indeed,
it has graphing capabilities. The graphs, appear on the screen.
The graphs have many valuable features -- you can include or
exclude an underlying grid; you can include or exclude the
coordinate axes; you can overlay multiple graphs using distinct
colors for each; there is a crosshair that, by means of the arrow
keys, you can move to any part of the screen so that you can read
off the coordinates of any point on the graph; and other features.
However, you cannot print the graph that you see on the screen
directly to paper. If you want a hard copy of a graph, you must
run graphics.com from DOS before loading UCALC. Then, to get a
hard copy, you must press PrtScreen when the graph you want is on
the screen. I don't know whether this is the most feasible
approach for a blind user. In any case, some modificationst would
be required. On a printer, a graph can be printed with a
resolution of 300 dpi2 on a braille embosser, a resolution of about
9 dpi is the most that is available.

     All this information and conjecture was obtained only from
reading the documentation. I still have to install UCALC and run
it to get a better feel for its capabilities. i will do that
soon and make another report at that time.

Best regards to all,

Abraham Nemeth, Ph.D.
anemeth@ece.eng.wayne.edu



This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST