MathGroup Archive 2007

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

Search the Archive

Re: Failure to convert certain symbols to InputForm when using when using AutoGeneratedPackage->True

  • To: mathgroup at
  • Subject: [mg79965] Re: Failure to convert certain symbols to InputForm when using when using AutoGeneratedPackage->True
  • From: John Fultz <jfultz at>
  • Date: Thu, 9 Aug 2007 06:26:11 -0400 (EDT)
  • Reply-to: jfultz at

On Thu, 9 Aug 2007 14:56:42 +1000, Andrew Moylan wrote:
> Create a new notebook and type the following into a Code (Alt+8) cell:
> Integrate[x, {x, 0, 1}]
> Sum[x, {x, 0, 1}]
> Now select the cell and convert it to StandardForm (Ctrl+Shift+N). The
> special integral and summation symbols, together with two-dimensional
> under-
> and overscripts, and super- and subscripts, appear.
> (As an alternative to the above, you could simply type the StandardForm
> directly using two-dimensional input.)
> Now save the notebook somewhere. When prompted to create an auto-save
> package, choose to create one. Examine the resulting .m file. It contains
> these lines:
> \!\(
> \*SubsuperscriptBox[\(\[Integral]\), \(0\), \(1\)]\(x
> \[DifferentialD]x\)\)
> \!\(
> \*UnderoverscriptBox[\(\[Sum]\), \(x = 0\), \(1\)]x\)
> They have not been converted to InputForm (which is normally the case for
> auto-generated package files as of version 6); they have been left as
> boxes!
> Here is what I expected to see in the automatically generated .m file:
> Integrate[x, {x,0,1}]
> Sum[x, {x,0,1}]
> Why is it that StandardForm integrals and sums are left as uninterpreted
> boxes instead of being converted to InputForm?

The "Convert to..." items in the menus use the kernel.  This explains the 
strengths and weaknesses of these items.  The strengths are that "Convert to..." 
is guaranteed to work using precisely the typesetting rules which exist in the 
kernel.  It will even work if you create your own form or extend one of the
existing ones.  However, the conversion goes through the kernel's parser, and 
thus throws away information the parser doesn't care about, such as the 
placement of whitespace and the existence of comments.

So, saving to package, in fact, does *not* do what Cell->Convert To->InputForm 
does.  If it did, it would reformat your code and throw away your comments, not 
to mention that it would invoke the kernel for every package-saving operation  
(and who knows what state the kernel will be in when you want to save?). So, 
package-saving is implemented in the front end.  This has a few implications.

First, if we're not going to query the kernel about typesetting rules, then we 
can really only convert those cases which are fairly unambiguous.  This pretty 
much amounts to FractionBox, InterpretationBox, and certain subsets of 
SuperscriptBox and SubscriptBox usage in version 6.  There are some more rules 
we could add which remain fairly unambiguous...the integral, sum, product, and 
limit rules fit that description, I believe.  But we had to ship version 6 at 
*some* point, and the complexity of implementing these rules without invoking 
the kernel was enough to...well, cause me to answer quite a number fewer 
MathGroup questions, at the very least.

I should note, incidentally, that there's one exception to the 
no-kernel-invocation rule for package-saving.  The conversion of a typeset 
Manipulate[] to InputForm is so incredibly useful and so unlikely to suffer any 
of the ill effects of going through the kernel parser that package-saving (as 
well as copy/paste) will call the kernel to get the Manipulate's InputForm. 

John Fultz
jfultz at
User Interface Group
Wolfram Research, Inc.

  • Prev by Date: Version 6 "Mathematica Book" - updated and expanded
  • Next by Date: RE: FindRoot can NOT handle mixed real and complex variables
  • Previous by thread: Failure to convert certain symbols to InputForm when using when using AutoGeneratedPackage->True
  • Next by thread: NMinimize a function of NMaximize