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

Re: Re: Front end problems!

• To: mathgroup at smc.vnet.net
• Subject: [mg32144] Re: [mg32127] Re: Front end problems!
• From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
• Date: Sat, 29 Dec 2001 03:57:34 -0500 (EST)
• Sender: owner-wri-mathgroup at wolfram.com

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