MathGroup Archive 1999

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

Search the Archive

Mathematica 3->Mathematica 4 error: symptoms and cure

  • To: mathgroup at
  • Subject: [mg19421] Mathematica 3->Mathematica 4 error: symptoms and cure
  • From: Tom Burton <tburton at>
  • Date: Mon, 23 Aug 1999 13:57:26 -0400
  • Sender: owner-wri-mathgroup at

Hello all,

I've just finished converting a large application from version 3 to version 
4. This note discusses the problems I've encountered and my solutions to them.

Upon loading the application in Mathematica 4.0, I encountered three types 
of difficulty:

1. Mathematica warned of a missing member of a sequence, as in [a,b,,c] or 
{d,e,}. The correction is simply to insert Null between two adjacent commas 
in the first example or to drop the final, superfluous comma in the second 

2. As has been noted in this group, the compiler in version 4 requires more 
explicit typing of symbols. The correction was to initialize local symbols 
in a compiled module to inform the compiler of the type. It was sometimes 
also necessary to type a global symbol as in this example:

     y=externalFunction[x]; y^2
   ], {{externalFunction,_Real,1}}

3. Some compound expressions produced errors or gave wrong results. The 
rest of this emo is devoted to this most serious of the three types of 


(1) Indentation looks peculiar.

(2) A compound statement yields inconsistent results

             notebook (*.nb)        package (*.m)
version 3     good                   good
version 4     good                   bad

By "package" I mean the definition stored in the package and initialized 
when <<package.m or Needs["package`"] is executed.

By "notebook" I mean the definition that is built when you "Evaluate 
Initialization" when the notebook has focus.


Reformat the compound expression in the kernel in StandardForm (CNTL-SHFT-N 
on Windows) and save. You can then alter by hand--adding hard returns 
around If-blocks, etc., without incurring a further error.

You will lose embedded comments, so put them aside first if they are really 
needed. (I try to code briefly and clearly so that comments are not needed.)

(I format longer compound expressions exclusively in StandardForm. I 
suspect that TraditionalForm but not InputForm might have similar problems.)

How does this error arise?

I'm not sure.  I found about 25 "bad" compound expressions confined to only 
two of seventeen notebooks. I would hazard a guess that I encouraged these 
bad compound expressions to form by editing these two notebooks alternately 
in version 3 and version 4--back and forth.

Ineffective remedies

Disabling "ShortBoxForm" never helped.
Manual reformatting sometimes helped; sometimes not.


Without an automated quality assurance program to find these errors, some 
might have gone undetected: not all bad results were obviously wrong.

Unless you have an automated QA system or equivalent, I recommend that you 
check your compound expressions--especially those which appear ragged--as 
follows:  compare the results of the definition from the notebook with 
those of the corresponding function in the package. If they differ, suspect 
the package.

Thomas E. Burton              353 Sanford Road
Brahea, Inc.                  Encinitas CA 92024-1508
tburton at            760/436-7436

  • Prev by Date: Re: Standard Evaluation with UpValues
  • Next by Date: RE:Any examples of FEA in Mathematica?
  • Previous by thread: Re: Please help me! (Warnings and Messages...)
  • Next by thread: RE:Any examples of FEA in Mathematica?