|A polite "rebuttal" to Valentin's HP-15C Reasonable Improvements|
Message #32 Posted by Karl Schneider on 3 Oct 2003, 1:59 p.m.,
in response to message #20 by Valentin Albillo
First, some emphsasis: By, "For what it is designed to be", I intended a fairly restrictive definition of the product within the technology of the era: its form factor, display type, features, and design objectives/constraints.
I agree that Valentin's suggestions are not unreasonable, and would certainly make the HP-15C more capable, but several are a bit "out of bounds", in my opinion.
- faster speed, as you mentioned
No disagreement here...
Certainly HP had the capability at the time to make LCD machines faster than the Voyagers; the antedated 41C* is about twice as fast. However, I'm not sure if the Voyagers' early '80s CMOS technology permitted faster operation. The hardware experts could explain how Voyager technolgy differed from 41 technology. It would be a shame if the Voyagers could have been faster, but were "held back" by a desire for non-competition with the 41C*.
- larger RAM, say up to 999 steps (i.e: matrices up to 12x12). More would be desirable but 999 is reasonable.
Well, 1 kB (1024 bytes) allocatable RAM would give the 999 lines or 12x12 matrix. Maybe that would be the "reasonable" upper limit. The 67x7 = 469 bytes was more than the base 41C, and more than twice as much as the 11C/16C and 34C had.
Certainly, more RAM always offers more flexibility, but, given the limitations (no I/O, alphanumerics or external labels for programming, slow processing), I think that most users would find it difficult to put very much more RAM to practical use. And, how expensive was this constant memory at the time?
It seems that the 64x7 = 448 bytes of allocatable RAM was a conscious decision by HP. It was just enough for an 8x8 matrix and solution of a 4-variable complex-valued system with some special techniques, as described in the manual. Would you really want to generate or enter larger ones? The calc is slow, and storing or recalling each element takes two keystrokes (unless a looping program is written). Forget about electronic data exchange...
999 lines of programming, shown in keycodes with no modularization with external labels, cataloguing, or alpha messages? Perish the thought. The 15C is not well-suited for permanent libraries of programs.
I would be nice, however, to have more memory to allow storage of large amounts of data while still being able to access INTEG and other features.
- program steps displayed as alphanumerics, not keykodes, even if no further alpha capabilites (no alpha input, no commands to do alpha manipulations).
How would this be done well with the 7-segment LCD characters? This was discussed extensively in the thread.
However, here's an idea: Represent the rows of the keycodes spreadsheet-cell style, using A, b, C, and d, rather than 1-4. That way, multi-digit numbers could be merged onto one line, as on the alphanumeric 41C*, 42S, and 32S/Sii.
- if the complex stack does exist (i.e.: we are in 'complex mode') then STO and RCL should deal with both components of a complex number at once, instead of forcing you to store and recall separately the real and imaginary parts. This would require an implicit redefinition of the registers' boundaries, but the HP-16C does it all the time when the word size changes, so it can be done.
This certainly would make some things easier, but I don't think it's a very sound idea. The 42S allows explicit redefinition of the numbered storage registers to allow them to accommodate complex-valued inputs, but you're talking about automatic changes. This is fraught with problems:
If the space allocated to numbered registers were to be automatically doubled each time complex mode was set, the expansion might constrain the pool (even at 1 kB). If there was inadequate pool space for the expansion, complex mode could not even be set. Also, the imaginary parts of complex numbers in numbered registers would be lost each time complex mode was un-set if redefinition were automatic.
If matrix-data allocation remained real-valued in complex mode, then storing the contents of any complex-valued data in numerical registers into matrices would not work the same way as in real mode -- the imaginary portion would fall into the "bit bucket".
BTW, the 16C will cut either the precision of data or number of registers each time the word size is changed, which may cause a loss of user data.
No, until there is Fortran-style data typing, these things should be avoided.