Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32176] Re: Front end problems!
- From: "Mirek Gruszkiewicz" <gruszkiewicz at ornl.gov>
- Date: Fri, 4 Jan 2002 05:03:50 -0500 (EST)
- Organization: Oak Ridge National Lab, Oak Ridge, TN
- References: <a0jm3k$322$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
These bugs have been in Mathemathica front end as long as I remember. I have reported them to WRI with short explicit repeatable examples. Basically the answer was "yeah, we know, but Mathematica handling of carriage returns and newlines and spaces and comments etc. is so complex and delicate, that we really are not sure how to deal with it". I was always puzzled how people apparently manage to use Mathematica without having constant problems with unexpected syntax errors. I came to the conclusion that a huge majority use Mathematica interactively and only create small cells with relatively short and few expressions that don't extend over more than one line and don't need any white space or comments in between. The others just assume they 'corrupted' something, probably due to their inferior understanding of the superior 'programing paradigms'. :-) The fact is, whenever more complex cells and expression are used, as in many physicochemical science/engineering problems, this problem will earlier or later crop up. This is scary, because who knows what can happen to the results. Most often it is just a syntax error mesage where there is no syntax error, without any clues as to how to find and fix it. Sometimes some junk gets appended to the result. By now I can usually manage to rearrange the cells to get rid of the errors. It's basically where you put your carriage returns. Unfortunately, fixing the errors is done at the cost of legibility, because the format Mathematica can generally digest in StandardForm is a terrible condensed mess (best with no carriage returns at all). Blank lines and comments are unsafe. It's also best to avoid printing the resulting abomination because somebody could witness it and hold it against you. Besides, legible printing of larger Mathematica programs is another can of worms (forget pretty). Altogether it becomes an ugly struggle if you have substantial chunks that cannot be divided into smaller cells, such as large Modules. Because of this I would not recommend Mathematica for building large programs. By the way, in some cases, putting parentheses () around the whole cell content can serve as a fix. The related bug is that initialization cells which execute OK in the notebook produce broken Autosave package (*.m ) files. For example the cell (*comment*) a=cc^2 (where the power is made by ctrl+^) , will produce a bad *.m file, while ((*comment*) a=cc^2) will produce a good *.m file. This is a simple example, there are others without any comments involved. Also a long time ago I tried to suggest to WRI compiling a bug list but they said 'NO'. They said it is impossible to create a bug list for Mathematica, because Mathematica is the one , uniquely complex piece of software with which such a crude and mundane concept as a bug list is not compatible, would not work and just cannot be done. One can make bug lists for this or that trivial software, but not for Mathematica. Can you capture the wind and put it in your pocket.?. this type of thing. MG "A.K." <koru at coe.neu.edu> wrote in message news:a0jm3k$322$1 at smc.vnet.net... > 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. > > > > > > > > > > >