Greek letters, subscripts, and superscripts in the editor

Why in the world is matlab's editor not capable of dealing with greek letters, subscripts and superscripts? I cannot possibly be the only one who would rather see the greek letter for pi instead of the word. Really, though, it would just be nice if my equations in the editor could more closely resemble the real thing..

c'mon... physics, engineering, math... everyone uses greek letters and subscripts/superscripts! Why can't matlab's editor?

[David Sherwood]

I agree. I would like to use Greek letters/symbols in comments, '% ...'. They can be pasted in fine and printed out fine but the editor does not save them! When you go back to your script after closing/saving it, the Greek letter/symbols appear as '?'. Is there a way around this other than "publishing" or LaTEX?

Answer 1

[Sean de Wolski]

Sure you can, you just have to use LaTeX. See the example in:

doc

Matlab>User Guide>Desktop Tools>Publishing M-Files>Formatting Mfile Comments:

• Including Inline LaTeX Math Symbols in M-Files for Publishing
• Including Blocks of LaTeX Math Symbols in M-Files for Publishing

[Clint Johnson]

yeah, that's not the same, though. I'm not talking about preparing one for publication. I'm talking about using Φ as a variable instead of phi while I'm coding. Matlab has about 60 or so basically unused ASCII characters... why on earth are these not used for at least a few of the greek letters? I can think of no good excuse for Mathworks in 2011 not to have the ability to at least use greek letters in the m-file editor window.

[Sean de Wolski]

So you want to be able to name a variable phi? I (and many others) don't see any advantage to that over a well named English word as a variable. If you want to be able to do it, use MathCAD - it's designed for that purpose.

[Walter Roberson]

The printable US-ASCII characters that MATLAB does not use as operators or punctuation are:

" (34)

# (35)

$ (36) -- pound sign in UK-ASCII

_ (95) -- valid in identifiers except as first character

