Re: Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32157] Re: Re: Front end problems!
- From: "Allan Hayes" <hay at haystack.demon.co.uk>
- Date: Sun, 30 Dec 2001 02:54:22 -0500 (EST)
- References: <email@example.com>
- Sender: owner-wri-mathgroup at wolfram.com
Andrzej, > 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. Just one thing that should be pointed out: Comments, between (* and *), are deleted by change of form and so will need to be reinstated. -- Allan --------------------- Allan Hayes Mathematica Training and Consulting Leicester UK www.haystack.demon.co.uk hay at haystack.demon.co.uk Voice: +44 (0)116 271 4198 Fax: +44 (0)870 164 0565 "Andrzej Kozlowski" <andrzej at tuins.ac.jp> wrote in message news:a0k0ol$3om$1 at smc.vnet.net... > 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 is wrong because of a whitespace bug. > > Since the two rules in In and In 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:= > > \!\(test\ = \ \ D\_z\[SmallCircle]\((y\ D\_x)\)\) > > > > Out= > > \!\(D\_z\[SmallCircle]\((y\ D\_x)\)\) > > > > In:= > > \!\(\(\(\[IndentingNewLine]\)\(test\ //. \ \ > > \(D\_u\)\__\[SmallCircle]\ \ > > \((c_\ \ D\_v_)\)\ \[RuleDelayed] \ \ c\ sc[D\_u, \ > > D\_v]\ + \ \ \(\(CircleDot[D\_u, \ c]\) > > \(D\_v\)\(\ \)\)\)\)\) > > > > Out= > > \!\(D\_z\[SmallCircle]\((y\ D\_x)\)\) > > > > In:= > > \!\(test\ //. \ > > D\_u_\[SmallCircle]\((c_\ D\_v_)\)\ \[RuleDelayed] \ > > c\ sc[D\_u, \ D\_v]\ + \ CircleDot[D\_u, \ c]\ D\_v\) > > > > Out= > > \!\(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 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. > > > > > > > > > > > > > >