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