MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Front end problems!

  • To: mathgroup at
  • Subject: [mg32139] Re: Front end problems!
  • From: "A.K." <koru at>
  • Date: Sat, 29 Dec 2001 00:47:02 -0500 (EST)
  • Organization: Northeastern University, Boston, MA. 02115, USA
  • Sender: owner-wri-mathgroup at

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> wrote in message
news:a0h8bl$stt$1 at
> "A.K." <koru at> wrote in message
news:a0enal$pge$1 at
> > 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
> > used  program. A while back I was advised to open the notebook in
> > 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
> syntax error because the Frontend has lost track of the semicolon
> 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
> the validity of my results, but it's hard to pin down the error because
> usually invisible on the screen.  And even though I'm very careful about
> Mathematica hygiene -- about clearing variables,  rules, etc. -- it's
> possible to exclude user error.  For instance, just giving CircleDot, say,
> the Attribute Flat somewhere in the code and then forgetting to clear it
> 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
> 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
> be done correctly, in a way that permits cutting and pasting without
> I believe that cutting and pasting, together with occasional mishandling
> 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
> with a standard Windows text editor, but the difficulties are presumably
> 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
> spaces, the result looks identical to In[3] but it still doesn't work!
> 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.

  • Prev by Date: Re: A=B example
  • Next by Date: Re: Searching for embedded zeros in list
  • Previous by thread: Re: Front end problems!
  • Next by thread: Re: Re: Front end problems!