I recently tried to implement a ranking algorithm, AllegSkill, to Python 3.

Here's what the maths looks like:

alt text

No, really.

This is then what I wrote:

t = (µw-µl)/c  # those are used in
e = ε/c        # multiple places.
σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

I actually thought it is unfortunate of Python 3 to not accept or ² as variable names.

>>> √ = lambda x: x**.5
  File "<stdin>", line 1
    √ = lambda x: x**.5
SyntaxError: invalid character in identifier

Am I out of my mind? Should I have resorted for a ASCII only version? Why? Wouldn't an ASCII only version of the above be harder to validate for equivalence with the formulas?

Mind you, I understand some Unicode glyphs look very much like each other and some like ▄ (or is that ▗▖ ) or ╦ just can't make any sense in written code. However, this is hardly the case for Maths or arrow glyphs.

Per request, the ASCII only version would be something along the lines of:

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2

...per each step of the algorithm.

  • 60
    That's insane, completely unreadable and unspeakably cool. – Dominique McDonnell Nov 1 '10 at 10:54
  • 2
    Talking about unicode... codinghorror.com/blog/2008/03/i-entity-unicode.html – CoderHawk Nov 1 '10 at 11:03
  • 3
    I find it a very good thing that Python doesn't accept arithmetic operations as variables. A square root sign should denote the operation of taking a square root, and should not be a variable. – David Thornley Nov 1 '10 at 21:31
  • 4
    @David, there's no such distinction in Python. Indeed, sqrt = lambda x: x**.5 gets me a function (more precisely, a callable): sqrt(2) => 1.41421356237. – badp Nov 1 '10 at 21:34
  • 4
    OutputStream.🚽; – user40980 Aug 7 '14 at 17:02

15 Answers 15


I feel strongly that just replacing σ with s or sigma doesn’t make sense and is counter-productive.

What’s the potential gain? Well, let’s see …

  • Does it improve readability? Nope, not in the slightest. If that were so, the original formula would have undoubtedly used Latin letters also.

  • Does it improve writability? On the first glance, yes. But on the second, no. Because this formula is never going to change (well, “never”). There will normally be no need to change the code, nor to extend it using these variables. So writability is – just this once – not an issue.

Personally, I think programming languages have one advantage over mathematical formulae: you can use meaningful, expressive identifiers. In mathematics, this isn’t normally the case, so we resort to one-letter variables, occasionally making them Greek.

But Greek isn’t the problem. The non-descriptive, one-letter identifiers are.

So either keep the original notation … after all, if the programming language does support Unicode in identifiers, so there’s no technical barrier. Or use meaningful identifiers. Don’t just replace Greek glyphs with Latin glyphs. Or Arabic ones, or Hindi ones.

  • 3
    Some tools cannot read unicode characters, even though the programming language supports their use. I would not call it a brain-dead decision to use non-unicode variable names, and this still holds true 2.5 years after your post. – Gary S. Weaver May 10 '13 at 18:47
  • 49
    @Gary “Some tools cannot read Unicode” – so change the tools, they’re crap. Sorry, it’s 2013 and I have zero sympathy and even less patience for such tools. Incessantly catering to defective tools prevents progress. – Konrad Rudolph May 11 '13 at 14:54
  • 3
    @KonradRudolph My point is that some tools do not and cannot support Unicode for whatever reason, so "change the tools" is not always the right answer. I agree that Unicode is good and tools should understand it, but that is not always an option. – user22815 Mar 4 '14 at 16:11
  • 3
    @John I maintain that “change the tools” is an appropriate answer. Your example in particular illustrates such a case: Java .properties files are trivial to parse. If you really happened to work with a tool chain which, backed by .properties files, didn’t support Unicode, it’s entirely reasonable to drop said tool chain (and either replace it yourself, find an alternative, or, in the worst case, commission one). Of course this doesn’t apply to legacy systems. But for legacy systems none of the considerations for best practices ever apply. – Konrad Rudolph Mar 4 '14 at 16:16
  • 9
    These "interchange" problems you speak of seem to be primarily the problem of Java and Windows developers. Most of the Linux world standardized on UTF-8 over a decade ago. It's definitely a toolchain problem. Stop using bad tools. – rich remer Jun 15 '14 at 3:30

Personally, I would hate to see code where I have to bring up the character map to type it again. Even though the unicode closely matches what's in the algorithm, it's really hurting readbility and ability to edit. Some editors might not even have a font that supports that character.

