They are indeed concise and beautiful, but some of the implementations I checked are quite naïve. They're great for academic purposes and for some simple problems they will work just fine, but I would advise against using them for real-world problems.
For instance, for some of the regression algorithms the pseudo-inverse of the matrix is used to solve the normal equations. Again, for small, well-behaved problems it is OK, but for larger scale, less well-behaved problems, it is actually dangerous (numerical instabilities and other issues). There are better, faster, more stable approaches. (PhD in Applied Math here)
BTW, I have been using Julia for work for several years now and I think it is a fantastic language for scientific computing. For those who use Matlab/Numpy regularly, you should definitely check it out.
It depends a lot of the problem. For a general least squares solution of the Ax=b problem, is your A matrix dense, sparse, structured? Do you need to solve it very accurately or just approximately? Are you going to be using this over and over with the same A but different b's? In that case, you may profit from a one time Cholesky factorization that can be used over and over very quickly. Is your linear operator A explicit (as in you can actually inspect the matrix) or is it a linear operator function in which you can only see the result of A(x) (and its adjoint A_adj(y)) ? In this case, you cannot use common factorizations (QR, cholesky, svd) but will have to use iterative methods (ie. Krylov space methods).
There's a whole branch in applied math that's called numerical linear algebra and deals with all these kinds of situations. One of the most important results is that you should almost never do an explicit computation of the inverse of a matrix. It is expensive and can be highly unstable. If you ever see a A\b or pinv(A)*b in somebody's code, it should raise a big red flag.
A little defense of the pseudoinverse here, it's often a fine tool, far more so than the true inverse.
If the matrix is not full rank the psuedoinverse provides the least squares solution.
It can also be done efficiently and may well already be implemented using whatever numerical method one prefers (SVD, QR).
And the implementation probably allows for regularization via a singular value cutoff.
I'm not sure what matlab's backslash operator does these days, but it looks like a more efficient way to get a least-squares solution (compared to the pseudoinverse), possibly with sparsity imposed slightly.
Yes, it basically means "solve 𝐗𝛉 = y for 𝛉", for which inverting 𝐗 is one of the many methods that can be used to solve it. MATLAB also has the same backslash operator to mean the same thing.
I don't know about the pseudoinverse in particular, but at least in the case of normal inversion -- you almost never want to invert a matrix, but sometimes you do, so it should be possible to sensibly express the idea of 'invert' I think.
True, but the specific combination of inversion and multiplication, with a well-known meaning, could be transformed. Standalone inversion would still stay an inversion. Algebraic identities are definitely one thing you might want to exploit with advanced compiler macros.
I guess the only concern I'd have is, is it possible that someone knows what they are doing (so, something is special about their matrix) and wants to do an in-place inversion, multiply, and then use their inverted matrix for something else. I'm don't know Julia, though, so I'm not sure if this would be a weird thing to do. (is invert even in-place?)
Not sure about inversion, but if I remember correctly, LAPACK can do for factorizations such as LU in place. You can the refuse the factorization to solve for many RHS.
The normal way (as far as I know) to do inversion in LAPACK is to do LU (in place), and then do invert (also in place) on the LU factors (so they get eaten up by the invert). I guess it would be possible to do: LU, then do some solves, then do invert with those LU factors, it just seems a little odd.
Often one is not really interested in solving Ax=b for all possible b but just one particular b. In that case one can iteratively solve for x by algorithms like conjugate gradient which only require multiplying A times the current best guess for x, which can be very fast and avoids numerical instability issues in many cases.
My first degree was in math. I've frequently discovered that I don't understand the notation in math papers. What does the paper mean by the harpoon (↼ arrow with half its arrowhead) and how is it different than the waved arrow (⬿ arrow with a wavy shaft)? Each discipline has its own conventions, is the backslash a set difference operator or is it matrix division. Is alpha, α, an angle in some trig equation or is it the minimum assured score value in alpha-beta pruning? It takes a bit of time to dive into a math paper. Even the universally understood symbol for integration (∫) can mean different things. Is it Riemann integration or is it Lebesgue integration? Is it symbolic or is it a numerical approximation. It depends upon context, and the context is communicated between mathematicians by the subject of the course, the preceding results in or paper, or just a few asides by a professor giving a lecture.
Computer scientists (I've been one for roughly 50 years) introduce their own academic notations. Is circled plus, ⊕, a boolean exclusive-or or is it bitwise exclusive-or. Take a look at Knuth Vol 4A, it's chock full of mathematical notations embedded in algorithms. He uses superscripts that are themselves superscripts, how are those supposed to be entered with our text editors?. What about sequence notations like 1, 4, 9, 16, ... we might suppose that it is just the integer squares, but the On-line Encyclopedia of Integer Sequences lists 187 other possibilities. Is the compiler supposed to guess what this is?
Well, if mathematicians use these concise notations, why shouldn't programmers? I believe it is because mathematicians don't want or need to take the time and space needed to spell out these operators, variables, and functions in their papers. It's not necessary for mathematicians. Other specialists in their field can figure out what the symbols mean while reading their papers. Their students can understand what a blackboard capital F (𝔽), likely a field in a class on abstract algebra.
Programmers are doing something different. Their programs are going to be a lot longer than most math papers or lecture expositions. The programs have to deal with data, networks, business rules, hardware limits, etc. And everything in a program must be unambiguous and precise. Programs are large and can be edited many times by many people. For these reasons, I'm inclined to favor programing in plain language with plain ascii.
See:
Knuth, The Art of Computer Programming Vol 4A, Combinatorial Algorithms
My background is also in maths and I am keenly interested in, and frustrated by, notation as it appears in various fields. There's a time and place for fancy, dense notation, and I don't think it's here. Subjectively I found the use of unusual math unicode symbols to be gratuitous in this repo.
> Well, if mathematicians use these concise notations, why shouldn't programmers? I believe it is because mathematicians don't want or need to take the time and space needed to spell out these operators, variables, and functions in their papers.
Mathematicians don't need to fight compilers, only other mathematicians. If Mathematicians needed to convince a compiler their equations, I'm sure they'd be forced to be fully explanatory and less handwavey at the margins.
Not a Julia expert, but these snippets don’t strike me as very idiomatic or algorithmically sound [1].
What they seem to do, instead, is to demonstrate that you can write code in Julia that is quite close to the mathematical notation. (Whether you should do so is another question).
[1] for example, adding a row of ones to a matrix by using array comprehension:
𝐗 = [j==0 ? 1.0 : X[i][j] for i in 1:m, j in 0:n]
or solving a linear system by multiplying with the (pseudo-)inverse:
I do think Julia is uniquely poised to provide a new kind of trade-off between concision, performance, understandability, etc. because of multiple dispatch, and great syntax for things like broadcasting.
Sometimes a practical algorithm does not look like a textbook algorithm, because they're different algorithms, but I think the main reason that there is such a discrepancy is:
1. math notation is many times quite ambiguous
2. there are a bunch of performance optimizations that end up being unsightly
I am not claiming it's easy work, but I think it's nice to try to find abstractions so that at least somewhere, the algorithm looks simple.
I don't, however, think that these code examples really make that shine at all. There are also choices I disagree with. For example, there is (paraphrasing) `map(vⱼ -> g(x, vⱼ), V)`. the `j` subscript is meaningless to me, and is an awkward combination of "point free" / "index free" notation with a higher-order function, and a more traditional spelling. Math texts love to do things like V = [v_1, ... , v_n]. That doesn't make sense to do in a programming language. instead of writing v_j, you just do V[j].
My favorite examples show the reference algorithm alongside the code (which cites it). The goal should be that the code provides enough similarity to the reference that it's easy to transition between the two and see past those necessary differences. For example:
Imagine a world where papers are written as a Julia Jupyter Notebook (or other nb format) that compiles to both a pdf suitable for publishing and also to a library that is directly consumable. The phrase "I'm using an algorithm I found in this paper" would become a much more meaningful statement.
That is a great world. But considering that we still do not really know how to write e.g. generic code that operates on both immutable and mutable arrays, I think Julia is not there yet.
The other big thing missing in Julia that is IMO important here is more control over evaluation, like allowing lazy evaluation. You can build some of these features on top of Julia (e.g. https://github.com/RelationalAI-oss/Salsa.jl).
Math is usually not written with computation in mind, so some algorithm might e.g. re-evaluate f(x) multiple times. Compiler optimizations can help in some cases, as can a "dynamic" solution like memoization/caching. But again, I don't think Julia is "there" yet.
I don’t really get the first issue. If an algorithm doesn’t need to mutate a matrix then it will work for a mutable or immutable matrix. If it needs to mutate a matrix then how could it work for an immutable matrix? If you want a polyalgorithm that uses a mutating algorithm on mutable matrices and a non-mutating algorithm on immutable matrices, then you can just do that (and multiple dispatch makes it easy). What additional features are needed? Is there some language that “does this right”?
to make a related point, I think that notions of programming (e.g. scope, types, awareness of Hungarian notation) should influence how we write math more. I do not think the goal can be to make code look like "math" completely because there is so, so much punning in how most people write math.
I think it's very interesting how some people are repulsed by the use of mathematical symbols in the sample code. While others love it.
The vast majority of the code I write is not mathy. But I do write a fair bit of mathy code because of the field I operate in. Because of this, I'd side with the ones that hate it for some of these algos: the various sorts, for example. But for others, the use of mathematical symbols brings clarity, IMO. Assuming you already know the algo.
I've had to translate mathematical notation from a set of papers into code before. When I first picked up Julia, I re-did something I had previously done in Python/pandas/numpy. I used mathy notation... and julia code, ended up both MUCH clearer and quite a bit faster. I call that a win in my book.
you have described perfectly the problem that I have when reading n0code written by programmers who are not mathematicians... my mind wants to read variables with multiple letters as products of each letter.
I find multi-letter variable names extremely old fasioned, as when math was written explicitly in latin before the advent of algeraic notation.
> I find multi-letter variable names extremely old fasioned
Sometimes I read things here on Hacker News that throw me so hard I leave the site for a month or two. Congratulations, this time it's your fault. Goodbye.
One-letter variables have all approximately the same physical size; this makes the “tokenization” step of reading a formula faster.
They are also less descriptive, and this makes the semantic interpretation more difficult.
Usually mathematicians read entire papers, or large excerpts, at a time. In this situation the semantic association symbols<->concepts is often made at the beginning of each section and reused for several formulas, making mathematical notation more effective.
Programmers instead often look at code in smaller fragments. They don’t have thesame level of contextual information readily available and so they often prefer to embed this information in variable names.
Add that programs are written mostly in ASCII, on a keyboard, with autocomplete, in a single typeface, and math by hand, on paper or blackboard, with much more graphic possibilities.
One of the things I like about code is that it's usually very easy to read. There are problems with characters like 1 l I 0 O i j etc that are addressed by font choices. But even with those problems I find it much easier to read the ASCII letters than math notation with subscripts and superscripts, Greek letters and script letters, bold and doubled, and so on.
People might deny having the same problem, but I've seen it hundreds of times where a mistake is made because two symbols were conflated or a subscript was overlooked, or a symbol with multiple uses in different contexts was assumed to be one thing when really it was another. That said it's still neat to see code using common symbols with what you'd find in textbooks.
These variable names are hard to read for those who could actually learn from this, but known to those who are already familiar with the algorithms and have little more to learn about them. This is a common problem you run into when you start learning about a new area.
Exactly. Each of these algorithms’ beauty comes from understanding them. And reading the original paper is probably the best way to understand and appreciate them.
I guess this site is trying to sell Julia a bit, by showing how close it looks to mathematical pseudo-code.
“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with ¨the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.” — Grace Hopper
Hopper was making a bit of a different point - you need to tailor your communication to your audience.
In this case, if the developers involved are assumed to know the math already, concise is probably for the good. If you are trying to teach the algorithms to a mathematically unsophisticated audience, it's a different story.
If I'm describing the same concept to a) a group of undergrad students, b) a group of mathematicians and grad students c) a group of software developers or d) a room full of execs - I'm going to do it differently in each case, including notation and emphasis.
Yes, that was my point, or at least part of it: COBOL style isn't suitable for mathematical programming.
The other part is that it was never intended for programmers at all; it was for the ‘vice-president or a colonel or admiral’ who wanted the illusion of being able to understand their underlings' work. I think it's unfortunate that it took over general-purpose computing during the dot-com boom; prolixity engenders clarity about as much in code as in human language.
I disagree. Virtually no one who worked even a little with these algorithms has used math symbols in their code. For better or for worse it messes up people's pattern recognition.
No, it's not. Readability assumes that code is easy to read and easy to understand. This code is easy to read for those, who understood the algorithm already, but is hard to read for those who has no understanding.
It's the famous "write-only" problem of the Perl language, which uses symbols heavily too.
Code that mirrors a paper is the easiest to understand. Verbose, "descriptive" variable names just put more friction between you and the math. You are unlikely to reverse engineer the algorithm from the code unless you were already in a position to understand the terse mathy code to begin with. Just go read the danged paper.
Obviously, these code samples are meant only for aesthetic display, not for their pedagogical value. The criticisms being leveled by some here could be valid if their target had a different purpose. As it is, they miss the purpose and their mark.
Hm, looks like math formulas... You could use any programming language and use one letter UTF-8 variable names and try to fit everything in one line...
By the way, on the subject of single-character variables, is there a list somewhere of the single-letter math symbols that julia supports? (e.g. multiply, divide, sigma, etc)
The last one in particular - how do you read this in your mind if you don't already know the name of the character? - "Hmm, that's a curly handwritten A". It's so disruptive to the thought process of the reader of your code if they don't already know the notation.
I really think that this is the opposite of beautiful. Code is about communicating with other people too. I also think that mixing code and math notation is liked by a vocal minority of Julia users but in the long term is harming the adoption of the language by beginners.
It's all about matching the language of the literature in your domain. If you don't work in a domain that uses those conventions, you shouldn't use them. If you do, you and your colleagues should recognize it.
If you're branching out into other code, you can always ask Julia itself what a particular character is — just paste it into a help prompt at the REPL:
help?> 𝒜
"𝒜" can be typed by \scrA<tab>
julia> '𝒜'
'𝒜': Unicode U+1D49C (category Lu: Letter, uppercase)
Gradient descent is a pretty common algorithm, and I've seen it implemented in everything from JavaScript to c++. I have to say in this case the notation is significantly more distracting than helpful imo. Or to put it another way, the set of people working in the ml field, is both larger and more diverse than the set of people working purely in math. Everyone in the population of people who can both program and understand this type of notation would also be able to understand the less terse but more readable utf8 based text, the inverse is not true.
I think that means this code in particular is not catering to the lowest common denominator of people using the algorithm, but is instead aimed to be easy to use by those already fluent in the domain. It's important for both types of implementations to exist, and as you say, there's lots of other implementations available for those not familiar with the mathematical notation.
>is not catering to the lowest common denominator of people using the algorithm
I don't think an expert in some field who just happens not to be an expert in some other field's jargon and pictographs should be branded "a lowest common denominator of people", this terminology is both judgmental and elitist in all the bad ways.
Anyone who has even basic fluency with these algorithms has ~never worked with code that uses these symbols and will likely find them distracting in this context.
I've seen plenty of function use, say, `theta` but I have never worked with θ.
There's a reason we use 'y = mx + b' instead of 'range = slope * domain + intercept' when we're doing math calculations. It's nice to use the long form when we're learning what the symbols are, but the symbols enhance readability when you're doing math, once you've become familiar with the meaning of the terms.
I'd be tempted to challenge this assertion. It made sense when handwriting to maximize for not having to spend too much time writing, but with modern auto-complete, I might start to believe that it be clearer to use the long form for everyone, yes even for a person familiar with mathematics. If all math was rewritten long form, I feel it would honestly have second order effect on approachability and being able to understand papers even from other mathematicians.
It's also a matter of knowing your audience. All due respect: but this looks like code intended for people familiar with the relevant math, for whom such variables are very familiar.
Personally, those 'strange letters' make it more readable, because that's how the mathematics are written.
Though it's worth keeping in mind that the mathematics is usually accompanied by an article that at a minimum (tersely) tells you what the symbols are.
Bingo. And it goes vice-versa; because software engineering standards are so lax (read: non-existent) in most academic disciplines and domains, on the rare occasion where you get accompanying code to an academic work it may be impossible to actually much of the source to the original work itself.
During my dissertation I had to collect implementations of about a dozen parameterizations of a process I was studying, with the intent of coupling them/incorporating them into a set of climate modeling experiments. All of the implementations were in Fortran (which in and of itself wasn't a problem, albeit it was annoying re-writing or re-factoring some F77 code to play more nicely with the more modern Fortran codebase in which our climate model was written). Of these codes I collected, the majority of them had bugs which restricted my ability to reproduce the reported results from the original work they accompanied. One or two of them had significant flaws in them - answer-changing bugs which, when corrected, potentially would yield different results from those reported in their original papers, and might actually lead to different conclusions.
One of the nice things about the Jupyter ecosystem of tools and Julia is the ability to more closely replicate equations from the original paper. It seems dumb, but in my anecdotal experience I've noticed fewer significant bugs when colleagues have used these features. I've also noticed a propensity for scientists and researchers to write clearer, better-documented code - if your next line of code is going to directly mimic Equation 13 in your paper, why wouldn't you go ahead and write a comment saying so?
Do folks normally write code using the Greek alphabet? I totally understand reading/writing math papers in latex, or on paper using the traditional mathematical symbols, but does anyone really want to edit their Julia code in vim and type \scrA<tab> for a variable name? Seems extremely annoying and convoluted vs naming your variables alpha or sigma, etc.
Exactly, this is the thing people always seem to forget. When I write a paper with mathematical symbols like this, I always include a glossary for the reader. It's even required in some venues.
People like to pretend that mathematical notations are standardized and obvious to practitioners, but they're just not. In my physics undergrad days we made a joke shirt with all the usages of the symbol "k" as it appeared in our physics texts. Is it the constant in Coulomb’s law? Is it a spring constant? The Boltzman proportionality factor? Is it kinetic energy? Is it a kilo? A kelvin? I think we were able to cover the front and back of the shirt with the overloaded usages.
Yeah things can get a little wild sometimes with all possible interpretations. I'm pretty sure there are a few equations that use 'i' as both the imaginary unit and an index at the same time.
I've noticed physicists can be a bit fast and loose with their definitions, somehow you're assumed to be up to do date on what concept is given the symbol "R" in that particular context. Though they do tend to agree with each other which concept should have which symbol.
The Greek letters don't bother me so much as the ones where I am not quite sure if it's an ASCII x, v or w that is just being displayed with a different font, or a letter is not technically an ASCII x, v or w.
That's more of an artifact of the font being badly designed though.
Math requires excellent fonts if you don't want your reader to want to murder you by attempting to decipher the difference between L, calligraphic L, script L, italic L...
Math's fondness for using multiple fonts with semantic meaning is going to backfire when the next generation's math genius uses comic sans for the new math they invent.
If you're a practitioner and not much of a programmer, it might be faster and easier to read the "math notation" version, which will be familiar to you, than the version a programmer might write, which might be unfamiliar and might require your brain to scan everything "from scratch".
I also find the combination of Greek letters where they would be in mathematical notation without subscripts where they would be in the same notation has a bit of a uncanny valley effect.
I don’t think that Julia having the capacity to use this style is bad, but I don’t think these examples are “beautiful and concise”, more “baroque and tasteless”.
Note that there is an effort to fix this. A group of Julia developers have written a proposal to give Unicode proper subscript and superscript modifiers.
I think these practices make sense for math-oriented code.
In particular, I don’t understand the last objection. When you read math, do you need to describe the letters and symbols with English phrases in your head, like “Calligraphic L...right arrow with double staff...bold italic a with squiggle on top....”?
> When you read math, do you need to describe the letters and symbols with English phrases in your head..?
I don't need to only if I already know what they mean. How does your brain process a character that you can't pronounce and whose meaning you're trying to understand from the code you're currently reading? Because my brain will need to assign something to it in order to use it.
In mechanical engineering class, there was squiggly, and double squiggly. I don't remember which Greek letters those correspond to, but it's easy enough.
Its not like anyone could draw them properly by hand either
Exactly. Making it harder to read, write and understand on purpose, unless you're a part of a specific small exclusive club. There's absolutely no reason.
No. There's a reason: it communicates extra information very cheaply and in-band with the code for people who are intimately familiar with the mathematics involved. This can be better than comments or documentation in some situations (and also doesn't preclude also having those).
It's becoming a pet peeve of mine how HN conflates a solid, classical mathematical education with some kind of gatekeeping club. Anyone is welcome to join. Anyone is welcome not to use this language if they wish. But please don't dictate how us mathematicians are supposed to communicate.
Yes, I agree completely. It communicates information very cheaply and in-band to very few people who are intimately familiar with the mathematics involved. And nobody else.
Calling this mathematical education makes me doubt your implicit claim of pedagogical ability.
I think a lot of math could be taught with a lot less overhead and in more understandable fashion. It's just that the natural incentives seem to drive people to unnecessary overhead and barriers for those who actually want to learn.
Lot of the language and symbols involved could be streamlined. But like QWERTY keyboard and C++, you would first have to turn this huge hulking ship of legacy cruft into that direction.
> I think a lot of math could be taught with a lot less overhead and in more understandable fashion. It's just that the natural incentives seem to drive people to unnecessary overhead and barriers for those who actually want to learn.
Ok. Have at it, I guess.
> Lot of the language and symbols involved could be streamlined. But like QWERTY keyboard and C++, you would first have to turn this huge hulking ship of legacy cruft into that direction.
This screams a fundamental misunderstanding of mathematics. The symbols need context to make any sense whatsoever. To a reader with intimate knowledge of the context, the symbols convey lots of information very efficiently. That doesn't mean that the symbols are understandable without context, or even that they could be made understandable without context.
For example, using greek instead of latin letters is completely unnecessary. Just to point out completely meaningless overhead.
Using in-group context-sensitive symbols is by definition exclusive. Using descriptive well thought out names is inclusive.
Math as a language seems very needlessly compressed. Imagine a world where programmers invented a new symbol for every function and you would have to look up what they mean, but when you look up what they mean, you would have to look up 10 other symbols. Most of those symbols refer back to symbols where you came from in the first place. It's a detriment for learning. Simple as that.
Not everybody wants to be a mathematician. Some people just want to get work done and read through a bunch of research papers.
> For example, using greek instead of latin letters is completely unnecessary. Just to point out completely meaningless overhead.
Are you saying the whole field of mathematics (and physics) is wrong, and we're doing something "meaningless"?
> Using in-group context-sensitive symbols is by definition exclusive. Using descriptive well thought out names is inclusive.
Not when the group is open to anyone who wants to join. Math is probably the most "open source" field out there. Barring the very cutting edge front of research, everything can be learned from free sources or ones that can be borrowed for free from libraries, or had through very very cheap second hand material.
That there is a high barrier to entry when it comes to effort isn't some malicious gatekeeping design. It's just because some things are hard.
> Math as a language seems very needlessly compressed. Imagine a world where programmers invented a new symbol for every function and you would have to look up what they mean, but when you look up what they mean, you would have to look up 10 other symbols.
You clearly have never done math! The way it works requires intimate familiarity with the definitions of the symbols. Once you actually manage to internalize that (it can be a lot of work), remembering what the symbols stand for comes for free.
> Not everybody wants to be a mathematician. Some people just want to get work done and read through a bunch of research papers.
"Not everyone wants to be a surgeon, some people just wanna read medical research papers."
"Not everyone wants to be an astrophysicist, some people just wanna read astrophysics papers."
Do you not see how ridiculous this is? Nobody is gatekeeping for the sake of gatekeeping. You're conflating gatekeeping with something just being hard, and the practitioners of the hard thing not wanting to change the way we work to accommodate non-practitioners (to our own detriment!)
Symbols and math are two completely different things. Symbols are just something you attach concepts and ideas to. I believe that with words and labels instead of obscure symbols and surnames of mathematicians, teaching math could be more efficient. Even with set theory being a branch of mathematics, categorizing things seems to be very shooting from the hip.
All I'm seeking here is how to improve communicating math without having to go through the credentialism of higher education.
edit: Why you didn't understand my comment on reading papers: some computer science papers require heavy math background. A lot of math is actually applied math.
> All I'm seeking here is how to improve communicating math without having to go through the credentialism of higher education.
Like I've already pointed out: mathematics is perhaps the most "open source" field there is. There's no need to go through the "credentialism" if you don't want to. Again you're just conflating math being hard with it being protected by some imagined wall of credentialism guarded by gatekeepers.
It's not about math notation on its own or about mathematical education. I'm very comfortable with mathematical notation in textbooks and papers and I still think that using it in code is a mistake.
> it communicates extra information very cheaply and in-band with the code for people who are intimately familiar with the mathematics involved.
I think it's just the opposite. People familiar with the relevant math have, most likely, worked with this stuff in other programming languages and never used math symbols in their code.
I'm used to seeing θ or α in text and theta or alpha in code. The combination of Greek letters and for loops looks very weird.
Your assumption is wrong. Lots of really useful math has 0 or 1 implementations. A Julia one may well be first. (Saying this as someone who's done several first implementations, but haven't coded a single line of Julia)
Why should we cater to the lowest common denominator? If we did it your way, we increase friction for the people most likely to use, read and edit this code. Just like the written word, code has a target audience. If you want to call that gatekeeping or some other putative pejorative, find by me.
> Why should we cater to the lowest common denominator?
The options aren't just complete beginner vs math PhD though. Imagine an experienced software developer who has written these kinds of algorithms in other languages and has never used latex. That's the kind of person you're also keeping out. Are they "the lowest common denominator"?
I also don't know why you assumed that the people who are most likely to use this code like this are automatically people who already know the glyphs.
It's gatekeeping not just because there is barrier to entry. It's because that barrier is artificial, unnecessary and comes with a smug feeling of superiority (you aren't the first person to use "lowest common denominator" in this thread).
Frankly, if you don't know the glyphs, you almost certainly have no business using the code. Basic notation is table stakes. I learned this stuff (yes, the latex) as an undergrad, and I wasn't even a math major.
It's fine if it's only for hard core mathematicians. Use a disclaimer front and center next time: NOT MEANT FOR MUGGLES.
(Seriously talking: From an educational point of view, lowest common deminator is exactly what you want, as long as you can communicate the entire concept effectively)
Well, now I can at least understand what it feels like to look at Lisp and hate all the parentheses, so I'm trying to temper my immediate repulsion a little. But no, absolutely not. I would code a pre-commit hook to reject these on the first attempt, and send you your P45 on the second, sorry.
I understand your frustration looking at symbols which may not be straightforward without a certain background or a glossary of terms. However, do you realize anyone outside the UK similarly likely would need to look up what a P45 form is? It's like a USian saying "pink slip" rather than any Anglophone just saying "termination papers". We all like our own shorthand symbols and tend toward discomfort when we're the out group.
That comment was obvious hyperbole on an internet message board, not production code, and even then it's a terrible analogy because I actually typed it, I didn't use some inscrutable emoji that you then had to cut and paste. Also the idea that "people in the know" write code like this is absurd - I've worked with mathematicians for more than a decade in languages that support unicode names, and it would never occur to any of them to do idiotic stuff like this. This is terrible practice and always will be.
I understand your opinion and I won't argue with the merits. I can say, though, that your experience and point of view inform your opinion and may not be universal. I can imagine the APL folks who look at Julia would be fine with it.
For instance, for some of the regression algorithms the pseudo-inverse of the matrix is used to solve the normal equations. Again, for small, well-behaved problems it is OK, but for larger scale, less well-behaved problems, it is actually dangerous (numerical instabilities and other issues). There are better, faster, more stable approaches. (PhD in Applied Math here)
BTW, I have been using Julia for work for several years now and I think it is a fantastic language for scientific computing. For those who use Matlab/Numpy regularly, you should definitely check it out.