` (96)

That is a maximum count of 5, which is not even close to "60 or so".

The MATLAB "name space of identifiers" is identical to the C "name space of identifiers", with the exception that C allows variable names to begin with underscore. Thus, every MATLAB identifier name may be used unchanged in C (unless it happens to match a C keyword), and MATLAB is given a bit of freedom to generate identifiers for use in communicating with C without worrying about accidentally conflicting with a user identifier.

MATLAB is currently defined in such a way that only characters in strings or comments can be outside of the US-ASCII character set. It is not unreasonable in the modern era to call for it to allow other languages, but however that was done would require encoding the characters so that if the program were taken to a system with a different character set, that the program would continue to run unchanged (just perhaps a bit uglier to read.) This includes the requirement that a full multilingual program must run (and be editable) in plain text, and that the encodings must be compatible with C/C++ . And _ideally_, the encoding of a character outside the US_ASCII range should have a readable name, such as _Phi__alpha_B3 (e.g., underscore before and after each entity name.) Now comes a question: should _Phi__alpha_B3 be considered an identifier of length 16, or should it be considered an identifier of length 4, for the purposes of the 63 character identifier limit (63 is the length of identifier that POSIX promises will be recognized for external linkage, so it is not just an arbitrary number chosen by TMW.)

[Clint Johnson]

yes, this is probably a good solution that is in keeping with their desire to keep the code usable in the same ways. I personally just want the display to be more readable.

So no, Sean, I think your contention that there's no advantage to just using an english word is ridiculous. If that was true, then physics textbooks would just write out all of their equations in english instead of using greek letters, subscripts and superscripts and so on. I mean, come on. It's obviously more readable and a lot more intuitive for those of us who are used to looking at equations that look like equations. It's high time matlab got out of the 1980s with the variable names.

as for the 64-character limit, I could care less what kind of autocoding mess it has to translate the variable names into. As far as I'm concerned, the variable names could be encoded like a compiler does when translating from C. For the overwhelming majority of Matlab users that only use the Matlab editor for creating and running their programs, allowing more intelligently named variables would be a significant advantage.

And yes, of course, I would love to use MathCAD if I could. Matlab's scripting advantages are not all there and the existing work my company has in Matlab could not be ported, though.

If you type in the Alt-### values in the matlab editor, pretty much every character beyond alt-170 is not used (so far as I can tell - it's really irrelevant, I just thought that was the most obvious place to put in a few greek letters)

[Walter Roberson]

Clint, you specifically talked about unused ASCII characters, but ASCII only uses the range 0 to 127. Characters such as alt-170 are not ASCII characters.

ASCII is a standard. Character encodings these days are standards, and characters cannot simply be inserted in to convenient places without a lot of compatibility trouble. In modern standards, the basic Greek characters run from position 880 to 1023. However, equations in math and physics are not actually written with Greek: they are written with glyphs that are derived from Greek. For example, in formula, the Greek-like glyphs are usually in italics, and that is considered separate symbols from the corresponding Greek characters. Then there are issues about how to deal with hats and dots and so on. The micro symbol appears multiple times in the standards depending on context.

I suggest you review http://unicode.org/reports/tr25/tr25-8.html

Quite a bit of my MATLAB work is from the command line, often with graphics (and the MATLAB editor) not available. The difficulty of entering characters *does* matter to me.

Maple deals with the problem by allowing HTML-like named characters that are rendered symbolically if you are using one of the Maple GUIs, but which are stored internally as ASCII and so can be worked with in plain text.

[Clint Johnson]

sorry, but that's just totally irrelevant. I don't know or care about the details of ASCII... I only suggested that because it seemed like low-hanging fruit. And if you don't like my example from physics, fine. How about the Radar range equation? If I write out all the subscripts and whatnot, it takes up an entire line of text. If I could use subscripts, it would be a lot easier to read. And geometry certainly does use greek characters. Again, this is all completely irrelevant. The fact is, there is no defensible reason for there not to at least be an option of using a more natural format for variable names in Matlab. Convert an underscore to a subscript and a ^ to a superscript... I don't know. Really, is it that inconceivably hard to do this? Part of the reason non-computer science people don't like coding is because you have to learn to deal with this kind of nonsense. Make it more natural to use and more people will use it with greater ease.

Everyone knows that this will eventually be fixed. It's not as though x squared will always look like x^2... that's just stupid. Seriously.

[Walter Roberson]

Sure, some programs (I mentioned Maple already) allow "2D notation" in entering equations. It is often a PITA to actually use or understand.

For example, in that input mode, Maple does translate underscore in to subscripts. Which is a nuisance if you have underscores in your variable names that do _not_ indicate subscripts. And when you see x with the subscript 1, does that indicate index 1 in to the vector x, or does it indicate the variable whose name is x subscript 1 ?

Or try something simple like x^2+1 . The ^ triggers superscript mode, so your cursor rises above the x, you type in the 2, you type in the +1 ... and you notice that you now have what is logically equivalent to x^(2+1) because the 2D math entry mode doesn't know that you finished entering the superscript. So after the 2, you have to press some key combination to indicate the end of superscript mode, and then the program tries to guess about where you want to be next ... usually getting it wrong, so a lot of the time you end up having to click to get where you want. And then you probably have to click again a few times because it highlighted an entire term instead of understanding that you are trying to position after the term...

So then you want to enter 1/2/3 (i.e., ((1/2)/3) . But the program helpfully went in to divisor mode when you typed the first / and so you end up with the equivalent of (1/(2/3))... and so on.

And Pi? You better pull it out of a character-table menu, since there are at least 6 different _kinds_ of Pi that are used as mathematical symbols with different meanings.

With regards to your claim that "And geometry certainly does use greek characters." -- did you read down to the "Semantic Distinctions" paragraph of section 2.2 of the technical report I referenced? As far as mathematics papers are concerned, a sans-serif bold italic "alpha" is *not* the same symbol as a Greek alpha.

The international standards encode characters. Characters are entities that retain their identity no matter how they are drawn. For example, an italic "k" in the Helvetica font is the same _character_ as a bold "k" is the Century New Schoolbook font, even though they look different. Mathematics and physics, though, impart meaning to the different looks of the symbols. When the meaning of a symbol depends on the way it looks, then one is not referring to characters: one is referring to glyphs. See http://en.wikipedia.org/wiki/Glyph for an example of 9 different glyphs associated with the lowercase character "a". Mathematics and physics (including geometry) prescribe different meanings to the different glyphs.

"No defensible reason" -- you would be surprised how much work it is to get the representations you propose to work properly. The effort is measured in person-decades. As you do not know or care about the details of ASCII, it seems fairly likely that you have not completed any of the "double-bend" exercises in Knuth's manuals on TeX and thus do not know how complicated some of the practical aspects get.