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: <firstname.lastname@example.org> <200602230535.AAA13302@smc.vnet.net> <email@example.com> <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
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.
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.
Prev by Date:
Re: Re: Limit
Next by Date:
Re: Live3D Points?
Previous by thread:
Next by thread:
Re: General--Making the DisplayFormula style in ArticleModern look like Traditional