Calca Review and Interview

When I first heard of Frank Krueger’s new app Calca, a fantastic re-imagining of a calculator, mathematical environment, and a text editor, I was hooked. On the surface of its functionality, Calca resembles Soulver, another real-time “calculator” program for your computer. But when you really take a deeper look at Calca, you realize there’s much beneath the surface.

In addition to being a perfect example of how math should be done on a computer (as opposed to making a window with buttons labelled 0-9), Calca gives you instant feedback and instant evaluation. It evaluates as much as it can, given the information it has, but it’s thoughtful enough to be OK when there are unknowns, patiently displaying the variables in-place.

More than just a calculator, Calca allows for Markdown formatted text, with mathematics and their evaluations appearing precisely where they are designated.

I just had to know more about this app and the work that went into it, so I’m delighted to present my interview with its developer Frank Krueger. I hope you enjoy it as much as I did.

Interview

Jason: As you explain on your website, Calca grew out of a frustration. How did you come to the decision to solve that with Calca? Had you explored some other ideas first, or did Calca come about all at once?

Frank: In one important way, I have been thinking about Calca for a long time. I found that whenever I needed to do some algebra, perhaps convert from a screen coordinate to a 3D coordinate in one of my applications, I would do my “heavy thinking” in a plain text file. I would write out examples and then go line by line manipulating those examples, and any other equations I could think of along the way, until I had something that I could convert into code.

So I’ve always had these text file “derivations”. But it’s a terrible system: Sometimes I actually needed to do some arithmetic that I couldn’t do in my head. So I would switch to Mac’s Calculator app, or query Wolfram Alpha or use Soulver, and then switch back to my text file and plug the results in. Also, because Copy & Paste were my main tools for doing algebra, I was always suspicious of my own work.

So Calca, you could say, came about all at once as the realization that I should just write a smarter text editor to handle these files I was creating - one that knew arithmetic and algebra, had features from the programming IDEs I use every day, but still tried its best to stay out of your way (programming IDEs are often too rigid to explore ideas.)

The idea that Calca should update as you type was an assumption from the start. I certainly wasn’t going to hit Cmd+R whenever I typed something new!

Jason: What’s your background?

Frank: I have been writing software professionally for 15 years now. I was lucky enough to intern at General Motors in an electronics R&D group writing embedded systems software while I was young. That job taught me a lot about engineering in general, but also about computers. I was writing embedded code in assembler and C and diagnostic tools in C++ before college. On the side, I was also active in groups writing level and content editors for video games.

In college I earned a Master’s degree in Electrical Engineering specializing in control systems (at RIT in NY). I mention this because it was the time when I became most comfortable with mathematics. Modern engineering degrees are sometimes hard to differentiate from applied math degrees!

From there, I moved to Seattle to work at Microsoft. That was a wonderful experience learning how big companies write software, but wasn’t fulfilling enough. So I packed up, went to India and started a company with an old friend building control systems for naval ships. That is the same company I operate today, Krueger Systems. But we ended up “pivoting” (in today’s parlance) to web development consulting and I spent some time doing that.

The introduction of the iPhone freed me from the terrible world of web development (this was before JavaScript’s ascendance, web dev is better now). Starting in the fall of 2008, I wrote a huge assortment of apps, some of which even shipped. I was basically in love with the iPhone and was just doing my best to create interesting software for it. I didn’t make much money from these apps, but I’m still proud of a bunch of them.

The introduction of the iPad changed everything for me. I started writing bigger and more interesting apps, and they started selling better. iCircuit is my flagship app and my obsession since July 2010 - another app that I wrote as a gift to my 1999 self. It’s a circuit simulator that is constantly showing you results - it has been quite popular with students and hobbyists.

So I’ve been writing iOS apps for nearly 5 years and have been making a living from them for 3.

Jason: What roll do you see Calca filling? To me it seems kind of like a melding of a word processor, a spreadsheet, and a calculator all in one. As the creator, how do you see it?

