▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
I don't have a 20b and don't plan to buy one, but I do have a 17b, which is described as "algebraic", but it is really a "chain logic" calculator. Unless you press the parentheses keys to force it to calculate correctly.
Actually, this is a term I had not heard until the 20b came out. Previously, I believe the term used had been "algebraic without precedence".
Now my question is, why? Why does HP even make calculators with such a stupid logic system? I am aware that nearly all cheap consumer "4bangers" and the like work that way, but why does HP have to copy them? For the 20b, you might say they were continuing the legacy of the 17b family, but, again, I wonder why they used this system to begin with?
I mean in what country do they teach math without the concept of algebraic precedence? Even if minimally educated people are not aware of this concept, surely that does not describe users of sophisticated business calculators.
I otherwise like my 17b, because it is so similar to my alltime favorite HP, the 27s, and it adds certain functions the 27s lacks. But nearly every time I pick it up, I end up cursing and starting over, because I forgot that it won't give me the correct answer unless I use the parentheses keys. Frustrating.
I know you RPN lovers will want to weigh in on this, but please remember, I am talking about calculators that are made for people who prefer algebraic.
Martin
▼
Posts: 193
Threads: 10
Joined: Mar 2008
hello,
Quote:
Now my question is, why? Why does HP even make calculators with such a stupid logic system [ALG with no priority]? I am aware that nearly all cheap consumer "4bangers" and the like work that way, but why does HP have to copy them? For the 20b, you might say they were continuing the legacy of the 17b family, but, again, I wonder why they used this system to begin with?
I mean in what country do they teach math without the concept of algebraic precedence? Even if minimally educated people are not aware of this concept, surely that does not describe users of sophisticated business calculators.
althrough you are right in lots of way, you are missing one point. most people will forget what they learned in school, and lots of business or even engineers people completely forgot the operator precedence and/or ignore it... this is why there is ALG with no operator precedence or CHAIN mode in the 20b.
ask your parents what 1+2*3= and most people will answer 9. My father did, and he is an engineer. my mother did and she has a PDH. when you stop dabeling in math or science, you forget these stuff...
cyrille
▼
Posts: 149
Threads: 7
Joined: Dec 2006
Chain mode is more efficient than enforcing operator precedence, which is simply a convention of written mathematical notation.
If you want to perform the operation (1+2)x3 = 9, chain mode allows you to do this without using parentheses, a saving of 2 keystrokes (or just 1 if the calculator can supply the opening parenthesis itself). If you really wanted the result to be 1+(2x3) = 7, then you can enter it as 2x3+1. If you're thinking about the problem you're working on, this shouldn't be an issue.
Once you understand how chain logic works, it's a better option than operator precedence. In a sense, this is similar to why many people prefer RPN, so I'm surprised to see the question being asked on this forum.
Posts: 320
Threads: 59
Joined: Dec 2006
As an educator, I'm totally baffled by this...
Quote:
...most people will forget what they learned in school, and lots of business or even engineers people completely forgot the operator precedence and/or ignore it... this is why there is ALG with no operator precedence or CHAIN mode in the 20b.
ask your parents what 1+2*3= and most people will answer 9.
and as soon as they do this on a "chain" mode calculator they will reinforce thier belief that it is true, along with kids learning maths early on. How horrendous to see 1+2*3=9 or 1+3*2=8 on a calculator. "No Johnny, multiplication is only commutative on select calculators and in certain situations." Yikes.
What if a repairman says parts are $105, labor $55 per hour. So a 3 hour job is obviously 105+55*3=480 (or $5940 if you're unlucky). If a student sees that on a calculator then it MUST be correct.
In a way it's is similar to the original TI81 (and maybe 82) order of operation "bug". Store 5 into x, and evaluate 10/2x. The early TI's produced 1, while the later (and current) ones produces the correct answer of 25.
If we are going to have "chain" logic, there may as well be a fourth mode called reverse logic which calculates everything right to left. Now that would create some interesting results, and keep our kids in perpetual belief that math IS difficult.
Edited: 7 Aug 2008, 2:29 p.m.
▼
Posts: 149
Threads: 7
Joined: Dec 2006
APL works like that.
Here is an article about mathematical notation which you might find interesting. It's by Ken Iverson, the devisor of the APL programming language:
http://elliscave.com/APL_J/tool.pdf
The relevant portion of this document is Sec.5.1, which begins on page 18 of the pdf.
Edited: 8 Aug 2008, 10:30 a.m.
Posts: 1,545
Threads: 168
Joined: Jul 2005
Couple of thoughts:
The 17b predates Cyrille and all other current HP calculator individuals, so they should get a pass on why the 17b used algebraic without precedence.
Having taught in business schools all during the late 1980s through the early 2000s, I can say how badly nonRPN HP business calculators performed for students compared to the TI offerings when doing any sort of nontrivial calculation. TI could be set to chain or AOS (nonprecedence or precedence). HP only offered chain.
Example: If you deposit $1000 into a savings account paying 6%, compounded monthly, how much will be in the account after 5 years.
Solving this WITHOUT using the TVM functions required these keystrokes on the chain HP 10b:
1000 x shift ( shift ( 1 + shift ( 0.06 divide 12 shift ) shift ) shift Y^X 60 =
That's 29 keystrokes if I counted correctly.
On the TI competitor, the keystrokes were (in AOS mode):
1000 x ( 1 + 0.06 divide 12 ) Y^X 60 =
Total of 20 keystrokes.
It was no wonder I had students throw away their HP 10b models and go buy the TI alternative.
[EDITED] For years I begged for algebraic with operator precedence on an HP ** financial calculator ** model.
Finally!
The HP 20b offers all three modes... RPN (woohoo), chain (for Cyrille's dad  kidding Cyrille!) and algebraic with precedence. I don't see the 20b continuing any legacy with the HP 17b, since it offers chain and algebraic. Chain is probably offered for comparison with TI as well as for "less sophisticated users".
This is a fantastic change and a welcome one.
Gene
P.S. As to why HP made calculators (and still does) that have a chain logic system... TI apparently thinks business users might want to use chain logic too, since it is present on all their business models. But at least they have almost always allowed a choice of modes, something that HP has at last provided. Way to go HP!
Edited: 8 Aug 2008, 8:54 a.m. after one or more responses were posted
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi Gene,
Quote:
For years I begged for algebraic with operator precedence on an HP model.
I'm far off my calcs right now, but IIRC at least the 27S had operator precedence according to math standards. Not 100% sure about the 20S, 21S and 22S, but there's a good chance all these work correctly (as far as algebraics can do ;)), too. So, where's the problem??
Regards, Walter
▼
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
Hi Gene,
I'm far off my calcs right now, but IIRC at least the 27S had operator precedence according to math standards. Not 100% sure about the 20S, 21S and 22S, but there's a good chance all these work correctly (as far as algebraics can do ;)), too. So, where's the problem??
Regards, Walter
The 20S has it, as do IRRC all the other algebraic scientific HP calc.
I think Gene was referring to HP financial calcs.
Dave.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Yep, my fault. I meant HP financial calculators. Was pretty clear elsewhere in my post but not in that one sentence. :)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hmmh, so what does it tell us that business calc users got "chain logic" while the other folks were thought to know the math rules? ;)
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Well, it tells us more about manufacturers who only gave business users chain logic.
After all, TI gave users a choice for years.
But, that's all the past!
HP has provided the best of all worlds...outclassing TI. :) RPN, chain and algebraic with precedence!
Woohoo. Lol.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
HP has provided the best of all worlds...outclassing TI. :) RPN, chain and algebraic with precedence!
I'll agree as soon as they give us a reasonable LCD. Sorry to repeat this request, but IMHO this is absolutely inevitable to reach out for a 42SII. A true "conditio sine qua non" 8)
Posts: 121
Threads: 21
Joined: Jun 2008
Key strokes on the 17B for
Formula:
1000*((1+(.06/12))^60
Algebraic (working inside to outside): 18 strokes
.06 / 12 + 1 shift yx 60 * 1000 =
Algebraic (working left to right): 26 strokes
1000 * ( ( ( 1 + ( .06 / 12 ) ) shift yx 60 ) ) =
RPN (working inside out): 17 strokes
.06 enter 12 / 1 + 60 yx 1000 *
RPN (working left to right): 20 strokes
1000 enter 1 enter .06 enter 12 / + 60 shift yx *
Point being: it's always more efficient to work smarter.
Gratuitous and obligatory point two: RPN is better than algebraic!
;)
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Mark 
Good illustration of the manual calculations of compund interest. I have a few points:
 I'd state "17BII" instead of "17B", as only that legacy financial model has both algebraic (without precedence) and RPN modes for direct comparison.
 The keystroke counts actually understate the differences, because 12 of them are required in each case just for data entry.
 "RPN (working inside out)" omits a necessary "shift" keystroke.
 "Algebraic (working left to right)" requires only the parentheses stated in the formula, so two of them could be omitted. Also, the last two closing parentheses could be omitted ("=" executes them). However, these simplifications would hide several intermediate results, so it's a fair comparison to include all the closing parentheses you have shown.
 An "algebraic with precedence" model such as the HP27S would require an "=" after the "1" to obtain the correct answer for "Algebraic (working inside to outside)".
 The correct answer is 1348.85015255, which can also be obtained/checked using builtin TVM on these models:
