jurjen@cwi.nl (Jurjen NE Bos) (08/02/90)
Playing with my 48, I found some bugs that I did not see reported by
others yet.
I found the following bugs on the HP48SX (version D):
Type [EQUATION] [{}] 1 / 7 + 2 [y^x] 5 + 3 -
Now type [{}] [<-].
You would expect only the - to disappear, but that doesn't happen:
It invents an entirely new formula for you.
How about this one:
Put 7 in I by 'I=7' DEF or 7 'I' STO.
Now watch the difference between
'N' {N I} | (giving 'I', wich is wrong), and
'N*1' {N I} | (giving the correct answer 7).
Why does | forget to evaluate?
A not so serious one, but it is still a bug:
Type [EQUATION] to get into the equationWriter, and type (2+3 [triangle <-]
now you can go all the way to the left by [blue-shift] [triangle <-], but
you cannot reach this location by repeated [triangle <-]. The rules act as
if the + is selected.
If you want to use the equivalent of TRACE on the 28, you can use the
the vectored ENTER to help you.
Enter the programs:
alphaENTER (25.5 bytes, #CA4Dh)
\<< PR1 OBJ\-> \>>
and
betaENTER (118.5 bytes, #F6B1h)
\<<
IF DUP "" ==
THEN DROP "?"
END 'KEY' \->TAG PR1 DROP
IF DEPTH
THEN DUP 1 \->TAG
ELSE "[Empty Stack]"
END PR1 DROP
\>>
Set flags -62 (user mode) and -63 (vectored ENTER). Make sure the output
is sent to the right port (printer to IR or wire).
Maybe you want to set -61 (USER toggle) to switch in and out USER mode
more quickly.
Watch out if you use USER key assignments.
A tip:
execute {STO 32.1 PURGE 54.2} STOKEYS so that STO and PURGE get a message when
typed (Yes, this is another bug. It is a result of the fact that the keys
differ from their commands (the keys save the old contents in LASTARG)).
Happy playing, Jurjen
--
| | "Never imagine yourself not to be otherwise than what |
| Jurjen N.E. Bos | it might appear to others that what you were or might |
| | have been was not otherwise than what you had been |
| jurjen@cwi.nl | would have appeared to them to be otherwise." |frechett@snoopy.Colorado.EDU (Mac the Ripper/ / / /) (08/03/90)
In article <1920@charon.cwi.nl> jurjen@cwi.nl (Jurjen NE Bos) writes: >Playing with my 48, I found some bugs that I did not see reported by >others yet. > >I found the following bugs on the HP48SX (version D): >Type [EQUATION] [{}] 1 / 7 + 2 [y^x] 5 + 3 - >Now type [{}] [<-]. >You would expect only the - to disappear, but that doesn't happen: >It invents an entirely new formula for you. > Ok, I was led to beleive that bigs in version D would be in C. I have a C. There is nothing wrong with this that I can see. It doesn't 'invent' a new formula, it just goes back and reformats it as if you HAD had inplicit () on. That is all. I suppose that it IS possible that D does something with it that C doesn't but this is really very unlikely. About the other ones, who knows.... Maybe someone from our friend 'Hewlett Packard' can shed some light on them. ian frechett frechett@snoopy.colorado.edu
billw@hpcvra.CV.HP.COM (William C Wickes) (08/04/90)
Mr. Bos is a little too liberal with the term "bug." A bug is usually considered to be a software defect where a program executes differently from its specifications, and which should be fixed if possible. This definition does not apply to any of the behaviors described by Mr. Bos. > Type [EQUATION] [{}] 1 / 7 + 2 [y^x] 5 + 3 - > Now type [{}] [<-]. > You would expect only the - to disappear, but that doesn't happen: > It invents an entirely new formula for you. When you hit backarrow, effectively the expression is reentered. Since you have changed the implicit parentheses mode, the entries are interpreted differently. > How about this one: > Put 7 in I by 'I=7' DEF or 7 'I' STO. > Now watch the difference between > 'N' {N I} | (giving 'I', wich is wrong), and > 'N*1' {N I} | (giving the correct answer 7). > Why does | forget to evaluate? When the source "expression" for | is a single name it is merely replaced if it matches the specified name, without evaluation. When the expression contains operators, their arguments are evaluated. This is in the specs; one could argue that the specs are "wrong." But | has almost no utility used in RPN form; an RPN execution was included only for completeness. > A not so serious one, but it is still a bug: > Type [EQUATION] to get into the equationWriter, and type (2+3 [triangle <-] > now you can go all the way to the left by [blue-shift] [triangle <-], but > you cannot reach this location by repeated [triangle <-]. The rules act as > if the + is selected. There is no value in reaching the left parenthesis, since all it can represent is the entire subexpression, which in this case is defined by the +. But there wasn't much point in spending extra code to prevent it either, for shift-left-arrow. > A tip: > execute {STO 32.1 PURGE 54.2} STOKEYS so that > STO and PURGE get a message when > typed (Yes, this is another bug. It is a result of the fact that the keys > differ from their commands (the keys save the old contents in LASTARG)). A full-featured trace mode was not provided nor supported on the HP 48SX, so we can hardly consider as a bug a behavior that does not support a particular attempt to provide a rudimentary trace mode. The STO and PURGE key actions, and vectored ENTER are excellent features that work EXACTLY as specified. Mr. Bos, you are to be congratulated on your evident enthusiasm for the HP 48SX, and your curiosity and attention to detail.
kevin@cbmvax.commodore.com (Kevin Klop) (08/04/90)
In article <24287@boulder.Colorado.EDU> frechett@snoopy.Colorado.EDU (Mac the Ripper/ / / /) writes: >In article <1920@charon.cwi.nl> jurjen@cwi.nl (Jurjen NE Bos) writes: >>Playing with my 48, I found some bugs that I did not see reported by >>others yet. >> >>I found the following bugs on the HP48SX (version D): >>Type [EQUATION] [{}] 1 / 7 + 2 [y^x] 5 + 3 - >>Now type [{}] [<-]. >>You would expect only the - to disappear, but that doesn't happen: >>It invents an entirely new formula for you. >> >Ok, I was led to beleive that bigs in version D would be in C. I have a C. >There is nothing wrong with this that I can see. It doesn't 'invent' a >new formula, it just goes back and reformats it as if you HAD had inplicit >() on. That is all. I suppose that it IS possible that D does something >with it that C doesn't but this is really very unlikely. About the other >ones, who knows.... Maybe someone from our friend 'Hewlett Packard' can >shed some light on them. Yes, it reformats the equation as if the implicit () was on, but that changes the semantics of the equation quite a bit. It shouldn't be doing that, IMHO., but rather should be leaving the part of the equation alone that had been set with implicit ()'s off. In fact, I venture to state that it should NOT be reformatting the equation at all when I press the <- key. The equation is as I want it, else I'll delete it myself, thank you. -- Kevin --