Frank: For me, Calca enables:

  1. Quick and dirty calculations

    No matter how many literate constructs I put in Calca, it is, at it’s heart, a calculator. I mean for it to replace the Calculator.app. It only takes 1 more keystroke in Calca to accomplish what you can do in Calculator, but once you’re in Calca you have an arsenal of math power at your finger tips.

    I’ll admit that I still use Spotlight for my simple two-number arithmetic problems. But the moment I have more than two numbers, or two operations, I switch to Calca.

  2. Development and Exploration of complex calculations

    Calca makes playing with math - no matter how complex - easy. Even after I used it to verify or derive some equation, I often sit in the tool just playing with inputs to see how the equations change. Perhaps I’m strange, but it’s fun to be in a tool that encourages exploration and experimentation.

  3. Thought out descriptions and explanations of research or study

    I remember writing lab reports in college and struggling with Word’s equation editor. They’ve improved it, but I have never gotten over just how bothersome the tool was for creating original research. Even after you finished your battle with the WYSIWYG equation editor, you were just left with a pretty picture. Even if you move on to TeX and solve the input problem, you’re still stuck with pretty pictures that do nothing. There was no way to test and prod your equations, no way to give examples of their use. They might as well have been printed by Gutenberg. And so Calca is a step in the direction of a research paper writing tool that actually tries to help you.

Jason: How does Calca compare to Soulver?

Frank: Compare and contrast or just compare? ;-)

Soulver and Calca have the same goals - to make computation easier and faster than using traditional calculators.

Calca takes ideas from Soulver and super sizes them:

  • Soulver allows free text editing within a line of computation; Calca allows free editing in the entire file
  • Soulver updates answers as you type; Calca updates answers and derivations
  • Soulver understands arithmetic; Calca knows algebra, calculus, and algorithms

But Calca also addresses Soulver’s deficiencies:

  • Soulver requires that all variables be defined; Calca does not
  • Soulver does not support user defined functions; to Calca, everything is a function
  • Soulver has no programming constructs; Calca is one step away from being a general purpose programming language.
  • Soulver does not support engineering math: matrices, derivatives, etc.

Anyway, I don’t want to go on since I do love Soulver. It was a first step to getting away from Excel and old-fashioned calculators - Calca is an attempt to build upon that progress.

Jason: When I first saw Calca, as a live-editing mathematical environment, I was reminded of Bret Victor’s Kill Math project (specifically his “Scrubbing Calculator”). Do you think Calca provides a better interface for doing Math than the mostly “pen-and-paper” derived way we do it today?

Frank: Yes, I do believe it’s superior to real pen and paper since eventually you will want the aid of a machine to do some math for you.

But I see tablet-based “pen and paper” as a perfectly valid input mechanism. In fact, the earliest versions of Calca, from years ago, used hand writing recognition for input. I was trying to avoid the keyboard all-together.

What I found was that there are some hard problems in recognition to accomplish (1) fast unambiguous input, (2) recognition of dependencies (order), and (3) high information density on the screen. It’s easy to create fun tech demos but very hard to create reliable apps that won’t just frustrate you.

So, for now, the keyboard is a superior input device - especially on the desktop. But I am completely open to more natural mechanisms.

Jason: I should clarify, when I say “pen and paper” I don’t just mean writing in the sense of hand-written math, what I should have said was “traditional symbolic” math. Whether written on paper or typed, something like “10 = 2x + 2” is represented the same way.

Do you think the traditional symbolic notation is sufficient for math, or do you think it can be improved with the benefits afforded by a computer (near-instant computation, simulation, limitless memory, graphical capabilities, etc.)? Symbolic notation is convenient when all you’ve got is paper, but do you have any thoughts on a “better interface” for math?

Frank: Oh, ha! Yes, I completely mis-understood.

That’s quite the philosophical question and I hope you’ll forgive that what I say is stream of conscience. While I have given the question a lot of thought in the field of robotics and engineering, I have not really considered how new tech like this influences mathematics.

So let’s start with YES. Simulation, near-instant Simulation (like iCircuit), Visualization, yes these are often superior representations of mathematics/physical systems. I’m reminded of Bret Victor questioning why we jagged little lines to represent resistors when computers give us the ability to represent the resistor more richly as an as a graphical IV curve (current vs. voltage). I am on board with this.

