Mathematica 3->Mathematica 4 error: symptoms and cure

*To*: mathgroup at smc.vnet.net*Subject*: [mg19421] Mathematica 3->Mathematica 4 error: symptoms and cure*From*: Tom Burton <tburton at brahea.com>*Date*: Mon, 23 Aug 1999 13:57:26 -0400*Sender*: owner-wri-mathgroup at wolfram.com

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 example. 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: Compile[{{x,_Real,2}}, Module[{y={0.}}, 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 difficulty. Symptoms -------- (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. Cure ---- 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. Discussion ---------- 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 brahea.com 760/436-7436