MathGroup Archive 2001

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

Search the Archive

Re: Re: Front end problems!

  • To: mathgroup at smc.vnet.net
  • Subject: [mg32157] Re: Re: Front end problems!
  • From: "Allan Hayes" <hay at haystack.demon.co.uk>
  • Date: Sun, 30 Dec 2001 02:54:22 -0500 (EST)
  • References: <a0k0ol$3om$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Andrzej,

> whenever I copy and paste anything in Mathematica I first convert
> everything (the cell from which I copy and the cell into which I paste)
> into InputForm. Afterwards I convert everything to StandardForm or
> TraditionalForm as needed.


Just one thing that should be pointed out:
Comments, between (* and *), are deleted by change of form and so will need
to be reinstated.

--
Allan

---------------------
Allan Hayes
Mathematica Training and Consulting
Leicester UK
www.haystack.demon.co.uk
hay at haystack.demon.co.uk
Voice: +44 (0)116 271 4198
Fax: +44 (0)870 164 0565


"Andrzej Kozlowski" <andrzej at tuins.ac.jp> wrote in message
news:a0k0ol$3om$1 at smc.vnet.net...
> I have not much to add to the above except the following brief comment.
> I first encountered this type of problems with version 3.0. I think, but
> I am not really sure, that they used to be worse then. At that time I
> adopted the following principle whcih I have followed ever since:
> whenever I copy and paste anything in Mathematica I first convert
> everything (the cell from which I copy and the cell into which I paste)
> into InputForm. Afterwards I convert everything to StandardForm or
> TraditionalForm as needed. I have never encountered any problems with
> this approach.
>
>
> Andrzej Kozlowski
> Toyama International University
> JAPAN
> http://platon.c.u-tokyo.ac.jp/andrzej/
>
> On Friday, December 28, 2001, at 04:41  PM, Alan Mason wrote:
>
> >
> > "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: Re: Searching for embedded zeros in list
  • Next by Date: Re: Meaning of @ ... not @@
  • Previous by thread: Re: Re: Front end problems!
  • Next by thread: ParamtricPlot3D