MATLAB’s Simulink is an early example of trying to improve design work using visualizations. Now their semantics are old and not very powerful, and their visualizations are not real time, but it gets the job done - it’s an improvement over writing procedural code that must interact with real complex systems.

I have high hopes that these modern tools can progress to allow arithmetic of their visualizations for these myriads of applications. Imagine Bret’s resistors in series so that their curves combine into one resistor. Cool.

My only concern with these computation intensive visual tools is how well they will handle algebra - the manipulation and combination of all the symbols that are used to create this data. When I design an amplifier using an operational amplifier, I know that the gain is: 

G = 1 + Rf/Rg

Now let’s say I’m in Bret’s tool that has curves instead of resistors. While he makes it easier to play with the values of Rf and Rg and see the effects of this, he doesn’t make it easier to visualize the gain equation, this algebra. I can play with the values all day long and never meet my design goal. Or worse, I stumble upon one of the solutions (there’s an infinite number) and assume that it’s the only solution.

Just like with a traditional circuit schematic, the designer can’t do his job reliably unless they know the rule: G = 1 + Rf/Rg. Naive visualizations and computations don’t instruct they only re-inforce what you already know. (Unless of course you stare at the visualizations long enough and self-instruct yourself to understand the equation.)

Now let’s say I’m an EE student from 50 years ago with no simulation software and no visualizations. Some how, I still need to learn enough to get us to the moon. That little equation, G = 1 + Rf/Rg is all you need to design the correct amplifier - no computers of software necessary. No only that, but they could probably derive the equation using just three others: v = i * R, Vout = A*(Vp - Vm), A = Infinity. There is power in being able to manipulate symbols.

So what I’m getting at is this: I have high hopes for these modern visualizers. I just hope that they find ways to increase our understanding and not decrease it (by not exposing governing equations). If they don’t increase our understanding, then we might as well stick with Calca. :-)

I hope you can make some sense of that.

Jason: You said you developed an LALR(1) parser generator for Calca. What is your background on writing parsers? How did you go about creating the parser?

Frank: I didn’t write the generator, just the grammar. The generator is jayc, which is a port of jay which is an implementation of yacc’s parsing algorithm. :-)

I wrote my first parsers back as that young intern at General Motors. When you work with embedded systems, you really learn what a compiler does. I spent a lot of time comparing my C code to the machine code that the compiler would generate. This ended up being a fantastic way to internalize, or grok, how computers work. Understanding compilers was then just a matter of writing some code to convert between the two.

I remember learning to write my first parser using Stroustrup’s The C++ Programming Language book. He has a chapter in there where he builds a little calculator utility. It’s still one of the best introductions I know of to recursive-decent parsing. It was mind opening as a young programmer. From there, I gorged myself on everything Niklaus Wirth had to say on the subject (and every other subject), and wrote scheme interpreters (following SICP) over and over again until I understood language design and implementation tradeoffs.

Calca’s parser is basically a yacc file from 1970. You start with IDENTIFIER and NUMBER tokens, and slowly build your way up to recognizing your full language. It’s actually quite fun. If you like using regular expressions in your programs, you have no idea what you’re missing by not using full blown parsers.

Jason: What technologies did you use for making this project? Did you build upon open source or did you roll it all your own? How did you build the project over the course of three months (did you have many beta testers, how did the app evolve, etc.)?

Frank: The app is 100% my code written in C#. I use Xamarin tools as my IDE and to compile the app for iOS/Mac/whatever else I’m in the mood for. C# provides a lot of benefits over older languages especially when it comes to writing interpreters and you’re bracingly re-writing expression trees.

I did look to license a CAS (Computer Algebra Library) but couldn’t find a good match for what I wanted and that had workable license terms.

At first, the app didn’t have big ambitions on the mathematics side so it seemed perfectly reasonable to write my own parser and interpreter. I had done that many times before so there wasn’t too much risk. While Calca’s engine is only now getting to be on par with these more mature libraries, and I apologize to users who actually need all the power of Mathematica, having a language and execution model that is specifically designed to be humane has benefited all of us.

