Re: Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32144] Re: [mg32127] Re: Front end problems!
- From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
- Date: Sat, 29 Dec 2001 03:57:34 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
I have not much to add to the above except the following brief comment. I first encountered this type of problems with version 3.0. I think, but I am not really sure, that they used to be worse then. At that time I adopted the following principle whcih I have followed ever since: whenever I copy and paste anything in Mathematica I first convert everything (the cell from which I copy and the cell into which I paste) into InputForm. Afterwards I convert everything to StandardForm or TraditionalForm as needed. I have never encountered any problems with this approach. Andrzej Kozlowski Toyama International University JAPAN http://platon.c.u-tokyo.ac.jp/andrzej/ On Friday, December 28, 2001, at 04:41 PM, Alan Mason wrote: > > "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. > > > > > >