Legible Mathematics: Sketches of interactive arithmetic for programming (2014) | Hacker News Reader

Legible Mathematics: Sketches of interactive arithmetic for programming (2014)

glench.com

116 pointsthrowaway315750 comments

I always enjoy seeing new attempts at visualizing and explaining function composition. Here’s something I played around with a few years ago that tried to visualize function composition: https://taliesin.ai/posts/function-trees/

So the only take-away I get is that the author does not like to use brackets and really likes writing fractions.

Unfortunately, this does work very badly for long fractions, iterated fractions or, well, anything more complicated than toy examples.

This pops up from time to time with latex and how a/b should give you a fraction instead of having to write \frac{a}{b}. Problem is, this makes one easy case marginally shorter, but something like \frac{a+b}{c+\frac{d}{3}} much harder.

{a+b}/{c+d/3}

Still looks much better

Hm, reading that it is not immediately obvious whether you mean (c+d)/3 or c + (d)/3. At that point I think it should be straightforward to implement {}/{} as syntactic sugar for \frac{}{}.

Mathematics notation is basically completely determined by consensus and people come up with new notation all the time whenever they need it. In particular, in order to convince someone that your notation is better you have to show previously how hard stuff becomes easy and not how easy stuff becomes even easier.

TeX already has the primitive of {}\over{} that does what you are saying. It is not typically used.

https://tex.stackexchange.com/questions/73822/what-is-the-di...

The mathematical notation has developed over centuries to __think about and solve problems on paper__. Besides it being taught in schools and hence familiar, I think it’s not at all a good tool to use in the significantly different digital medium.

Another reason is that the notation is mostly a tool for __oneself__ to think in, but is fairly bad at communicating (think about the level of expertise required to read a math paper vs reading someone’s code).

Here’s a concrete difference to support these claims. Using math notation we often write large expressions which include many meaningful subexpressions and complex operations. In code we prefer to use lots of names (variables) and simple expressions.

Reading math is hard because math is hard. The notation is incredibly powerful, intuitive and flexible. In all my years hanging around mathematicians I’ve never heard anyone complain about notation. After all, you are always free to use your own notation if you want, and if others like it they will follow.

> In all my years hanging around mathematicians I’ve never heard anyone complain about notation.

There's likely to be some survivorship bias at play here.

No, since anyone is free to invent and use whatever notation they prefer. That’s how mathematical notation has evolved so far. People come up with new notation all the time.

"Free" here is a bit abstract. In what way is an undergraduate mathematician free to use their own notation, as opposed to the notation of their lecturer, textbooks, and examination papers? You can think in your own terms, but mathematics has to be taught and communicated with some kind of consensus - and unless you're lucky enough to be the first in the field, that consensus has preceeded you.

Mathematics is completely meritocratic. If you invent a notation that is better than some existing notation, people WILL use it, without asking for your credentials.

I think that's a naive statement, and it's also not really relevant to the original point being made, which is that existing mathematical notation can be difficult to grok.

Inventing new notation does not help with existing material - and that material is what makes mathematicians. People who can put up with old notation, especially if it is bad, are much more likely to become mathematicians: that gives a survivorship bias.

Besides which, you are welcome to invent your own notation, but good luck trying to get anyone to adopt it, particularly if the mathematical field involved is studied enough. Inertia is very strong, even in very abstract disciplines - aren't physicists still treating current as flowing the wrong direction?

Though when you are writing a paper, it's useful to pick standard notation.

But yeah, when working something mathematical out for the first time, picking / making up the right notation is crucial.

sure unless you quit because you struggled to learn what was in place.

Inertia

The most likely place to be hanging around mathematicians is at a school, and that's also where you would expect to hear students complaining about notation as an impediment to learning.

I don’t think it is a given that students are good judges about what impedes them from learning.

Having said that, I personally have never had issues with notation in mathematics nor did I have the impression others I helped had. IMO, abstraction is the main stumbling block, not notation.

I’m talking about the math institutions at the two universities I attended, I took a lot of phd classes. But same with students, the complaint has never been about notation. In fact the only people that seem to complain about notation is computer programmers who find it too loose, but that is precisely its power.

Are you kidding? Bad notation abounds in mathematics and theoretical computer science

Do you have any examples?

