As a kid, my father had picked up a mechanical calculator similar to this Figurematic 10SDX. I messed around with it a little, it was quite the contraption. The AC motor in it ran continuously, and wasn’t quiet. Being the curious kid with screwdrivers, I eventually took it apart, but I can’t say I learned anything specific from its innards.
I guess the author of the article didn’t know SpeedCrunch, which is my daily math driver for over 5 years now. It supports a huge subset of the features of Chalk while also providing more programmer specific things like:
ieee754_single_encode(pi)
= 0x40490FDB
and supports fractional numbers in the typical bases:
A good page, with many useful ideas being outlined. I would note, though, that many of the shorfalls of software calculators do not apply to terminal programs. In particular, both bc(1) and dc(1) are fine calculator programs that have the advantage of being standard Unix utilities. (And both are included in MacOS’s Unix.)
Yeah my go to calculator these days is just the Haskell interpreter GHCi - arbitrary precision integers, can write full expressions and have history so I can go back and make changes, saving values in variables, a broad range or types; IEEE-754 Doubles, Rationals, and the numbers package gives you things like the arbitrary precision CReal type:
> cabal repl --build-depends numbers
Resolving dependencies...
Build profile: -w ghc-9.0.2 -O1
In order, the following will be built (use -v for more details):
- fake-package-0 (lib) (first run)
Configuring library for fake-package-0..
Preprocessing library for fake-package-0..
Warning: No exposed modules
GHCi, version 9.0.2: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /var/folders/jq/n5sg557s0q56g3ks4bpzy_lr0000gn/T/cabal-repl.-31497/setcwd.ghci
ghci> import Data.Number.CReal
ghci> showCReal 100 $ pi + exp 1
"5.8598744820488384738229308546321653819544164930750653959419122200318930366397565931994170038672834954"
ghci> showCReal 200 $ pi + exp 1
"5.85987448204883847382293085463216538195441649307506539594191222003189303663975659319941700386728349540961447844528536656891125820617962580462569370338907674818841643132988201186879347450370215018140098"
“Eventually, I realized that my favorite everyday “software calculator” was simply the Google search engine, its major drawback being the requirement for an Internet access.”
Aside from the Numerical Truth issues and such the author details and focusing just on user experience, Has the author considered notepad-style text calculators like calca.io or parsify desktop? I found myself rather devoted to calca and recently been trying parsify after switching to Linux.
It does so here because the locale on my pc uses a period as thousands separator. The author has just acknowleged that it is a bug that will be corrected.
I think this post would be greatly improved with a summary section. It took a while to get to even the first interesting points about what’s wrong with existing calculators.
I valued this post because it offered good, in-depth, well-reasoned criticisms, with worked examples.
I am not particularly interested in calculator apps of any kind. What I liked was that the author took a widely-accepted design and slowly and meticulously deconstructed the problems with it.
When people criticise something widely-accepted and understood and even liked, it is necessary to do so slowly and methodically, or else one will be dismissed as a crank. Summaries are the enemy of this form of reasoning.
I appreciate summaries because they allow me to skip sections and entire posts that I already agree with or that are obvious after hearing them. I had never thought about how the skeuomorphism of these calculators was bad; if the author had said “hey, are you actually point-and-clicking these, and why?” then I could have skipped all the parts explaining why that’s bad. Someone who doesn’t get it right away can then go on to read the explanation.
I do know what you mean, but your reply indicates that you’re not the audience I was talking about.
If you read this and thought “oh, that’s a good point,” then you’re receptive to the message.
The problem comes when the reader is unreceptive to the message.
For instance, I often cite our local Lobster David Chisnall’s “C is not a low level language” paper. When I have said this on Twitter, I have received death threats as a result.
(I wish I were exaggerating. I am not.)
I also have criticisms of various Linux tools, such as desktops. (Not Emacs vs Vi; I hate both.) These evoke strong feelings. So I must be very specific and spell out, point by point, the precise and specific problems I have with KDE, or MATE, or else their admirers will pillory me.
Being so specific merely elicits responses of “oh well I don’t want that so it doesn’t matter to me”, but the point is, it’s necessary to itemise them and describe them in detail, because otherwise, enthusiasts will simply reject my criticisms altogether and accuse me of being incompetent, ignorant, a liar, pathologically motivated, etc.
I have worked for 2 prominent enterprise Linux vendors. In one, when I criticised the product, people didn’t like it but they accepted my points. In the other, I got flamed and then the company fired me.
(And then later fixed the things I criticised.)
This is a real issue. A summary can be a bad thing, because closed-minded readers will only read the summary, ignore the detailed points, and then start flaming.
Re: standard software calculators are surprisingly good. The author discusses macOS Calculator and Windows Calculator, but you should have a look at the new Android Calculator (aka ExactCalculator). The work was accepted by PLDI 2020. See Toward an API for the real numbers for details.
How about opening Terminal (on MacOS) and typing “bc”. It’s like the google calculator but without internet. You probably want to specify “-l” and also bump “scale=25”
FYI: it’s the frontend for “dc” (desk calculator).
One thing I strongly disagree with is that there should be a symbol picker available. Click the square root button and it pops a sqrt({cursor}) into the input box.
KDE’s runner applet also has a calculator built-in, though it’s pretty feature-sparse. (Alt-F2 -> 5 * 5. You can also write it in the start menu search field.)
It seems to me that the obvious answer is to use a web view for everything, not just rendering history. Taking it further, if the core were ported to wasm using enscripten, the calculator could be made available to any student using a locked-down computer where they can’t install apps.
Something I’m surprised I haven’t seen mentioned: Spotlight evaluates mathematical expressions entered into the search bar. That’s the only “calculator” I’ve used on my Mac for years.
That’s not a desktop calculator, this is a desktop calculator.
Sir, I am afraid you are mistaken, this is a desktop calculator.
Fellow crustaceans, I am afraid you are both mistaken, this is a desktop calculator.
I see, sirs, that you’re still hung up on your machines, when obviously, these are desktop calculators
As a kid, my father had picked up a mechanical calculator similar to this Figurematic 10SDX. I messed around with it a little, it was quite the contraption. The AC motor in it ran continuously, and wasn’t quiet. Being the curious kid with screwdrivers, I eventually took it apart, but I can’t say I learned anything specific from its innards.
I guess the author of the article didn’t know SpeedCrunch, which is my daily math driver for over 5 years now. It supports a huge subset of the features of Chalk while also providing more programmer specific things like:
and supports fractional numbers in the typical bases:
But cool to have more tools like this! It looks like Chalk even supports proper matrix stuff which is super awesome.
A good page, with many useful ideas being outlined. I would note, though, that many of the shorfalls of software calculators do not apply to terminal programs. In particular, both
bc(1)
anddc(1)
are fine calculator programs that have the advantage of being standard Unix utilities. (And both are included in MacOS’s Unix.)Yeah my go to calculator these days is just the Haskell interpreter GHCi - arbitrary precision integers, can write full expressions and have history so I can go back and make changes, saving values in variables, a broad range or types; IEEE-754 Doubles, Rationals, and the
numbers
package gives you things like the arbitrary precision CReal type:Aside from the Numerical Truth issues and such the author details and focusing just on user experience, Has the author considered notepad-style text calculators like calca.io or parsify desktop? I found myself rather devoted to calca and recently been trying parsify after switching to Linux.
My favorite app for this is Soulver on macOS https://soulver.app/
I was a bit surprised to not see soulver mentioned.
Also https://numbr.dev/
yep, just discovered that via https://lobste.rs/s/myieuw/favorite_interactive_web_apps_without#c_2q09bv
Numbr shows the same value for “1.001”, “1,001”, and “1001”. That’s not cool.
Does not do this for me.
It does so here because the locale on my pc uses a period as thousands separator. The author has just acknowleged that it is a bug that will be corrected.
I also found this one: https://bbodi.github.io/notecalc3/
I think this post would be greatly improved with a summary section. It took a while to get to even the first interesting points about what’s wrong with existing calculators.
Just FWIW, I disagree.
I valued this post because it offered good, in-depth, well-reasoned criticisms, with worked examples.
I am not particularly interested in calculator apps of any kind. What I liked was that the author took a widely-accepted design and slowly and meticulously deconstructed the problems with it.
When people criticise something widely-accepted and understood and even liked, it is necessary to do so slowly and methodically, or else one will be dismissed as a crank. Summaries are the enemy of this form of reasoning.
I appreciate summaries because they allow me to skip sections and entire posts that I already agree with or that are obvious after hearing them. I had never thought about how the skeuomorphism of these calculators was bad; if the author had said “hey, are you actually point-and-clicking these, and why?” then I could have skipped all the parts explaining why that’s bad. Someone who doesn’t get it right away can then go on to read the explanation.
I do know what you mean, but your reply indicates that you’re not the audience I was talking about.
If you read this and thought “oh, that’s a good point,” then you’re receptive to the message.
The problem comes when the reader is unreceptive to the message.
For instance, I often cite our local Lobster David Chisnall’s “C is not a low level language” paper. When I have said this on Twitter, I have received death threats as a result.
(I wish I were exaggerating. I am not.)
I also have criticisms of various Linux tools, such as desktops. (Not Emacs vs Vi; I hate both.) These evoke strong feelings. So I must be very specific and spell out, point by point, the precise and specific problems I have with KDE, or MATE, or else their admirers will pillory me.
Being so specific merely elicits responses of “oh well I don’t want that so it doesn’t matter to me”, but the point is, it’s necessary to itemise them and describe them in detail, because otherwise, enthusiasts will simply reject my criticisms altogether and accuse me of being incompetent, ignorant, a liar, pathologically motivated, etc.
I have worked for 2 prominent enterprise Linux vendors. In one, when I criticised the product, people didn’t like it but they accepted my points. In the other, I got flamed and then the company fired me.
(And then later fixed the things I criticised.)
This is a real issue. A summary can be a bad thing, because closed-minded readers will only read the summary, ignore the detailed points, and then start flaming.
Re: standard software calculators are surprisingly good. The author discusses macOS Calculator and Windows Calculator, but you should have a look at the new Android Calculator (aka ExactCalculator). The work was accepted by PLDI 2020. See Toward an API for the real numbers for details.
Another very powerful option is the Emacs calculator.
This is what I use, though I know I’ve barely scratched the surface; I just use it as a plain RPN calcluator.
Still not as good as a TI-89 near the keyboard.
How about opening Terminal (on MacOS) and typing “bc”. It’s like the google calculator but without internet. You probably want to specify “-l” and also bump “scale=25”
FYI: it’s the frontend for “dc” (desk calculator).
The nicest thing about the google calculator to me is that it has a bunch of constants and unit conversions.
https://www.google.com/search?q=speed+of+light+in+feet+per+second
for example, quite convenient.
That’s what the cli programm “units” is for ;-) granted this one is usually not in the default install, although it apparently is on MacOS?
One thing I strongly disagree with is that there should be a symbol picker available. Click the square root button and it pops a
sqrt({cursor})
into the input box.KDE’s runner applet also has a calculator built-in, though it’s pretty feature-sparse. (Alt-F2 -> 5 * 5. You can also write it in the start menu search field.)
I do use it a lot. The windows calculator on the other hand annoys me. You’re always searching for that window.
It seems to me that the obvious answer is to use a web view for everything, not just rendering history. Taking it further, if the core were ported to wasm using enscripten, the calculator could be made available to any student using a locked-down computer where they can’t install apps.
Something I’m surprised I haven’t seen mentioned: Spotlight evaluates mathematical expressions entered into the search bar. That’s the only “calculator” I’ve used on my Mac for years.