There was a core of 3 beta testers working over the entire development time of the app. I know, not a lot of people, but we didn’t know that any one else would like it! :-) To help make up for the lack of testers, a pretty extensive set of automated tests have been developed. Last I checked, I run about 3,000 unit tests whenever something changes to make sure that the engine is consistent.

That said, having 1,000 people use your app is quite different than 3 so I’ve been fixing a fair share of v1.0 bugs. :-)

Jason: Most of my peers (self-included) work in a lot of Objective C. What differences have you found between it and C#? How do you find iOS development with a non-Xcode environment?

Frank: Ah, I didn’t know, I wouldn’t have been so glib.

There are two big difference between C# and Obj-C is the garbage collector and the more succinct syntax. As for the GC, JWZ said it best, “I have to admit that, after that, all else is gravy”. Having one around instead of manual memory management, or reference counting, or even some automatic reference counting frees you to focus on computation instead of data management. There is a correlation between the popularity of scripting languages and the fact that they have a GC.

On top of that C# just has a lot of syntactic convenience. It’s a two-pass compiler so you don’t have to repeat declarations. There is a unified safe type system (like Obj-C’s id, except that it applies to everything, including C code). It has modern language features: generator functions, list comprehensions, closures that can capture variables, co-routines that can be written using procedural syntax, and on and on. There is also a giant class library and a huge 3rd party ecosystem. The real benefit is that it can still access C code and functions natively so I can use the entire SDK. So mostly pros, and just a few cons.

My first two years of iOS development were in Xcode, but it was a younger version so it’s hard for me to compare the two IDEs. Generally speaking, Xamarin’s tools have superior code completion and debugging visualization. But both IDEs are mature powerful products, and I honestly like them both.

I have not had any real problems being “non-Xcode”. There was that silly scare years ago when Apple was trying to block non Obj-C apps, but that was an obvious blunder on their side so I never concerned myself with it.

Jason: Where do you see Calca going forward?

Frank: Well, I’m submitting v1.1 to Apple today (for both platforms) that fix a lot of the v1.0 bugs (Note: v1.1 has since been released to the App Store).

After that, there is a lot of low-hanging-fruit that I cut for v1.0:

  1. Unit conversion
  2. Plotting
  3. Solving differential equations
  4. Larger library of utility functions

These are all features I want myself, so they’re guaranteed to be added. I’m also actively listening to feedback. This v1.1 release is essentially all fixes from bugs submitted by users.

After all that, we as a Calca community have to see how to proceed. As I use it as a tool every day in my own work, the app will be maintained as long as I’m still working. But we as a community will have to decide what additional features would make it more powerful, or if it, itself, should be eventually supplanted for something better. Always advance the state of the art!

Jason: It’s funny you should mention plotting. I’ve actually been working on a math-related program in my spare time lately, specifically to do with graphical representations of formulas, so when I found Calca, it caught my eye. Do you think plotting is an essential function missing (most of) today’s “calculators”? Will you be approaching some of Mathematica’s functionality?

Frank: Plotting is a very important feature.

I have spent a lot of time in Grapher.app playing with different blending functions:

y = x
y = x^2
y = sqrt(x)

I would just look at the graphs and decide which one met my needs. Now I could do this with a calculator by asking for its derivatives at the points x = [0, 1] but that’s tedious and silly. It’s much easier to see a plot and just pick the one that seems right. I want that feature in Calca.

I plan on supporting plotting of one parameter functions like: g(x) = sin(x) + 1/x^5. These will be displayed as graph’s similar to Grapher’s.

I also will try to add two-parameter functions: h(x, y) = if x > 0.5 && y > 0.5 then 1 else 0. These will be displayed as images.

I’m not sure how far to go from there - I will simply listen to feedback and see what more features people need.

Jason: Finally, any chance of a Mac version?

Frank: It’s available now! Calca for Mac OS X

I’d like to thank Frank once again for taking the time to be interviewed. Go buy Calca.

Speed of Light