The Emacs Calculator (2009) | Hacker News Reader

The Emacs Calculator (2009)

nullprogram.com

177 pointsPete_D53 comments

Emacs calc can do financial/TVM calculations, too. A useful tutorial by Andrew Hyatt on doing financial calculations [0]; he has wrote many other calc tutorials [1] in the Emacs Google Plus community [2].

[0] Emacs financial calculations: https://plus.google.com/+AndrewHyatt/posts/YdwsbNmZ4NL

[1] Index of Andrew Hyatt's emacs calc tutorials: https://blog.markhepburn.com/2013/12/07/andrew-hyatts-emacs-...

[2] Emacs Google Plus community: https://plus.google.com/communities/114815898697665598016

I took the time to properly learn and use emacs-calc this year, after being an emacs user anyway. Before that, I tended to use bc on the shell for quick calculations, but always felt that to be too limited.

Since then I am practically a daily user.

It's not without downsides, and some simple workflows that seem common and trivial to me personally feel a bit awkward and contorting. For example, working with variables/equations, with that '=>' "operator", is rather strange. There also seems to be no support for hex numbers in 0x-prefixed lowercase notation, which makes it hard to impossible to just copy and paste hex numbers for programming. And while emacs-calc has a very impressive scientific unit system, often I just want to use unit prefixes, like u,m,M for micro,milli,Mega respectively, without having to resort to using actual physical units in my calculations (and then finding out again how to simplify appropriately).

I also almost don't use the trail at all, mostly because its navigation and actioning feels tedious and downright archaic, making me think that emacs-calc probably started out a few decades ago, with a specific, now outdated, terminal paradigm in mind.

But all in all, it's pretty impressive, and fills the role as my daily companion for quick, and sometimes more elaborate, computations well.

This small addition lets you work with SI byte units. I have no idea why this wouldn't be in the default unit set, but hey, this is why we use emacs.

https://raw.githubusercontent.com/mnp/dotfiles/master/shared...

Since I've discovered "nickle"[1] (by pure chance), I've been aliasing bc=nickle on every system I had access to.

nickle has normal algebraic notation with arbitrary precision, configurable base input/output for every expression (very reminiscent of calc), math functions and C operators work out of the box. It has variables, as well as a simple c-like language for additional extensions.

If RPN is not for you, "nickle" is a perfect "bc" replacement which works as you would expect.

[1] https://nickle.org/manual.html

Being an old HP48 user, finding Calc was what me fall the rest of the way in love with Emacs. If I'm at the shell prompt I'll still startup GP/Pari for quick calculations, but it's hard to beat Calc for longer sessions.

The only downside is that, like any advanced Emacs functionality, if you don't use it frequently you forget all the commands.

I fell in love with smartphones (iPhone) when I downloaded the HP41 app. I feel ya.

And an HP48 emulator is still what I use on my phone as a calculator.

For the reason you mention, I need to get into the habit of using Calc for my quick calculations; right now, I usually use Google (ick, infix notation) or dc.

I'm the same! None of the native RPN apps even come close.

RPN is so efficient when you are running a series of calcs when you learn it. I feel icky now if I use algebraic input or calculator and I have to backspace. It's like using a word processor, not a calculator! I am in Emacs all day for all things. It is a big mess of a world I like muddying about in!

I've have Free42 on my Android phone. Do you have a particular emulator to recommend?

http://thomasokken.com/free42/

I use Droid48: https://play.google.com/store/apps/details?id=org.ab.x48&hl=... (https://github.com/shagr4th/droid48)

Thank you. I saw that one. Some of the more recent critical comments (stability, responsiveness) gave me some pause.

I'll give it a go.

“The only downside is that, like any advanced Emacs functionality, if you don't use it frequently you forget all the commands.”

I thought this was happening only to me... but I’ve ditched Vim and went Emacs 100% so it’s bit better now, since I’ve been stuck with using both for like a year.

