> Why not?
Keystroke count and progressive computations.
Let me illustrate using an example from a YouTube video called "The hardest Exam Question : Only 6% of students solved it correctly" (https://www.youtube.com/watch?v=NfgEPsm9Jzw), which is about a simplified formulation for (sqrt(2)-1)^10.
The first remark is that a CAS-capable calculator like DB48x can help with the symbolic part of the computation shown in the video. However, to be fair, DB48x still lacks some of the relevant HP48 interactive equation manipulation features to be able to demonstrate that. So let's focus for now on the numerical part.
The author shows that (sqrt(2)-1)^10 is the same as 3363-2378*sqrt(2). Let's evaluate that using bc.
Attempt 1: bc, then (sqrt(2)-1)^10-(3363-2378*sqrt(2))
Result: -985. Er... What?
OK. What is the option for precision again? man bc. Search for precision. Mentions the @ operator. Does not seem to do it. 5 minutes of search later, find that precision is called scale, that I need the -S option. I could also presumably use the -l option, which experimentally seems to set the scale to 20. Starting to remember why I am not a big fan of bc ;-)
Trying again. bc -l
(sqrt(2)-1)^10-(3363-2378*sqrt(2)) now gives me:
-.00000000000000000402.
Counting "bc -l" and ENTER keys, that's I believe 42 keystrokes.
Trying again with db48x: I need 23 keys using the most naive RPN data entry. The result is -1.57861 99E⁻²⁰ with the default 24-digit precision.
I can also enter the same algebraic expression as in bc directly in the simulator using copy-paste. I get a nice graphical rendering of the expression, which I can check, and then just one key (EVAL/=) to get the numerical value.
As another example, let's try to check if the Ramanujan constant in an integer:
bc -l
e(sqrt(163)*pi(20))
262537412640768743.98947654935272888605
That does not look like an integer to me. And it's way more than the 20 digits I would expect from scale. What is weird is that it gives me a false sense of accuracy, all the digits after "43.9" are bogus, as shown by switching the scaling to 100:
bc -l -S100
e(sqrt(163)*pi(100))
262537412640768743.9999999999992500725971981856888793538563373369908\
627075374103782106479101186073126534265238592035363
21 keystrokes, and a result that is a bit hard to interpret with the default precision (scaling). In other words, it's pretty easy to get bogus numerical results and not know it.
With DB48x, after selecting a precision of 100, 11 keystrokes including menu selection to get the pi constant, and I get:
262 537 412 640 768 743.99999 99999 99250 07259 71981 85688 87935 38563 37336 99086 27075 37410 37821 06479 10118 60730 76
> At least I can easily copy the results and the code to a document which avoids transcription errors.
This is also true with the DB48x simulator, which supports copy and paste both ways. This is how I copied the values above, or entered the exact same algebraic expression as in bc into the simulator.