P/YR = 12; N = 60; I%YR=6; PV = 1000; PMT = 0; calculate FV.
 In this particular problem, "working smart" (from the inside out) requires only one "extra" operation (excluding entry of digits and math operations) for RPN and for algebraic without precedence. Algebraic with precedence requires two extra operations. "Working left to right" requires three extra operations for RPN and nine extra operations for algebraic without precedence.
 Bottom line: "Inside outward" is more efficient than lefttoright. RPN is never less efficient than algebraic for a single problem.
 KS
Edited: 10 Aug 2008, 6:20 p.m. after one or more responses were posted
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
I certainly agree that working "inside out" is more efficient on many algebraic models.
In fact, that's the way I show the manual calculations in the textbook I wrote that was used at the local university.
However, it is also problematic for many "business students".
Working inside out requires enough math ability to think the problem inside out. RPN does too, of course.
I have run across many students who can't do math well enough to do that.
And, too, it turns the usual argument for AOS on its head, which is: "Key the problem just as it is written".
If you are performing much work with a nonprecedence algebraic business calculator (die quickly, 10b2 !!), then insideout is the best game in town.
Again, that said, the 20b is marvelous because it finally gives you a proper choice from HP: chain, algebraic and RPN. :)
Posts: 121
Threads: 21
Joined: Jun 2008
Thanks for catching those items Karl.
I thought it would be interesting to count the TVM keystrokes, since you brought it up. Might as well be thorough!
Yes, this is the 17BII. Solving compound interest using builtin TVM function. Same problem as above:
shift MAIN FIN (3 strokes to get to the menu from any level)
TVM OTHER 12 P/YR EXIT
60 N
6 I%YR
1000 +/ PV
0 PMT
FV
Total strokes: 23
Subsequent calcs of this function would be fewer key strokes, so perhaps this is not a fair comparison  ;)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi Karl,
if we want to be picky, I have some more points:
Quote:
 "RPN (working inside out)" omits a necessary "shift" keystroke.
 "Algebraic (working left to right)" could be two keystrokes shorter if the two closing parentheses are omitted ("=" executes them). However, this would hide several intermediate results, so it's a fair comparison to include them.
 "RPN (working inside out)" may be done with only 14 keystrokes:
