MathGroup Archive 2003

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

Search the Archive

Re: Readability confuses mathematica?

  • To: mathgroup at
  • Subject: [mg44577] Re: Readability confuses mathematica?
  • From: Andrzej Kozlowski <akoz at>
  • Date: Sat, 15 Nov 2003 02:05:07 -0500 (EST)
  • References: <p05200f0fbbda77047608@[]>
  • Sender: owner-wri-mathgroup at

> Right now the working form is determined from the output format type
> only. That is since your default output format was TraditionalForm
> then the input and output rules were created only for traditional
> form. If you are going to use mixed forms you should create two
> statements. one for each form.
> e.g.
> Cell[BoxData[
>     RowBox[{"Symbolize", "[",
>       TagBox["\[Placeholder]",
>         NotationBoxTag,
>         TagStyle->"NotationTemplateStyle"], " ", "]"}]], "Input"]
> and
> Cell[BoxData[
>     FormBox[
>       RowBox[{"Symbolize", "[",
>         RowBox[{
>           TagBox["\[Placeholder]",
>             NotationBoxTag,
>             TagStyle->"NotationTemplateStyle"], " ", ",",
>           RowBox[{
>           "WorkingForm", " ", "\[Rule]", " ", "TraditionalForm"}]}],
>         "]"}], TraditionalForm]], "Input"]

Okay, now I understand what has happened. It took me a long time to 
accept what Paul has been arguing for years: that TraditionlForm is a 
"good thing". Until about a year ago I worked exclusively in 
StandardForm, only occasionally converting  certain cells to 
TraditionalForm. Only fairly recently I started using TraditionalForm 
as the default for output but I still kept StandardForm for input. It 
is this change that must have caused my problems with the Notation 
package, which are therefore not related to any changes in Mathematica.

I am still not convinced that TraditionalForm makes good input. It 
hides too much of the underlying Mathematica code, it makes it 
difficult to copy and paste cells and, it seems to me, is more prone to 
corruption. Besides, I do tend to think of input and output as 
performing a different role, with input being essentially "source 
code". Even when I teach undergraduate classes I prefer StandardForm 
for input, since it reveals much more of the Mathematica programming 
language and hence is more instructive. So it seems to me that the 
mixed form (Standard for input, Traditional for output) is the most 
natural setup.

  Andrzej Kozlowski

