Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32139] Re: Front end problems!
- From: "A.K." <koru at coe.neu.edu>
- Date: Sat, 29 Dec 2001 00:47:02 -0500 (EST)
- Organization: Northeastern University, Boston, MA. 02115, USA
- Sender: owner-wri-mathgroup at wolfram.com
Dear Mr. Mason, It was a great relief to read your experiences and experiments about the front end. Somehow, to this day I was truly convinced that I was doing something that shouldn't be done in a mathematica common sense. Therefore, rewriting codes would be tormenting. Due to these errors I have lost days thinking that there is an error in my calculations. At least from now on when I get absurd outputs I'll be able to look for a front end error with a tad more confidence. I'm also glad to hear that my mathematica coding rituals weren't useless. I agree with the white space problems. They would account for a number of my troubles. Hence, when I paste some piece of code I try to handle them line by line with the minimum possible amount of white space. It requires some patience but beats retyping. Also another odd problem I had to battle last night was with font colors. I'm a rather messy programmer, so color coding helps keep track of things easier. However, last night mathematica would not recognize a bracket because it was blue. Well, I turned blue before I could find the error. So for me mathematica coding is a B&W occupation from now on. Once again thank you very much for your kind and very helpful reply. Despite all of its frustrating front end problems I still believe that it is an amazing product. I'm sure we agree on that too. Best wishes, Aybek Korugan Ps: It might be a good idea to create some sort of a mathematica front end suspected (fuzzy) bugs and bad coding experiences knowledge base, since not all problems are easily reportable to WRI. "Alan Mason" <swt at austin.rr.com> wrote in message news:a0h8bl$stt$1 at smc.vnet.net... > > "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. > > > >