Why not? At least I can easily copy the results and the code to a document which avoids transcription errors. Or do you mean that there simply isn't a program that has the functions you use?
> Why not? At least I can easily copy the results and the code to a document which avoids transcription errors. Or do you mean that there simply isn't a program that has the functions you use?
My guess it's the ergonomics between a specialized tool and a non-specialized one. Technically, python may be able to replace "a good engineering calculator," but so can ASM. No one would even ask "Why non ASM?," because its ergonomics are near-universally understood to be so poor, but the same issues can apply to more popular tools like python, just less obviously.
The ONLY benefit to these tools that I can surmise is basically that they are a physical device for scientists or others in the lab or field and not in front of a computer.
For any kind of data work I've seen, Excel, R, Python, Mathematica, or Matlab are all vastly superior. They allow faster entry, can show large amounts of data on screen, can allow for saving large amounts of data ...etc.
This is similar to programming language discussions: any programming language can be discredited by saying "but I can do all that in assembly/C/whatever". Yes, you can, but perhaps there are better ways to do it.
for the engineering calculators, it seems the advantage is that some people learnt to use them in school and really love using them? that's great, I'm tempted to look into them myself, because it does sound cool to have a small device that does that sort of thing while I'm reading a book. but the truth is that for me, both at work and at home, my laptop is never more than 5 seconds away from showing me a repl, so maybe I'm not the target audience.
What impresses me in this discussion is how coy everybody has been about the actual benefits of these devices.
I don't need to justify my reasoning to you in a way that convinces you your way is wrong and mine is right. People like different things. I learned to use a scientific calculator as an extracurricular competition that allowed me to become very proficient at 10-key. Because of that, doing calculations on a computer goes against muscle memory. Laptops don't even have a 10-key. If I have a bunch of notes/papers with numbers that need to be added, I can pull out a calculator and just do the data entry and get a result. I don't have to go to my computer, or lug the laptop around in the shop. I just need numbers quickly crunched so I can then turn around and make a cut, drill a hole, or whatever. I don't need a large clunky compute device for that. Dropping a calculator on the shop floor is much less expensive than doing the same with a laptop. Lots of time, I just don't feel like needing to write a damn script just to get the tangent/cosine of a value to determine the lengths of the whatever.
Again, just because you have a hammer doesn't mean that you should use it drive that screw. Sometimes that tool that specifically made for purpose is better for the task at hand.
Now, pick any of the aforementioned options as to why I might prefer a calculator over a programming env just to crunch some numbers.
today's episode has been brought to you by the letter A for acceptance and the number 9
1. What happens if I rotate binary pattern 1001 right by 3 positions on a 18-bit PDP-9?
RPL code: 18 STWS 2#1001 3 RRC
Result: #8001 in base 16, #1000 0000 0000 0001 in base 2.
RPL code: 6 36 * STWS 2#1001 3 RRC
Result: #20 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001
Program: [[1 y]['2+x' b]] DET
Answer: 'b-(x+2)·y' (shows graphically on calculator screen)
Program: R1=4_kΩ R2=10_Ω V=100_V 'ROOT(ⒺVolt Divider;[V1];[1_V])' EVAL
Result: [ V1=99.75 V ]
Note that ⒺVolt Divider is a built-in equation, but you can of course put your own.
Program: « 'exp(√ 163·Ⓒπ)'60 PRECISION →Num FractionalPart »
Result: -7.50E⁻¹³, so no, not an integer, but really close
Program: '(√(Ⓒε0·Ⓒμ0))⁻¹' →Num
Result: 299 792 458.00 m/(F↑(¹/₂)·H↑(¹/₂))
Convert to SI units: UBASE
Result: 299 792 458. m/s
Convert to feet per second: ³⁷⁴ ⁷⁴⁰ ⁵⁷² ⁵⁰⁰/₃₈₁ ft/s or 983 571 056.43 ft/s.
(if you subtract the Ⓒc constant, you get -0.00031 11057 21 m/s)
Program: « if dup 1 ≠ then if dup 2 mod then 3 × 1 + else 2 ÷ end Collatz end » 'Collatz' STO 989345275647 Collatz
Result: 1 (conjecture is verified)
Program: 20241107.000751_date 20241101.231527_date - 1_h convert UVAL →HMS
Result: 120:52:24
yet you use paper and calculator.
You don't need the calculator to do the final sums until you've done all of the work gathering all of the data that needs to be calculated. It doesn't mean the calculator wasn't needed, just that it's only needed for one thing not every step along the way.
This wasn't the gotcha you think it was
I'd really like to run HP50G on iOS, but the only emulator I know was abandoned years ago (I got the source just in case, but it's a lot of work to fix the issues and build it).
Incidentally the 50G (and Prime) has a decent CAS built in which seems to get stuck less than some other commercial ones.
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.
You moved the goalposts. The original discussion was about calculators not emulators.