> I have added it to my list of updates that for the next major
> revision if the user has differing forms for Input and Output then
> the notations / symbolizations will be created in both forms. That is
> the WorkingForm option will be able to take a list and the Automatic
> value is substituted for the list of forms used. That is if  "Cell"->
> "Default Input FormatType" and "Cell"-> "Default Output FormatType"
> differ then the notation statements should be created in both types.
> Thus at present there is no "bug" per say, its working as I
> originally intended. However, this came up once before as a source of
> frustration for users so I guess we should be more forgiving and just
> generate the notations in all the forms involved.
> Cheers,
>   Jason
>>> I am afraid it is not going to be that simple. It seems that my
>>> repeated attempts to use Symbolize caused me to enter the
>>> NotationBoxTag wrapper twice, but this is a red herring and has
>>> nothing to do with the problem. (It is actually rather unlikely
>>> that I would have the habit of entering this tag twice. It was just
>>> one of those unlikely coincidences that keep happening, that when I
>>> decide to post the error to the MathGroup this kind of thing
>>> happens which obscures the whole problem.)
>> I know the feeling first hand only too well... :)
>>> In any case, the point is that with only a fresh kernel and only
>>> the following input:
>>> In[1]:=
>>> <<Utilities`Notation`
>>> In[2]:=
>>> Cell[BoxData[
>>>     RowBox[{"Symbolize", "[",
>>>       TagBox[
>>>         SubscriptBox["x", "_"],
>>>         NotationBoxTag,
>>>         TagStyle->"NotationTemplateStyle"], "]"}]], "Input",
>>>   CellLabel->"In[2]:="]
>>> whcih you can now see is quite correct I still get:
>>> In[3]:=
>>> \!\(f[\(x\_1\) : _] := x\_1\^2\)
>>> From In[3]:=
>>> \!\(\*FormBox[
>>>   RowBox[{\(Syntax::"sntxf"\), \(\(:\)\(\ \)\), \
>>> "\<\"\\\"\\!\\(TraditionalForm\\`\\(f[\\)\\)\\\" cannot be
>>>       followed by \\\"\\!\\(TraditionalForm\\`\\(\\(\\(x\\_1 :
>>> _\\)\\)]\\)\\)\
>>> \\\".\\!\\(TraditionalForm\\`\\\"\\\"\\) 
>>> \\!\\(\\*ButtonBox[\\\"More?\\\", \
>>> ButtonStyle->\\\"RefGuideLinkText\\\", ButtonFrame->None, \
>>> ButtonData:>\\\"General::sntxf\\\"]\\)\"\>"}], TraditionalForm]\)
>>> From In[3]:=
>>> \!\(\*
>>>   StyleBox[
>>>     RowBox[{
>>>       RowBox[{"f", "[",
>>>         ErrorBox[\(\(x\_1\) : _\)], "]"}], ":=", \(x\_1\^2\)}],
>>>     ShowStringCharacters->True]\)
>> Ahh I think I might know what the problem is what are your settings
>> for forms? That is look in menu "Cell"->"Default Input FormatType"
>> and "Cell"->"Default Output FormatType" what are these set to?
>> StandardForm or TraditionalForm or mixed?
>> I am guessing these are both TraditionalForm from your output?
>> I think there might be a new bug in getting the state of these menus
>> items in 5.0. The Notation package looks at them to determine which
>> form to create the notation in. It looks like this low level packet
>> has changed or has some glitch. In the meantime you can get around
>> this problem by adding the option WorkingForm->TraditionalForm
>> Cell[BoxData[
>>     FormBox[
>>       RowBox[{"Symbolize", "[",
>>         RowBox[{
>>           TagBox[
>>             SubscriptBox["x", "_"],
>>             NotationBoxTag,
>>             TagStyle->"NotationTemplateStyle"], ",",
>>           RowBox[{"WorkingForm", "\[Rule]", "TraditionalForm"}]}], 
>> "]"}],
>>       TraditionalForm]], "Input",
>>   CellLabel->"In[5]:="]
>> I am going to investigate the packet and I'll get back to you
>> hopefully shortly. Thanks for noticing this!
>> Cheers,
>>   Jason
>>> Andrzej
>>> On 14 Nov 2003, at 16:23, Jason Harris wrote:
>>>> Hi Andrzej,
>>>> [Notation example snipped]
>>>>>  On my system this example just fails miserabley (the
>>>>>  definiton of transmissionCoefficient does not parse) although it 
>>>>> once
>>>>>  used to work. (Actually, I would like to hear from other people,
>>>>>  because either the Notation package is no longer working or 
>>>>> something
>>>>>  is wrong with my installation).
>>>> I know these things can appear frustrating at times, but the 
>>>> Notation
>>>> package is working fine. In the example you have given, you have
>>>> managed to include the box wrapper twice in your Symbolize 
>>>> statement.
>>>> (You likely did this through copying the k subscript including box
>>>> wrapper and pasted it into a new Symbolize statement.)
>>>>>  Anyway, if this works on your system than the problem is solved. 
>>>>> You
>>>>>  can symbolize subscripted variables and use them as if they were
>>>>>  symbols. On the other hand, in the past, when this package used 
>>>>> to work
>>>>>  on my system, I got myself into a huge mess when I tried to 
>>>>> evaluate
>>>>>  again a notebook that had previously worked correctly.
>>>> If there is some notebook corruption going on then we definitely 
>>>> want
>>>> to know about this. In the example you have given it is extremely
>>>> likely that you inadvertently caused the error with a copy and paste
>>>> from one symbolize statement to another. (I know notation statements
>>>> can be tricky and it is not all that hard to "hang yourself".)
>>>>>  Because of that I finally decided that relying on a package like 
>>>>> this is
>>>>>  just too risky if you are doing any serious work.
>>>> Hmm... Actually I personally think its just the opposite. If you are
>>>> really doing serious work you need to know about typesetting and how
>>>> to enter expressions in notations which are familiar to
>>>> Mathematicians, physicists, and other users and have these notations
>>>> function correctly.
>>>> First a general comment:
>>>> When you are troubleshooting problems with setting up notations it 
>>>> is
>>>> often necessary to look at the underlying boxes representing the
>>>> typeset expression. You can do this through either the command key
>>>> shortcut of cmd-shift-E (OSX) and I think cntrl-shift-E (Win), or
>>>> through the menu item "Format" -> "Show Expression..."
>>>> Looking at the underlying boxes shows you how the typeset expression
>>>> is represented. As a Mathematica programmer you no doubt use 
>>>> FullForm
>>>> at times to examine how a certain pattern is structured. Its really
>>>> not too different with typesetting in that Mathematica functions 
>>>> through
>>>> MakeBoxes and MakeExpression which operate on these box structures. 
>>>> If
>>>> you don't have the correct structures, the boxes will not be
>>>> interpreted as they should be.
>>>> In a Symbolize statement waiting to be filled in the underlying
>>>> structure is
>>>> Cell[BoxData[
>>>>     RowBox[{"Symbolize", "[",
>>>>       TagBox["\[Placeholder]",
>>>>         NotationBoxTag,
>>>>         TagStyle->"NotationTemplateStyle"], "]"}]], "Input"]
>>>> To see this load the notation package, type Esc-symb-Esc and then 
>>>> show
>>>> the underlying expression. The box structure to be symbolized must 
>>>> be
>>>> the first argument of this TagBox.
>>>> The tag box wrapper, NotationBoxTag, is necessary so you can enter
>>>> typeset expressions into Mathematica that are not currently
>>>> syntactically valid. Then once the Notation package gets a hold of
>>>> them, it compiles / translates these into corresponding rules for
>>>> MakeExpression and MakeBoxes that do what you instructed. The tag 
>>>> box
>>>> wrapper inertizes the box structure so it becomes syntactically 
>>>> valid
>>>> Mathematica input.
>>>> You can see this by copying out the box wrapper into a new cell and
>>>> entering some syntactically invalid input into the wrapper, say "x"
>>>> followed by "*", and then viewing how it is interpreted by
>>>> Mathematica. E.g. after loading the notation package paste the
>>>> following cell into Mathematica and interpret it:
>>>> Cell[BoxData[
>>>>     TagBox[
>>>>       RowBox[{"x", "*"}],
>>>>       NotationBoxTag,
>>>>       TagStyle->"NotationTemplateStyle"]], "Input"]
>>>> Then evaluate this interpreted cell. Then start a new cell and
>>>> evaluate FullForm[%]. The answer will be
>>>> NotationBoxTag[RowBox[List["x", "*"]]]
>>>> Thus the TagBox wrapper, NotationBoxTag, has allowed us to enter
>>>> something that is syntactically invalid and get the box structure 
>>>> into
>>>> the kernel. (Incidentally you can programmatically create symbolize
>>>> and notation statements this way.) The TagBox wrapper NotationBoxTag
>>>> can do this miraculous feat because it itself has a corresponding
>>>> notation. (The TagStyle option is set so you can get some visual
>>>> indication of where these tag box wrappers occur.)
>>>> So anyway getting back to your example if you look at the underlying
>>>> boxes you will see that instead of having
>>>> Cell[BoxData[
>>>>     RowBox[{"Symbolize", "[",
>>>>       TagBox[
>>>>         SubscriptBox["k", "_"],
>>>>         NotationBoxTag,
>>>>         TagStyle->"NotationTemplateStyle"], "]"}]], "Input"]
>>>> You had
>>>> Cell[BoxData[
>>>>     RowBox[{"Symbolize", "[",
>>>>       TagBox[
>>>>         TagBox[
>>>>           SubscriptBox["k", "_"],
>>>>           NotationBoxTag,
>>>>           TagStyle->"NotationTemplateStyle"],
>>>>         NotationBoxTag,
>>>>         TagStyle->"NotationTemplateStyle"], "]"}]], "Input"]
>>>> i.e. the wrapper was in there twice. Fixing this mistake resolves
>>>> your problem.
>>>> Cheers,
>>>>   Jason
>>>> -------------
>>>> Jason Harris
>>>> Wolfram Research
>>> Andrzej Kozlowski
>>> Yokohama, Japan
Andrzej Kozlowski
Yokohama, Japan

  • Prev by Date: Re: I have put "==" in every equation I have in NDSolve, why it keeps telling me they are not equations
  • Next by Date: Help
  • Previous by thread: Re: Readability confuses mathematica?
  • Next by thread: Re: Readability confuses mathematica?