Why chain logic?



#29

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 "4-bangers" 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 all-time 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


#30

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 "4-bangers" 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


#31

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.

#32

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.


#33

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.

#34

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 non-RPN HP business calculators performed for students compared to the TI offerings when doing any sort of non-trivial calculation. TI could be set to chain or AOS (non-precedence 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


#35

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


#36

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.


#37

Yep, my fault. I meant HP financial calculators. Was pretty clear elsewhere in my post but not in that one sentence. :-)


#38

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? ;)


#39

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.


#40

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)
#41

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!

;)


#42

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 HP-27S 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 built-in 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 left-to-right. 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


#43

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 non-precedence algebraic business calculator (die quickly, 10b2 !!), then inside-out 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. :-)

#44

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 built-in 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 - ;)

#45

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.


#46

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 business-oriented HP-17BII.

Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models -- notably the financial models and the HP-35s.

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


#47

Hi Karl,

Quote:
"6 %" does not, in general, produce 0.06 on any RPN model -- even the business-oriented HP-17BII.

Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models -- notably the financial models and the HP-35s.


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

#48

Quote:

Entering 1000 as "E 3" is a nice shortcut that was not implemented on all models -- notably the financial models and the HP-35s.



yes, AFAIK it works on the HP 41, HP 48, HP 12C but not on HP 35S (results in "Syntax Error")


#49

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 B-calculators up to 37E didn't feature an EEX (or E) function at all.

Edited: 11 Aug 2008, 2:57 a.m.

#50

Quote:
Both shortcuts work flawlessly on my 14B

... it seems that "E 3" as a shortcut for entering 1000 works on the low-end (HP-10B) and mid-grade (HP-14B) Pioneer-series financial models, but not the high-end Pioneer-series HP-17B, HP-17BII, and HP-27S.

Ya learn somethin' every day, trivial as it might be...

I can think of only this as a plausible rationale:

These high-end Pioneers had alphanumeric capabilities for named variables (accessible only through SOLVE); also, the use of numbers in base-ten exponential form is far less common for business applications than in scientific/engineering applications.

Given this, H-P didn't want users to mistakenly believe that to keystroke "E" was to enter the letter "E". Thus, to precede base-ten "E" with a number was made compulsory.

One could argue that the HP-27S was intended for science/engineering managers, not financiers. True, but the HP-27S is algebraic-entry, and functionally is more akin to the HP17B/BII than to the HP-42S.

For the HP-35s, 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 HP-32S, HP-32SII, and HP-33s -- 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 base-ten "E", it shouldn't be accepted as the start of an entry. What seems likeliest to me is that additional RPL-style "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


#51

Quote:

For the HP-35s, 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 base-ten "E", perhaps it shouldn't be accepted as the start of an entry. However, it seems that some RPL-style "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.


#52

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 base-ten "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.

#53

Quote:
I can think of only this as a plausible rationale:

The high-end Pioneers had alphanumeric capabilities for named variables (but only through SOLVE); also, the use of numbers in base-ten exponential form is far less common for business applications than in scientific/engineering applications.

Given this, H-P didn't want users to mistakenly believe that to keystroke "E" was to enter the letter "E". Thus, to precede base-ten "E" with a number was made compulsory.

Now, one could argue that the HP-27S was intended for science/engineering managers, not financiers. True, but the HP-27S is algebraic-entry, and functionally is more akin to the HP17B/BII than to the HP-42S.

For the HP-35s, 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 base-ten "E", perhaps it shouldn't be accepted as the start of an entry. However, it seems that some RPL-style "accept anything into the buffer, and process it later" logic was incorporated.


Any statement from HP regarding these speculations?
#54

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 four-bangers 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.


#55

I thought adding machine logic was postfix for addition or subtraction, and infix for mult and div?


#56

Well, it sure seems I accomplished my goal with my original post, which was to stir up some interesting opinions.

Martin


Possibly Related Threads...
Thread Author Replies Views Last Post
  RPN logic question Victor Quiros 52 3,525 03-12-2013, 02:59 PM
Last Post: Victor Quiros
  HP-65 logic board repair - help required Alberto Fenini 1 418 02-17-2013, 06:39 PM
Last Post: John Robinson
  HP-50G Equation Editing Logic Matt Agajanian 4 531 04-20-2012, 11:21 PM
Last Post: Matt Agajanian
  The story of HP's Logic Analyzers Steve Leibson 3 490 02-19-2012, 11:44 PM
Last Post: Bruce Larrabee
  32-bit MCODE tool chain for the HP41 incl. D41 now MichaelG 4 586 02-12-2012, 08:57 PM
Last Post: Kerem Kapkin (Silicon Valley, CA)
  OT: Help with Logic Dart AC adapter Donald Williams 9 896 03-19-2011, 10:22 AM
Last Post: Donald Williams
  USB Logic Analyzer Thomas Chrapkiewicz 7 662 03-09-2010, 04:54 PM
Last Post: Adrian Godwin
  HEPAX chain broken - and fixed Geir Isene 8 812 11-17-2009, 04:54 AM
Last Post: Vieira, Luiz C. (Brazil)
  Classic Series Logic Board - Desoldering Temp ? John Robinson 7 712 09-17-2009, 09:36 PM
Last Post: Dan W
  Voyager series, logic PCA and keyboard PCA Geoff Quickfall 7 753 07-28-2009, 04:20 PM
Last Post: Eric Smith

Forum Jump: