Call for all people presenting the Louis or Carl, Big trouble syndrom

*To*: mathgroup at smc.vnet.net*Subject*: [mg26333] Call for all people presenting the Louis or Carl, Big trouble syndrom*From*: Jacqueline Zizi <jazi at club-internet.fr>*Date*: Tue, 12 Dec 2000 02:54:46 -0500 (EST)*References*: <90kr7d$r49@smc.vnet.net> <200012100520.AAA06998@smc.vnet.net> <200012110238.VAA10112@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Call for all people presenting the Louis or Carl , Big trouble syndrom ---------------------------------------------------------------------------------- As I am still curious about this problem, please send your code if you bet for a bug. But please localize the "bug" just like Carl do it. For a localization, please see my last post to Louis. So, thanks to Carl K.Woll for his example as it is at the step,"simple". The "bug" is in fact an error that Carl does and it is very easy to point it out. Indeed: He defines : f:= If [g==1, x2=1; x1=-d/2] Mathematica understand: f:= If [g==1,(x2=1;) (x1=-d/2)] and Mathematica is right . Indeed the structure of If , if you ask Mathematica is the following: ?If "If[condition, t, f] gives t if condition evaluates to True, and f if it \ evaluates to False. If[condition, t, f, u] gives u if condition evaluates to \ neither True nor False." So the user did not respect this structure. He wrote If [---, ---; ---] he put a ; instead of a , for the second separator. Refering to my comparison of the skier, the "fall" is there. Now, why does Mathematica make this interpretation? Coming back to Louis's code and just taking one of the simplest thing that he wrote you find for example (see my last post to mathGroup) makswmat[n_, k_, c_] := Module[{}, setlatticedata[n, k, c]; Return[makswmat[]]; You can notice that the body of this function is composed of the application of 2 functions: 1) setlatticedata[n, k, c]; and 2) Return[makswmat[]]; So this should have been written (___; ____). Louis did not put the ( ), and in this case, Louis is quiet happy that Mathematica put parenthesis around 1) and 2) for him. Mathematica is a computer system, no more, so you can't want Mathematica to do something sometimes and not another time following the errors you are doing. In the case of Carl he encountered after the first ", " an expression which is : x2=1; x1=-d/2. As there is no other ", " this expression should be interpreted as one expression. There is at least 2 ways of putting parenthesis. This one (x2=1; ) * x1=-d/2 or the other way (x2=1; x1=-d/2 ). Now Carl set his code by going to the line after the ";". So it looks like the user wants the 1st interpretation. There is a way to avoid Mathematica such Choices and the user such problems. Keep as clean as possible in your way of coding. That is why in my proposal I gave: makswmat[n_, k_, c_] := (setlatticedata[n, k, c]; makswmat[]) Indeed, I get rid of what is not usefull and I put the ( ) around the ....; .... so that Mathematica don't have any guess to do about what I want. I hope that this mail is a one more step to understand this problem. Jacqueline Zizi , who still want a real example to be convinced that this syndrome is a bug ---------------------------------------------------------------------------------------------------------- "Carl K. Woll" wrote: > Hi all, > > Since many people seem to believe that the problem Louis is encountering is > not a bug, I just wanted to supply a notebook which has the parsing problem > that Louis is running into, at least when running on Windows. To reproduce > the bug, you will need to copy the notebook statement given at the end of my > post into Mathematica. Simply copying the following code will not reproduce > the bug. The notebook defines a function as follows: > > f:=If[g==1,x2=1; > x1=-d/2 > ] > > Basically, if g equals one, then two statements are supposed to be executed. > If one executes the above code, though, you will find out that the > definition of f is > > In[7]:= > ?f > > Global`f > f := If[g == 1, (x2 = 1; )*(x1 = -(d/2))] > > As you can see, the two statements are multiplied together, and so when g is > given the value 1 and f is exectued, we get > > In[13]:= > g = 1; > f > > Out[14]= > -(d Null) > --------- > 2 > > So, it appears that spurious Nulls are being introduced, just as Louis > reported. This particular bug can be remedied by any edit of the code. The > above code fragment is modified from a project I worked on a while ago, > where the bug would appear after I saved and reloaded a particular notebook. > The Wolfram recommended solution here is to set the option ShortBoxForm to > false. This worked for me, but it apparently didn't work for Louis. > > The notebook follows, just copy and paste into Mathematica. > > Notebook[{ > Cell[BoxData[ > \(f := If[g == 1, \(\(x2 = 1;\)\[IndentingNewLine] > x1 = \(-\(d\/2\)\)\)\[IndentingNewLine]]\)], "Input"], > > Cell[BoxData[ > \(\(?f\)\)], "Input"] > }, > FrontEndVersion->"4.0 for Microsoft Windows", > ScreenRectangle->{{0, 1024}, {0, 695}}, > Evaluator->"Local", > WindowSize->{913, 587}, > WindowMargins->{{27, Automatic}, {38, Automatic}}, > Magnification->1 > ] > > Carl Woll > Physics Dept > U of Washington > > ----- Original Message ----- > From: "David Bailey" <db at salford-software.com> To: mathgroup at smc.vnet.net > To: mathgroup at smc.vnet.net > Subject: [mg26333] [mg26323] [mg26301] Re: Big trouble with Mathematica Code parsing -- Rant. > > > > > "Louis M. Pecora" <pecora at anvil.nrl.navy.mil> wrote in message > > news:90kr7d$r49 at smc.vnet.net... > > > [[ This message was both posted and mailed: see > > > the "To," "Cc," and "Newsgroups" headers for details. ]] > > > > > > {\RANT ON} > > > > > > I have just spent another 3 hours debugging Mathematica code that, for > > > some reason unclear to me, insists on putting Null's into the return > > > values, as in > > > > > > 2 > > > Null Return[{1.0,2.9}] (in which the numbers are right, but the > > > Null's don't belong) > > > > > > Rather than just returning > > > > > > {1.0,2.9} > > > > > > Where are they coming from? Beats me. This is the third time in the > > > last month or so that I've spent the better part of a day (a few days > > > in some cases) trying hard to figure why Mathematica parses my code in > > > a brain-dead way. > > > > > > Beware. Adding white space and blank lines for readability can cause > > > Null's to appear and other problems. I suspect this is partly related > > > to the fact that space can be taken as a multiplication, but > > > eliminating spaces and blank lines may not cure the problem. I know. > > > I've tried. > > > > > > I've done things such as copy the code into a text editor then right > > > back to Mathematica and then it works...until I change something or > > > open up the file later and try to use it. Then I may get a syntax > > > error or just more Nulls, again. Sometimes recopying the code out and > > > in will fix it, again. Sometimes not. But what a Kludge! > > > > > > Mathematica is doing things behind the scenes to the text in its > > > parsing and it messes stuff up. Mathematica Support have responded > > > with hints such as Set Save in Box Form to False, eliminate white space > > > (there goes readability), make sure all lines end in ";" (that one, at > > > least, makes sense). I've done it all and still have problems. > > > > > > It is ridiculous when one of the most powerful sofeware packages in the > > > world cannot parse code correctly. It cannot handle simple, clear > > > white space correctly. And it insists on changing things which cause > > > failures. > > > > > > These are not feature or even bugs. They are FLAWS. > > > > > > Maybe it's the automatic indenting. I don't know. I am totally > > > frustrated. If anyone knows of anyway to turn off or on some setting > > > to get this program to just handle my code sensibly, PLEASE let me > > > know. > > > > > > I hope Wolfram is listening. There is a serious upgrade-FIX needed for > > > Mathematica 4.0. Right now I would not recommend this program to > > > anyone in my lab. > > > > > > {\RANT OFF} > > > > > > Obviously this is a problem which other Mathematica users are not > > encountering - so you clearly must give more details in order to sort this > > out. > > > > 1) On which platform are you running Mathematica (PC,MAC, etc.) > > 2) Are you creating a notebook or writing .M files. > > > > Assuming you are creating a notebook it might be an idea to make a typical > > corrupt notebook available on the internet somewhere and post the URL to > the > > newsgroup. (You can paste bits of notebook into messages, but in this case > > it might be safer to see the file absolutely raw!). > > > > I am sure this problem does not require an "upgrade-FIX", but is the > result > > of some unusual settings in the option inspector or something similar. > > > > David Bailey > > > > Salford Software > > > > > >

**References**:**Re: Big trouble with Mathematica Code parsing -- Rant.***From:*"David Bailey" <db@salford-software.com>

**Re: Re: Big trouble with Mathematica Code parsing -- Rant.***From:*"Carl K. Woll" <carlw@u.washington.edu>

**Re: Re: Big trouble with Mathematica Code parsing -- Rant.**

**Re: Re: Big trouble with Mathematica Code parsing -- Rant.**

**Re: Re: Big trouble with Mathematica Code parsing -- Rant.**

**Re: Call for all people presenting the Louis or Carl, Big trouble syndrom**