Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2001

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

Search the Archive

Re: Front end problems!

  • To: mathgroup at smc.vnet.net
  • Subject: [mg32127] Re: Front end problems!
  • From: "Alan Mason" <swt at austin.rr.com>
  • Date: Fri, 28 Dec 2001 02:41:44 -0500 (EST)
  • References: <a0enal$pge$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

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





  • Prev by Date: Re: Integration of "Which"
  • Next by Date: Matrix Series
  • Previous by thread: Front end problems!
  • Next by thread: Re: Front end problems!