I find it so surprising that I got a HP48 young, felt in love with RPL, then later liked emacs, then later loved lisp and realizing they were all connected.

I keep an HP48 in the office and an HP28S at home.

I might buy another HP28 for the car. :D

I love Emacs but the calculator, being stack based is just too awkward for me. I know there is the "algebraic mode" but it still is too much. Is there a way to configure it to work like, say, SpeedCrunch (my favorite calculator by far) ?

I would sometimes open the Messages buffer and then repeatedly use M-x quick-calc to evaluate a few expressions. Each result is written to the Messages so I have a log. Dirty but works :)

Why open messages, though? You can paste quick calc results with ctrl y and they end up in messages none the less.

TIL about SpeedCrunch!

http://www.speedcrunch.org/

http://www.speedcrunch.org/download.html even links to 32- and 64-bit prebuilt Qt binaries for Linux. Nice.

How does it compare with good old command line 'mc'?

you mean "bc" ? Dunno, never used a lot.

For computations such as 10+3, it's comparabale. But I give SpeedCrunch an dedge because it can compute "sin(pi/2)" out of the box.

Yes, bc. Obviously it's been a while since I used it!

I use Qalculate which is awesome and has similar features.

https://qalculate.github.io/

Gotta raise my hand here too. I'm in my mid-40's, have worked at all levels of the software stack, have played with favored development tools of like nine generations of engineers.

I still can't wrap my brain around a RPN calculator well enough to use it productively (but boy howdy can I tell you how the stack engine works!). All the cool kids in physics class in the 80's were using HP's, and I felt left out even then. Never managed to make it work for myself.

I think about it as first listing a bunch of scalars, then consolidating them with operations.

It takes a little practice to start thinking postfix, but it's a relief to not consider order of operations, and tends to be a lot more consistent with how I do arithmetic in my head in the first place.

I'm the exact opposite. RPN calculators are totally natural to me, whereas I get confused on normal calculators.

Normal (non-algebraic) calculators are inconsistent. To get "2+3", it's infix: 2, +, 3, =. To get "cos(45)" it's postfix: 45 cos (and no equals). And something like "cos(2+3)" is a mixture of both. RPN, is always the same, numbers first, then operators, and usually more keystroke efficient. Some operators take multiple arguments.

RPN also has the advantage of (rarely) needing a memory register, since the values can be left on the stack and accessed as they are needed.

I mainly use the algebraic mode

Just prefix every expression with '

Calc is so useful to have right there. I have never used Windows calc since discovering the emacs one many years ago. Once I got used to it I had to find an RPN one for my phone (RealCalc and PCalc for Android and IOS, respectively).

Algebraic formulas are great but beyond my typical reuse recall duration.

Could you explain why you feel RPN is better for you ? I've never been able to get used to it... Maybe I get it wrong...

After you get used to it, you end up being able to calculate much more quickly. It's basically having a little Forth machine in your hand or at the end of your keyboard.

The joy of never, ever having to type a parenthesis must be experienced to be appreciated.

And yet so many RPN people are Lisp programmers the rest of the time. I guess it balances out.

I would really like a postfix lisp.

I wonder what edge cases I would run into designing one.

Aren't concatenative languages like Forth and Factor essentially what you're looking for?

They are very focused on the stack, which isn't very lispy.

I was wondering how difficult it would be to make a common lisp or scheme, but with postfix syntax instead of prefix.

We could start by tinkering with a silly macro:

  [10]> (defmacro rev (&rest forms)
         `(progn ,@(mapcar (lambda (form)
                     (if (and (consp form) (rest form))
                       `(,(car (last form)) ,@(butlast form))
                       form))
                 forms)))
  REV
  [11]> (rev (1 1 +))
  2
  [12]> (rev (3 print) (1 1 +))
  3 
  2

Start by writing some small programs in this; what exactly is the syntax?

A Lisp macro (rpn ...) could provide a DSL whereby all the forms in ... are recursively code walked and turned from a postfix notation into a regular Lisp notation.

