Y’know, all of this junk about order of operations and the broken nature of calculators that don’t observe them makes me really glad I use an HP-48GX, an RPN calculator. Order of operations is meaningless in RPN.
It’s also meaningless in Lisp, a functional language which essentially enforces a prefix notation (viz: (* (+ 3 5) (- 5 2)) results in (* 8 3) which results in 24).
Needless to say, I think Lisp is one of the best things to happen to programming, but not for prefix notation. Lambda closures have won my heart.
And a language to combine RPN with the Lambda calculus? Oh, Joy!
(Yes, this whole post was a setup for a pun. Maybe the hackers will appreciate the pointer to the language.)
I’ve never owned a HP scientific calculator, I’ve never even seen one for sale in the UK so I don’t know. But Sharp, Casio and Texas Instruments seem to use that system.
Giving it a little more thought I see that the el-cheapo calculator has to solve the problem the exact way you must.
given 2+34 you can’t start with adding 2 and 3, why should you expect the calculator to? You start with 34 then you add 2, this is the way you do it and the way it was done for centuries no matter how it’s written. The simple calculator needs the numbers inputted in the way that the equation has to be solved.
I’m convinced the calculator is right and you are wrong.
I agree about these improperly programmed calculators.
To use the log function of the Microsoft calculator in scientific mode, you must enter a number (say, 10) and then press log. This is obviously incorrect. You don’t write out “10 log”, you write “log 10”. This is not an obscure piece of mathematics that only scientists care about. This is a basic rule.
But wait, it gets worse! Everyone knows that “5 log 10” means “multiply 5 by the log of 10”. But when I enter [5] [log] [1] [0], the calculator takes the log of 5, then throws it away and simply displays 10. Calculators that don’t follow the order of operations are daft, IMHO.
My TI-86 gets all this right, so it seems Microsoft is simply catering to the lowest common denominator.
We’re even. I typed it wrong the first time. I swapped the operators because in the original problem, APL’s odd operator rules would have yielded the expected answer, of course.
BTW, on using series expansions for basic functions:
You might wish to look up a topic called “economization” of power series. One problem with using something like a certain number of terms of the standard power series like that given above for sin(x) is that the distribution of error is terrible. Over the range that you wish to use the function (say 0 to pi/4 in the case of the sin()), a graph of the error for a particular number of terms will usually be much higher the further away you get from the point you choose to expand around to obtain the power series. In the case of that sin() expansion, 0 is dead on of course, and the error increases greatly the further you get away from 0.
You COULD just take more terms of the series until the “bad end” of the error distribution for your desired interval was acceptable. However, there are some techniques for jiggering the coefficients of a truncated power series to distribute the error more evenly. Applying these techniques can let you get away with fewer coefficients to obtain a desired level of precision. If you pick up a numerical analysis text, you should be able to find a discussion of the techniques, probably using something called the “Chebychev polynomials”.
(Actually, the sin() expansion converges fairly rapidly for pi/4, but the general remarks apply.)
Computational efficiency being what it is these days, people may not bother to economize their expansions, but it was important when machines were slower. It probably doesn’t make much difference for a calculator which only has to produce a single result at human speed.
Desmostylus, I think you missed that Tradnor was joking, when he complained that he should be able to enter [5][log][1][0], and get 5log10. He was making fun of all the people who’ve posted here complaining that a calculator should always respect the mdas order of precedence.
I think you’ll find that a calculator which will give an answer of 14, will allow you to set the order of operations by making parentheses available. If a calculator doesn’t have parentheses, then it will almost certainly do the operations as soon as you hit the next operator button.
In this way, Microsoft did it correctly. Their standard version of the calculator will give 20 for “2+3*4=”, but the scientific mode, which has parentheses available, will give 14.
That being said, I don’t know how you people put up with algebraic entry calculators. I switched to RPN in 1979, and algebraic is just such a PITA that I don’t know how you can manage to be even marginally productive with one.
I can’t see how you can take a long string of infix algebra and turn it into RPN on such a calculator without an error. I don’t know how you can manage to be even marginally productive with one.
The correct solution:
Get all the math textbooks and treatises and papers written in RPN.
Derleth, on reading about Joy, it looks remarkably like the native programming language of the HP 48 series. Is that a correct assessment? Granted, the 48 also allows assignment to variables, while Joy apparently doesn’t, but it’s not really necessary.
I’ll agree with you, by the way, that stack input and output for functions is a thing of beauty, and the Way Things Should Be. That’s about the only thing I find lacking in good ol’ trusty C.
I realize that a debate over calculators won’t go over in this forum, so I’ll stay away from that. But really - how often do you have to type in a printed-out string of algebra? I can’t recall ever needing to do that. I use a calculator to do what I would otherwise do with pencil and paper (and maybe trig/log tables), but much faster and less error-prone.
I realize that there are calculators that let you input algebraic notation, complete with variables, and then let you manipulate that symbolically, but for just doing calculations with numbers, have you ever just input the string that’s written down, and ask the calculator to do its thing? I haven’t.
Yeah, I think that’s pretty close. About the only thing I’ve found in Joy that isn’t really in Forth/RPL (RPL being Reverse Polish Lisp, the semi-joking name for HP’s RPN programming language) is the second-order map function that allows you to iterate an arbitrary function (composed inside square brackets) over an arbitrary list (also composed inside square brackets). Other than that, it’s pretty intuitive to those who hack HP’s RPN calcs.
And you can assign things to symbolic names, 'cause you can define new words (er, functions) and every number is a function which puts itself on the stack.
Yeah, stacks are da bomb. They even make sense in assembly and virtual machines, because you don’t have to worry about which registers will be saved between calls and which ones will be stomped.
That stack-based calling convention gets nicer when you have preincrement and postdecrement addressing modes, as in the beloved VAX.
(C hackers know about [pre|post][increment|decrement] from how the ++ and – operands are parsed. Needless to say, C was developed on a DEC minicomputer (the PDP-8, ancestor to the PDP-11, direct ancestor to the VAX).)