Well, here you have one! Computer science notation is vastly superior to the common mathematical one. It's a different league of clarity.

But my papers need to follow the consensus, as I'm already trying to get a hard idea across to my reader who decides to spend 15 minutes to try and understand me, maybe.

So yes, then I need to introduce 15 symbols, half of them greek, and a number of operations between them using whatever line/subscript/superscript/brace is fashionable.

The biggest difference is in slides. In slides I try and can usually avoid the math notation. Because I am there talking it through, which makes notation less important and gives me an opportunity to switch to long variable names and everything a function, more akin to the software notation.

The only people I’ve ever heard having problems with math notation (as opposed to math concepts, which are often extremely abstract) are computer scientist and computer people in general. I think what irritates them is the fluidity and flexibility of most math notation. It’s not really machine readable since it really assumes you know what you’re doing. The same string of symbols can mean vastly different things in different contexts, which is precisely the power of math notation. Brevity is actually a goal in itself, it makes it possible to keep even larger constructions in your mind at the same time.

Consider einteinian notation, with implicit summation. Very terse, and very powerful when you know what you’re doing.

I’m sure CS notation is great for CS but trust me, math notation is pretty damn near optimal for math. Second only to theoretical physicists, mathematicians are probably the smartest of scientists.

Ken Iverson complained so much about notation he came up with his own and won the Turing award.

Anyone interested in this stuff who hasn't read it yet should check out Bret Victor's Kill Math series of essays and explorable explanations: http://worrydream.com/#!/KillMath

This dovetails to some degree with thoughts that I've been having about language and expression design.

Associativity and operator precedence are ideas that made sense as a shorthand in written mathematics (and have deep roots in the structure of arithmetic) but don't actually add a lot of value in programming languages, except to put a huge mental burden on developers to unpack the precedence.

My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)". In my experience, though, especially in programming (though not always in financial programming), there are almost always semantics associated with those intermediate values which makes one of the two groupings preferable.

Taking numeric constants and adding internal separators makes a lot of sense as well (both before and after the decimal point). Ideally this would be enforced at some arbitrary cultural level, (e.g. using the US-standard groupings of three with comma), and would be required -- "2000" is invalid and "20,00" is invalid (so python3's approach of allowing arbitrary _'s in numbers is not really great, because it doesn't protect against typos). The right-of-the-decimal-point separators are not really common, but it would be nice to take advantage of this to make a sensible arbitrary enforced designation, like using "," to the left and "_" to the right, once again mandatory and required to support groupings of three.

Would probably also be desirable to have a convention for hexadecimal numbers and other supported bases -- in particular binary is not supported by many languages, but is very natural for most programming languages, if we had a way of using delimiters -- 0b0100_0000 is more readable and meaningful than 0x40, but 0b0010_0100_0011_0010_0000_0010_0010 is not so good (quick, how many bytes did I just type?).

> My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)".

Or how about... (+ a b (/ c 2))

I think S-expressions are annoying in that they tend to infect a language. If you're not careful, every function invocation becomes an s-expr, and you're left with the idea that + is no different from any other function, so we could write things like "plus(a, b, divide(c,2))" if we wanted to make a functional notation. And S-exprs don't save us from associativity, here you've made + associative, which is, fine, I guess, but what does (- a b c) mean, or (/ a b c)? This sort of asymmetry is a burden that isn't worth dealing with in my mind.

On thing that I think imperative languages bring to the table is naming intermediate values through assignment, so we can do things like

    base_index = root_index + offset
    midpoint = length / 2
    final_index = base_index + midpoint

It's rarely useful to be so verbose, but it's nice to have the ability.

