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]}}

enter image description here

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]]]

screen

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?

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. — rcollyer, Aug 10 '11 at 15:17
@rcollyer 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). — Sjoerd C. de Vries, Aug 10 '11 at 15:53
`$Version = 7.0 for Mac OS X x86 (64-bit) (February 19, 2009)` and `$System = Mac OS X x86 (64-bit)`. — rcollyer, Aug 10 '11 at 15:57
@Sjoerd I have checked this on versions 7.0.1 and 5.2 for Windows. In both cases the problem persists. — Alexey Popkov, Aug 10 '11 at 17:33

Sjoerd C. de Vries · Accepted Answer · 2011-08-15T19:02:25.197

2

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

enter image description here

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:

enter image description here

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

enter image description here

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).

edited Aug 15 '11 at 19:02

answered Aug 10 '11 at 15:20

Sjoerd C. de Vries

16,122
3
42
94

All tokens in the list of the `LimitsPositioningTokens` option are strings. – Alexey Popkov Aug 10 '11 at 17:37
@rcollyer is that a typo or is there a new version 7.1 out? I didn't get the memo. – Mr.Wizard Aug 12 '11 at 22:15
@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. – rcollyer Aug 13 '11 at 00:28
@alexey I mean, as strings they don't pollute symbol namespace. So I don't think your max problem derives (directly) from `LimitsPositioningTokens`. – Sjoerd C. de Vries Aug 14 '11 at 15:32
@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. – Alexey Popkov Aug 15 '11 at 06:24
@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. – Sjoerd C. de Vries Aug 15 '11 at 11:48
@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. – Alexey Popkov Aug 15 '11 at 15:18
@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 http://reference.wolfram.com/mathematica/ref/LimitsPositioning.html – Sjoerd C. de Vries Aug 15 '11 at 16:22
@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. – Alexey Popkov Aug 15 '11 at 18:32
@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. – Alexey Popkov Aug 16 '11 at 06:02
@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). – Alexey Popkov Sep 23 '11 at 13:10

Dangerous symbol names that begin with a lowercase letter

1 Answers1