Services & ResourcesWolfram ForumsMathGroup Archive

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

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

• To: mathgroup at smc.vnet.net
• Subject: [mg64781] Re: [mg64718] Re: [mg64696] Re: General--Making the DisplayFormula style in ArticleModern look like Traditional
• From: Daniel Lichtblau <danl at wolfram.com>
• Date: Thu, 2 Mar 2006 19:27:55 -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> <440464A0.3070001@wolfram.com> <200603010911.EAA19382@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

Paul Abbott wrote:
> On 28/2/06, Daniel Lichtblau wrote:
> 
> 
>>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.
> 
> 
> No -- all of these things can be fixed (via appropriate TagBoxes).

TagBoxes will not address the problem of reading ambiguous input and
typing it into a notebook or package by eye. This is what a couple of
TMJ readers did. Following which they wrote to tell me "my" code was not
working.


> [...]
> 
>>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.
> 
> Amusing -- but ambiguity _is_ avoidable.

In a notebook, yes. If one knows what to do to address it e.g. with
TagBoxes (I do not). Certainly if people want to privately pass around
notebooks containing code, and prefer to see it in traditional form,
this should be fine. Well, usually. Me, I sometimes find that whatever
front end/kernel configuration I am using has objections to the
traditional form from the one used to create the notebook I was sent.
But that may be because I am more likely to have a development front end
and kernel (and these can be fragile), hence it might not be a general
issue.


> [...]
> 
>>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.
> 
> 
> Again I disagree. Select all input cells and do a "Convert to 
> StandardForm". This should not take long, and will, I'm sure, make 
> you feel more comfortable.
> 
> If the conversion is not correct then there is a problem (a bug) with 
> the Mathematica implementation of TraditionalForm. Essentially, the 
> necessary TagBoxes required to make the conversion unambiguous must 
> be missing.
> 
> Cheers,
> Paul

I will confess there is a logic to your argument that I find compelling
and cannot help but admire. In a nutshell:

(1) I write code in InputForm. It works basically as expected.
(2) You can convert it to TraditionalForm for, say, a TMJ column.
(3) Readers may try to replicate it and for them it fails to work properly.
(4) You can then claim this is a bug in the Mathematica kernel, in
effect making it my responsibility.

I have to admit I am impressed.

Okay, maybe you had in mind that it's only a bug if the electronic form
fails to behave. But not all readers will have access to, let alone use,
the electronic form. And of course this becomes the essential matter
when the publication in question is not TMJ.

This brings me back to my main point. Visually ambiguous code is not a
valuable commodity.


Daniel Lichtblau
Wolfram Research

• References:
  • Re: Re: General--Making the DisplayFormula style in ArticleModern look like Traditional
    • From: Paul Abbott <paul@physics.uwa.edu.au>