6 % 12 / 1 + 60 shift y^x E 3 *
 For "'Algebraic' (working left to right)" I'd need 21 strokes:
E 3 * ( ( ( 1 + ( 6 % / 12 ) ) shift y^x 60 =
plus 2 for the final closing parentheses if you want to see the intermediate results.
 For real "Algebraic (working left to right)" on a 27S only 19 strokes are necessary:
1000 * ( 1 + 6 % / 12 ) shift y^x 60 =
BTW the 27S refuses to do the E 3 trick.
 "Algebraic (working inside out)" is hardly used in real life. Algebraic users get the parentheses to avoid thinking inside out. Also "RPN (working left to right)" is hardly used straightforward  it's simply too risky as long as stack depth is limited to 4.
Regards, Walter
Edited: 10 Aug 2008, 6:49 p.m.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Walter 
Yes indeed, there usually shortcuts or ways to save keystrokes on data entry. I addressed the problem as "MikeO" posed it. Really, it is proper to count operations, not keystrokes.
To enter 0.06 as "6 %" is not germane to RPN or algebraic; it is a particular implementation of the function.
In your example,
6 % 12 / 1 + 60 shift y^x E 3 *
"6 %" does not, in general, produce 0.06 on any RPN model  even the businessoriented HP17BII.
Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models  notably the financial models and the HP35s.
For full, comparable detail in calculations, it is important to see each intermediate result. Hence, the ")" or "=" where necessary.
Regards,
 KS
Edited: 11 Aug 2008, 1:59 a.m. after one or more responses were posted
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi Karl,
Quote:
"6 %" does not, in general, produce 0.06 on any RPN model  even the businessoriented HP17BII.
Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models  notably the financial models and the HP35s.
Both shortcuts work flawlessly on my 14B 8)
You're right with the RPN models however  I was too fast with the analogy ;)  so this section of my post must read:
"RPN (working inside out)" may be done with only 16 keystrokes:
.06 ENTER 12 / 1 + 60 shift y^x E 3 *
I count the 35s as an exception ;)
Regards, Walter
Posts: 408
Threads: 45
Joined: Oct 2007
Quote:
Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models  notably the financial models and the HP35s.
yes, AFAIK it works on the HP 41, HP 48, HP 12C but not on HP 35S (results in "Syntax Error")
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
As far as I can check, entering 1000 as E 3 works on each and every scientific from 35 to 50g except the 35s (HP, why did you make this exception?!?). Furthermore, it works on the 27, but not on the 27S. Out of dedicated business calculators, the 12C, 12C Ann, and the 14B process it correctly. The earlier Bcalculators up to 37E didn't feature an EEX (or E) function at all.
Edited: 11 Aug 2008, 2:57 a.m.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
Both shortcuts work flawlessly on my 14B
... it seems that "E 3" as a shortcut for entering 1000 works on the lowend (HP10B) and midgrade (HP14B) Pioneerseries financial models, but not the highend Pioneerseries HP17B, HP17BII, and HP27S.
Ya learn somethin' every day, trivial as it might be...
I can think of only this as a plausible rationale:
These highend Pioneers had alphanumeric capabilities for named variables (accessible only through SOLVE); also, the use of numbers in baseten exponential form is far less common for business applications than in scientific/engineering applications.
Given this, HP didn't want users to mistakenly believe that to keystroke "E" was to enter the letter "E". Thus, to precede baseten "E" with a number was made compulsory.
One could argue that the HP27S was intended for science/engineering managers, not financiers. True, but the HP27S is algebraicentry, and functionally is more akin to the HP17B/BII than to the HP42S.
For the HP35s, a similar rationale of preventing confusion may have been the issue, given the presence on the keyboard of an unshifted white "E" for numbers with exponents, and a red "E" as storage register or label. This characteristic is shared with the HP32S, HP32SII, and HP33s  all of which also logically use "E" for hexadecimal fourteen (but that's a different issue). Technical people, however, ought not be confused about these multiple meanings.
If there's no way to create a valid input that begins with the baseten "E", it shouldn't be accepted as the start of an entry. What seems likeliest to me is that additional RPLstyle "accept anything for the input buffer, and process it later" logic was incorporated here, but the handy shortcut was not coded.
 KS
Edited: 12 Aug 2008, 6:16 a.m. after one or more responses were posted
▼
Posts: 408
Threads: 45
Joined: Oct 2007
Quote:
For the HP35s, a similar rationale of preventing confusion may have been the issue, given the presence of an unshifted white "E" and a red "E" accessed through "STO" or "RCL". If there's no way to create a valid input that begins with the baseten "E", perhaps it shouldn't be accepted as the start of an entry. However, it seems that some RPLstyle "accept anything into the buffer, and process it later" logic was incorporated.
 KS
why didn't HP stick with "EEX" which is the hallmark of traditional HP claculators? I'm happy that "EEX" has made a comeback on the new HP 20B.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
why didn't HP stick with "EEX" which is the hallmark of traditional HP calculators? I'm happy that "EEX" has made a comeback on the new HP 20B.
"EEX" might have looked somewhat cryptic, and "E" is quite familiar to technical people who write programs in Fortran or C; e.g., 2.79E+009 for 2.79 billion.
Not all models had both baseten "E" and alphabetic "E" on the keyboard.
(BTW, I clarified my earlier post a bit  not to contradict your reply...)
 KS
Edited: 11 Aug 2008, 2:56 a.m.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
I can think of only this as a plausible rationale:
The highend Pioneers had alphanumeric capabilities for named variables (but only through SOLVE); also, the use of numbers in baseten exponential form is far less common for business applications than in scientific/engineering applications.
Given this, HP didn't want users to mistakenly believe that to keystroke "E" was to enter the letter "E". Thus, to precede baseten "E" with a number was made compulsory.
Now, one could argue that the HP27S was intended for science/engineering managers, not financiers. True, but the HP27S is algebraicentry, and functionally is more akin to the HP17B/BII than to the HP42S.
For the HP35s, a similar rationale of preventing confusion may have been the issue, given the presence on the keyboard of an unshifted white "E" and a red "E" accessed through "STO" or "RCL". If there's no way to create a valid input that begins with the baseten "E", perhaps it shouldn't be accepted as the start of an entry. However, it seems that some RPLstyle "accept anything into the buffer, and process it later" logic was incorporated.
Any statement from HP regarding these speculations?
Posts: 901
Threads: 113
Joined: Jun 2007
Way back in the dark ages we used to call chain logic "adding machine arithmetic" because that is the way the old mechanical adding machines did it. I think that the early electronic fourbangers did it that way because (1) that is the way most of the intended users expected it to be, and (2) it was easier to mechanize.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
I thought adding machine logic was postfix for addition or subtraction, and infix for mult and div?
▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
Well, it sure seems I accomplished my goal with my original post, which was to stir up some interesting opinions.
Martin
