Dangerous symbol names that begin with a lowercase letter

Question

I am looking for a full list of dangerous symbol names that begin with a lowercase letter in Mathematica.

At this moment I know three such names: min, max and lim. These names appear in the LimitsPositioningTokens list and are being treated as operators at least when they are entered in the FrontEnd with a superscript:

In[3]:= Options[$FrontEnd,LimitsPositioningTokens]
Out[3]= {LimitsPositioningTokens->{\[Sum],\[Product],\[Intersection],
         \[Union],\[UnionPlus],\[Wedge],\[Vee],lim,max,min,\[CirclePlus],
         \[CircleMinus],\[CircleTimes],\[CircleDot]}}

For example, type in the FrontEnd the following (use Ctrl+^ for making superscript - it is important!):

In[1]:= max^n+4
(max^n+4)//HoldComplete//FullForm
Out[1]= 4 max^n
Out[2]//FullForm= HoldComplete[Times[Power[max,n],Plus[4]]] 

You see that max^n+4 is interpreted as 4*max^n in this case.

Can anyone explain what LimitsPositioningTokens option really does?

Are there other dangerous symbols that begin with a lowercase letter in Mathematica?

Oversew

To be sure I was seeing it accurately, I ran FullForm[max^n + 4] (where the superscript ^ was generated as above) and I got Times[4, Power[max,n]]. It seems like the worst sort of bug. – Hominoid

@Hominoid Alexey Perhaps you should post $Version and $System as it seems to be version/system related. Both on a pc and mac running M8 I couldn't confirm this bug (see below). – Flunkey

$Version = 7.0 for Mac OS X x86 (64-bit) (February 19, 2009) and $System = Mac OS X x86 (64-bit). – Hominoid

@Sjoerd I have checked this on versions 7.0.1 and 5.2 for Windows. In both cases the problem persists. – Oversew

Well, it looks like it has been solved in 8.0.1 then. – Flunkey

Answer 1

I cannot confirm the problem you report. Besides, the tokens you've found seem to be strings rather than symbols.

This is on win7-64/M8.0.1, my wife's mac lion/M8 doesn't show it either.

The fact that they are strings seems to be consistent with the description on the doc page of LimitsPositioning

LimitsPositioningTokens is a Cell option which can be set to a list of forms for which LimitsPositioning->True should be used.

All examples given there use strings.

---

Update to illustrate the point made in the comments below

This is with the standard LimitsPositioningTokens setting in $FrontEnd:

and this is with SetOptions[$FrontEnd, LimitsPositioningTokens -> {}]:

Please note that the $FrontEnd setting with SetOptions is sticky. It is likely that yours isn't at default anymore. Use the option inspector to return LimitsPositioningTokens to its default value (search for LimitsPositioningTokens with Global Settings on and remove the cross next to the variable if there is any).

Flunkey

All tokens in the list of the LimitsPositioningTokens option are strings. – Oversew

@Hominoid is that a typo or is there a new version 7.1 out? I didn't get the memo. – Inappetence

@Mr.Wizard, under the About menu: it gave 7.01.0, I dropped the first zero. Under the system information it generates, it puts the creation date as Feb 2009. – Hominoid

@alexey I mean, as strings they don't pollute symbol namespace. So I don't think your max problem derives (directly) from LimitsPositioningTokens. – Flunkey

@Sjoerd LimitsPositioningTokens is related only to the FrontEnd, not to the kernel. It will not pollute the kernel's namespace. As I understand, this option controls how the FrontEnd interprets user input. If I evaluate SetOptions[$FrontEnd,LimitsPositioningTokens->{}] and then enter max^n+4 using Ctrl+^ for creating the superscript the problem disappear in v. 7.0.1. – Oversew

@alexey From reading the documentation and my own experimentation it was my understanding that this option has to do with formatting not interpretation. Some elements like the sigma for sum have subscripts and/or superscripts that go to bottom and top, resp. of that element when this element appears in-line, but that go to bottom-right and top-right when used in a division. LimitsPositioningTokens determines which elements will do this. Try, for instance, Limit[1/x, x -> [Infinity]] and 1/Limit[1/x, x -> [Infinity]]. Don't execute, but change to TraditionalForm. – Flunkey

@Sjoerd Entering Limit[1/x, x -> [Infinity]] and 1/Limit[1/x, x -> [Infinity]] and converting them to TraditionalForm Display via Cell|Convert to gives nothing unexpected: both are formatted identically (converting to TraditionalForm does nothing). I do not understand what you are trying to show with this example. I think that the examples in my question clearly show that in version 7.01 the option LimitsPositioningTokens affects interpretation of the input. Do you mean that this behavior is a bug and in really it should affect only formatting? Your example does not clarify this. – Oversew

@Alexey the backslash before [Infinity] disappeared in the copy&paste process. Could you try TraditionalForm again, but now with the backslash present? Indeed SetOption[$FrontEnd,LimitsPositioningTokens->{}] changes the behavior of the formatting to not go to the sideways style in divisions. Take care to set it to the original set first. More info at reference.wolfram.com/mathematica/ref/LimitsPositioning.html – Flunkey

@Sjoerd Really, there is no any difference in how these two expressions are converted to the TraditionalForm via Cell|Convert to|TraditionalForm menu token in version 7.0.1! Here are the expressions: Limit[1/x, x -> \[Infinity]] and 1/Limit[1/x, x -> \[Infinity]]. And evaluating SetOption[$FrontEnd,LimitsPositioningTokens->{}] with restarting Mathematica does not show any difference (I have saved and restored original value of this option before). BTW, the "\" symbol does not disappear when I enter it in the comment here. – Oversew

@Sjoerd Now I see your point, thank you. It seems that LimitsPositioningTokens should not affect input interpretation and it is good to know that this bug is fixed in version 8.0.1. – Oversew

@Sjoerd I accept your answer. Up to this moment no other dangerous symbol names suggested in this thread and so I hope that there are no other dangerous symbols names starting with a lowercase letter in Mathematica. The only thing that is really confusing me is that such hazardous bug persisted so long time (from at least v.5 up to v.7). – Oversew