▼
Posts: 144
Threads: 20
Joined: Jan 1970
I'm taking yet another remedial math class (it's a nonchallengable requirement for older people going back to college in CA) and we've run into an interesting quirk:
3^2
this is reported as reducing to 9 on my 28s and 48sx
On the professor's TI30x (recentish model) it's 9,
on another student's ti83 it's 9,
and on my TI30 (1976 model), it's 9
She insists that it is properly 9 as written, and that to get an answer of 9, you have to do
(3)^2
(fine, it's a convention of reading that I won't argue with)
So her question is why it happens. I know why it happens with an rpn calc, operation are done in order but other scientifics?
Christof
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
On the 28 series, 48 series, or 49G, try '3^2' EVAL and
\<< 3 2 ^ NEG \>> EVAL.
Regards, James
▼
Posts: 144
Threads: 20
Joined: Jan 1970
I hadn't thought to do an eval on the hp, and yes,
'3^2' does give the answer according to standard operation order.
I knew that 3 <enter> x^2 would give the answrr as entered in rpn, so no worries there.
I think I find it more interesting that the various TI calcs give different answers when they are all billed as suitable for "natural" entry and education.
I'm going to go try this on various Casio models now.
The question for the future is whther or not I can explain to the professor how and why this happens in the calcs. (admirably, she only uses a basic ti30 for everything up to and including her calc series courses the flip side is she doesn't *understand* graphing calcs at all and is confused about the programming capabilities).
C
Posts: 25
Threads: 11
Joined: Jan 1970
On many TI's the "" key simply multiplies by a 1 so it looks like you wrote 1*3^2 instead of (3)^2. I think many people would disagree with your math teacher.
ARUID
▼
Posts: 144
Threads: 20
Joined: Jan 1970
as for how to "read"
3^2
 yah, some people will argue how you handle the  . I've found books that claim both methods.
C
Posts: 136
Threads: 22
Joined: Aug 2010
Hi Christof,
An algebraic calculator will parse the expression entered to convert it to an internal stackform  essentially RPN or similar.
Programming languages use a similar trick. The following is copied from my Borland Pascal language reference manual:
In complex expressions, rules of precedence determine the order in which operations are performed.
Operators Precedence
 
@, not first (highest)
*, /, div, mod, and, shl, shr, as second
+, –, or, xor third
=, <>, <, >, <=, >=, in, is fourth (lowest)
An operator with higher precedence is evaluated before an operator with lower precedence, while operators of equal precedence associate to the left. Hence the expression
X + Y * Z
multiplies Y times Z, then adds X to the result; * is performed first, because is has a higher precedence than +. But
X  Y + Z
first subtracts Y from X, then adds Z to the result; – and + have the same precedence, so the operation on the left is performed first.
You can use parentheses to override these precedence rules. An expression within parentheses is evaluated first, then treated as a single operand. For example,
(X + Y) * Z
multiplies Z times the sum of X and Y.
Interestingly, in this Pascal implementation, there is no power operator. You have to choose 3 * 3 or else (3 * 3), thus forcing you to choose.
If, on the TI, "^" takes precedence over "" then I would expect an answer of 9. If the reverse, then 9. If they are of equal precedence, then I would expect lefttoright evaluation and hence an answer of 9. As long as the TI is consistant in its treatment, then there is no right or wrong, IMO.
Derive, which is written by mathematicians, shows and entry of 3^2 as
2
 3
and evaluates it as 9.
Perhaps someone with a mathematics background could say if if "^" takes precedence over "" by convention.
Posts: 540
Threads: 22
Joined: Jan 2005
Simple: exponentiation takes a higher precedence than unary negation.
So, 3^2 is the same thing as (3^2), and not at all the same thing as (3)^2
Best,
 Les [http://www.lesbell.com.au]
Posts: 72
Threads: 8
Joined: Jan 1970
Hi,
I have always made a different argument about this matter:
When you look at a textbook, it cannot distinguish between a dash corresponding to subtraction and a dash corresponding to negation.
So when you see an expression or subexpression in a text / textbook with a leading "", I have always interepreted this as a minus with an implied preceding zero. So:
3^2 is the same as 03^2 or 9
(3)^2 is the same as +9
That is the latter would be equivalent to:
(03)^2 or (Negative 3)^2
Now whether this is absolutely correct, I do not know, but it tends to make sense. I would also contend the expression display algebraic calculators have the wrong precedence rules, because for the most part, they can distinguish between these 2. Part of this is to make the pressing of the subtraction key automatically bring up "ANS " if it is the first key pressed. Also it would confuse many students if they typed [()]3^2 and received the answer, 9 as I believe would be appropriate. That is, the answer would not be the same as the book, on the other hand I would contend that they didn't transcribe what was in the book. Note that I also tell my students that 2 operators should never be adjacent to each other, use common sense to figure out where that extra pair of parenthesis should be, correct the expression (perhaps in your head), and then carry out the calculation.
I also tell my students to always put parenthesis around negative numbers on these calculators to avoid any surprises. It is instructive to look at how Sharp calculators employ the [()] keys. If hit before the number, they work just like HPs or TIs in algebraic mode, but when hit after the number, they automatically negate the number and wrap it in parenthesis. All of these calculators should work this way.
I have written about this matter in more detail in the scientific calculator forum on the TI website. I am doing this just before a class, so I may elaborate in another posting.
▼
Posts: 144
Threads: 20
Joined: Jan 1970
Well, after much explaining of code (I do enough lisp to make up for my lack of current rpl skills), the design of computer/calculator operating systems, and reference to a dozen algebra texts, My professor is firmly convinced that:
for 3^2
the "standard" "way to read it" in college algebra is (3^2). But some mathemeticians read it (3)^2 .
Calculators do what you tell them, in order (menaing that if you enter 3, thay assume you mean 3. and when you follow that by x^2, you mean to square (3).)
Some calculators (most programmables and "educationals" )will allow you to enter an equation in "textbook language" and then evaluate it but *some*, like the ti83, the casio fx115, and the ti89, *assume* that you are *not* entering in order, and instead are entering an equation to be evaluated at the end of complete entry.
Personally, the fact that TI can't keep the same operation style in all of its educational calcs bothers me. The ti 30 series calcs don't act the same as the ti 80 series calcs, yet both series are marketed as stepladder rungs.
C
▼
Posts: 72
Threads: 8
Joined: Jan 1970
I stand by my interpretation. My interpretation is also quite consistent and arrives at the right answer every time as far as I can tell [now I'm in trouble], provided you never allow an expression with contiguous operators such as "2 * 3". I feel that this should be interpreted as
"(2)*(3)" or
"(2)(3)" if using implicit multiplication. The expression "2(3)" would get the same result, but that would not be my interpretation of the expression.
I have never seen "3^2" as written in a textbook with the appropriate superscripting interpreted to result in the value, +9. Now if the textbook had clearly different versions of the symbol "", one version for negation and another for subtraction, and the "" in the expression was clearly that which corresponded to negation, then, indeed, the answer would be +9. However as written in the book, I believe an interpretation that is CONSISTENT and achieves the right results is the presumption that an expression written as "3^2" in a textbook corresponds to "0  3^2".
Consequently it doesn't matter whether you interpret the expression, say "5" as negative 5 or alternatively "0  5",
the result is the same. For practical purposes we can just accept that "5" is negative 5 and leave it at that.
The problem with the calculator algorithm is that the [()] should bind to the following number before the exponentiation. This would be much the same as in AOS or RPN calculators. But calculators perform as they have been programmed to perform, and they can be programmed to have whatever precedence rules are chosen by the manufacturer.
I contend that the problem described pertaining to the TI calculators is NOT a matter of inconsistency as much as it is the fact that their AOS calculators handle this appropriately and their EOS calculators do not. Those HP calculators that handle EOS also have the same problem. I want to emphasize the fact that the problem is easily resolved with whatever interpretation you might have by enclosing negative numbers with parenthesis on EOS calculators.
BTW, I find this an interesting topic because of the ambiguity here. I don't believe there is a definite answer. I am an adjunct math instructor at a community college [among other things], and I have discussed this matter with other math instructors. We all get the correct results for such textbook calculations, but many of us have different explanations for this subtle matter. I, too, have a background and work experience in the computer field, including compiler testing, and that is probably one reason for my choice of explanation. It is essentially equivalent to zeroing a register prior to carrying out a calculation.
Posts: 152
Threads: 12
Joined: Jan 1970
I've always interpreted it based on context, rather than observing any hard and fast rules. For instance:
2x^{3}3^{2}
would be:
2(x^{3})(3^{2})
but:
3^{2} (i.e. by itself)
would be:
(3)^{2}
Just to complicate matters however, I seem to recall that:
x^{n}
should almost always be interpreted:
1(x^{n})
Basically, algebraic notation is ambiguous in this instance. That's one of the reasons why prefix (and, by extension, postfix) notation was developed. Just another good argument for using RPN. Accept no substitutes! ;^)
▼
Posts: 72
Threads: 8
Joined: Jan 1970
Hi John,
The "multiply by (1) rule" as applied in an EOS calculator is ok IF you're willing to accept that the keystroke sequence:
[()] 3 [^] 2 [ENTER]
should return the result (9) on an EOS calculator. I contend that it should return (+9) and that the negation should bind immediately, as on an RPN or AOS calculator.
On the other hand the keystroke sequence,
0 [] 3 [^] 2 [ENTER]
is the correct transcription of the textbook expression
"3^2" on an EOS calculator. See my preceding post. In many programming languages there is no equivalent to [()] and in such languages you would use the equivalent of:
[] 3 [^] 2 [ENTER]
Unfortunately, most EOS calculators do not allow an expression with a leading minus. [I believe they should.]
This would, then, be equivalent to "0  3^2".
[BTW, it is interesting to see how negative exponents are entered in RPN on an HP19BII.]
▼
Posts: 152
Threads: 12
Joined: Jan 1970
You bring up some interesting points (in both posts). It should be noted that I am most definitely not a mathematician. In fact, I never really liked math. Having said that, allow me to dive in over my head...
In general, I agree. Given the general form x^{n}, any notational ambiguity seems to be in whether to interpret the "" as a property of the specific value of "x" as in the case x = 3 and (3)^{2}, or as an operator (i.e. subtraction) as in x = 3 and (3^{2}). My point was that it is vital to look at the context of the example before trying to interpret the meaning.
In Christof's original post, the example was 3^{2}. Is this in the form of x^{n}? It seems to me (well, both of us, really  and others to boot) that it is and that Christof's teacher (and the TI83) was wro erm, confused. :^)
Now, if it had been a fragment of a larger equation (e.g. 84  3^{2}) then the other interpretation would have been correct, since the "" in that case is most definitely an operation involving the whole of x^{n}. I have noticed that, in most texts, this case is indicated by a space between the "" and the x as I have done.
(BTW, I'm not sure what "EOS" refers to. Or "AOS" for that matter. "RPN" I do know. :^)
[I]t is interesting to see how negative exponents are entered in RPN on an HP19BII.
I'm not sure what you mean. For 25^{3} it would be:
25 [Enter] 3 [+/] [y^{x}]
wouldn't it? Seems straightforward enough. Or do you mean (25^{3})? That would be keyed:
25 [Enter] 3 [y^{x}] [+/]
Just like you'd work it in your head. IIRC, in algebraic mode, it would be:
25 [y^{x}] 3 [+/] [=]
or (assuming no pending operation):
25 [y^{x}] 3 [=] [+/]
or even more confusingly (assuming a pending value):
[] [(] 25 [y^{x}] 3 [)] [=]
(the last "[)]" is optional)
Doesn't RPN simply rock? ;^)
▼
Posts: 144
Threads: 20
Joined: Jan 1970
AOS is Algebraic Operating System according to my old 1970's TI manuals. EOS I assume is "educational" or something. RPN we all know.
19BII serno: 3523s00779
RPN mode:
[3] [+/] [shift] [x^2] gives 9
[3] [input] [3] [+/] [shift] [^] gives 3.703703703...E2
ALG mode gives the same answers.
C
▼
Posts: 882
Threads: 23
Joined: Jan 2005
Posts: 72
Threads: 8
Joined: Jan 1970
Hi John,
Clarifications on my posting:
About the 19BII, negative numbers are handled with the
[+/] key, whereas negative exponents are handled with the
[] key. This is not directly related to the general discussion, I just believe it is interesting.
AOS is TI's term for "traditional" algebraic calculators in which a number is displayed, the aforementioned TI30, e.g., the TI30Xa [NOT the TI30XII, etc.]. Other examples are the HP20S, CASIO fx260 solar, HP6S, etc. AOS stands for algebraic operating system.
EOS is TI's term for algebraic calculators that display the entire algebraic expression. This is, then, interpreted/evaluated when the [ENTER] key is selected. Common examples are the HP30S, all TI graphing calculators, HP49 in algebraic mode [oops :)], HP48 with tick marks delimited expressions, etc. This is called DAL by Sharp, and VPAM or SVPAM by CASIO. EOS stands for either equation operating system or expression operating system  I don't recall which.
There seems to be a line of reasoning here that goes like this:
how do the calculators work?  lets explain and/or justify this methodology rather than asking the question of how should calculators work based on the way textbooks display expressions and what, precisely, the "" symbols in the textbook truly represent. I am simply contending that the calculator implementation in these EOS calculators is not quite correct.
I agree  RPN calculators don't present this problem, and I prefer RPN calculators. Unfortunately, I cannot recommend these to my students for a variety of reasons including the current dependability of a continued supply of such calculators as well as the school's and students' embedded base of TI calculators. I can't teach algebra students how to use calculators that they don't have. On the other hand, I need a consistent way to explain EOS calculator results in the context of expressions displayed in a textbook.
▼
Posts: 152
Threads: 12
Joined: Jan 1970
About the 19BII, negative numbers are handled with the [+/] key, whereas negative exponents are handled with the [] key.
Hmm. That is indeed interesting. For all of the other HP RPN machines I'm familiar with, the [+/] is used. I've got a 19BII around somewhere. It's in pretty rough shape, but you've made me curious about that aspect of it.
I am simply contending that the calculator implementation in these EOS calculators is not quite correct.
Ah. Given your explaination of "AOS/EOS," I think I understand more clearly. To restate:
In the case of the older (AOS) machines, the operators are evaluated as they are entered. The only exception being that, if the [(] key is used, the imediately preceding operation is postponed until the enclosed sequence has been evaluated and terminated by a matching [)] or by the [=] operation.
On the newer (EOS) devices, however, the entire sequence is held without evaluation until complete. So, if I enter 3^{2}, the operations are evaluated in strict precedence order (exponentiation, then subtraction in this case). But, since there is no value preceding the "", subtraction from "0" is assumed.
I agree with you that is a dangerous  and often incorrect  assumption. On the other hand, I'm not sure how it could be implemented differently on an EOS machine. By the time the parser gets around to dealing with the "" operation, it has already evaluated the exponent. I'm sure it is possible, if decidedly nontrivial, to create a parser that would take the existence of any preceding values or symbols into account before deciding on how to interpret the "3". Much simpler  though less graceful  to simply use a different operation to represent negation (e.g. [+/], [CHS], [()], etc.). Of course, that brings us right back to how the user interprets and keys in the expression... :^)
It's puzzling to me that the TI83 doesn't have a "signswap" key. Still more puzzling is how Christof's teacher could possibly interpret 3^{2} as (3^{2}), let alone that it should always be interpreted so.
▼
Posts: 72
Threads: 8
Joined: Jan 1970
Hi John,
This is one of those "your mileage may be different" posts. Simply my opinions. Probably best read in context with my previous postings:
In the case of the older (AOS) machines, the operators are evaluated as they are entered. The only exception being that, if the [(] key is used, the imediately preceding operation is postponed until the enclosed sequence has been evaluated and terminated by a matching [)] or by the [=] operation.
yes
On the newer (EOS) devices, however, the entire sequence is held without evaluation until complete. So, if I enter 3^{2}, the operations are evaluated in strict precedence order (exponentiation, then subtraction in this case). But, since there is no value preceding the "", subtraction from "0" is assumed.[n;]
Not exactly  There are 2 keys on these EOS that are pertinent on these calculators. Using the RPN terminology, they are [()] CHS, and [] subtraction. I am contending that on these calculators:
[()]3[x^{2}] should yield positive 9 because negation should precede exponentiation. Negation is not subtraction.
OTOH in the expression "3^{2}" as written in, for example, a textbook, the "" represents subtraction and whenever it is the first character in an expression or subexpression in such text there is an implied preceding zero. So in the textbook:
"3^{2}" means the same thing as
"0  3^{2}"
I agree with you that is a dangerous  and often incorrect  assumption. On the other hand, I'm not sure how it could be implemented differently on an EOS machine. By the time the parser gets around to dealing with the "" operation, it has already evaluated the exponent. I'm sure it is possible, if decidedly nontrivial, to create a parser that would take the existence of any preceding values or symbols into account before deciding on how to interpret the "3". Much simpler  though less graceful  to simply use a different operation to represent negation (e.g. [+/], [CHS], [()], etc.). Of course, that brings us right back to how the user interprets and keys in the expression... :^)
They do have a negation key as well as a subtraction key. They both work as advertised. Unfortunately, in my opinion, the negation key has the wrong precedence. Negation should immediately bind to the following number, variable, function, and/or expression enclosed in parenthesis immediately following the negation operator. [I hope I've covered all the bases, but I've probably neglected something].
It's puzzling to me that the TI83 doesn't have a "signswap" key.
Well in the form of [()], they do, but EOS would not allow it to act immediately, because the expression, as you stated, isn't evaluated until it is entered in its entirety.
Still more puzzling is how Christof's teacher could possibly interpret 3^{2} as (3^{2}), let alone that it should always be interpreted so.
Well, in this case the result is the same, but I think the interpretation may not be correct. There may also be another issue here and it might be what you intended to write about above. The pertinent issue is whether
3^{2} yields the same value as (3)^{2}
If these expressions emanate from a text, it is absolutely clear that they don't. If they are generated by any current EOS calculator and the "" is created by pressing the CHS key, they still don't, but it is my contention that they should on such calculators.
In a text in the first expression above, the "" would correspond to subtraction from an implicit zero, and in a text in the second case it really doesn't matter whether you consider the "" to correspond to subtraction from an implicit zero or negation, but the implicit zero rule will always work provided you never allow contiguous operators.
It all relates to the precedence level of the negation operator on the calculator. It should also be noted that the "" issued by the CHS key and the "" issued by the subtraction produce distinct symbols on the display. Unfortunately, they are not sufficiently distinct in most cases.
There is another source of confusion. Christof's teacher uses an AOS calculator, the TI30Xa. In terms of negation on this calculator, there is no ambiguity, because negation, the CHS key which appears as [+/] [sort of] is a postfix operator and works just like the CHS key in RPN.
▼
Posts: 152
Threads: 12
Joined: Jan 1970
I am contending that on these
calculators[,] [()]3[x^{2}] should yield positive 9 because negation should precede exponentiation. Negation is not subtraction.
Agreed.
OTOH in the expression "3^{2}" as written in, for example, a textbook, the "" represents subtraction and whenever it is the first character in an expression or subexpression in such text there is an implied preceding zero. So in the textbook [...]
"3^{2}" as "0  3^{2}"
This is the one that leaves me scratching my head. Seems very counterintuitive and more than a little ambiguous. Oh well, I guess that's why my degree is in history, not math. :^)
It's interesting to note that, on the HP 27S, if you press the [] (subtraction) key without a pending value or operation, the display will show "0  ". Very cool. :^)
They do have a negation key as well as a subtraction key. They both work as advertised. Unfortunately, in my opinion, the negation key has the wrong precedence. Negation should immediately bind to the following number, variable, function, and/or expression enclosed in parenthesis immediately following the negation operator.
Once again, I agree. Unfortunately, however, the negation key ([()], [+/], [CHS], etc.) on most EOS machines  including the HP 39G  seems to be interpreted as "stick a minus sign in front of the current (or next, depending on entry logic for the key) value, which then get parsed as "subtract from previous value or zero (if no previous value)." Very frustrating.
The pertinent issue is whether 3^{2} yields the same value as (3)^{2}[.] If these expressions emanate from a text, it is absolutely clear that they don't. If they are generated by any current EOS calculator and the "" is created by pressing the CHS key, they still don't, but it is my contention that they should on such calculators.
Yes, but only if the calculator supplies (and displays) the parens around, in this case, the "3" as on the Sharp which you previously mentioned. If it doesn't, then the current approach seems to be the "safer" one, since it tends to eliminate any potential ambiguity in the user's interpretation of the displayed formula, prior to evaluation.
Of course, the unfortunate sided effect is that mathematically inept people like myself, laboring under the mistaken assumption that the "" in "3" serves to indicate some intrinsic property of the value in question, rather than an operation to be performed on the value "3", will misinterpret it anyway, thus producing long, esoteric, and tedious message threads on discussion boards. :^)
It should also be noted that the "" issued by the CHS key and the "" issued by the subtraction produce distinct symbols on the display. Unfortunately, they are not sufficiently distinct in most cases.
Hmm. I don't think I've ever really noticed any difference in the symbols. (Guess that's a pretty good argument for "not sufficiently distinct," huh? ;^) I'll have to remember to look more closely at the displays next time.
Posts: 909
Threads: 40
Joined: Jan 1970
After searching the Casio website, I found this out. I still don't know what "SVPAM" means, though.
Posts: 144
Threads: 20
Joined: Jan 1970
My professor's contention is that all calculators *should* accept
[] [3] [x^2] [=] == 1(3^2)
(where [] represents a change sign key)
Note again the Casio makes the most sense of currently marketed educationals (assuming rumors of the hp20s demise) the chsgn key is actually a () which is explained by casio as multiplying by negative 1.
I think the main issue that came up here is that the *way* calculators work isn't addressed in classes and this particular prof wants something thatfollows her shortcuts and standards.
My problem is that I *think* math incommon lisp, elisp, or RPL and don't get the same intuitive answer for this. yes, the rules of precedence say that exp functions before multiplcation; so assuming '' to always mean '1 times' works fine. I tend to add that when rewriting EQs for entry into emacs or rpn but it doesn't seem to come natural to many people.
Maybe I should use some of the info in these posts to write an operation faq for the class.
C
▼
Posts: 152
Threads: 12
Joined: Jan 1970
My professor's contention is that all calculators *should* accept [] [3] [x^2] [=] == 1(3^2) (where [] represents a change sign key)
Okay, now I'm confused again. This seems contrary to your earlier statement. Do you mean that [] [3] [x^2] [=] should evaluate to 9 or to 9? (Above, you seem to be indicating the first case.) If the latter, it would really be interesting if your professor could be conviced to write up a short explanation of her(?) position.
As rsenzer indicated elsewhere, the signswap operation modifies the internal representation of a value (e.g. 3[+/] or [+/]3, depending on how the individual device works, becomes 3), whereas the [] implies a pending subtraction operation and will, on those EOS machines mentioned, be evaluated  however wrongly  as 0  (3^{2}) (or, alternately, as 1(3^{2})). The situation doesn't exist in AOS calculators (or RPN, for that matter) because operations are generally performed immediately (see my earlier post), thus neatly sidestepping the entire issue of operational precedence.
I guess we can distill this entire thread down to the maxim: Know Thy Calculator.
Or, better still, simply use RPN... ;^)
▼
Posts: 144
Threads: 20
Joined: Jan 1970
Oops!
That was supposed to read:
My professor's contention is that all calculators *should* accept
[] [3] [x^2] [=] == 1(3^2)
(where [] represents a change sign key)
Sorry about that.
C
▼
Posts: 152
Threads: 12
Joined: Jan 1970
Mm. That's what I thought you meant. :^)
I would have to take issue with your professor's position. The signswap operation should only affect the value immediately following (or preceding, for postfix logic machines) the operator. In this case, that would be the "3" not "3^{2}".
If you are a daring fellow and are willing to risk your future grade and educational opportunities, you might try the following argument:
Given that the sign of a value is an intrisic property of that value and that the signswap operator serves to allow that property to be set, if we assume that the signswap operation is unary and that unary operators have a higher priorty than other, binary, operators (such as exponentiation), why shouldn't we be forced to enclose the 3[^]2 in parens? Anything else would seem to be inconsistent with other unary operators such as [n!].
If, on the other hand, we don't wish to stipulate that the signswap operator is unary, why shouldn't we consider it to be so? After all, isn't it simply used to set an intrinsic property of a value?
Use it with caution. As always, YMMV, of course. :^)
Posts: 57
Threads: 27
Joined: Jan 1970
Posts: 136
Threads: 22
Joined: Aug 2010
I intended my other reply to your thread to be "opinion neutral". Just a statement of facts. However, since reading all the arguments I have changed my mind.
At first, I thought that 3^2 ought to be 9, but now I think it should be 9. Indeed, '3^2' EVAL on my 28S and 48SX yields 9. I'm not sure how you reached 9 unless you used RPN, which relies on your interpretation of the expression.
To my mind, the most compelling argument is that 893^2 = 80, therefore 3^2 by itself ought to be 9.
▼
Posts: 152
Threads: 12
Joined: Jan 1970
To my mind, the most compelling argument is that 893^2 = 80, therefore 3^2 by itself ought to be 9.
Ah, but isn't it really just an specific example of the more general x^{n}, where x = 3 and n = 2? Surely that would be written as 3^{2} (I can't recall ever seeing otherwise) and interpreted as (3)^{2}, not (3^{2})?
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
If we consider the "" sign to mean "multiply by negative one", let a=1, b=3, and n=2. Consider the expression ab^{n}.
Should this mean (ab)^{n} or should it mean a(b^{n})?
▼
Posts: 152
Threads: 12
Joined: Jan 1970
Consider the expression ab^{n}. Should this mean (ab)^{n} or should it mean a(b^{n})?
I may be wrong, but isn't ab^{n} always read as a(b^{n})? After all 3x^{3} isn't interpreted as (3x)^{3}  unless I've forgotten more algebra than I thought. :^)
Besides, while it is true 3 = 1 ^{.} 3, that doesn't mean that I should always represent a negative number in that form any more than I should always represent 6 as 2 ^{.} 3. In fact, whenever a number is replaced by its factors, it is usual to enclose them in parens. For example, given that n = 6:
n! > 6! > (2 ^{.} 3)! = 720 (correct)
not
n! > 6! > 2 ^{.} 3! = 12 (incorrect)
nor
n! > 6! > (2! ^{.} 3!) = 12 (also incorrect)
Therefore, since pulling out 1 is simply the factoring of 3...
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
I see your point, but the convention is that exponentiation has a higher precedence than negation, so a^{n} means (a^{n}), not (a)^{n}. Maybe there isn't any good reason for the convention other than that that's the way that mathematicians have agreed to interpret expressions.
Regards,
James
▼
Posts: 152
Threads: 12
Joined: Jan 1970
[B]ut the convention is that exponentiation has a higher precedence than negation, so a^{n} means (a^{n}), not (a)^{n}.
I must admit, I'm not familiar with that convention. It seems rather counterintuitive. How can an operation have a higher precedence than an intrinsic property of a value?
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
I must admit, I'm not familiar with that convention.
What can I say? I learned that convention, I suppose, sometime back in the early 1960s. My grandniece learned it a couple of years ago in prealgebra.
It seems rather counterintuitive.
Now that I think about it, it would probably seem strange to me if I weren't accustomed to it.
How can an operation have a higher precedence than an intrinsic property of a value?
Good question; I don't know. My guess is that when the convention came into use perhaps negative numbers weren't considered to be properly "natural" values. After all, can you hold 3 of anything in your hand?
Regards,
James
▼
Posts: 152
Threads: 12
Joined: Jan 1970
After all, can you hold 3 of anything in your hand?
I don't know about that. I've got a stack of bills here that I can (barely) hold in my hand that would seem to argue differently... :^)
Kidding aside, you're probably right. I do seem to recall reading somewhere that "natural numbers" are only positive integers. In that light, I suppose, the interpretation makes sense.
I always knew there was something decidedly "unnatural" about creditors... ;^)
Posts: 540
Threads: 22
Joined: Jan 2005
Actually, precedence (and associativity) is a thorny issue. In the world of mathematics in general, I've always understood exponentiation to have a higher precedence than negation. However, wanting to check my facts, my first reaction was to pull my ancient copy of Harbison & Steele's "C: A Reference Manual" off the shelf  completely forgetting that C, of course, does not even have an exponentiation operator.
However, I infer from the standard C table of precendence and associativity that *if* C did support exponentiation, the unary minus operator would be of higher precedence than exponentiation. This is because in C, the unary operators as a group all have higher precedence than the binary operators.
Unfortunately, I no longer have reference manuals for languages like FORTRAN or PL/I (?) which ISTR support exponentiation. (I'm guessing, in the case of PL/I, but it seems like that language had operators for *everything* <g>).
Best,
 Les [http://www.lesbell.com.au]
▼
Posts: 72
Threads: 8
Joined: Jan 1970
Hi Les,
Some of the more recent programming languages might have negation operators per se, but most of these "older" languages did not and the "", essentially the subtraction operator was the means for entering a negative number. So you frequently had to wrap a parenthesis around the entity to be negated to assure the desired effect. Since they had no negation operator, they didn't explicitly have precedence rules for negation.
Nevertheless, a function or subroutine might encounter an parameter whose value was a negative number. The contents of a variable or data structure such as an array might contain a negative number as well or an expression or subexpression might evaluate to a negative number.
Clearly, early programming languages such as Fortran, PL/I, and Cobol had rules for handling such data. For example, "Y= 1.0 / X" where the content of X might be negative. They could also handle an expression like "N = 1". The Fortran 77 Standard and I presume the latest Fortran standards defined the rules for constants and 1 probably met the rules for a constant as opposed to treating it as "0  1". It would be interesting to see what the standards say about an expression like
"N = M". Needless to say, such expressions generally work with the expected results, so I'm not questioning that. [Although, I'm sure there is a gotcha in PL/I, there always is.]
I use to know this stuff for C and Fortran, but its been years since I was involved with compiler testing.
If I recall, C has some form of binary negation operator, "~" tilde, if I recall, but this may just be one's compliment [or is that complement ? :) ]
▼
Posts: 540
Threads: 22
Joined: Jan 2005
>>
If I recall, C has some form of binary negation operator, "~" tilde, if I recall, but this may just be one's compliment [or is that complement ? :) ]
<<
In C, "the prefix operator "" computes arithmetic negation of its operand" (Harbison & Steele). But they then go on to say "A unary minus expression "e" may be considered to be a shorthand notation for "0(e)"; the two expressions in effect always perform the same computation". Which leaves us not much the wiser, I'm afraid.
For an integral type, "" would give the two's complement. The "~" operator is bitwise negation (one's complement) and the "!" operator is logical negation.
It's nice that, at least in the world of programming languages, all this stuff is tightly specified, so that the programmer and the compiler or interpreter can be brought to some kind of agreement, and a shame that it's not so clear in the wider world of math. . .
Best,
 Les [http://www.lesbell.com.au]
Posts: 13
Threads: 3
Joined: Jan 1970
In Fortran77, the operator precedence high to low is: exponentiation, multiplication and division, addition and unary plus and subtraction and unary minus.
▼
Posts: 540
Threads: 22
Joined: Jan 2005
Interesting. The language that I've been using most recently, Perl, is the same. See
http://tit.irk.ru/perl2/prog3/ch03_01.htm
for more info. I think that programming languages generally give exponentiation higher precedence than unary minus, and the HP48 agrees.
Best,
 Les [http://www.lesbell.com.au]
Posts: 489
Threads: 11
Joined: Jan 2005
"Ask Dr. Math" from the Math Forum at Drexel University gives two different explanations (from two different people) of the precedence rules. One says that exponentiation ALWAYS takes precedence over negation (http://mathforum.org/library/drmath/view/53194.html). The other says the same thing when working with variables, but that when working with numbers the precedence is unclear and should always be specified with parentheses (http://mathforum.org/library/drmath/view/55713.html). I tend to agree with the first interpretation.
▼
Posts: 610
Threads: 53
Joined: Aug 2005
If I understood correctlyt he main problem is to know wether the  sign is equal to 0  abs(x) or 1*abs(x).
If x^2 is quite clear (ie (x^2)), 3^2 is not as such. Therefore to avoid any doubt it is recommended to use parentheses in potentially dubious cases.
▼
Posts: 152
Threads: 12
Joined: Jan 1970
Therefore to avoid any doubt it is recommended to use parentheses in potentially dubious cases.
Sound advice.
Lukasiewicz, I feel your pain... ;^)
Posts: 1,041
Threads: 15
Joined: Jan 2005
I too agree with his first interpretation, but because not everyone does, perhaps it's best to use the parentheses when we're writing for someone other than ourselves and there's some chance of misunderstanding, and certainly when we're not sure of what the precedence rules of a particular calculator or programming language are.
By the way, on the 48 series and the 49G, setting flag 53 causes extra parentheses to be displayed when an algebraic expression is put on the stack, explicitly showing the order of operations. Makes for a rather cluttered looking expression, but perhaps easier than looking up the rules in the manual.
Regards,
James
Posts: 1,041
Threads: 15
Joined: Jan 2005
Of course the developers of a language can use any precedence rules that they choose to. Preferably they'd choose rules which seemed intuitive to the users, and one would hope for clear documentation of the rules. It seems to me that I've run across at least one that considered + and  to have the same precedence as * and /, using a strict left to right order so that 1 + 2 * 3 equalled 9 instead of 7. Presumably this is for people who've never taken an algebra class. I suppose that you could set + and  to have a higher precedence than * and / if you really wanted to; you'd just have to place your parentheses differently.
Interestingly, on the 28 series and 48 series, 'a^b^c' is treated as '(a^b)^c', but on the 49G the same expression is treated as 'a^(b^c). I've asked my sister and brotherinlaw (both math teachers) which is correct, and they both said that parentheses were needed; without them they wouldn't know which way to interpret the expression.
I can't seem to find any "authoritative" (other than textbooks) document on the order of operations in algebra, it seems to be regarded as something that "everybody knows".
Regards,
James
▼
Posts: 540
Threads: 22
Joined: Jan 2005
>>
Interestingly, on the 28 series and 48 series, 'a^b^c' is treated as '(a^b)^c', but on the 49G the same expression is treated as 'a^(b^c). I've asked my sister and
brotherinlaw (both math teachers) which is correct, and they both said that parentheses were needed; without them they wouldn't know which way to interpret the
expression.
<<
Interesting. . . This isn't a question of precedence, but rather of associativity  and I could swear that one of the math references I saw recently pointed out that exponentiation associates right to left, meaning that a^b^c should be interpreted as a^(b^c)  which is certainly how I would have done it without stopping to think(!?!).
A quick Google search is returning me lots of pages that agree for computer languages such as Perl, but I'm pretty sure it is the case for paperandpencil math as well.
Best,
 Les [http://www.lesbell.com.au]
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Yes, it is a matter of association rather than precedence, but I'd guess that it's still a matter of "order of operations". My intuition tells me to associate from right to left on a "tower of exponents" (that is, 'a^b^c'='a^(b^c)', and I was surprised when my calculator (48SX, IIRC) did the opposite, but I didn't recall ever seeing it without parentheses in a textbook, so I just figured that my intuition had led me astray. Dr. Math at http://mathforum.org/library/drmath/view/54362.html agrees that the (informal) convention is to work from right to left on this problem for a variety of reasons. For myself, perhaps the easiest explanation is that (a^b)^c is equivalent to the simpler a^(b*c), or, using superscripts and implied multiplication, a^{bc}, so why bother using a "tower of exponents" for it and requiring parentheses for a^(b^c)? I don't find Dr. Ian's final example at all convincing though.
Regards,
James
Posts: 72
Threads: 8
Joined: Jan 1970
Pure Speculation here:
I tend to believe that the issue of how to interpret consecutive exponentiation operators may have originated more as a computer science issue rather than a math issue. As alluded to in a number of the postings, when you don't have an operator, but instead use a "tower" for expressing exponentiation, there is no ambiguity.
I suspect when it became necessary, perhaps, for the first time in Fortran, to make a decision about the order of execution of
a**b**c
[** is the exponentiation operator in fortran]
that is when the "official" order of operations from right to left for exponentiation operators was established. This may have been based on the fact that it was easier to write the program this way on the particular hardware on which the initial fortran compiler was developed or something of that nature. [Due to the rule of exponentiation described below and elsewhere in another post, if you have just one set of sequential exponentiation operators, it is probably "cheaper/easier" to perform a product and an exponentiation, then to perform 2 exponentiations. Moreover, more than 2 sequential exponentiations probably didn't arise too often.] Before, Fortran, it may not have been necessary to formalize this, because there was little need to express an exponentiation operator to be used in a strictly left to right sequential expression, per se.
Alternatively, individuals just used parenthesis, or applied the rules of exponentiation as specified in another posting, i.e.,
(a^{b})^{c} is equivalent to
a^{(b*c)}
Because of the limitations of stack size [operation and/or operand stack] on an algebraic calculator, it would be advantageous to execute exponentiations in the order in which they are encountered. On an AOS calculator this, of course, corresponds to left to right order. On an EOS calculator, the same would be true. However, if stack size is not at a premium or is not an issue, then either order is feasible. That may explain why the 48 series performs the operations expressed in EOS in an order comparable to the original fortran specification whereas earlier calculators performed the operation from left to right. However, other than that original convention, I have no idea why HP decided this was the appropriate order.
Personally, I would prefer left to right evaluation. Needless to say, parenthesis should be employed liberally when programming such an expression in an EOS style language.
▼
Posts: 144
Threads: 20
Joined: Jan 1970
A lot of people especially people in this math class of mine :)  tend to forget that math is not all 15k year old stuff writ in stone.
Since computers *are* a part of life now, and since at least some small percentage of algebra students may end up actually doing calculations in a programming language at some point. (well, okay, not many, but still...)  I think it is an issue that should be addressed more, and maybe codified better.
Personally, I'd like a totally seperate negation character, so (neg)3 never can be confused for 03. Among other things, this style helps me a lot when reducing a lot of linears. no subraction ever, just addition of (neg)x numbers. Or maybe that's just a personal hangup from learning programming before ever taking an algebra class. I learned to think of 255 as s single variable instead of an operator and variable and I'm not thinking that's a bad thing.
Christof
Posts: 1,041
Threads: 15
Joined: Jan 2005
Actually the 48 series does exponentiation left to right, so that a^b^c=(a^b)^c. It's the 49G that matches the fortran convention of working right to left so that a^b^c=a^(b^c).
I can see some sense in working left to right (opposite of the fortran convention) when working with "singleline" notation like a^b^c, but with multiline notation like a^{bc}, my intuition is to work top to bottom (right to left), so that a^{bc}=a^{(bc)}
But in the 48 series and 49G the same expression can be displayed in either singleline notation or multiline notation, so I guess that it's best to choose one convention for both styles of notation.
▼
Posts: 72
Threads: 8
Joined: Jan 1970
Hi James,
Yes, I assumed that the 48 and 49G handled it the same way and I was thinking 48s and 49s when I said 48 series. But, I do seem to remember a posting here that said that the 49 behaved differently from the 48 series for sequential exponentiation.
I also stand corrected on the towering notation. Clearly, without parenthesis, the result is ambiguous. You have to decide whether to go from left to right or right to left if you don't use parenthesis. As usual, since there is ambiguity, it is best to use parenthesis, but that is not an answer to the question. I will defer to everybody else here and accept that there might be a number of reasons to go from right to left for sequential exponentiation.
Another mea culpa, the rule:
a^{bc} = a^{bc}
works only for left to right interpretation, NOT for right to left interpretation. So my earlier posting on Fortran was incorrect on this matter. Which, of course, makes me wonder why they made the choice they made, since they wouldn't have been able to use the above rule in that case. On the other hand, perhaps, they are on "high moral grounds", in the choice they made rather than the most expedient choice.
▼
Posts: 144
Threads: 20
Joined: Jan 1970
I would intuitively assume that to solve
a ^ b ^ c
One would first have to solve b^c.
I would expect any AOS or EOS type system (including HP equation tools) to do it what way. But I'd be wrong
for that EQ 4^3^2 :
solving 3^2 first, then 4^9 gives 262,144
and 4^3 follwed by ^2 gives 4096 (as does 4^6, so that works)
Now, for the individual calculators:
if I type in
4 y^x 3 y^x 2
on a 20s, I get 4096. typing
4 y^x (3 y^x 2)
gives me 262,144
Now if I enter this as an equation into the 32sii
X=A^B^C
and then solve for X (providing a=4, b=3, c=2) I get 4096 again.
Posts: 1,153
Threads: 94
Joined: Mar 2006
If you're interested, on the Sharp EL5100S, pressing the keys:
() 3 x^2 =
results in the answer "9".
Entering same as "formula 1" and "evaluating" it gives the same answer.
▼
Posts: 144
Threads: 20
Joined: Jan 1970
Thanks I don't have any modern sharp calculators.
On the good side, i've finally bothered to get and use the low end HPs 20s and 30s. On the bad side, the final answer from the professor is that "in algebra, it's negative"  meaning 9. I guess this is the kind of stuff that keeps me interested, not her *shrug*
I do wonder if there's room out there for more of the old style calculator books "lay" manuals, I suppose. Seems that there's not much interest in anything below the 40g/82 level for that. The 30s, especially, could use something better to carry around than that flimsy paper thing. (Admittedly, there isn't much to the calc that needs a manual at all but since this is presumably for the non science major, some kind of "how to" book that includes refresher info on algebra, trig, stats, and personal business problems could be useful).
I will say, having used the 30s now, that I find it better than the casio though the casio is easier to hold. I think I just expect thicker calculator bodies.
It's not about to make me give up a 32sii42s. It's a bit of a toss up with the 20s, though.
Christof
Posts: 72
Threads: 8
Joined: Jan 1970
Sharp has, presumably, changed its entry logic. On a Sharp EL506L and a Sharp EL531VB, they have [+/] as both a prefix and postfix operator. Here's how they function:
Prefix:
[+/]3[x^{2}][ENTER]
produces the expression:
"3^{2}"
yielding 9
Postfix:
3[+/][x^{2}][ENTER]
produces the expression:
"(3)^{2}"
yielding 9
Both of these calculator purportedly use "ADVANCED D.A.L.". These are documented features and the
[+/] keys are clearly marked with "NEG ()" and "()" on the face of the calculator underneath the keys.
OTOH, the Sharp EL500L [ostensibly a calculator although I'm not entirely convinced] also employs Advanced DAL and uses a [()] key, but it does not allow the postfix operation.
