Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32127] Re: Front end problems!
- From: "Alan Mason" <swt at austin.rr.com>
- Date: Fri, 28 Dec 2001 02:41:44 -0500 (EST)
- References: <a0enal$pge$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
"A.K." <koru at coe.neu.edu> wrote in message news:a0enal$pge$1 at smc.vnet.net... > Hello all, > > I have been using mathematica for years now. I intensely use versions 3 and > 4. While using mathematica I've encountered a mysterious problem -mysterious > to me at least- that's been recurring independent of the version. > Whenever I use the notebook, after a certain time and effort of programming > with correct intermediate results, I start getting peculiar outputs > following some more additional programming. At this point of course I start > deleting any additional material to be able to go back to the closest > functioning state. Alas, I end up finding this state corrupted, and get > truly odd outputs. > > This problem usually occurs after pasting some part of another previously > used program. A while back I was advised to open the notebook in another > editor and delete or add a line or two. But this remedy doesn't work either. > Hence, I end up rewriting the code. > > My major question is that, is there any other individual suffering from this > type of phenomena or are these only my omens? > > And also are there any patches, service packs or upgrades etc. that I'm > missing maybe? Such tools would be useful in either of the two versions that > run on NT 4.0. > > Best Regards. > > Aybek Korugan > Hello, Alas, the problems you report are not unique to you. Sometimes, the error is obvious -- you insert a comment into a Module, hit Shift-Enter, and get a syntax error because the Frontend has lost track of the semicolon preceding the comment (looks like a typical off-by-one error). But things are not always this clear. Sometimes after long complicated sessions, I've suspected Frontend errors (with white space and comments) may be corrupting the validity of my results, but it's hard to pin down the error because it's usually invisible on the screen. And even though I'm very careful about my Mathematica hygiene -- about clearing variables, rules, etc. -- it's rarely possible to exclude user error. For instance, just giving CircleDot, say, the Attribute Flat somewhere in the code and then forgetting to clear it can cause a pattern involving CircleDot to suddenly fail to match later. The internal state of Mathematica gets very complicated and can be virtually impossible to understand; when this occurs, it's time to start a new session. As it happens, just a few days ago I was able to catch Mathematica red-handed, and I give the short notebook below. Here there can be no question of user error. Mathematica isn't handling white space properly. There may be other errors as well in longer notebooks. For AutoGenerated packages the situation is even worse than for notebooks; all too often, a package generated from a master notebook that runs perfectly will contain syntax errors which persist even after all comments have been stripped (great for the documentation, needless to say). There are also bugs and maddening inconsistencies in the keyboard-to-screen-to-file correspondence that any finished software program should have down cold. That such bugs should persist even at this late stage could be considered disgraceful and can be tolerated only because of Mathematica's unique virtues; WRI really needs to understand what's going on here and fix these problems once and for all. In the following notebook, Out[2] is wrong because of a whitespace bug. Since the two rules in In[2] and In[3] look alike on the screen, this is pernicious. Apparently, Mathematica is attempting to record additional formatting information in the notebook, a laudable effort. But it needs to be done correctly, in a way that permits cutting and pasting without error. I believe that cutting and pasting, together with occasional mishandling of comments, is the source of most if not all of these Frontend errors. Because of the Mathematica-centric approach that WRI has had to adopt with its notebooks, the parsing and analysis are considerably more difficult than with a standard Windows text editor, but the difficulties are presumably not insuperable. In[1]:= \!\(test\ = \ \ D\_z\[SmallCircle]\((y\ D\_x)\)\) Out[1]= \!\(D\_z\[SmallCircle]\((y\ D\_x)\)\) In[2]:= \!\(\(\(\[IndentingNewLine]\)\(test\ //. \ \ \(D\_u\)\__\[SmallCircle]\ \ \((c_\ \ D\_v_)\)\ \[RuleDelayed] \ \ c\ sc[D\_u, \ D\_v]\ + \ \ \(\(CircleDot[D\_u, \ c]\) \(D\_v\)\(\ \)\)\)\)\) Out[2]= \!\(D\_z\[SmallCircle]\((y\ D\_x)\)\) In[3]:= \!\(test\ //. \ D\_u_\[SmallCircle]\((c_\ D\_v_)\)\ \[RuleDelayed] \ c\ sc[D\_u, \ D\_v]\ + \ CircleDot[D\_u, \ c]\ D\_v\) Out[3]= \!\(y\ sc[D\_z, D\_x] + D\_z\[CircleDot]y\ D\_x\) Alan PS. Actually, the rules don't look *exactly* the same in the notebook -- the first is preceded by a newline, and there's an extra space before the first D, for example. However, if I delete this newline, and all the extra spaces, the result looks identical to In[3] but it still doesn't work! It looks like some effort has been made to permit better control over the formatting of notebooks, but the details aren't quite right. In any case, it's normal for users to consider rules that differ only by white space to be semantically identical.