(Assuming I'm understanding correctly,) I'm honestly curious why `+` _should_ be different from any other function. (Also, AFAIK the ability of naming intermediate values is totally separate from imperativeness; see Haskell's `let` form, for example.)

Still a bunch of pointless parens. Obviously

a b + c 2 /

or even

/ 2 c + b a

is the more efficient, unambiguous notation.

  a b + c 2 / +

  + a + b / c 2

While I can see where the author is coming from, I have a couple of points where I disagree.

1. I've yet to see any automatically formatting system that's not extremely painful to work with.

2. Mathematical notation hasn't just been developed over 100s of years it is continuing to do so.

3. Units aren't labels.

I would like a computer system that can do algebraic reductions. This is the only thing that forced me to go back to pen and paper.

This looks like it does substitutions but I didn't see reductions.

This sort of thing is called a Computer Algebra System (CAS) and there are good free ones.

https://www.sagemath.org/

http://maxima.sourceforge.net/

https://www.sympy.org/en/index.html

It's probably not a good solution for most people, but here's what I do: I have a TI-89 emulator on my android phone. I used one of those calculators for about six years in high school and college, and I'll never lose the muscle memory of the interface. (I also still own the device, which justifies using the emulator ethically, if not strictly legally.) I believe it's actually faster for me than, say, sympy, which I also use in other contexts. Also faster than using pencil and paper, for sufficiently large problems.

If you're not familiar, it uses a CAS called derive which handles algebraic simplification (including trigonometry), differentiation and integration. Oh, and a function called "rref" (reduced row echelon form; familiar to matlab users), which solves a linear system (including symbolically), with absolutely minimal overhead in the "CLI".

Now that I say that, I want an actual CLI tool called rref that works in the same way.

How hard have you looked? You'd be hard pressed to find a computer alebgra system (CAS) that doesn't support algebraic reduction. It's been available for decades at this point. Popular systems offering this can do this include Mathematica, Maple and Sage. Even MATLAB had extensions for symbolic manipulation now.

Here's something worth investigating, IMO:

> PRESS (PRolog Equation Solving System) is a system for solving symbolic, transcendental, non-differential equations. The methods used for solving equations are described, together with the service facilities. The principal technique, meta-level inference, appears to have applications in the broader field of symbolic and algebraic manipulation.

https://dream.inf.ed.ac.uk/software/press/

And: https://github.com/maths/PRESS

> This directory contains a copy of the PRESS ... modified to run on SWI Prolog

Such things exists under the name "Computer Algebra Systems". Notable commercial offerings include Mathematica and Maple, but there is also free software such as Sage and Sympy.

A big downside of that proposal is that everything takes up much more space, which makes it much harder to keep track of what else is going on. In toy problems it is fine, but in real problems having the answer to "did the code already check for i == j" visible at the same is really important. Let alone context such as "is this the reference implementation for single core validation or the vectorized function" or "is the radius at timestep n or n+1/2".

This looks a heck of a lot like Desmos without the graph.

(https://desmos.com/calculator)

My thought as well - it's jarring at first to get used to, but Desmos' way of typing in equations, where keypresses really act more like operations on the equation than raw text input, gives a natural easy way to write good equations.

At the very least, typing / automatically makes a fraction with separate top and bottom input areas - which means that brackets for numerator and denominator aren't necessary.

Desmos's input is done with an open source library called MathQuill: https://github.com/mathquill/mathquill

If the labels are supposed to indicate units, they should at least indicate the RIGHT units! rent, electric, and internet are dollars/month. Otherwise the 12480 in the example is dollars*months, clearly not the right units.

Looks like a follow-up to yesterday's thread here: https://news.ycombinator.com/item?id=22399516

The post is from 2014. I wonder what progress was made since.

Well, I'd hope he fixed the 10^11 to 10^-11 in the excel sheet, but given he hasn't updated the page to reflect that, I'm not hopeful.

Although, perhaps it's deliberate as a canary test for those that intend to defend non-traditional mathematical notation in programming.

Python3 Allows you to put underscores in numbers for legibility:

a = 100_000 b = 1_000_000

That started at least with Ada, in 1979 (https://softwareengineering.stackexchange.com/a/403959).

Traditional FORTRAN ignores all spaces, so one can write a million as 1 000 000 there, C++14 allows apostrophes (https://en.wikipedia.org/wiki/Decimal_separator#Data_versus_...)

the first example feels deliberately complicated, where gravity constant can be shortened to G_ = 6.67x10^-11, (G_ * M1 * M2 / Rad^2)

Observable.js is like this

I guess it is useful if you are teaching kindergarteners. For high schoolers we write

      for(i=0;i<N;++i){
          for(j=0;j<N;++j){
              force = G*mass1[i]*mass2[j]/radius(i,j)^2
              // do something with the force
          }
      }

Reply on news.ycombinator.com