You probably want the walker not to fiddle with expressions like '(a b c) quoted lists. That creates a special case to handle. You have to know that (quote (a b c)) is in a context where it is evaluated (which normally undergoes rpn to Lisp transformation) and so should be left alone. You don't want (quote z) being treated as RPN denoting (z quote)! Likewise, you don't want #'foo, which is (function foo) to be turned into (foo function).

So, basically, a code walker is needed which knows what is evaluated and what isn't, which leaves alone stuff that isn't evaluated, and also avoids RPN-to-lisp-transforming certain expressions that are evaluated.

For me RPN is just the way a calculator should function. But I'm not shure I could explain why. Some of the explanation is

".. it gives you more insight into your calculations than using the ‘algebraic’ systems used by other calculators and it keeps you and not your calculator (see Appendix D) in command of what is calculated."

from here: https://hansklav.home.xs4all.nl/rpn/index.html

Two reasons. With an algebraic system, I have to plan ahead and add open parentheses, or reorder, to do what I want. With a stack, I can always push/dup, then roll or pop back. It’s the same reason I like having function calls and a call stack when programming, compared to APL.

Second reason, RPN systems are typically open: I or others can add operations. That’s pretty rare in an algebraic machine, though not completely nonexistent.

.. plan ahead and add open parentheses, or reorder, ..

The classic example

  3 + 4   7 + 8
  ----- + -----
  5 + 6   9 + 2

Strait forward in RPN

  3 ^ 4 +  5 ^ 6 +  /  7 ^ 8 +  9 ^ 2 +  /  +

It separates naming from evaluating.

I have to bake 7 pies...

and each pie takes 45min

7 45 *

=> 315

But I can fit 3 pies in the oven at a time

7 45 * 3 /

=> 105

Using infix notation, I would need to consider order of operations, and put operators before data, increasing the mental stack size.

Using a postfix calculator, I can just throw values onto the stack, and start consolidating them with operations.

1 point by shoover 0 minutes ago | edit | delete [-]

I’m not sure :) I think it’s because the stack makes it easier to see the state of the calculation, whereas without RPN I have to keep more in my head and can’t see it.

Basically what thomastjeffrey said.

JOE also had a calculator: Esc M

It tries to include features of a Casio scientific calculator, so includes things like statistics / regression (of selected block) and engineering notation display. It inserts underscores between every three digits for easier reading: 0.123_456

It is not reverse polish.

This totally nerd sniped me last night. But what is the point? I can't think of a situation where it would give better results than professional tools dedicated to the same tasks. It was probably cool in the 90s, when the alternatives were much weaker.

I find the undogmatic approach to notations interesting here; the basic calculator is RPN, but CAS/symbolic features ("expressions") use algebraic notation (with separate "big" and normal notations). Of course everything has elisp underpinnings with its prefix notation, which is also used for custom extensions. Beyond those broad strokes, the basic notation used feels quite quirky, like using _ for negatives

"That's just awesome! That's a text editor ... doing calculus!"

Well, some might call that a good definition of scope creep, but at this point I'm sure we're all well aware that even though Emacs might be called a text editor, that's not really all it is.

I like to think of Emacs as a virtual lisp machine for writing your own text editor.

Here it goes again, my favorite OS, Emacs. If only it had a web browser as good as chrome.

I wonder what a web browser would look like if it evolved inside emacs.

There were and still are approaches to web browsing in Emacs. But like every other completely mainstream web browser, keeping up with the evolving web, and especially its client-side programmability and performance needs, made its usefulness rather marginal.

In the end it’s often less trouble to switch over to the browser window that’s already open anyway and copy and paste data between it and emacs.

Missed a word there: "But like every not completely mainstream web browser..."

That's exactly the reason why I use Stumpwm as a wrapper for Emacs and multiple chrome windows.

Been using Emacs since '89 and did not know this was a thing. Thanks!

Reply on news.ycombinator.com