Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2002
*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 2002

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

Search the Archive

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




  • Prev by Date: Re: Find many Roots
  • Next by Date: Re: Length and Drop
  • Previous by thread: Re: Find many Roots
  • Next by thread: Re: Front end problems!