Qalculate – A multi-purpose cross-platform desktop calculator
qalculate.github.io
qalculate.github.io
You can make Speedcrunch look like a good old fashioned bc session, whereas Qalculate puts way too much stuff on the screen. It misses a simple REPL mode.
Qalc has poor documentation so I don't find learning its extra features to be worthwhile.
Qalc is also awkward to type.
Edit: https://www.friendlyskies.net/speedcrunch/
Kinda funny but also impressive in its way...
I have it on speed dial (pause / break key to open and close) and use it all the time.
I use many of the following almost daily:
- currency conversion: `x USD to EUR` or `BTC to USD`
- time calculations: `now - 27 hours`
- unix epoch conversion: `timestamp(now - 3 days)`, also `stamptodate()`
- unit conversion: `34 oC to oF`
and more.
Works really nicely with https://github.com/svenstaro/rofi-calc
Does there exist a solution for that?
I'd let the post about qalculate be about qalculate here.
Do you put those in your startup.jl? Do you have a Startup package like some recommend for Julia 1.9+?
function calc() { awk "BEGIN{print $*}"; }
# usage in bash
$ calc 'sqrt(25) + 2**3 - 17.17'
-4.17Calling it irrelevant is a bit like calling vim irrelevant. Classic calculators don't use REPL, they are designed to minimize the number of keypresses required to input your problem and explore it in the intuitive manner. They use highly efficient modal input languages (kind of like vim). Besides being efficient, these languages tend to have one-off commands you have to remember. Having a cheatsheet on your screen by default is useful for discoverability. In the algebraic calculator paradigm and their typical use cases (napkin math), having a history is not very useful (unlike in RPN where having the stack on the screen is nice).
That said, Qalculate is weird in that it uses a REPL and the input line, which is much slower and clunkier than the algebraic input, but still tries to mimic a classic calculator. It's also slow to start. Not sure what's its use case, as it offers neither speed of a classic calculator nor the feature set of full-fledged math software.
What kind of efficient modal input language is it where you have to move your hands off the keyboard and move your mouse to press a button to insert a number?
> where you have to move your hands off the keyboard and move your mouse to press a button
Command cheatsheet, not number cheatsheet obviously (doubling as input won't hurt). Having numbers on it is excessive, as I already said Qalculate does it the weird way.
> Command cheatsheet, not number cheatsheet
How do sin/cos/tan/e/p/i/ln/kg/mod buttons (that take most of the screen real estate ignoring the numbers) help you "cheat"? Do they help you discover sin/cos? Or is there some shortcut label that helps you remember how to toggle some extra options without using a mouse?
Or replacing sin with the rad/degree switcher (without the dropdown)?
It's launching instantly here, with cold caches.
I use it since I discovered it.
$ calc 2^x=4
x is undefined
$ qalc 2^x=4
((2^x) = 4) = (x = 2)
I think my most recent real-world application for units calculation was about how much energy a device uses in kWh after a year, given that it draws 10W during office hours:
$ qalc 10W*(8h/day)*1year to kWh
(10 * watt) * ((8 * hour) / day) * (1 * year) = 29.22 kW*h
I don't know why this isn't the universally used command-line calculator. I have it on my phone as well via a Debian subsystem and it's the best
Question: why didn't you need quotes around the first expression? Both Zsh and Bash error on that command without quotes. Are you using nushell?
¹ https://zsh.sourceforge.io/Doc/Release/Shell-Grammar.html#Pr...
$ qalc 10W*(8h/day)*1year to kWh
zsh: bad pattern: 10W*(8h/day)*1year
$:1 noglob qalc 10W*(8h/day)*1year to kWh
(10 watts) × (8 hours/day) × (1 year) = 29.22 kW·h
Using https://github.com/ArashPartow/exprtk I have one calculator with a repl at 512kb, including a QML wrapper. I have a combined rpn calculator using sympy (based on the work of others) with exprtk as a 'programmer's calculator' on the side (https://github.com/poetaster/fibonacci). And several QML apps for symbolic CAS using sympy.
I have way too many calculators. They are so much fun to build. Now I ask myself, port the Qalculate methods to macros for exprtk or check out using libqalculate? I'm not sure. exprtk is so light? And adding macros discrete.
Just what's coming to mind for basic daily use here.
I imagine Siri has a database of constants, but is it usable?
Example question: what is the diameter of a sphere of tungsten - in inches, say - that weighs the same as a human (say, 150 lbs)?
Looking up the formula for the volume of a sphere gives: v = (4/3) pi (r^3), and googling the density of tungsten gives us 19.3 g/cm3.
Great! Now we already have inches, centimeters, pounds, grams, a fiddly ^3 to trip up our unit conversion from cubic centimeters to cubic inches (or is it vice versa?), some rearranging of an equation to extract the 'r'...
Luckily with qalculate, we can just smoosh it all together without thinking. We can substitute 'd/2' for "r", followed by 'x' for 'd' to tell qalculate that that's the quantity we want to figure out, and put it in inches while we're at it:
v = (4/3) pi ((x/2 inches)^3)
We're not after the volume but rather the mass, which is the volume times the density, and should equal 150lbs:
150 lb = (19.3 g/cm3) (4/3) pi ((x/2 inches)^3)
Hit enter and:
x ≈ 7.434184004
Amazing. A 7.4 inch cannonball of tungsten weighs as much as an adult human. Note that the result is only dimensionless because we balanced the equation - if we'd messed up any part of this formula, we'd have probably got our answer back in some perverse unit instead.
Oh and we didn't actually need to look up the formula for the volume of a sphere:
150 lb = (19.3 g/cm3) sphere(x/2 inches)
If it's missing anything you need, let me know.
It's in Gentoo (can be selected as the main bc), Void, Alpine, and a few others. I think there's also a Nix package?
If someone's willing to go to bat for me to get it into Debian, I'll do the package myself.
Also:
https://www.gnu.org/software/bc/manual/html_mono/bc.html#TOC...
Environment variables
BC_ENV_ARGS
EDIT: The parent comment is disingenuous: the application isn't even 70MB. It's only 70MB if you download the windows edition with vendored libicu (unicode, 31MB) library. It weighs around ~20MB on linux distributions, which is insignificant.
Development productivity over everything. Features matter not app binary size.
Check (eg.) the Elevated 4k Demo winner to glimpse what modern computers are actually capable of in the hands of good developers.
>Check (eg.) the Elevated 4k Demo winner to glimpse what modern computers are actually capable of in the hands of good developers.
If all software were to be built using the same techniques the demo scene uses, nothing would ever get done, and if by chance a project does get released, no one would be able to maintain it afterwards. Let's not confuse art and engineering just because both use code as the medium.
Sizecoding productions are an exception, because they tend to use really slow and memory hungry unpackers (can take up to gigabytes of RAM to do their job, for a 4k intro!), and they tend to lack all optimization techniques that could improve speed in exchange for more code (ex: culling, etc...). And flooding memory with millions of generated objects is no problem for these productions, as long as they are not stored in the executable.
But in general, larger binaries are slower to load, simply because there is more bytes to copy from disk to RAM. And although it is not always the case (ex: sizecoding), it usually means a larger memory footprint, resulting in worse CPU cache efficiency, less memory for other apps and filesystem caches, etc... Also, large binaries tend to be a symptom of inefficient code, with too many abstraction layers, poor optimization, etc... Another very common reasons for bloated executables is that they bundle all their libraries, which means that they don't take advantage of shared libraries, requiring the OS to maintain multiple copies of the same library, possibly including some outdated or poorly optimized versions.
*.exe in Everything = 11 586 objects on this machine.
At 70MB a piece that would come out to ~800GB.
Of course you could also provide a Win32 frontend to bring down the space requirements drastically and make it more Windows "native"; there's a well documented libqalculate for exactly those purposes.
I loved Qalculate back when it was a KDE3 application. In KDE4 times the UI switched to GTK+, but recently the dev added a newer Qt frontend which is really nice save for the fact that it doesn't have an app menu other than a hamburger menu not really accessible via keyboard; you must use the mouse for it.
I'd love to see a KDE Plasma frontend again with the more traditional layout. The app is great and powerful.
Highly recommend!
And it has a really cool physical-world electronic calculator look, hence the name.
Stuff it. I’m just reformulating https://qalculate.github.io/features.html ; you can do that yourself.
If not maxima, then the old M-x calc will usually do the job
“Popular” is a bit of a stretch though, I’m not aware of any fanclubs
also you need a designer. the website looks like from the 2000s.
thanks for sharing the app.
Along the same lines, I'm nearly Goad Complete (TM) with an amazing SaaS called Append-Slash-Ess as a browser extension. It does what you would expect, at the click of a mouse or touch of a finger, no need of keyboards, which are so last century. We aim to obsolete them so we can rake in, oops, take on our mission of improving the world.
And since our team is made up of (literally) outstanding ex-Ghroaglers, we'll only support the Ghroan browser, of course. And it'll detect and reject others, for the benefit of everyone.
I like the 2000s website style. It’s functional, simple, and loads very fast.
The website's design is fine.
- had low contrast text in a thin font
- had pointless animations of content fading in as you scroll down
- had a GDPR cookie consent popup
- popped up an interstitial form asking for your email address so you could receive their newsletter, but only after you've had the site open for 30 seconds and were in the middle of trying to read it
- was completely blank if you disabled JavaScript to try to avoid all of that nonsense
No thank you; the current design is unironically perfect IMHO.