Hacker News Reader

Comment by sohamsankaran | Hacker News Reader

This is not even true across subfields in mathematics -- there's a lot of context-specific notational overloading, and there is often inconsistent notation even within a single long paper.

View on HN

Ok, but if you see something like ∫Ωf (with Ω as a subindex of ∫ ) you can be 100% sure that it means some kind of linear operator on an object "f", that is additive over disjoint union of the set parameter Ω, and a few other natural rules that are satisfied by integrals (monotony, positivity, etc). Of course in one paper it will mean Riemann integral, on another Lebesgue integral, an on another something completely different, defined axiomatically over discrete objects, but with exactly the same formal properties. In programming languages you have nothing universal like that, except maybe the notation for quoted strings. Such an integral may be written in some language as

    integration.integral.apply(omega, eff)

on another as

    omega.getNaturalIntegrator().applyTo(eff)

and yet on another as

    eff.integrateOver("planarDomain", omega)

and on each of these constructions the visually evident formal properties of the integral are lost and difficult to reason about.

For me, each of those text based representations is more clear, despite their divergence, than the symbolic version.

I have a lot of frustration with this notion of the "visually evident formal properties of the integral" -- I think the existing visual-symbolic paradigm of mathematical notation is intuitive to some subset of people, but that subset does not encompass everyone who could do mathematics at a high level, excluding those for whom some alternate, in this case more text-based, representation is more tractable.

I guess it depends on your background. Some of us studied math much before programming, and then we find some of the notations used in programming extremely preposterous. I meant the examples above as obvious failures of the notation used in programming. I'm honestly surprised (and terrified) that somebody can consider those better in any sense than the mathematical notation.

So much of what I do as a programmer is just try to understand what some existing piece of code does. If I come across code like that, I can search documentation or start to guess at intentions even if it's something I'm not familiar with. I'll probably need to read the documentation associated with some classes or methods to fully understand, but my tools make that readily available.

If I encounter math notation that I'm not already familiar with, my only real options are to start asking people, "hey do you know what this is saying?" or start shotgunning references/papers/books and hoping for the best. Even if I know the names of some symbols, searching something like "integral omega f" doesn't generally yield useful results.

> I can search documentation or start to guess at intentions even if it's something I'm not familiar with. I'll probably need to read the documentation associated with some classes or methods to fully understand, but my tools make that readily available.

I don't see it all that difference in mathematics. A given piece of math will make assumptions on the notations and expects the audience to share those - the example of integrals is a good one. Usually within a particular subdiscipline (or from the context) you'll know if this is a Lebesgue or a Riemann integral - so they don't bother having separate symbols for them. If you're new to the discipline, you may not know the convention, so you have to ask or search.

The thing with software and programming is that it is usually "complete", and that's why you can use your tools to access the docs/definition. It is complete because the universe of options for a given program is relatively small. In mathematics, though, it isn't that small, so the challenge of making all the definitions, conventions available to you for a given piece of math you're reading is much greater. Textbooks typically are good about this, but the more advanced you go, the more you are expected to know as "these are the conventions in this subdiscipline".

A lot of this is probably historical, and no one today wants to bother with making a consistent set of tooling that will get you what you want.

For me, one important feature of notation is its consistency. Eg a inverse of sin function should not be written the same as powers, in superscript. Some programming languages enforce (function-name argument1 ... argumentn), or similar structure, some don't

Using negative powers for applications of the inverse function is arguably consistent, because it is a generalization of the same notation for linear maps.

It does not pose major problems, either. You can easily distinguish f^p(x) and f(x)^p. The first one means "apply f p times to x, iteratively" and the second one means "compute f(x) and raise it to p". It works just as well when p=-1.

> Using negative powers for applications of the inverse function is arguably consistent, because it is a generalization of the same notation for linear maps.

Except that no one will let you get away with (sin^-1)^-1 x to represent sin x. But you can do that with inverse function notation in general. Some of this is just cultural.

That would be a strange notation indeed. But I once met an engineer that called the exponential function the "antilogarithm". It was not a weird mannerism, it was his bona-fide way of calling the function exp(x). Apparently it was the standard name where he came from (somewhere in south america).

I've seen antilogarithm in textbooks. I think it's more common in the complex domain.

we find some of the notations used in programming extremely preposterous.

E.g., = as assignment instead of equality.

Which I presume is why pascal uses `:=`.

Also, in more declarative languages, particularly ones that don't allow reassignment, = can be regarded as an assertion of equality rather than an assignment.

Reply on news.ycombinator.com