What about an alternative and just have up top //µ = u and write everything in ascii?

  • 15
    By the way, don't assume all keyboards expose standard coding keys comfortably. My keyboard layout needs three keys to type { and } (which fails in ttys btw) and completely lack ` and ~... how wouldn't any Bash script not require me to use a character map, if I wasn't using a custom keymap? :) – badp Nov 1 '10 at 11:31
  • 4
    I installed a greek keyboard alongside my native one, and can switch between those with a one keystroke. This is useful when talking about math on IM/email... and I already thought of using it in python scripts. – liori Nov 1 '10 at 12:20
  • 19
    Ugh. Just replacing the greek letters by plain ones? No gain whatsoever. Use meaningful variable names, or stick with the names from the paper. No reason to get creative. – Konrad Rudolph Nov 1 '10 at 16:46
  • 12
    Just don't mix up µ and μ... – endolith May 26 '11 at 21:38
  • 4
    Reasonable editors have reasonable input methods for Unicode which make it easy to edit code like this. For example, Emacs supports (among other things) the TeX and rfc1345. TeX is just what it sounds like; it lets you type \sigma for σ and \to for . rfc1345 gives you some combinations like &s* for σ and &-> for . As a rule of thumb, I do not worry about accommodating programmers using editors less capable than Emacs. – Tikhon Jelvis Dec 3 '12 at 6:33

This argument assumes you have no problem with typing unicodes nor reading greek letters

Here's the argument: would you like pi or circular_ratio?

In this case, I'd prefer pi to circular_ratio because I've learned about pi since I was in grade school and I can expect the definition of pi is well ingrained to every programmers worth his salt. Therefore I wouldn't mind typing π to mean circular_ratio.

However, what about

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2


σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

To me, both versions are equally opaque, just like pi or π is, except I didn't learn this formula in grade school. winner_sigma and Wwin means nothing to me, or to anyone else reading the code, and using neither σw doesn't make it any better.

So, using descriptive names, e.g. total_score, winning_ratio, etc would increase readability much better than using ascii names that merely pronounce greek letters. The problem isn't that I can't read greek letters, but I can't associate the characters (greek or not) with a "meaning" of the variable.

You certainly understood the problem yourself when you commented: You should have seen the paper. It's just eight pages.... The problem is if you base your variable naming on a paper, which chooses single-letter names for conciseness rather than readability (irrespective whether they're greek), then people would have to read the paper to be able to associate the letters with a "meaning"; this means you're putting an artificial barrier for people to be able to understand your code, and that's always a bad thing.

Even when you live in an ASCII-only world, both a * b / 2 and alpha * beta / 2 are an equally opaque rendering of height * base / 2, the triangle area formula. The unreadability of using single-letter variables grows exponentially as the formula grows in complexity, and the AllegSkill formula is certainly not a trivial formula.

Single letters variable is only acceptable as a simple loop counter, whether they are greek single-letters or ascii single-letter, I don't care; no other variables should consist solely of a single letter. I don't care if you use greek letters for your names, but when you do use them, make sure I can associate those names with a "meaning" without needing to read an arbitrary paper somewhere else.

When in grade school, I definitely wouldn't mind seeing mathematical expressions using symbols such as: +, -, ×, ÷, for basic arithmetics and √() would be a square-root function. After I graduated grade school, I wouldn't mind the addition of a shiny new symbols: ∫ for integration. Note the trend, these are all operators. Operators are much more heavily used than variable names, but they are less often reused for an entirely different meaning (in the case where mathematicians reuse operators, the new meaning often still holds some basic properties of the old meaning; this is not the case for when reusing variable names).

