MathGroup Archive 1999

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Re: Subscripts, Doh!!!

  • To: mathgroup at
  • Subject: [mg19311] Re: [mg19296] Re: [mg19269] Re: Subscripts, Doh!!!
  • From: Jason Harris <j.harris at>
  • Date: Sat, 14 Aug 1999 23:42:46 -0400
  • References: <7o5ier$> <7oba5o$> <"199908060358.XAA08108"> <v04210100b3d0c0366e0b@[]> <"199908120524.BAA04506"> <"199908130234.WAA07302">
  • Sender: owner-wri-mathgroup at

Carl Woll wrote:

>Like you, I like subscripts and I don't like to use the Symbolize function.
>You mentioned a few things that go wrong when you use subscripts, and I
>have some proposed solutions.
> Colin Rose wrote:
>> The most common problem occurs when people simultaneously
>> try to use:
>>      x   AND   x_1, x_2  etc
>> They then set
>>     x=7,
>> and get very confused when they get terms such as
>>      7_1, 7_2, 7_3
>> These sorts of problems are easily avoided by NOT
>> simultaneously using x   WITH   x_1, x_2... .
>An alternative solution to avoidance is to give Subscript the attribute
>HoldFirst. For example,
><snipped examples>
>Another problem you discussed in a later post:
> Colin Rose wrote:
>> Yes - it would have been nice if Clear[Subscript[m, 1]] had
>> been 'made to work' in v4. At the moment, one has to use
>>     Unset[Subscript[m, 1]]
>> or
>>     Clear[Subscript]       (which clears all subscripted 'variables').

Unquestionably, clearing all subscripts is far too much of a shotgun 
approach. This would just break too many things.

>If I want to clear a single definition, then Unset is acceptable.

Yeah but its a hassle to remember. In fact if one looks at your own 
programming style, its obvious you clear variables before using them. 
If one looks at your code below you use ClearAll. You would be 
changing your programming style to then turn around and say...

x sub 0 =.
y sub 0 =.
z sub 0 =.

It works, but is kind of ugly. The solution needs to be seamless.

>problem I have is when I want to clear a lot of subscripted definitions for
>a single base  symbol. One approach is to make the definitions upvalues for
>the base symbol. A neat alternative is to massage the downvalues of
>Subscript directly, as in the following function:
>SetAttributes[ClearSubscript, {HoldAll}]
>ClearSubscript[a_] := Module[{b},
> DownValues[Subscript] =
>  Cases[DownValues[Subscript], (b_ :> _) /; FreeQ[b,
>HoldPattern[Subscript[a, _]]]];
><snipped examples>
>Finally, the point about ?m sub 1 brought up by Jason.
>> Jason Harris wrote:
>> >Just using subscripted symbols has its problems though...
>> >
>> >For instance  \!\(\(?m\_1\)\), that is ? m sub 1 will yield an
>> >error. As will something like \!\(Clear[m\_1]\), that is Clear[ m
> > >sub 1]. etc.

This was just *one* example among many such ones to illustrate the 
problems with an "incomplete" approach.

>One could similarly cook up a function that provides just the information
>related to a base symbol as follows:
>y = 2
>y  = 2
> 2
>So what do you think? Are there any major problems with the above ideas?

Well I don't know if I would call the problems major but the solution 
is certainly not seamless. (Then again I don't suppose you intended 
it to be... )

In any good solution you should "set the object up", and then it 
should act just like a normal Mathematica object. Having to 
specifically remember to call things like ClearSubscript and 
SubscriptInformation, instead of the normal Mathematica functions 
that do these things, is in my opinion pretty ugly. One should just 
use the normal Mathematica functions Clear and '?'. It is possible to 
set up other parsing rules for '?' to enable this to be done 
automatically, but then you are going down the path the notation 
package takes... Similarly you would probably be able to get Clear 
working in such a way as to seamlessly call your ClearSubscript code 
when applicable. However, just fixing these functions is not going to 
fix the overall problem. The problem will occur in other places since 
you will not have "true symbols".

The design goal should be, in my opinion : state that these composite 
objects are "symbols". Then have them treated like normal symbols 
throughout Mathematica, without needing to remember any specialized 

Moreover, setting attributes on a system level function as major as 
Subscript is begging for trouble. Some packages will break because 
you assume Subscript has the attribute HoldFirst. ( E.g. consider the 
construction of a matrix of coordinates 
Table[Subscript[coord[i],j],{i,1,3},{j,1,3}]].) In a similar vein, 
packages that use OverHat would also break, if the attributes of 
OverHat are set to HoldFirst. For instance, if OverHat was used as 
complex conjugation.

Most importantly, if you are calling some other package that requires 
variables to be symbols your solution will outright fail. For 
instance a simple example is the vector calculus package in 
Mathematica. (<< Calculus`VectorAnalysis`)

The following fails without symbolizing x\_1, x\_2, x\_3, since 
coordinates need to be "symbols".

\!\(SetCoordinates[Cartesian[x\_1, x\_2, x\_3]]\)

Yet in many applications it might be convenient / applicable to have 
coordinates x sub 1, x sub 2, x sub 3. It can't be easily done 
without Symbolize.

Symbols are a basic data type in Mathematica and any solution that 
doesn't seamlessly reproduce them is going to break in one place or 
another...  Still, if you only have limited aspirations for your 
applications then changing attributes and introducing auxiliary 
functions could be enough to graft on an approximation to proper 
subscript handling.



  • Prev by Date: Re: Element Extraction
  • Next by Date: Re: Subscripts, Doh!!!
  • Previous by thread: Re: Subscripts, Doh!!!
  • Next by thread: Re: Subscripts, Doh!!!