Hacker News new | ask | show | jobs
by mvzvm 1872 days ago
> Write equations; not code

This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.

4 comments

We must be evil twins in opposite universes. I've always wanted to be able to code the equations the way they look on paper. I actually am quite annoyed that most languages won't let you use Greek characters as variables. To me, it just makes it easier to spot errors.
Julia lets you use all sorts of Unicode characters as variable names and even as operators. It works quite well in the REPL, since it supports a TeX-like input method for Unicode characters. It's probably my favorite feature in the language, since it makes the code much more concise and expressive. (I've always hated having to step down from the mathematical beauty of LaTeX-typeset equations into the ugly reality of spelled-out Greek-letter names in a codebase that didn't support Unicode.)

However, input method support in editors isn't as straightforward, which can become a limiting factor if you have to work on a Julia codebase that uses Unicode characters and your editor doesn't make it easy to insert those characters.

The problem with Julia is it only supports what Unicode supports directly. Which means you cannot have x,y,z as subscript for coordinate variables because Unicode, for some weird reason, does not have the full alphabet in subscript or superscript form. Also, when I first dived into Julia I found quite a few Unicode symbols that, when used as function names, lead to all kinds of weird compiler errors. Kind of defeats the purpose.

A language hoping to make this complete would have to do special formatting that allow super- and subscripting any Unicode symbol. But that won't work in a normal terminal...

I mean I guess that makes sense for a mathematics-oriented language. Generally, literate coding would encourage you to come up with friendlier variable names as software engineers aren't mathematicians per se and code is meant to be accessible to more than just academics/mathematicians.

In particular, I see a lot of this done in machine learning python code. Lots of "z", not "zeta", etc. Pretty tough to understand as a non-researcher.

It seems backward to try and understand a known math technique or fact from code when there are likely pedagogical presentations of the same material. And if we're talking about novel math, it seems more than fair to ask that the reader is comfortable with the domain.

Can you imagine someone learning math by contemplating the sum of effects in a program? Heaven forbid there's any emphasis on performance whatsoever.

Trying to abbreviate greek variables ends up causing a lot of issues too. It's common to have both "zeta" and x,y,z in the same scope. As well as a capital and lower case zeta. And maybe a zeta prime, and some subscripts. Unless you plan well ahead, it's hard to be consistent across all parts of the code and be concise at the same time.

Trying to come up with more descriptive names isn't practical as the variables often have very complex definitions, and it'd be impossible to explain in a variable name.

Agreed. With normal math notation I can just see how something works. In programming language math notation I cant even always parse the hierarchy.
In general, that depends on the programming language though, and not all things in math are easy to parse and rely on precedence rules. Math is far from optimal in this aspect and I guess you just have experience in reading math.
Mathematical notation is not perfect, but it does a pretty good job of choosing clarity when ambiguity might be a problem. For a basic example, the fraction bar for division makes groupings obvious, where a single '/' in a long string of text can get visually lost. Of course it's understandable that most programming languages would shy away from special notation like that in favor of plain text, but it gives mathematical notation a strong clarity advantage, in my opinion.
you can get pretty close with mathematica using the notation package e.g. these three defines compute euler-lagrange equations given a lagrangian.

https://imgur.com/aMfdYQy

  > I actually am quite annoyed that most languages won't
  > let you use Greek characters as variables.

  $ python3
  >>> φ = 2
  >>> σ = 3
  >>> φ + σ
  5
This. Also, in IPython, one can write greek letters by doing:

    \Sigma<TAB>
which will get converted to an actual Σ.
Same here, writing code seems to map better to what you would step through solving the equations by hand. You can see how the equation “works”. But it may be, that I just haven’t gotten my mind wrapped around the concept of programming with equations yet.
This is a competitor to MathCAD which is used for things like structural calculations. I've used it for traction drive calculations. Generally you're implementing equations that are defined in papers and it's really nice to be able to make them look roughly the same.

In MathCAD you can annotate them with actual snippets from the papers too. Definitely beats coding for some specific applications.

> if its going to be executed

You prefer to write code as code, which makes sense as it skips the translation part - but technical code is the implementation of the math so any given equation can represent multiple possible code-implementations.

From that perspective, it might make sense to separate the two, with good tooling. Since tooling generally isn't good, it's just as hassle.