edp@jareth.enet.dec.com (Always mount a scratch monkey.) (04/05/91)
Several years ago, I sent Hewlett-Packard a wishlist in regard to the
HP-28 to. They incorporated nearly everything I (and I am sure others)
suggested into the HP-48. So, here is my wishlist for the successor to
the HP-48.
First are two things I would categorize as fixes:
Make SST-into evaluate directories instead of recalling them,
and make it step into IFERR constructs.
Fix the derivative and inverse of ABS. The derivative of
'ABS(X)' is 'SIGN(X)', but 'ABS(X+0)' 'X' \.d returns
'(CONJ(X)+X)/(ABS(X)*2)'. Yuck. Also, the 48 doesn't know
the inverse of ABS(X), but it is just 's1*X'.
Here's something a third party could do:
Provide AC power. This could be done without any
modifications to the 48, just with something that fits into
the battery compartment. A third party ought to be making
this, and Educalc should be selling it.
Next are some behavior changes:
In the multiple equation solver: If a list is specified as
the value of a variable, make that variable
calculator-controlled rather than user-controlled, since the
user is apparently specifying a guess.
When figuring the independent variable for plot parameters,
don't always pick X. How about choosing the global variable
that appears first in the expression and that is undefined
or, if none is undefined, the first global variable in the
expression? If you don't want to make this the default, how
about making it the algorithm used if an algebraic object is
passed to INDEP?
Upon editing an object, convert all undisplayable or
untypeable characters to "\code" form. Upon parsing, convert
back. This would allow editing of strings containing null
characters and the entry of programs containing strings with
unusual characters.
Include system and user flags in archives and restores.
Possibly include objects in Port 0 in archives and restores,
particularly libraries.
After a program in an alarm is evaluated, the system routine
that evaluates the alarm object ought to restore the
calculator to its previous state unless the program has
somehow requested otherwise. The state I am primarily
considering here is on/off -- after an alarm program runs,
the calculator should return to the off state if it were off
before the alarm. But if alarms disrupt other aspects of
state, those aspects should also be restored.
The next group is added functions:
Provide HP-16C functions for binary numbers: twos
complement, shifting by variable numbers of bits, et cetera.
Generate errors when converting between reals and binary
numbers if the conversion is out of range (e.g., negative
real to unsigned binary) or the conversion is imprecise
(binary to real greater than 10e12 or real with non-zero
fractional part to binary). Allow these errors to be turned
on or off with system flags, in the manner of the overflow
and underflow flags. Make comparisons (less than, greater
than) between binaries and reals work.
Provide the programmer access to everything the user has
access to: The Equation Writer, the Rules, the Matrix
Editor, et cetera. For example, access to the Rules
transformations might be provided by making the
transformations retrievable in the form of lists to use with
the MATCH commands. E.g., "n RULES" would provide the n-th
rule.
In the 48 are routines to support menus with dynamically
evaluated parts (such as the routines that make
white-background menu keys or menu keys with/without the
"on/off" box). Let MENU provide these functions to
user-specified menus. Also provide the programmer with
access to the catalog routines that are in the 48.
Provide ways to exit control structures -- to leave a current
loop iteration, to leave a loop or other construct, and to
leave a program. For example, make a new program construct:
named clauses. Hypothetical syntax for this might be:
<< : name : << clause >> >>
or
<< -> a b c 'name' << clause >> >>.
Within these programs, the sequence 'name' EXIT would cause
the clause to be exited.
There should be an application card including things like
ASC-> and ->ASC and a simple terminal program (with hooks
into Kermit). Let ASC-> take an optional checksum -- it
should accept "string" or { "string" #checksum }. The latter
case provides a check on communication integrity; the former
allows user experimentation. ASC-> should ignore whitespace.
Provide a way to wake up the calculator from the I/O port --
perhaps a selectable stand-by mode? I'd love to attach the
48 to my workstation and have it be usable over the network.
If there are issues of noise causing the calculator to turn
on spuriously, then make it settable by a flag. The default
out of the box is that OFF turns the calculator off. Set a
flag and OFF turns the calculator off but it will wake if
enough transitions are detected on the receive line in a
short period. Losing a few bytes during the power-up process
is acceptable. Once on, the 48 can check for a specific
sequence of bytes ("Hey, you, the 48, wake up!") as a
confirmation message or it will shut off, perhaps after
setting an annunciator to notify the user later that noise
caused an erroneous power-up.
Implement Kermit features to make more use of the 9600-baud
line -- such as sliding windows.
Make the Equation Writer faster. There's a wish-list item
for you: "I want this; don't ask me how to do it.".
Hewlett-Packard usually does an excellent job researching and
selecting algorithms, but is the design for the Equation
Writer really best? Can you use shortcuts?
My last topic is pie in the sky, a real way-out-there idea. It is sort
of a computational semanticist's dream -- or nightmare. But I think
the idea is a continuation of the object generalization that
Hewlett-Packard has already done on the 28 and 48.
Realize that lists, programs, and algebraics have basically
the same internal representation -- they are all lists of
objects. GET, PUT, and OBJ-> could work on programs and
algebraics as well as lists.
To start the changes I suggest, make GET and PUT work on
programs and algebraics: Get or put the n-th object. In
'A*B', the objects are A, B, and *, in that order. In the
program << A B * >>, the same is true. For the program <<
WHILE test REPEAT loop END >>, an OBJ-> should produce:
WHILE test REPEAT loop END
1
on the stack. Observe that this is the result the 48
currently gives for { WHILE test REPEAT loop END } OBJ->;
little change is needed here except the make the program type
acceptable as input to OBJ->. However, if the WHILE
statement above is in level 1, then another OBJ-> should
produce:
<< test >>
<< loop >>
2
WHILEREPEAT
Here "WHILEREPEAT" is a new token/command name. I suggest
that programs in the form << clause >> and constructs like WHILE
statements be considered objects of different types -- the
former, programs, act like lists when OBJ-> is used. The
latter, constructs, act like algebraics when OBJ-> is used.
Continuing this extension, applying WHILEREPEAT to the
objects << test >> and << loop >> on the stack would return
WHILE test REPEAT loop END. Observe that the program
delimiters on test and loop went away -- just as the
delimiters on A and B go away if you do 'A' 'B' *.
Extend this to all twelve of the 48's program structures:
IFTHEN
IFTHENELSE
CASETHEN
STARTNEXT
STARTSTEP
FORNEXT
FORSTEP
DOUNTIL
WHILEREPEAT
IFERRTHEN
IFERRTHENELSE
->LOCAL
Shown with inputs, these are:
test-clause true-clause IFTHEN
test-clause true-clause false-clause IFTHENELSE
{ { test-clause true-clause } . . . } CASETHEN
loop-clause STARTNEXT
loop-clause STARTSTEP
'var' loop-clause FORNEXT
'var' loop-clause FORSTEP
loop-clause test-clause DOUNTIL
test-clause loop-clause WHILEREPEAT
trap-clause error-clause IFERRTHEN
trap-clause error-clause normal-clause IFERRTHENELSE
{ name1 name2 ... namen } program ->LOCAL
Unfortunately, the FORNEXT, FORSTEP, and -> commands might
require some processing of the last of their inputs, to
change global variables to local.
Consider the behavior of IFTE. If it is passed algebraics,
it returns an algebraic expression containing IFTE. But if
the argument in level 3 is a number, IFTE returns either the
level 2 argument or the level 1 argument, depending on the
value of the number. The new IFTHENELSE command can do the
same thing:
If the level 3 argument is a number, return the level 2
or level 1 argument.
If all arguments are algebraics, return an algebraic.
If any argument is a program, return a program containing
IF THEN ELSE.
In fact, IFTE is now redundant and can be eliminated (or,
rather, what I have proposed under the name IFTHENELSE can be
called IFTE).
Similarly, IFTHEN is just named IFT. If the level 2 argument
is not a number, a program containing IF THEN is returned.
If the level 2 argument is a non-zero number, the level 1
argument is returned. Otherwise, a null program, << >>, is
returned.
Similar behaviors can be created for some of the other
program structures. 0 << loop >> WHILEREPEAT should return
the null program, and << loop >> 0 DOUNTIL should return <<
loop >>.
Lists are redundant. Programs are lists; we could eliminate
list as a separate object type, except that they may be
useful to keep certain semantics clear.
As justification for this, I will point out two times I have
wanted to build or operate on programs. The calculator state
is unpredictable by the time an alarm goes off, so an alarm
object may need to set the path. For this, a program such as
<< PATH { HOME dir1 dir2 ... dirn } EVAL other stuff >> is
needed. The sequence PATH 2 PUT is just what is needed to
prepare that program for use as an alarm object. Another
time I desired to make programs was to create a custom menu
list where each key did something similar, except that a
different argument was passed to a program -- each key did
something of the form << n ACTIONROUTINE >>. Again, a PUT is
just what is needed.
As I said, some of this is pie in the sky -- the parts about
decomposing program constructs like WHILE statements and
putting them together again with WHILEREPEAT is interesting
in itself. But to get back down to Earth, it really would be
useful to have GET, PUT, and OBJ-> work on programs and a
->PRG function that made programs, analogous to ->LIST.
-- edp (Eric Postpischil)
"Always mount a scratch monkey."
edp@jareth.enet.dec.comJohn@cup.portal.com (John Thomas Moylan) (04/08/91)
replacing their saturn processor with a 68332 would go along ways toward making the hp calculators handheld computers, increasing speed, address range a processor with more/easily acessible information, while remaining relativel inexpensive...
michaelv@IASTATE.EDU (Vanloon Michael Lee) (04/11/91)
In article <41032@cup.portal.com>, John@cup.portal.com (John Thomas Moylan) writes: > replacing their saturn processor with a 68332 would go along ways toward > making the hp calculators handheld computers, increasing speed, address range > a processor with more/easily acessible information, while remaining relativel > inexpensive... Yes, and use batteries at the rate of six a day! ;) michaelv@iastate.edu