[Some ways the HP48SX differs from the 28S, by Bill Wickes. -jkh] (Comp.sys.handhelds) Item: 2356 by edp at jareth.enet.dec.com Author: [Eric Postpischil] Subj: HP-28 to HP-48 changes Date: Fri Mar 08 1991 ---------- Resp: 2 of 2 by billw at hpcvra.cv.hp.com. Author: [William C Wickes] Date: Tue Mar 12 1991 From Eric Postpischil: > > On the 28, doing something (like plotting) that caused PPAR to be > created caused the 28 to scan the equation and select the first variable > as the independent variable. On the 48, X is always assumed. Why did > HP make this change? One guess is that algebraics can now contain local > variables (because of the "where" and integration operators), so the > first variable seen is not necessarily a free variable of the > expression. Is this why they made the change? This was just part of the general overhaul of the plotting interface. It appears that x (X) is the most common independent variable name used in plotting discussions, just as y is commonly used as the dependent variable. It also simplifies manual descriptions etc. to be able to use a specific name. Nothing profound here. > Another change is that storage arithmetic has been generalized. It used > to be that STO+ would accept only certain objects to be added (real and > complex numbers, I think). Now any objects acceptable to + are > acceptable to STO+, and similarly for the other STO operators. Okay, > that change provides more function, as do the evaluation of lists and 0 > WAIT. STO+ and friends were originally written to allow "in-place" arithmetic on stored numbers and arrays, primarily so that you could succeed in performing some array operations for which there might otherwise not be enough free memory. Many people requested the extensions of STO+ that are present in the 48. > Two items that fit into the category of trying to improve behavior are > that STO checks for directly recursive definition (putting 'var' in > 'var') This is a property of certain keys (STO, solver menu keys, and left-shifted VAR or CST menu keys), not of STO itself. > and plotting 'variable=expression' plots only the expression > (unless flag setting is changed). It is common for people to say they are plotting "y=f(x)" even though they are really just plotting f(x), so the 48 lets you define a plot with either 'f(x)' or 'y=f(x)'. In the latter case, y is only used as an axis label. > ABORT is gone. 0 DOERR is not the same thing -- why was this function > deleted? People wanted the ability to abort a program with an error message, hence DOERR. 0 DOERR is essentially equivalent to pressing ATTN, which is the same as ABORT on the HP28, except that HP48 ATTN is a trappable error, whereas ATTN was not trappable on the 28. > == and != now properly compare reals and algebraics. On the 28, (0,0) > did not equal 0, according to ==, but on the 48 they do. Call it a refinement. From Jurjen NE Bos: > Of course, OBGET and OBPUT are vanished, and nothing has come to replace > them. One can disassemble algebraics with OBJ->, or use \v|MATCH, but > sometimes you wished they were there. Same for EXGET and EXPUT. The problem is that with the advent of functions with an indefinite number of arguments, plus the ability for libraries to define new functions, providing a position argument for OBGET etc. becomes rather problematic. The MATCH commands plus OBJ-> provide more and better substitution/extraction capabilities. > What is also missing are the catalogs. They were rather useful, especially > the units catalog, becuase it knew the full name of all the units. And: > USAG is not a catalog. We would have liked to have added output descriptions to the command catalog, but this would have been very expensive in ROM, so we traded the catalogs for the Quick Reference Guide. And the UNITS menu is a more useful units catalog than the HP28 units catalog, since the units are sorted by type and the menu provides active entry/conversion facilities. You can alway get the full name of a unit with REVIEW. > One big missing function is VIEW\^| and VIEW\v|. Why were these left out? > I do not always have the memory to edit an object just to see a few more > lines. VIEWup and VIEWdown evolved into the interactive stack on the 48. It's true that editing an object can take more memory than VIEWdown, but even the latter can run out of memory so it's only a question of the threshold of pain. I generally find that if there isn't enough memory to edit an object, there likely will not be enough memory to do much else with it. Bill Wickes