Re: Re: General--Making the DisplayFormula style in ArticleModern look like Traditional
- To: mathgroup at smc.vnet.net
- Subject: [mg64716] Re: [mg64696] Re: General--Making the DisplayFormula style in ArticleModern look like Traditional
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Wed, 1 Mar 2006 04:11:36 -0500 (EST)
- References: <dthhpd$nhn$1@smc.vnet.net> <200602230535.AAA13302@smc.vnet.net> <dtm6bo$hk2$1@smc.vnet.net> <200602280649.BAA17588@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Paul Abbott wrote: > In article <dtm6bo$hk2$1 at smc.vnet.net>, > Daniel Lichtblau <danl at wolfram.com> 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