MathGroup Archive 2006

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

Search the Archive

Re: Re: General--Making the DisplayFormula style in ArticleModern look like Traditional

  • To: mathgroup at
  • Subject: [mg64716] Re: [mg64696] Re: General--Making the DisplayFormula style in ArticleModern look like Traditional
  • From: Daniel Lichtblau <danl at>
  • Date: Wed, 1 Mar 2006 04:11:36 -0500 (EST)
  • References: <dthhpd$nhn$> <> <dtm6bo$hk2$> <>
  • Sender: owner-wri-mathgroup at

Paul Abbott wrote:
> In article <dtm6bo$hk2$1 at>,
>  Daniel Lichtblau <danl at> wrote:
>>TraditionalForm is bad for input. Very bad. 
> No it is not. As a daily user of Mathematica, I find TraditionalForm to 
> be a robust and elegant input format. Agreed, there are some issues in 
> the use of TraditionalForm for input. However, since TraditionalForm is 
> available as a Mathematica input form (and has been since 1996), then 
> any problems with the implementation of TraditionalForm are bugs (I have 
> reported many) that should be fixed in successive releases of 
> Mathematica.

Traditional form is intrinsically ambiguous. Some of these things can be 
fixed, but not all (ergo, not all are bugs). This format should not be 
used for input.

Let me elaborate on one remark above. TraditionalForm is not exactly 
"available as a Mathematica input form". It is available, period. Which 
is to say, it is there, and in principle can be used for any type of 
cell, including Input. But it should not be used in that particular 
setting, because it is ambiguous.

There are other reasons I vastly prefer StandrdForm in Input cells. But 
ambiguity, unlike my opinions, is a matter of hard unavoidable fact. It 
is the solid basis for the claim that TraditionalForm should not be used 
in that particular setting.

>>I still field questions from 
>>an In and Out column of The Mathematica Journal 8(1) (published in 2001) 
>>that were typeset using TraditionalForm. Okay, there were limitations in 
>>the code itself, but the formatting managed to alter precedence 
>>somewhere in a way that exacerbated the trouble.
> Exactly the point -- there was a problem with the formatting of the 
> code, not with TraditionalForm itself. And, if there is a problem, then 
> you are just acknowledging a Mathematica bug that should be fixed.
> Cheers,
> Paul
> [...]

My recollection is it fell into the ambiguity category, which is to say, 
it was not a bug. But that does not really matter because we are 
discussing an area of typesetting that is difficult to perfect. So if it 
was a bug it could well be one that is difficult to redress. The way to 
avoid these problems is to not use traditional form in input.

Let me put it this way. Mathematica uses square brackets instead of 
parentheses for procedure invocation (more correctly, XXXValues). This 
is by intent and for a compelling reason. While one can and should use 
traditional formatting in the context of mathematical exposition, actual 
code is not the place to reintroduce the ambiguities that the language 
design rather specifically avoids.

Coincidently, last night I received a notebook that appears to indicate 
a speed bump in some integer arithmetic code. The function and tests are 
presented in TraditionalForm. It is taking me longer than it ought to 
pare down the problem because reformatting is not working very well 
(which may be a bug) and I cannot otherwise isolate the slow spot. My 
point is that this isn't an abstraction; use of TraditionalForm in input 
has real costs to productivity.

Daniel Lichtblau
Wolfram Research

  • Prev by Date: Re: Re: Limit
  • Next by Date: Re: Live3D Points?
  • Previous by thread: Re: Limit
  • Next by thread: Re: General--Making the DisplayFormula style in ArticleModern look like Traditional