In conclusion, no, it's not bad to use Unicode characters for variable names; however, it's always bad to use single letter names for variable names, and being allowed to use Unicode names is not a license to use single letter variable names.

  • 10
    To be honest, the formulas here do not make more sense even if I were to use error_on_measured_skill_with_99th_percent_confidence instead of sigma. – badp Nov 1 '10 at 15:33
  • 4
    @badp: Long names != Good names. Nevertheless, there are occasions where it is impossible for you to choose a good name (e.g. when you only understand the formula, but don't fully comprehend what each parts of the formula do (which takes a wholly different level of comprehension)), then in that case, the second best alternative is to cover up your ass with some comments (better than sending them off to an external paper). Add a data dictionary that explains what the variable names refers to, e.g. // σw = skill level measurement error, etc – Lie Ryan Nov 1 '10 at 15:40
  • 1
    @badp: To be honest, with just that information, that sigma refers to some fudge factor (so to speak), it gives me slightly better understanding of the formula than what sigma strikes me. When the formula is hard to understand to begin with, you don't want to add more opaqueness on top of it. – Lie Ryan Nov 1 '10 at 16:36
  • 2
    Yes. This. Unfortunately, I overlooked it when writing my answer. – Konrad Rudolph Nov 1 '10 at 16:54
  • 3
    Well, anyone working in anything related to statistics knows that σ means "standard deviation". It's a very well known standard symbol in that domain. – TRiG Nov 21 '12 at 0:58

Do you understand the code? Does everyone else who needs to read it? If so, there's no problem.

Personally I'd be glad to see the back of ASCII-only source code.

  • Done. (I assume the last line was you asking to see the ASCII-only version of the code?) [ ](http://~) – badp Nov 1 '10 at 11:24
  • 4
    @badp: No, it was me asking to see the death of ASCII-only code. – user4051 Nov 1 '10 at 11:43
  • until you begin to see what happens to Unicode source files when landing on a Windows 1252 system... – user1249 Nov 1 '10 at 11:46
  • 1
    @Thorbjørn: if they contain the BOM, then hopefully nothing will happen. – user4051 Nov 1 '10 at 14:04

Yes, you are out of your mind. I would personally reference the paper and formula number in a comment, and write everything in straight ASCII. Then, anyone interested would be able to correlate the code and the formula.

  • 5
    It was difficult for me to make sure the code and the formula matched in the first place... – badp Nov 1 '10 at 15:17
  • 10
    @Paul: luckily, Unicode is > 10 years old so that objection’s been taken care of. And although there’s no clear winner between the different UTFs, that’s not an issue: there wasn’t supposed to be one. Telling them apart is trivial for software. – Konrad Rudolph Nov 1 '10 at 17:00
  • 1
    @Konrad: I mean 10 years from now. A fair number of programs still don't support Unicode. Further, I disagree with your assertion - It is not trivial to write a generic reverse routine that handles all 3 utfs. There needs to be a clear winner. There's no sense in supporting 3 different UTFs (let us not consider the other code pages still extant). – Paul Nathan Nov 1 '10 at 22:57
  • 3
    @Paul: How often do you need to write a "generic reverse routine"? The three UTFs serve different purposes, and I don't think you're ever going to get your wish of consolidation. – Dean Harding Nov 1 '10 at 23:23
  • 7
    @Paul: screw these programs. There are enough good editors that know how to handle Unicode. If some editor still hasn’t got on the bandwagon, let economic selection take care of it. And as Dean said, the UTFs serve different purposes. It’s a good thing that they exist. And I don’t see the point in your multiple reverse routines. You only need to write it once (ignoring normalization forms for now): for code points, not for individual UTFs. – Konrad Rudolph Nov 2 '10 at 7:43

I would say using Unicode variable names is a bad idea for two reasons:

  1. They're a PITA to type.

  2. They often look almost the same as English letters. This is the same reason why I hate seeing Greek letters in math notation. Try telling rho apart from p. It's not easy.

  • 6
    Depends what you're using to type them. – endolith May 26 '11 at 21:42

In this one case, a complex maths formula, I'd say go for it.

I can say in 20 years I've never had to code something this complex and greek letters keeps it close to the original maths. If you can't understand it, you shouldn't be maintaining it.

Saying that, if I ever have to maintain µ and σ in bog standard code that you bequeathed me, I will find out where you live...

  • Pro: it looks nice
  • Con: the unicode characters and so the whole meaning might get lost in the tool chain (editor, code formatter, version control, older compiler)

How big is the risk for you? Does the gain outweigh the risk?

  • 2
    Tool chain? What tool chain? – badp Nov 1 '10 at 11:36
  • 2
    Editor, code formatter, version control, older compiler. Every tool and person touching your file. I've had bad experience with tools messing up with unicode files, YMMV. – LennyProgrammers Nov 1 '10 at 12:04

Sometime in the not too distant future, we'll all be using text editors / IDEs / web browsers that make it easy to write edit text including Classical Greek characters, etc. (Or maybe we'll all have learned to use this "hidden" functionality in the tools we currently use ...)

But until that happens, non ASCII characters in program source code would be hard for many programmers to handle, and are therefore a bad idea if you are writing applications that might need to be maintained by someone else.

(Incidentally the reason you can have Greek characters but not square root signs in Python identifiers is simple. The Greek characters are classified as Unicode Letters, but the square root sign is a non-letter; see http://www.python.org/dev/peps/pep-3131/ )

  • I think that it would be a great idea to make an IME which could translate characters for users who can't directly input them. – AndrejaKo Nov 1 '10 at 15:15
  • Yeah, more or less when we'll have switched to DVORAK. :( – badp Nov 1 '10 at 15:35
  • 1
    @AndrejaKo Linux does have a IME that accepts LaTeX style commands -- that is, you type \mu and it insterts µ. – badp Nov 1 '10 at 15:36
  • @badp Thanks a lot! I'll try that next time I boot! – AndrejaKo Nov 1 '10 at 15:40
  • Emacs supports a bunch of nice input methods that make typing Unicode symbols easy. (Including a TeX one which is what I use.) Emacs is hardly futuristic. (It is awesome, of course.) – Tikhon Jelvis Dec 3 '12 at 6:53

You didn't say what language/compiler you are using, but usually the rule for variable names is that they must start with an alphabetic character or underscore, and contain only alphanumerics and underscores. A Unicode √ would not be considered alphanumeric, since it is a mathematical symbol instead of a letter. However σ might be (since it is in the Greek alphabet) and á would probably be considered alphanumeric.


personally I am motivated to consider programming languages as a tool for mathematicians in this context, as I don't actually use math that looks anything like that in my life. :D And sure, why not use ɛ or σ or whatever — in that context, it is actually more legible.

(Although, I have to say, my preference would be to support superscript numbers as direct method calls, not variable names. eg 2² = 2 ** 2 = 4, etc.)


I posted the same kind of question on StackOverflow

I definitely think that it worth using unicode in heavy math-related problems, because it makes it possible to read the formula directly, which is impossible with plain ASCII.

Imagine a debugging session: of course you can always hand-write the formula the code is supposed to compute to see if its correct. But ninety percent of the time, you won't bother and the bug can stay hidden for a long, looong time. And no one is ever willing to look at this abstruse 7-line, plain ASCII formula. Of course, using unicode isn't as good as a tex-rendered formula, but it is way better.

The alternative of using long descriptive names is not viable because in math, if the identifier is not short, the formula will look even more complicated (why do you think people, around the XVIII century, began to replace "plus" by "+" and "minus" by "-" ?).

Personnally, I would also use some subscripts and superscripts (I just copy-paste them from this page). For instance: (had python allowed √ as an identifier)

√ = math.sqrt #function alias
c² = c**2
σʷ² = σʷ**2
γ² = γ**2
σ′ʷ = √(σʷ² * (1 - (σʷ²/c²)*Wʷⁱⁿ(t, e)) + γ²)

Where I used superscripts because there is no subscript equivalent in unicode. (Unfortunately, the unicode subscript character set is very limited. I hope that one day, subscripting in unicode will be considered as diacritics, i.e. a combination of one char for subscript, and another char for the subscripted letter)

One last thing, I think this conversation about using non-ASCII character is primarily biased, because many programmers never deal with "formula intensive mathematical notations". So they think that this question is not that important, because they never experienced a significant portion of code that would require the use of non-ASCII identifiers. If you are one of them (and I was until recently), consider this: suppose that the letter "a" is not part of ASCII. Then you will have a pretty good idea of the problem of having none of greek letters, subscripts, superscripts when computing non-trivial math formulas.


Is this code just for your personal project? If so, go nuts, use whatever you want.

Is this code meant for others to use? i.e., and open source app of some sort? If so, you're likely just asking for trouble because different programmers use different editors, and you cant be certain all editors will support unicode correctly. Plus not all command shells will show it correctly when the source code file is type'd/cat'd, and you may run into issues if you need to display it within html.


What the hell is σ, what is W, what is ε, c and what is γ?
You are to name your variables in a way that explains what their purpose is.
I'd personally beat up anyone who'd leave the Unicode or the ASCII-version for me to maintain, although the ASCII-version is better.

What is evil is calling variables σ or s or sigma or value or var1, because this doesn't convey any information.

Assuming you write your code in English (as I believe you should wherever you are from), ASCII should suffice to give your variables meaningful names, so there is no actual need for Unicode.

  • 2
    what if he did a copy/paste of the paper and then made it part of his source code as a comment despite the one character variable names? – Brian Nov 1 '10 at 13:25
  • 20
    A lot of these variable names have strong meanings to those familiar with the problem domain. To someone familiar with the domain, English names might be less readable than names like sigma or rho. – dsimcha Nov 1 '10 at 13:50
  • 3
    I'm afraid something like rank_error_with_99_pct_confidence is a bit too long for this and wouldn't actually make the formulas any easier to understand. AllegSkill/TrueSkill call those sigma, so I believe it's perfectly acceptable of me to maintain the domain specific name they have. – badp Nov 1 '10 at 15:37
  • 3
    @badp: good names is concise and descriptive; but it does not have to be fully descriptive. For your sigma, it is perfectly good to use rank_error and put the extra detail about 99-percent confidence in the documentation/comment somewhere. – Lie Ryan Nov 1 '10 at 17:05
  • 1
    @dsimcha: I think those familiar with a particular domain are significantly rarer than those, who never heard of it. And I think those familiar with the domain will be able to cope with plain english names, whereas those not familiar with it will be completely unable to understand what's happening if everything is obfuscated by greek one-letter-variables. – back2dos Nov 1 '10 at 17:35

For variable names with well-known mathematical origins this is absolutely acceptable - even preferred. But if you ever expect to distribute the code, you should place these values in a module, class, etc. so that IDE auto-complete can handle "typing" the strange characters.

Using √ or ² in an identifier - not so much.

Not the answer you're looking for? Browse other questions tagged or ask your own question.