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

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.
>
>
>
>