A21 You are of course right, I forgot that Mathematica does not try to keep precision or accuracy of machine arithmetic computations. But I think the actual precision you set need not be higher than machine precision, it just has to be set explicitely (is that right?). For example: In[1]:= Clear[f,a,b,k] In[2]:= k = $MachinePrecision; In[3]:= f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ (2*b),k]; In[4]:= a=77617.;b=33096.; In[5]:= a=SetAccuracy[a,k]; In[6]:= b=SetAccuracy[b,k]; In[7]:= f Out[7]= !((-5.51716400890319`-2.8311*^19)) In[8]:= Accuracy[f] Accuracy::mnprec: Value -23 would be inconsistent with $MinPrecision; bounding by $MinPrecision instead. Out[8]= -20 Andrzej > Andrzej Yes, like you I took the original question to be about how to get the > result > of using the naive rational versions in place of the inexact numbers. > Bobby raises the question of how we might know accuracy of the result. You answer this with > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 However this computation is done in machine arithmetic, which means > that > Mathematica keeps no check on the accuracy and precision of the > computation, > and Mathematica gives the default accuracy value without any real > signifcance: $MachinePrecision - Log[10,Abs[f]]//Round -5 To get meaningful accuracy and precision values we need to force the > computation to be in bignums (bigfloat, arbitrary precision) > arithmetic. > Mathematica then keeps track of the accuracy and precision that it can > guarantee. Clear[f,a,b,k] > k=50; f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; > a=77617.;b=33096.; > a=SetAccuracy[a,k]; > b=SetAccuracy[b,k]; > f -0.82739605995 Accuracy[f] 11 Precision[f] 11 Which tells us that the error in the computed value of f is not more > than 10^-11 > The above results are rounded. More accurately we get Accuracy[f, Round->False] 11.4956 Precision[f, Round->False] 11.4133 There are several related issues here: > - is the precision (accuracy) of rhe input known? > - how does Mathematica interpret what one gives it? > - how does Mathematica go about the calculation? -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other words, > it was why are the results of these two computations not the same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Actually, we don't know whether SetAccuracy succeeds, because we > don't > know how inexact those numbers really are. If they are known to more > digits than shown in the original post, they should be entered with > as > much precision as they deserve. If not, there's no trick or > algorithm > that will give the result precision, because the value of f really is > in the noise. That is, we have no idea what the value of f should > be. Mathematica's failing is in returning a value without pointing out > that > it has no precision. Bobby -----Original Message----- > Sent: Monday, September 30, 2002 11:59 AM Andrzej, Bobby, Peter It looks as if using SetAccuracy succeeds here because the inexact > numbers > that occur have finite binary representations. If we change them > slightly to > avoid this then we have to use Rationalize: 1) Using SetAccuracy Clear[a,b,f] > f=SetAccuracy[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > Infinity]; a=77617.1; > b=33096.1; a=SetAccuracy[a,Infinity];b=SetAccuracy[b,Infinity]; f > -1564032114908486835197494923989618867972540153873951942813115514949 > 3891236234 525007719168693704591197760187988046304361497869199129319625743010292 > 36 > 3 > 1246 > 75 / > 108671061439707605510003578275547938881981431359756495796079898677435 > 72 > 8240 > 16 > 0653953612982932181371232436367739737604096 2) Rewriting as fractions a=776171/10; > b=330961/10; f=33374/100*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+54/10*b^8+a/(2*b) -(5954133808997234115690303589909929091649391296257/ > 41370125000000) 3) Using Rationalize Clear[a,b,f] > f=Rationalize[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > 0]; a=77617.1; > b=33096.1; a=Rationalize[a,0];b=Rationalize[b,0]; f -(5954133808997234115690303589909929091649391296257/ > 41370125000000) > I use Rationalize[. , 0] besause of results like Rationalize[3.1415959] 3.1416 Rationalize[3.1415959,0] 31415959/10000000 > -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > Well, first of of all, your using SetAccuracy and SetPrecision does > nothing at all here, since they do not change the value of a or b. > You > should use a = SetAccuracy[a, Infinity] etc. But even then you won't > get the same answer as when you use exact numbers because of the > way > you evaluate f. Here is the order of evaluation that will give you > the > same answer, and should explain what is going on: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121* > b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity]; a = 77617.; > b = 33096.; a = SetAccuracy[a, Infinity]; b = SetAccuracy[b, Infinity]; f 54767 > -(-----) > 66192 Andrzej Kozlowski > Toyama International University > JAPAN > Could someone explain what is going on here, please? In[1]:= > a = 77617.; b = 33096.; In[2]:= > SetAccuracy[a, Infinity]; SetAccuracy[b, Infinity]; > SetPrecision[a, Infinity]; SetPrecision[b, Infinity]; In[4]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + > a/(2*b) In[5]:= > SetAccuracy[f, Infinity]; SetPrecision[f, Infinity]; In[6]:= > f Out[6]= > -1.1805916207174113*^21 In[7]:= > a = 77617; b = 33096; In[8]:= > g := (33375/100)*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > (55/10)*b^8 + a/(2*b) In[9]:= > g Out[9]= > -(54767/66192) In[10]:= > N[%] Out[10]= > -0.8273960599468214 > PK Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ ==== So? It's just as it should be, isn't it? Andrzej Andrzej Kozlowski Toyama International University JAPAN http://sigma.tuins.ac.jp/~andrzej/ > Go one step further: Clear[f, a, b, k] > k = $MachinePrecision; > f = SetAccuracy[333.75*b^6 + > a^2*(11*a^2*b^2 - b^6 - > 121*b^4 - 2) + > 5.5*b^8 + a/(2*b), k]; > a = 77617.; b = 33096.; > a = SetAccuracy[a, k]; > b = SetAccuracy[b, k]; > f > Accuracy[f] > Precision[f] -5.517164009`0*^19 Accuracy::mnprec:Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. -20 0 Accuracy::mnprec:Value !(-23) would be inconsistent with > $MinPrecision; > bounding by $MinPrecision instead. See that? NO precision. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 5:53 PM > Cc: drbob@bigfoot.com You are of course right, I forgot that Mathematica does not try to keep precision or accuracy of machine arithmetic computations. But I think > the actual precision you set need not be higher than machine precision, it just has to be set explicitely (is that right?). For example: In[1]:= > Clear[f,a,b,k] In[2]:= > k = $MachinePrecision; In[3]:= > f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; In[4]:= > a=77617.;b=33096.; In[5]:= > a=SetAccuracy[a,k]; In[6]:= > b=SetAccuracy[b,k]; > In[7]:= > f Out[7]= > !((-5.51716400890319`-2.8311*^19)) In[8]:= > Accuracy[f] Accuracy::mnprec: Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. Out[8]= > -20 > Andrzej Andrzej Yes, like you I took the original question to be about how to get the result > of using the naive rational versions in place of the inexact numbers. > Bobby raises the question of how we might know accuracy of the result. You answer this with > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 However this computation is done in machine arithmetic, which means > that > Mathematica keeps no check on the accuracy and precision of the > computation, > and Mathematica gives the default accuracy value without any real > signifcance: $MachinePrecision - Log[10,Abs[f]]//Round -5 To get meaningful accuracy and precision values we need to force the > computation to be in bignums (bigfloat, arbitrary precision) > arithmetic. > Mathematica then keeps track of the accuracy and precision that it can > guarantee. Clear[f,a,b,k] > k=50; f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; > a=77617.;b=33096.; > a=SetAccuracy[a,k]; > b=SetAccuracy[b,k]; > f -0.82739605995 Accuracy[f] 11 Precision[f] 11 Which tells us that the error in the computed value of f is not more than 10^-11 > The above results are rounded. More accurately we get Accuracy[f, Round->False] 11.4956 Precision[f, Round->False] 11.4133 There are several related issues here: > - is the precision (accuracy) of rhe input known? > - how does Mathematica interpret what one gives it? > - how does Mathematica go about the calculation? -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other words, > it was why are the results of these two computations not the same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that > its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything > wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Actually, we don't know whether SetAccuracy succeeds, because we > don't > know how inexact those numbers really are. If they are known to > more > digits than shown in the original post, they should be entered with as > much precision as they deserve. If not, there's no trick or > algorithm > that will give the result precision, because the value of f really > is > in the noise. That is, we have no idea what the value of f should > be. Mathematica's failing is in returning a value without pointing out > that > it has no precision. Bobby -----Original Message----- > Sent: Monday, September 30, 2002 11:59 AM Andrzej, Bobby, Peter It looks as if using SetAccuracy succeeds here because the inexact > numbers > that occur have finite binary representations. If we change them > slightly to > avoid this then we have to use Rationalize: 1) Using SetAccuracy Clear[a,b,f] > f=SetAccuracy[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > Infinity]; a=77617.1; > b=33096.1; a=SetAccuracy[a,Infinity];b=SetAccuracy[b,Infinity]; f > -1564032114908486835197494923989618867972540153873951942813115514949 > 3891236234 > 525007719168693704591197760187988046304361497869199129319625743010292 > 36 > 3 > 1246 > 75 / 108671061439707605510003578275547938881981431359756495796079898677435 > 72 > 8240 > 16 > 0653953612982932181371232436367739737604096 2) Rewriting as fractions a=776171/10; > b=330961/10; f=33374/100*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+54/10*b^8+a/(2*b) -(5954133808997234115690303589909929091649391296257/ > 41370125000000) 3) Using Rationalize Clear[a,b,f] > f=Rationalize[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > 0]; a=77617.1; > b=33096.1; a=Rationalize[a,0];b=Rationalize[b,0]; f -(5954133808997234115690303589909929091649391296257/ > 41370125000000) > I use Rationalize[. , 0] besause of results like Rationalize[3.1415959] 3.1416 Rationalize[3.1415959,0] 31415959/10000000 > -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > Well, first of of all, your using SetAccuracy and SetPrecision does > nothing at all here, since they do not change the value of a or b. You > should use a = SetAccuracy[a, Infinity] etc. But even then you > won't > get the same answer as when you use exact numbers because of the > way > you evaluate f. Here is the order of evaluation that will give you the > same answer, and should explain what is going on: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121* > b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity]; a = 77617.; > b = 33096.; a = SetAccuracy[a, Infinity]; b = SetAccuracy[b, Infinity]; f 54767 > -(-----) > 66192 Andrzej Kozlowski > Toyama International University > JAPAN > Could someone explain what is going on here, please? In[1]:= > a = 77617.; b = 33096.; In[2]:= > SetAccuracy[a, Infinity]; SetAccuracy[b, Infinity]; > SetPrecision[a, Infinity]; SetPrecision[b, Infinity]; In[4]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + > a/(2*b) In[5]:= > SetAccuracy[f, Infinity]; SetPrecision[f, Infinity]; In[6]:= > f Out[6]= > -1.1805916207174113*^21 In[7]:= > a = 77617; b = 33096; In[8]:= > g := (33375/100)*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > (55/10)*b^8 + a/(2*b) In[9]:= > g Out[9]= > -(54767/66192) In[10]:= > N[%] Out[10]= > -0.8273960599468214 > PK > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ ==== I think I'd prefer that Mathematica gave me a clue -- without being asked explicitly in JUST the right way that only you know and had forgotten -- that there's a precision problem. Oddly enough, when you DO ask it nicely, you get error messages, but if you're not aware there's a problem, it lets you go on your merry way, working with noise. Bobby -----Original Message----- Clear[f, a, b, k] > k = $MachinePrecision; > f = SetAccuracy[333.75*b^6 + > a^2*(11*a^2*b^2 - b^6 - > 121*b^4 - 2) + > 5.5*b^8 + a/(2*b), k]; > a = 77617.; b = 33096.; > a = SetAccuracy[a, k]; > b = SetAccuracy[b, k]; > f > Accuracy[f] > Precision[f] -5.517164009`0*^19 Accuracy::mnprec:Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. -20 0 Accuracy::mnprec:Value !(-23) would be inconsistent with > $MinPrecision; > bounding by $MinPrecision instead. See that? NO precision. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 5:53 PM > Cc: drbob@bigfoot.com You are of course right, I forgot that Mathematica does not try to keep precision or accuracy of machine arithmetic computations. But I think > the actual precision you set need not be higher than machine precision, it just has to be set explicitely (is that right?). For example: In[1]:= > Clear[f,a,b,k] In[2]:= > k = $MachinePrecision; In[3]:= > f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; In[4]:= > a=77617.;b=33096.; In[5]:= > a=SetAccuracy[a,k]; In[6]:= > b=SetAccuracy[b,k]; > In[7]:= > f Out[7]= > !((-5.51716400890319`-2.8311*^19)) In[8]:= > Accuracy[f] Accuracy::mnprec: Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. Out[8]= > -20 > Andrzej Andrzej Yes, like you I took the original question to be about how to get the result > of using the naive rational versions in place of the inexact numbers. > Bobby raises the question of how we might know accuracy of the result. You answer this with > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 However this computation is done in machine arithmetic, which means > that > Mathematica keeps no check on the accuracy and precision of the > computation, > and Mathematica gives the default accuracy value without any real > signifcance: $MachinePrecision - Log[10,Abs[f]]//Round -5 To get meaningful accuracy and precision values we need to force the > computation to be in bignums (bigfloat, arbitrary precision) > arithmetic. > Mathematica then keeps track of the accuracy and precision that it can > guarantee. Clear[f,a,b,k] > k=50; f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; > a=77617.;b=33096.; > a=SetAccuracy[a,k]; > b=SetAccuracy[b,k]; > f -0.82739605995 Accuracy[f] 11 Precision[f] 11 Which tells us that the error in the computed value of f is not more than 10^-11 > The above results are rounded. More accurately we get Accuracy[f, Round->False] 11.4956 Precision[f, Round->False] 11.4133 There are several related issues here: > - is the precision (accuracy) of rhe input known? > - how does Mathematica interpret what one gives it? > - how does Mathematica go about the calculation? -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other words, > it was why are the results of these two computations not the same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that > its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything > wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Actually, we don't know whether SetAccuracy succeeds, because we > don't > know how inexact those numbers really are. If they are known to > more > digits than shown in the original post, they should be entered with as > much precision as they deserve. If not, there's no trick or > algorithm > that will give the result precision, because the value of f really > is > in the noise. That is, we have no idea what the value of f should > be. Mathematica's failing is in returning a value without pointing out > that > it has no precision. Bobby -----Original Message----- > Sent: Monday, September 30, 2002 11:59 AM Andrzej, Bobby, Peter It looks as if using SetAccuracy succeeds here because the inexact > numbers > that occur have finite binary representations. If we change them > slightly to > avoid this then we have to use Rationalize: 1) Using SetAccuracy Clear[a,b,f] > f=SetAccuracy[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > Infinity]; a=77617.1; > b=33096.1; a=SetAccuracy[a,Infinity];b=SetAccuracy[b,Infinity]; f > -1564032114908486835197494923989618867972540153873951942813115514949 > 3891236234 > 525007719168693704591197760187988046304361497869199129319625743010292 > 36 > 3 > 1246 > 75 / 108671061439707605510003578275547938881981431359756495796079898677435 > 72 > 8240 > 16 > 0653953612982932181371232436367739737604096 2) Rewriting as fractions a=776171/10; > b=330961/10; f=33374/100*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+54/10*b^8+a/(2*b) -(5954133808997234115690303589909929091649391296257/ > 41370125000000) 3) Using Rationalize Clear[a,b,f] > f=Rationalize[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > 0]; a=77617.1; > b=33096.1; a=Rationalize[a,0];b=Rationalize[b,0]; f -(5954133808997234115690303589909929091649391296257/ > 41370125000000) > I use Rationalize[. , 0] besause of results like Rationalize[3.1415959] 3.1416 Rationalize[3.1415959,0] 31415959/10000000 > -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > Well, first of of all, your using SetAccuracy and SetPrecision does > nothing at all here, since they do not change the value of a or b. You > should use a = SetAccuracy[a, Infinity] etc. But even then you > won't > get the same answer as when you use exact numbers because of the > way > you evaluate f. Here is the order of evaluation that will give you the > same answer, and should explain what is going on: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121* > b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity]; a = 77617.; > b = 33096.; a = SetAccuracy[a, Infinity]; b = SetAccuracy[b, Infinity]; f 54767 > -(-----) > 66192 Andrzej Kozlowski > Toyama International University > JAPAN > Could someone explain what is going on here, please? In[1]:= > a = 77617.; b = 33096.; In[2]:= > SetAccuracy[a, Infinity]; SetAccuracy[b, Infinity]; > SetPrecision[a, Infinity]; SetPrecision[b, Infinity]; In[4]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + > a/(2*b) In[5]:= > SetAccuracy[f, Infinity]; SetPrecision[f, Infinity]; In[6]:= > f Out[6]= > -1.1805916207174113*^21 In[7]:= > a = 77617; b = 33096; In[8]:= > g := (33375/100)*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > (55/10)*b^8 + a/(2*b) In[9]:= > g Out[9]= > -(54767/66192) In[10]:= > N[%] Out[10]= > -0.8273960599468214 > PK > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ ==== I've been looking over the file and directory manipulation functions in Mathematica 4.1, and I'm not finding good examples of how to test for the existence of a file or directory before I attempt to create, access, or delete it. Are there any good examples of this somewhere? STH ==== FileNames[] does what you want. Steve Luttrell > I've been looking over the file and directory manipulation functions in Mathematica > 4.1, and I'm not finding good examples of how to test for the existence of > a file or directory before I attempt to create, access, or delete it. Are > there any good examples of this somewhere? STH > Reply-To: kuska@informatik.uni-leipzig.de ==== FileNames[] returns an empty list if there are no files. So FileNames[blub.txt] will return {} if the file does not exist. Jens > > I've been looking over the file and directory manipulation functions in Mathematica > 4.1, and I'm not finding good examples of how to test for the existence of > a file or directory before I attempt to create, access, or delete it. Are > there any good examples of this somewhere? > > STH ==== If you don't wont error messages all you need to do is to set MinPrecision low enough: In[1]:= $MinPrecision = -3; In[2]:= k = $MachinePrecision; In[3]:= f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + a/(2*b), k]; In[4]:= a = 77617.; b = 33096.; In[5]:= a = SetAccuracy[a, k]; In[6]:= b = SetAccuracy[b, k]; In[7]:= f Out[7]= -5.517164009`-2.8311*^19 In[8]:= Accuracy[f] Out[8]= -23 In[9]:= Precision[f] Out[9]= -3 In any case the answer you get is meaningless. > I think I'd prefer that Mathematica gave me a clue -- without being > asked explicitly in JUST the right way that only you know and had > forgotten -- that there's a precision problem. Oddly enough, when you DO ask it nicely, you get error messages, but if > you're not aware there's a problem, it lets you go on your merry way, > working with noise. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 8:05 PM > Cc: 'Allan Hayes'; mathgroup@smc.vnet.net So? It's just as it should be, isn't it? Andrzej Andrzej Kozlowski > Toyama International University > JAPAN > http://sigma.tuins.ac.jp/~andrzej/ > Go one step further: Clear[f, a, b, k] > k = $MachinePrecision; > f = SetAccuracy[333.75*b^6 + > a^2*(11*a^2*b^2 - b^6 - > 121*b^4 - 2) + > 5.5*b^8 + a/(2*b), k]; > a = 77617.; b = 33096.; > a = SetAccuracy[a, k]; > b = SetAccuracy[b, k]; > f > Accuracy[f] > Precision[f] -5.517164009`0*^19 Accuracy::mnprec:Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. -20 0 Accuracy::mnprec:Value !(-23) would be inconsistent with > $MinPrecision; > bounding by $MinPrecision instead. See that? NO precision. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 5:53 PM > Cc: drbob@bigfoot.com You are of course right, I forgot that Mathematica does not try to > keep precision or accuracy of machine arithmetic computations. But I think > the actual precision you set need not be higher than machine > precision, it just has to be set explicitely (is that right?). For example: In[1]:= > Clear[f,a,b,k] In[2]:= > k = $MachinePrecision; In[3]:= > f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; In[4]:= > a=77617.;b=33096.; In[5]:= > a=SetAccuracy[a,k]; In[6]:= > b=SetAccuracy[b,k]; > In[7]:= > f Out[7]= > !((-5.51716400890319`-2.8311*^19)) In[8]:= > Accuracy[f] Accuracy::mnprec: Value -23 would be inconsistent with $MinPrecision; > > bounding by $MinPrecision instead. Out[8]= > -20 > Andrzej Andrzej Yes, like you I took the original question to be about how to get the result > of using the naive rational versions in place of the inexact numbers. > Bobby raises the question of how we might know accuracy of the > result. You answer this with > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 However this computation is done in machine arithmetic, which means > that > Mathematica keeps no check on the accuracy and precision of the > computation, > and Mathematica gives the default accuracy value without any real > signifcance: $MachinePrecision - Log[10,Abs[f]]//Round -5 To get meaningful accuracy and precision values we need to force the > computation to be in bignums (bigfloat, arbitrary precision) > arithmetic. > Mathematica then keeps track of the accuracy and precision that it > can > guarantee. Clear[f,a,b,k] > k=50; f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; > a=77617.;b=33096.; > a=SetAccuracy[a,k]; > b=SetAccuracy[b,k]; > f -0.82739605995 Accuracy[f] 11 Precision[f] 11 Which tells us that the error in the computed value of f is not more than 10^-11 > The above results are rounded. More accurately we get Accuracy[f, Round->False] 11.4956 Precision[f, Round->False] 11.4133 There are several related issues here: > - is the precision (accuracy) of rhe input known? > - how does Mathematica interpret what one gives it? > - how does Mathematica go about the calculation? -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which > Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other > words, > it was why are the results of these two computations not the > same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that > its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything > wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Actually, we don't know whether SetAccuracy succeeds, because we > don't > know how inexact those numbers really are. If they are known to > more > digits than shown in the original post, they should be entered with as > much precision as they deserve. If not, there's no trick or > algorithm > that will give the result precision, because the value of f really > is > in the noise. That is, we have no idea what the value of f > should > be. Mathematica's failing is in returning a value without pointing out > that > it has no precision. Bobby -----Original Message----- > Sent: Monday, September 30, 2002 11:59 AM Andrzej, Bobby, Peter It looks as if using SetAccuracy succeeds here because the inexact > numbers > that occur have finite binary representations. If we change them > slightly to > avoid this then we have to use Rationalize: 1) Using SetAccuracy Clear[a,b,f] > f=SetAccuracy[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > Infinity]; a=77617.1; > b=33096.1; a=SetAccuracy[a,Infinity];b=SetAccuracy[b,Infinity]; f -1564032114908486835197494923989618867972540153873951942813115514949 > 3891236234 > 525007719168693704591197760187988046304361497869199129319625743010292 > 36 > 3 > 1246 > 75 / 108671061439707605510003578275547938881981431359756495796079898677435 > 72 > 8240 > 16 > 0653953612982932181371232436367739737604096 2) Rewriting as fractions a=776171/10; > b=330961/10; > f=33374/100*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+54/10*b^8+a/(2*b) > > -(5954133808997234115690303589909929091649391296257/ > 41370125000000) 3) Using Rationalize Clear[a,b,f] > f=Rationalize[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > 0]; a=77617.1; > b=33096.1; a=Rationalize[a,0];b=Rationalize[b,0]; f -(5954133808997234115690303589909929091649391296257/ > 41370125000000) > I use Rationalize[. , 0] besause of results like Rationalize[3.1415959] 3.1416 Rationalize[3.1415959,0] 31415959/10000000 > -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > Well, first of of all, your using SetAccuracy and SetPrecision > does > nothing at all here, since they do not change the value of a or b. You > should use a = SetAccuracy[a, Infinity] etc. But even then you > won't > get the same answer as when you use exact numbers because of the > way > you evaluate f. Here is the order of evaluation that will give you the > same answer, and should explain what is going on: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121* > b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity]; a = 77617.; > b = 33096.; a = SetAccuracy[a, Infinity]; b = SetAccuracy[b, Infinity]; f 54767 > -(-----) > 66192 Andrzej Kozlowski > Toyama International University > JAPAN > Could someone explain what is going on here, please? In[1]:= > a = 77617.; b = 33096.; In[2]:= > SetAccuracy[a, Infinity]; SetAccuracy[b, Infinity]; > SetPrecision[a, Infinity]; SetPrecision[b, Infinity]; In[4]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 > + > a/(2*b) In[5]:= > SetAccuracy[f, Infinity]; SetPrecision[f, Infinity]; In[6]:= > f Out[6]= > -1.1805916207174113*^21 In[7]:= > a = 77617; b = 33096; In[8]:= > g := (33375/100)*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > (55/10)*b^8 + a/(2*b) In[9]:= > g Out[9]= > -(54767/66192) In[10]:= > N[%] Out[10]= > -0.8273960599468214 > PK > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ ==== >>In any case the answer you get is meaningless. Precisely. Bobby -----Original Message----- 121*b^4 - 2) + 5.5*b^8 + a/(2*b), k]; In[4]:= a = 77617.; b = 33096.; In[5]:= a = SetAccuracy[a, k]; In[6]:= b = SetAccuracy[b, k]; In[7]:= f Out[7]= -5.517164009`-2.8311*^19 In[8]:= Accuracy[f] Out[8]= -23 In[9]:= Precision[f] Out[9]= -3 In any case the answer you get is meaningless. > I think I'd prefer that Mathematica gave me a clue -- without being > asked explicitly in JUST the right way that only you know and had > forgotten -- that there's a precision problem. Oddly enough, when you DO ask it nicely, you get error messages, but if > you're not aware there's a problem, it lets you go on your merry way, > working with noise. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 8:05 PM > Cc: 'Allan Hayes'; mathgroup@smc.vnet.net So? It's just as it should be, isn't it? Andrzej Andrzej Kozlowski > Toyama International University > JAPAN > http://sigma.tuins.ac.jp/~andrzej/ > Go one step further: Clear[f, a, b, k] > k = $MachinePrecision; > f = SetAccuracy[333.75*b^6 + > a^2*(11*a^2*b^2 - b^6 - > 121*b^4 - 2) + > 5.5*b^8 + a/(2*b), k]; > a = 77617.; b = 33096.; > a = SetAccuracy[a, k]; > b = SetAccuracy[b, k]; > f > Accuracy[f] > Precision[f] -5.517164009`0*^19 Accuracy::mnprec:Value -23 would be inconsistent with $MinPrecision; > bounding by $MinPrecision instead. -20 0 Accuracy::mnprec:Value !(-23) would be inconsistent with > $MinPrecision; > bounding by $MinPrecision instead. See that? NO precision. Bobby -----Original Message----- > Sent: Tuesday, October 01, 2002 5:53 PM > Cc: drbob@bigfoot.com You are of course right, I forgot that Mathematica does not try to > keep precision or accuracy of machine arithmetic computations. But I think > the actual precision you set need not be higher than machine > precision, it just has to be set explicitely (is that right?). For example: In[1]:= > Clear[f,a,b,k] In[2]:= > k = $MachinePrecision; In[3]:= > f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; In[4]:= > a=77617.;b=33096.; In[5]:= > a=SetAccuracy[a,k]; In[6]:= > b=SetAccuracy[b,k]; > In[7]:= > f Out[7]= > !((-5.51716400890319`-2.8311*^19)) In[8]:= > Accuracy[f] Accuracy::mnprec: Value -23 would be inconsistent with $MinPrecision; > > bounding by $MinPrecision instead. Out[8]= > -20 > Andrzej Andrzej Yes, like you I took the original question to be about how to get the result > of using the naive rational versions in place of the inexact numbers. > Bobby raises the question of how we might know accuracy of the > result. You answer this with > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 > > However this computation is done in machine arithmetic, which means > that > Mathematica keeps no check on the accuracy and precision of the > computation, > and Mathematica gives the default accuracy value without any real > signifcance: $MachinePrecision - Log[10,Abs[f]]//Round -5 To get meaningful accuracy and precision values we need to force the > computation to be in bignums (bigfloat, arbitrary precision) > arithmetic. > Mathematica then keeps track of the accuracy and precision that it > can > guarantee. Clear[f,a,b,k] > k=50; f=SetAccuracy[333.75*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.5*b^8+a/ > (2*b),k]; > a=77617.;b=33096.; > a=SetAccuracy[a,k]; > b=SetAccuracy[b,k]; > f -0.82739605995 Accuracy[f] 11 Precision[f] 11 Which tells us that the error in the computed value of f is not more than 10^-11 > The above results are rounded. More accurately we get Accuracy[f, Round->False] 11.4956 Precision[f, Round->False] 11.4133 There are several related issues here: > - is the precision (accuracy) of rhe input known? > - how does Mathematica interpret what one gives it? > - how does Mathematica go about the calculation? -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 message > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which > Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other > words, > it was why are the results of these two computations not the > same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that > its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything > wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Actually, we don't know whether SetAccuracy succeeds, because we > don't > know how inexact those numbers really are. If they are known to > more > digits than shown in the original post, they should be entered with as > much precision as they deserve. If not, there's no trick or > algorithm > that will give the result precision, because the value of f really > is > in the noise. That is, we have no idea what the value of f > should > be. Mathematica's failing is in returning a value without pointing out > that > it has no precision. Bobby -----Original Message----- > Sent: Monday, September 30, 2002 11:59 AM Andrzej, Bobby, Peter It looks as if using SetAccuracy succeeds here because the inexact > numbers > that occur have finite binary representations. If we change them > slightly to > avoid this then we have to use Rationalize: 1) Using SetAccuracy > > Clear[a,b,f] > f=SetAccuracy[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > Infinity]; a=77617.1; > b=33096.1; a=SetAccuracy[a,Infinity];b=SetAccuracy[b,Infinity]; f -1564032114908486835197494923989618867972540153873951942813115514949 > 3891236234 > 525007719168693704591197760187988046304361497869199129319625743010292 > 36 > 3 > 1246 > 75 / 108671061439707605510003578275547938881981431359756495796079898677435 > 72 > 8240 > 16 > 0653953612982932181371232436367739737604096 2) Rewriting as fractions a=776171/10; > b=330961/10; > f=33374/100*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+54/10*b^8+a/(2*b) -(5954133808997234115690303589909929091649391296257/ > 41370125000000) 3) Using Rationalize Clear[a,b,f] > f=Rationalize[333.74*b^6+a^2*(11*a^2*b^2-b^6-121*b^4-2)+5.4*b^8+a/ > (2*b), > 0]; a=77617.1; > b=33096.1; a=Rationalize[a,0];b=Rationalize[b,0]; f -(5954133808997234115690303589909929091649391296257/ > 41370125000000) > I use Rationalize[. , 0] besause of results like Rationalize[3.1415959] 3.1416 Rationalize[3.1415959,0] 31415959/10000000 > -- > Allan --------------------- > Allan Hayes > Mathematica Training and Consulting > Leicester UK > www.haystack.demon.co.uk > hay@haystack.demon.co.uk > Voice: +44 (0)116 271 4198 > Well, first of of all, your using SetAccuracy and SetPrecision > does > nothing at all here, since they do not change the value of a or b. You > should use a = SetAccuracy[a, Infinity] etc. But even then you > won't > get the same answer as when you use exact numbers because of the > way > you evaluate f. Here is the order of evaluation that will give you the > same answer, and should explain what is going on: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121* > b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity]; a = 77617.; > b = 33096.; a = SetAccuracy[a, Infinity]; b = SetAccuracy[b, Infinity]; f 54767 > -(-----) > 66192 Andrzej Kozlowski > Toyama International University > JAPAN > Could someone explain what is going on here, please? In[1]:= > a = 77617.; b = 33096.; In[2]:= > SetAccuracy[a, Infinity]; SetAccuracy[b, Infinity]; > SetPrecision[a, Infinity]; SetPrecision[b, Infinity]; In[4]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 > + > a/(2*b) In[5]:= > SetAccuracy[f, Infinity]; SetPrecision[f, Infinity]; In[6]:= > f Out[6]= > -1.1805916207174113*^21 In[7]:= > a = 77617; b = 33096; In[8]:= > g := (33375/100)*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > (55/10)*b^8 + a/(2*b) In[9]:= > g Out[9]= > -(54767/66192) In[10]:= > N[%] Out[10]= > -0.8273960599468214 > PK > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ ==== >Many thanks to all who replied. > >The original problem was as follows: > >In a presentation I wish to use Plot to generate a sequence of frames and >then animate them. The problem is that the audience sees the animation >twice. Once when the frames are being generated and then again after I have >closed the group and double clicked on the top graphic. However, the first >showing during generation is enough (but uncontrolled). > >Is it possible to tidy up the generation of the graphic so that it becomes >the animation? >There were two main solutions which I now apply to my real problem and not >the simple, generic, problem in the original post. >The real problem was how to build up a probably density function (PDF) in >real time. In the examples below I redraw the PDF every time I add 10 >points. > >Initialise <<<<< JLink`; >wb=WeibullDistribution[2.101349094155377,22.58126779173235`]; >midpts=Table[i,{i,0.5,50,1}]; > >Solution from Omega Consulting > >GraphicCell[graphics_] := > Cell[GraphicsData[PostScript, DisplayString[graphics]],Graphics] > >Block[{$DisplayFunction=Identity, graphs}, > data={}; > graphs = > Table[data=Flatten[Join[data,RandomArray[wb,10]]]; > freq=BinCounts[data,{0,50,1}]; > GraphicCell[ > BarChart[Transpose[{freq,midpts}],ImageSize ->500] ], {500}]; > NotebookWrite[EvaluationNotebook[],Cell[CellGroupData[graphs,Closed]]]; > SelectionMove[EvaluationNotebook[], All, GeneratedCell]; > FrontEndExecute[{FrontEndToken[EvaluationNotebook[], > SelectionAnimate]}] > ] > >This solution works but it generates 500 frames and sometimes exceeds the >memory. >The paradigm here is generate all frames, then animate all frames. We >really need a loop that does: generate next frame, delete last frame, show next frame > >Is it possible to do this? Yes, however, I thought you didn't want to see the selection bar moving around during the animation. That's why I chose to generate the whole animation in one shot. Also, when you write the new cell over the old cell there is a flash between frames as the old frame is deleted. Here's an example of a frame-by-frame method. GraphicCell[graphics_] := Cell[GraphicsData[PostScript, DisplayString[graphics]],Graphics] CellPrint[Cell[,Graphics]]; Block[{$DisplayFunction=Identity}, Do[ SelectionMove[EvaluationNotebook[], All, GeneratedCell]; NotebookWrite[EvaluationNotebook[], GraphicCell[Plot[x y,{x,0,1}, PlotRange->{0,50}]]], {y,50} ] ] Also, if you add ShowCellBracket->False to GraphicCell and a Pause to the loop, then things get much better visually. -------------------------------------------------------------- Omega Consulting The final answer to your Mathematica needs Spend less time searching and more time finding. http://www.wz.com/internet/Mathematica.html ==== I am trying to use FindRoot in mathematica 4.0 to find the zeros of a complex-valued function of one complex variable. In particular, I am looking for the one root with a positive imaginary part. I have a rough approximation for where the root should be, and this is good enough to give a reasonable guess. However, there are always two other roots near the one I want - one with 0 imaginary part and another with negative imag part. (For those who are interested, the zeros are the roots of the dispersion relation for a plasma interacting with a laser). Sometimes FindRoot picks up one of these instead of the one I want. So, I'd like to tell mathematica to look for a root only in a certain rectangular region of the complex plane. Well, if I could tell it, 'look for roots with imag. part > something', I'd be happy too. I tried specifying complex values for the start and stop points of an interval, hoping mathematica would interpret these as the corners of a rectangle. No such luck. Any help would be greatly appreciated. I'd also like to point out that this and other issues about complex roots are not clearly addressed in the built-in help files. ==== Just a shot: Try using the DampingFactor option to force FindRoot to take smaller steps. --- Selwyn Hollis ==== > > > I am trying to use FindRoot in mathematica 4.0 to find the zeros of a > complex-valued function of one complex variable. In particular, I am > looking for the one root with a positive imaginary part. I have a rough > approximation for where the root should be, and this is good enough to > give a reasonable guess. > > However, there are always two other roots near the one I want - one with > 0 imaginary part and another with negative imag part. (For those who > are interested, the zeros are the roots of the dispersion relation for a > plasma interacting with a laser). Sometimes FindRoot picks up one of > these instead of the one I want. > > So, I'd like to tell mathematica to look for a root only in a certain > rectangular region of the complex plane. Well, if I could tell it, > 'look for roots with imag. part > something', I'd be happy too. > > I tried specifying complex values for the start and stop points of an > interval, hoping mathematica would interpret these as the corners of a > rectangle. No such luck. > > Any help would be greatly appreciated. > > I'd also like to point out that this and other issues about complex > roots are not clearly addressed in the built-in help files. > I believe it is difficult to restrict FindRoot. Below are several suggestions. (1) You might try rigging the function, say with g[x_?NumberQ] := f[x] + If[Im[x]<=0,1000,0] (2) If you have version 4.2 a related approach would be to take advantage of constrained optimization and do NMinimize[{Re[f[x,y]]^2 + Im[f[x,y]]^2, rectangle range constraints}, {x,y}] or something along those lines. (3) If proximity of the other roots is the main problem it might be alleviated by rescaling your variable. (4) Alternatively you could write your function as a pair of real valued functions of two real valued arguments. Then you can use Interval to split the rectangle into parts, keeping subrectangles for which {0,0} lives in f[Interval[x],Interval[y]] where Interval[x], for example, is a shorthand for an interval for the x part of the rectangle being split. Daniel Lichtblau Wolfram Research Reply-To: kuska@informatik.uni-leipzig.de ==== and solving the real and imaginary part for for z->x+I*y with FindRoot[Evaluate[({Re[#] == 0, Im[#] == 0} &[ z^3 - 1]) /. z -> x + I y], {x, -3/2, 0}, {y, 0.5, 0.9}] helps not ? Jens > > > I am trying to use FindRoot in mathematica 4.0 to find the zeros of a > complex-valued function of one complex variable. In particular, I am > looking for the one root with a positive imaginary part. I have a rough > approximation for where the root should be, and this is good enough to > give a reasonable guess. > > However, there are always two other roots near the one I want - one with > 0 imaginary part and another with negative imag part. (For those who > are interested, the zeros are the roots of the dispersion relation for a > plasma interacting with a laser). Sometimes FindRoot picks up one of > these instead of the one I want. > > So, I'd like to tell mathematica to look for a root only in a certain > rectangular region of the complex plane. Well, if I could tell it, > 'look for roots with imag. part > something', I'd be happy too. > > I tried specifying complex values for the start and stop points of an > interval, hoping mathematica would interpret these as the corners of a > rectangle. No such luck. > > Any help would be greatly appreciated. > > I'd also like to point out that this and other issues about complex > roots are not clearly addressed in the built-in help files. > ==== The last part of my message you are quoting was completely wrong, as was pointed out by Allan Hayes. Mathematica does not track precision of machine arithmetic computations. In order for Mathematica to give reliable information about the precision of a computation you have to explicitly set the precision of all the numerical quantities. Your own example at the bottom simply shows you have not understood the evaluation mechanism of Mathematica. What you are doing is this: In[1]:= a = SetAccuracy[77617., Infinity]; b = SetAccuracy[33096., Infinity]; At this point you have converted a and be to have the following exact values: In[3]:= a Out[3]= 77617 In[4]:= b Out[4]= 33096 Next you evaluate: f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + a/(2*b), Infinity] but this is a two step process (which is what you seem not to have grasped). First Mathematica computes: In[5]:= 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + a/(2*b) Out[5]= 1.1805916207174113*^21 Now, because there were machine floats in the formula (333.75 and 5.5 ) the whole expression was computed using machine arithmetic without keeping track of precision. The answer is therefore completely inacurate. Mathematica returns the purely formal accuracy: In[6]:= Accuracy[%] Out[6]= -5 But the second part of your evaluation tells it to take this inaccurate answer and convert it to an exact number. In[7]:= SetAccuracy[%%, Infinity] Out[7]= 1180591620717411303424 In[8]:= Accuracy[%] Out[8]= Infinity But of course doing this is meaningless, after converting an inexact answer to an exact number does not make it a an exact answer! Of course had you evaluated f before you assigned the values to a and b you would not have encountered the problem because no machine reals would have appeared in the computation. ALternatively you might have used: f = SetAccuracy[333.75, Infinity]*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + SetAccuracy[5.5, Infinity]*b^8 + a/(2*b) Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ > It seems clear to me that what Allan and what you mean by succeeds > here refer to quite different things and your objection is therefore > beside the point. There are obviously two ways in which one can > interpret the original posting. The first interpretation, which Allan > and myself adopted, was that the question concerned purely the > computational mechanism of Mathematica. Or, to put it in other words, > it was why are the results of these two computations not the same?. > In this sense success means no more than making Mathematica return > the same answer using the two different routes the original poster > used. > You on the other hand choose to assume that the posting shows that its > author does not understand not just the mechanism of significance > arithmetic used by Mathematica but also computations with inexact > numbers in general. I do not think this is necessarily the correct > assumption. I also don't see that Mathematica is doing anything wrong. > After all, one can always check the accuracy of your answer: In[1]:= > a = 77617.; b = 33096.; In[2]:= > f := 333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + > 5.5*b^8 + a/(2*b) In[3]:= > f Out[3]= > -1.1805916207174113*^21 In[4]:= > Accuracy[%] Out[4]= > -5 which tells you that it can't be very reliable. What more do you > demand? > As you are dealing here only with machine-precision numbers, your When you do calculations with arbitrary-precision numbers, as > discussed in the previous section, Mathematica always keeps track of > the precision of your results, and gives only those digits which are > known to be correct, given the precision of your input. When you do > calculations with machine-precision numbers, however, Mathematica > always gives you a machine-Áçprecision result, whether or not all the > digits in the result can, in fact, be determined to be correct on the > basis of your input. In practice, to rely on a numerical result, you ALWAYS have to check > its accuracy. How reliable is Accuracy anyway? In[1]:= > a = SetAccuracy[77617., Infinity]; > b = SetAccuracy[33096., Infinity]; In[3]:= > f = SetAccuracy[333.75*b^6 + > a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + 5.5*b^8 + > a/(2*b), Infinity] Out[3]= > 1180591620717411303424 In[4]:= > Accuracy[f] Out[4]= > Infinity We got completely wrong result with Infinite accuracy. In conclusion, > one can not rely on Accuracy. Checking numerical results in > Mathematica sounds like a tough task.:-) --PK Andrzej > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ [...] > ==== leap to MathGroup so I'll respond there as well to some of the issues raised herein. > > Daniel, > >>The precision/accuracy tracking mechanism will generally let you know, >>in some fashion, that you have no trustworthy digits. But it is up to >>the user to check that sort of thing. > > In this case Mathematica did NOT let us know, in any fashion, that we > had no trustworthy digits. Precision and Accuracy outputs were > completely misleading. (16 and -5 respectively.) Precision, in this case, is itself a bit misleading. As I recall machine arithmetic was in use. For that domain just regard 16 as the definition of precision. Moreover no tracking is done. It is only when bignums are used that significance arithmetic will be at play. By the way, the distinction between precision for machine numbers vs. bignums will be more clear with our next big release. At present one does not know if 16 refers to a machine number or a bignum of that same precision. > Even Andrzej > Kozlowski, who's adept in Mathematica, thought that would be meaningful, > and never came up with a better way to check (other than using infinite > precision for numbers that probably aren't known that exactly). Peter > Kosta demonstrated that he could get a completely erroneous answer with > Infinite precision. > > I blame the problem primarily, and I don't think there's any way to make > the answer meaningful. That's not Mathematica's fault at all, and users > need to be aware of that old maxim: garbage in, garbage out. Right. One cannot artificially raise precision or accuracy after the fact and expect a meaningful result. Again, had significance arithmetic been used, I think there would have been adequate information to assess the problem. > comes up with a 22-digit result, it doesn't take much sophistication to > realize the answer can't have 16-digit precision. > > Here's an even more extreme result: > > f = SetAccuracy[333.75*b^6 + a^2*(11*a^2*b^2 - b^6 - > 121*b^4 - 2) + 5.5*b^8 + a/(2*b), 50]; > a = 77617.; b = 33096.; > f > Precision[f] > > -1.180591620717411303424`71.0721*^21 > 71 > > 71.0721 digits of precision? I don't think so!! It's correct, albeit the number is garbage. You start with a number that is, in your words, all noise. (I assume you had set a and b before f, because otherwise I get a different result for Precision[f]). Now f ~ 10^21, and so has accuracy of around 71 digits. Garbage notwithstanding, this behavior is entirely correct and as it should be. > We can do the following instead: > > x = Interval[333.75]; > y = Interval[5.5]; > a = Interval[77617.]; > b = Interval[33096.]; > x*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + y*b^8 + a/(2*b) > > Interval[{-4.486248158726164*^22, 4.2501298345826815*^22}] > > and that looks like the right answer, finally!! I like that method. Yes, it's a useful way to show that the result has no digits to trust. Actually you can achieve a similar effect using significance arithmetic, as below. x = SetPrecision[33375/100, 16]; y = SetPrecision[11/2, 16]; a = SetPrecision[77617, 16]; b = SetPrecision[33096, 16]; In[18]:= InputForm[x*b^6 + a^2*(11*a^2*b^2 - b^6 - 121*b^4 - 2) + y*b^8 + a/(2*b)] Out[18]//InputForm= -1.1339143158169`0*^14 This tells you there are NO reliable digits. The advantage to this is that is is more flexible than interval arithmetic in Mathematica which will not, for example, deal well with complex-valued functions or complex domains. Also significance arithmetic (aka arbitrary precision arithmetic) is much faster than interval arithmetic for large problems. > However, that doesn't change the fact that Accuracy, Precision, and > SetAccuracy appear to be completely useless. My own experience is that they are quite useful. But only if used with care and in appropriate ways. Raising accuracy after the fact does not fall into that category. > I haven't seen an example > in which they did what anyone (but you) thought they should do. > > Bobby Maybe. But, curiously enough, I am a user rather than developer when it comes to that stuff. I used the precision mechanism alot in polynomial NSolve, and it did indeed work to my liking. Which counts for something from the ordinary users' perspective, because now NSolve works better than it otherwise might. > -----Original Message----- > > > I think I'd prefer that Mathematica gave me a clue -- without being > asked explicitly in JUST the right way that only you know and had > forgotten -- that there's a precision problem. > > Oddly enough, when you DO ask it nicely, you get error messages, but > if > you're not aware there's a problem, it lets you go on your merry way, > working with noise. > > Bobby > > Mathematica is not a mind reader. But the evaluation sequence, while > complicated, is reasonably well documented. If you perform machine > arithmetic, or for that matter significance arithmetic, and there is > massive cancellation error, no use of SetAccuracy after the fact will > fix it. > > The precision/accuracy tracking mechanism will generally let you know, > in some fashion, that you have no trustworthy digits. But it is up to > the user to check that sort of thing. It is not obvious to me what sort > of error the software might notice to report. If you have a concise > example of input, and expected output, I can look further. I've not seen > anything in this thread that struck me as a failure of the software to > warn the user, but maybe I missed something. > > Daniel Daniel Lichtblau Wolfram Research ==== > > The more I play with the example the more depressing it gets. Start > with floating point numbers but explicitely arbitrary-precision ones. > > In[1]:= > a=77617.00000000000000000000000000000; > b=33095.00000000000000000000000000000; > > In[3]:= > !(333.7500000000000000000000000000000 b^6 + a^2 ((11 a^2 > b^2 - > b^6 - 121 b^4 - 2)) + 5.500000000000000000000000000000 b^8 + > a/(2 > b)) > > Out[3]= > !((-4.78339168666055402578083604864320577443814`26.6715*^32)) > > In[4]:= > Accuracy[%] > > Out[4]= > -6 > > Due to the manual section 3.1.6: > > When you do calculations with arbitrary-precision numbers, as > discussed in the previous section, Mathematica always keeps track of > the precision of your results, and gives only those digits which are > known to be correct, given the precision of your input. When you do > calculations with machine-precision numbers, however, Mathematica > always gives you a machine[CapitalEth]precision result, whether or not all the > digits in the result can, in fact, be determined to be correct on the > basis of your input. > > Because I started with arbitrary-precision numbers Mathematica should display > only those digits that are correct, that is none. No, 26 digits are correct (check Precision instead of Accuracy to see this). You appear to be showing output in InputForm. If you use OutputForm or StandardForm only 26 digits will be shown. 32 Out[3]= -4.7833916866605540257808360 10 InputForm is showing more because it exposes bad digits as well as good ones. > To relax a bit, set a new input cell to StandardForm and type > 77617.000000000000000000000000000000000 > > Convert it to InputForm. You get > 77616.999999999999999999999999999999999999999999952771`37.9031 > > Convert back to StandardForm > 77616.99999999999999999999999999999999999999999976637`37.9031 > > Again to InputForm > 77616.99999999999999999999999999999999999999999963735`37.9031 > > Back to StandardForm > 77616.99999999999999999999999999999999999999999951376`37.9031 > > See what you can get if you have enough patience or a small program. > > PK Agreed, it's not very pretty. I am uncertain as to whether this indicates a bug in StandardForm or elsewhere in the underlying numerics code, and will defer to our numerics experts on that issue. My guess is it is a bug if only because it violates the spirit of IEEE arithmetic wherein floats that have integer values should be representable as such (or something to that effect). I will point out, however, that the two numbers in question are equal to the specified precision. Also it appears to be improved in our development kernel. Daniel Lichtblau Wolfram Research ==== The more I play with the example the more depressing it gets. Start with floating point numbers but explicitely arbitrary-precision ones. In[1]:= a=77617.00000000000000000000000000000; b=33095.00000000000000000000000000000; In[3]:= !(333.7500000000000000000000000000000 b^6 + a^2 ((11 a^2 b^2 - b^6 - 121 b^4 - 2)) + 5.500000000000000000000000000000 b^8 + a/(2 b)) Out[3]= !((-4.78339168666055402578083604864320577443814`26.6715*^32)) In[4]:= Accuracy[%] Out[4]= -6 Due to the manual section 3.1.6: When you do calculations with arbitrary-precision numbers, as discussed in the previous section, Mathematica always keeps track of the precision of your results, and gives only those digits which are known to be correct, given the precision of your input. When you do calculations with machine-precision numbers, however, Mathematica always gives you a machine[CapitalEth]precision result, whether or not all the digits in the result can, in fact, be determined to be correct on the basis of your input. Because I started with arbitrary-precision numbers Mathematica should display only those digits that are correct, that is none. To relax a bit, set a new input cell to StandardForm and type 77617.000000000000000000000000000000000 Convert it to InputForm. You get 77616.999999999999999999999999999999999999999999952771`37.9031 Convert back to StandardForm 77616.99999999999999999999999999999999999999999976637`37.9031 Again to InputForm 77616.99999999999999999999999999999999999999999963735`37.9031 Back to StandardForm 77616.99999999999999999999999999999999999999999951376`37.9031 See what you can get if you have enough patience or a small program. PK ==== > The more I play with the example the more depressing it gets. Start > with floating point numbers but explicitely arbitrary-precision ones. > > In[1]:= > a=77617.00000000000000000000000000000; > b=33095.00000000000000000000000000000; > > In[3]:= > !(333.7500000000000000000000000000000 b^6 + a^2 ((11 a^2 > b^2 - > b^6 - 121 b^4 - 2)) + 5.500000000000000000000000000000 b^8 + > a/(2 > b)) > > Out[3]= > !((-4.78339168666055402578083604864320577443814`26.6715*^32)) > > In[4]:= > Accuracy[%] > > Out[4]= > -6 > > Due to the manual section 3.1.6: > > When you do calculations with arbitrary-precision numbers, as > discussed in the previous section, Mathematica always keeps track of > the precision of your results, and gives only those digits which are > known to be correct, given the precision of your input. When you do > calculations with machine-precision numbers, however, Mathematica > always gives you a machine[CapitalEth]precision result, whether or not all the > digits in the result can, in fact, be determined to be correct on the > basis of your input. > > Because I started with arbitrary-precision numbers Mathematica should display > only those digits that are correct, that is none. I retract the above comment. I did not notice that was an error in the input. b=33095.00000000000000000000000000000 intstead of intended b=33096.00000000000000000000000000000 I am sorry for the mistake. PK > > > To relax a bit, set a new input cell to StandardForm and type > 77617.000000000000000000000000000000000 > > Convert it to InputForm. You get > 77616.999999999999999999999999999999999999999999952771`37.9031 > > Convert back to StandardForm > 77616.99999999999999999999999999999999999999999976637`37.9031 > > Again to InputForm > 77616.99999999999999999999999999999999999999999963735`37.9031 > > Back to StandardForm > 77616.99999999999999999999999999999999999999999951376`37.9031 > > See what you can get if you have enough patience or a small program. > > PK ==== > The last part of my message you are quoting was completely wrong, as > was pointed out by Allan Hayes. Mathematica does not track precision of > machine arithmetic computations. In order for Mathematica to give > reliable information about the precision of a computation you have to > explicitly set the precision of all the numerical quantities. > > Your own example at the bottom simply shows you have not understood the > evaluation mechanism of Mathematica. Just opposite, thanks to you and other participants, I completely understood it. SetAccuracy just takes anything and calls it accurate. This behavior is useless if not stupid. It was apparently intended by Mathematica developers but that doesn't make it right. On a side note, I hate the argument It is descibed in the manual, therefore it is correct. Legal doesn't mean right. Besides there is no supreme court here to overrule some stupid law. :-) PK > > [...] ==== >Dear Colleagues, > >I calculated: > >Sum[1/Prime[n], {n, 15000}] // N > >Result: 2.74716 > >Now I wonder if this sum will converge or keep on growing, albeit very >slowly. >Matthias Bode >Sal. Oppenheim jr. & Cie. KGaA >Koenigsberger Strasse 29 >D-60487 Frankfurt am Main >GERMANY >Mobile: +49(0)172 6 74 95 77 >Internet: http://www.oppenheim.de > The serie is divergent! I suggest you to look at this beautiful introduction to primes distribution http://www.maths.ex.ac.uk/%7Emwatkins/zeta/vardi.html Bye, rob Roberto Brambilla CESI Via Rubattino 54 20134 Milano tel +39.02.2125.5875 fax +39.02.2125.5492 rlbrambilla@cesi.it ==== > I've been looking over the file and directory manipulation functions in Mathematica > 4.1, and I'm not finding good examples of how to test for the existence of > a file or directory before I attempt to create, access, or delete it. Are > there any good examples of this somewhere? STH Steven, Directory[] returns the current directory $Path returns the directories in your path where files can be found. SetDirectory[] changes to the specified directory and makes it the current directory. FileNames[] returns a list of all the file names (text documents, picture documents etc) and subdirectory (folder) names in the current directory. Since FileNames returns a list of elements, you can use all sorts of tests to see if a file you're looking for is in a said directory or not or whether it is a subdirectory or not. I hope that this will get you started. Yas ==== has anybody tried to modify the classes.m package in the way, it would be possible to have several superclasses? Oleg. ==== What does this page say, auf Englisch? I only pretend to understand German. http://www.mertig.com/neu/HTMLLinks/index_6.html STH ==== The sum diverges. See Elementary Number Theory, 5th edition by David M. Burton, pages 355-356. -----Original Message----- Sal. Oppenheim jr. & Cie. KGaA Koenigsberger Strasse 29 D-60487 Frankfurt am Main GERMANY Mobile: +49(0)172 6 74 95 77 Internet: http://www.oppenheim.de ==== Technical support has responded to my query. They say that one of the simplifications that Mathematica does when using Simplify is to Factor the expression, and factoring an expression consisting of inexact numbers leads to the type of behavior I observed. They stated that changing the behavior of Simplify to avoid the problems I noticed would make Simplify less capable, and that the majority of users would prefer to have Simplify behave the way it currently does. Of course, that doesn't answer the question about why the number of terms in the expression would cause the coefficients to go from rational to inexact to rational again. At any rate, I have another lesson learned. When using Simplify, check the result if you are mixing infinite precision and inexact numbers, as the result may not be what you wanted. In the past I always assumed that the result of using Simplify on an expression produced a result equivalent to the original expression, but now I discover that this is not true. Carl Woll Physics Dept U of Washington ----- Original Message ----- > {i, > n}]], x[1]] Now lets try CW for the first 100 values of n: > In[30]:= > Table[CW[n], {n, 100}] Out[30]= > {1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, > 0.5`12.3085, 0.5`12.0074, 0.5`11.7064, 0.5`11.4054, > 0.5`11.1043, 0.5`10.8033, 0.5`10.5023, 0.5`10.2012, > 0.5`9.9002, 0.5`9.5992, 0.5`9.2982, 0.5`8.9971, > 0.5`8.6961, 0.5`8.3951, 0.5`8.094, 0.5`7.793, 0.5`7.492, > 0.5`7.1909, 0.5`6.8899, 0.5`6.5889, 0.5`6.2879, > 0.5`5.9868, 0.5`5.6858, 0.5`5.3848, 0.5`5.0837, > 0.5`4.7827, 0.5`4.4817, 0.5`4.1806, 0.5`3.8796, > 0.5`3.5786, 0.5`3.2776, 0.5`2.9765, 0.5`2.6755, > 0.5`2.3745, 0.5`2.3745, 0.5`1.7724, 0.5`1.7724, > 0.5`1.1703, 0.5`1.1703, 0.5`0.5683, 0``0.1423, 0``0.1423, > 0``0.1423, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, > 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, > 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, > 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, > 1/2, 1/2, 1/2} In[31]:= Map[Length,Split[#]] Out[31]= > {12,43,45} This is indeed curious.The problem seems to occur for values between 13 > and 55 and then go away (for good???) At first I thought it maybe in > some fascinating way related to some properties of the integer n, but > now I am not sure. It certainly worth a careful examination. I hope > whoever discovers the cause of this will let us know. Andrzej Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > To Technical Support and the Mathematica User community, > > I'm writing to report what I consider to be a bug. First, I want to > show a > simplified example of the problem. Consider the following expression: > > expr=0.22 + x[0] + (3*(-0.16+ x[1]))/4 + (9*(0.546 + x[2]))/16; > > When simplified I expected to get some real number plus > x[0]+3x[1]/4+9x[2]/16, but instead I get the following: > > Simplify[expr] > 0.407125 + x[0] + 0.75 x[1] + 0.5625 x[2] > > As you can see, for some reason Mathematica converted the fractions > 3/4 and > 9/16 to real machine numbers. I consider this to be a bug. > > Now, for an example more representative of the situation that I've been > coming across. > > expr12 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 12}]; > expr13 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 13}]; > expr55 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 55}]; > > As you can see, I have replaced the real numbers by extended precision > numbers. The simplified example above demonstrates that the problem > exists > when using machine numbers. Now, we'll see what happens when we use > arbitrary precision numbers. First, let's simplify the expression with > 12 > terms. > > Simplify[expr12] > (1.0010000000000 + 2048 x[1] + 1024 x[2] + 512 x[3] + 256 x[4] + 128 > x[5] + > > 64 x[6] + 32 x[7] + 16 x[8] + 8 x[9] + 4 x[10] + 2 x[11] + x[12]) > / 4096 > > As you can see, a sum with 12 terms upon simplification has > coefficients > which are still integers as they should be. However, increasing the > number > of terms to 13 yields > > Simplify[expr13] > 0.0001221923828125 + 0.500000000000 x[1] + 0.250000000000 x[2] + > > 0.1250000000000 x[3] + 0.0625000000000 x[4] + 0.0312500000000 x[5] + > > 0.01562500000000 x[6] + 0.00781250000000 x[7] + 0.00390625000000 > x[8] + > > 0.001953125000000 x[9] + 0.000976562500000 x[10] + 0.000488281250000 > x[11] > + > > 0.000244140625000 x[12] + 0.0001220703125000 x[13] > > Now, all of the coefficients are converted to real numbers, > replicating the > bug from the simplified example. Finally, let's see what happens when > we > have 55 terms. Rather than putting the resulting expression here, I > will > just leave it at the end of the post. The result though is somewhat > surprising. Each of the coefficients of the x[i] are again real > numbers, but > now their precision is only 0! The proper result of course is the sum > of > some real number (with a precision close to 0 due to numerical > cancellation) > and an expression consisting of rational numbers multiplied by x[i]. > The > loss of precision of the coefficients of the x[i] is precisely what > occurred > to me. Of course, in this simple example, simply using Expand instead > of > Simplify produces the expected result, and is my workaround. I hope you > agree with me that this is a bug, and one that Wolfram needs to > correct. > > Carl Woll > Physics Dept > U of Washington > > Simplify[expr55] > -16 -1 -1 -1 > 0. 10 + 0. x[1] + 0. x[2] + 0. 10 x[3] + 0. 10 x[4] + 0. 10 > x[5] + > > -2 -2 -2 -3 -3 > 0. 10 x[6] + 0. 10 x[7] + 0. 10 x[8] + 0. 10 x[9] + 0. 10 > x[10] > + > > -3 -3 -4 -4 > -4 > 0. 10 x[11] + 0. 10 x[12] + 0. 10 x[13] + 0. 10 x[14] + 0. 10 > x[15] + > > -5 -5 -5 -6 > -6 > 0. 10 x[16] + 0. 10 x[17] + 0. 10 x[18] + 0. 10 x[19] + 0. 10 > x[20] + > > -6 -6 -7 -7 > -7 > 0. 10 x[21] + 0. 10 x[22] + 0. 10 x[23] + 0. 10 x[24] + 0. 10 > x[25] + > > -8 -8 -8 -9 > -9 > 0. 10 x[26] + 0. 10 x[27] + 0. 10 x[28] + 0. 10 x[29] + 0. 10 > x[30] + > > -9 -9 -10 -10 > 0. 10 x[31] + 0. 10 x[32] + 0. 10 x[33] + 0. 10 x[34] + > > -10 -11 -11 -11 > 0. 10 x[35] + 0. 10 x[36] + 0. 10 x[37] + 0. 10 x[38] + > > -12 -12 -12 -12 > 0. 10 x[39] + 0. 10 x[40] + 0. 10 x[41] + 0. 10 x[42] + > > -13 -13 -13 -14 > 0. 10 x[43] + 0. 10 x[44] + 0. 10 x[45] + 0. 10 x[46] + > > -14 -14 -15 -15 > 0. 10 x[47] + 0. 10 x[48] + 0. 10 x[49] + 0. 10 x[50] + > > -15 -15 -16 -16 > - > 16 > 0. 10 x[51] + 0. 10 x[52] + 0. 10 x[53] + 0. 10 x[54] + > 0. 10 > x[55] > ==== Dear Carl You have discovered what is perhaps a bug but maybe something even mor einteresting . However, I think you stopped your investigation a little prematurely. Here is a function that just computes the coefficient of x[1] in your Simplified expression for various values of n: CW[n_] := Coefficient[Simplify[1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, n}]], x[1]] Now lets try CW for the first 100 values of n: In[30]:= Table[CW[n], {n, 100}] Out[30]= {1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 0.5`12.3085, 0.5`12.0074, 0.5`11.7064, 0.5`11.4054, 0.5`11.1043, 0.5`10.8033, 0.5`10.5023, 0.5`10.2012, 0.5`9.9002, 0.5`9.5992, 0.5`9.2982, 0.5`8.9971, 0.5`8.6961, 0.5`8.3951, 0.5`8.094, 0.5`7.793, 0.5`7.492, 0.5`7.1909, 0.5`6.8899, 0.5`6.5889, 0.5`6.2879, 0.5`5.9868, 0.5`5.6858, 0.5`5.3848, 0.5`5.0837, 0.5`4.7827, 0.5`4.4817, 0.5`4.1806, 0.5`3.8796, 0.5`3.5786, 0.5`3.2776, 0.5`2.9765, 0.5`2.6755, 0.5`2.3745, 0.5`2.3745, 0.5`1.7724, 0.5`1.7724, 0.5`1.1703, 0.5`1.1703, 0.5`0.5683, 0``0.1423, 0``0.1423, 0``0.1423, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2, 1/2} In[31]:= Map[Length,Split[#]] Out[31]= {12,43,45} This is indeed curious.The problem seems to occur for values between 13 and 55 and then go away (for good???) At first I thought it maybe in some fascinating way related to some properties of the integer n, but now I am not sure. It certainly worth a careful examination. I hope whoever discovers the cause of this will let us know. Andrzej Andrzej Kozlowski Yokohama, Japan http://www.mimuw.edu.pl/~akoz/ http://platon.c.u-tokyo.ac.jp/andrzej/ > To Technical Support and the Mathematica User community, I'm writing to report what I consider to be a bug. First, I want to > show a > simplified example of the problem. Consider the following expression: expr=0.22 + x[0] + (3*(-0.16+ x[1]))/4 + (9*(0.546 + x[2]))/16; When simplified I expected to get some real number plus > x[0]+3x[1]/4+9x[2]/16, but instead I get the following: Simplify[expr] > 0.407125 + x[0] + 0.75 x[1] + 0.5625 x[2] As you can see, for some reason Mathematica converted the fractions > 3/4 and > 9/16 to real machine numbers. I consider this to be a bug. Now, for an example more representative of the situation that I've been > coming across. expr12 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 12}]; > expr13 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 13}]; > expr55 = 1.001`17 + Sum[(x[i] - 1.001`17)/2^i, {i, 55}]; As you can see, I have replaced the real numbers by extended precision > numbers. The simplified example above demonstrates that the problem > exists > when using machine numbers. Now, we'll see what happens when we use > arbitrary precision numbers. First, let's simplify the expression with > 12 > terms. Simplify[expr12] > (1.0010000000000 + 2048 x[1] + 1024 x[2] + 512 x[3] + 256 x[4] + 128 > x[5] + 64 x[6] + 32 x[7] + 16 x[8] + 8 x[9] + 4 x[10] + 2 x[11] + x[12]) > / 4096 As you can see, a sum with 12 terms upon simplification has > coefficients > which are still integers as they should be. However, increasing the > number > of terms to 13 yields Simplify[expr13] > 0.0001221923828125 + 0.500000000000 x[1] + 0.250000000000 x[2] + 0.1250000000000 x[3] + 0.0625000000000 x[4] + 0.0312500000000 x[5] + 0.01562500000000 x[6] + 0.00781250000000 x[7] + 0.00390625000000 > x[8] + 0.001953125000000 x[9] + 0.000976562500000 x[10] + 0.000488281250000 > x[11] > + 0.000244140625000 x[12] + 0.0001220703125000 x[13] Now, all of the coefficients are converted to real numbers, > replicating the > bug from the simplified example. Finally, let's see what happens when > we > have 55 terms. Rather than putting the resulting expression here, I > will > just leave it at the end of the post. The result though is somewhat > surprising. Each of the coefficients of the x[i] are again real > numbers, but > now their precision is only 0! The proper result of course is the sum > of > some real number (with a precision close to 0 due to numerical > cancellation) > and an expression consisting of rational numbers multiplied by x[i]. > The > loss of precision of the coefficients of the x[i] is precisely what > occurred > to me. Of course, in this simple example, simply using Expand instead > of > Simplify produces the expected result, and is my workaround. I hope you > agree with me that this is a bug, and one that Wolfram needs to > correct. Carl Woll > Physics Dept > U of Washington Simplify[expr55] > -16 -1 -1 -1 > 0. 10 + 0. x[1] + 0. x[2] + 0. 10 x[3] + 0. 10 x[4] + 0. 10 > x[5] + -2 -2 -2 -3 -3 > 0. 10 x[6] + 0. 10 x[7] + 0. 10 x[8] + 0. 10 x[9] + 0. 10 > x[10] > + > > -3 -3 -4 -4 > -4 > 0. 10 x[11] + 0. 10 x[12] + 0. 10 x[13] + 0. 10 x[14] + 0. 10 > x[15] + -5 -5 -5 -6 > -6 > 0. 10 x[16] + 0. 10 x[17] + 0. 10 x[18] + 0. 10 x[19] + 0. 10 > x[20] + -6 -6 -7 -7 > -7 > 0. 10 x[21] + 0. 10 x[22] + 0. 10 x[23] + 0. 10 x[24] + 0. 10 > x[25] + -8 -8 -8 -9 > -9 > 0. 10 x[26] + 0. 10 x[27] + 0. 10 x[28] + 0. 10 x[29] + 0. 10 > x[30] + -9 -9 -10 -10 > 0. 10 x[31] + 0. 10 x[32] + 0. 10 x[33] + 0. 10 x[34] + -10 -11 -11 -11 > 0. 10 x[35] + 0. 10 x[36] + 0. 10 x[37] + 0. 10 x[38] + -12 -12 -12 -12 > 0. 10 x[39] + 0. 10 x[40] + 0. 10 x[41] + 0. 10 x[42] + -13 -13 -13 -14 > 0. 10 x[43] + 0. 10 x[44] + 0. 10 x[45] + 0. 10 x[46] + -14 -14 -15 -15 > 0. 10 x[47] + 0. 10 x[48] + 0. 10 x[49] + 0. 10 x[50] + -15 -15 -16 -16 > - > 16 > 0. 10 x[51] + 0. 10 x[52] + 0. 10 x[53] + 0. 10 x[54] + > 0. 10 > x[55] > ==== I think, for input of that many numbers (and other inputs), I might use an input file that has textual names or descriptions in the first ten or twenty columns, followed by values starting at a fixed column after that. Mathematica or Java could easily read inputs from that, and a human could read it as well. If you're concerned that a human might jumble the file format -- accidentally deleting lines, etc. -- a program could key on the names or descriptions rather than trusting them to be in correct order, and point out missing values. A strategy like that allows you to start with a previous input file (not from scratch) and change only what needs to change. Also, Mathematica 4.2 adds XML support to the picture, and that might be useful. Bobby -----Original Message----- > I agree with Mr. Kuska, that the system Mr Nagesh describes is not > userfriendly. But I think, the suggestions of Mr. Kuska do not make it more > userfriendly, rather the opposite is true. > > Mr. Nagesh asks > > Is any body here have expertise or information about the capability of > Mathematica as a system simulation tool? > Mr. Kuska answers: > Since the most system simulation tools are simply solving a system of > ordinary differntial equations it is simple to do this with NDSolve[]. > > My comment: > > That is: He sees the simulation system merely as a set of differential > equations. hmm, since the original poster write My refrigeration system simulation package is likely to have > approximately 60 First order Differential equations. it seems not completly wrong to assume that the system consists of > of ode's .. > Yout should not ignore the word merely. It is not enough to have a set 60 differential equations and a set of 200-250 numbers. That is not simulation system, which can be used by users with the exception, perhaps, of the programmer of the system himself. How does e.g. the user know what meaning a number in the set has, ought he count the numbers from the beginning? Your nice command shows only, if there is an input, which is not a number. But I think the user would like to know, which of the 200 elements are not numbers. The only good of your command is, that it looks nice and shows your knowledge! > > The question of Mr. Nagesh: > > My 4th Objective:- How can I program the check for correctness of the > input values supplied by the package user ? > The answer of Mr. Kuska is: > And @@ (NumericQ /@ {aListOfAllYourNumericParameters}) > > My comment: > > This is a nice command and shows the knowledge of Mr.Kuska. But does Mr. > Nagesh understand it and is it sufficient to check, if all inputs are > numerical? It seems you have a deeper knowlege about the things that Mr. Nagesh > understand. You know him personally ? It is not very polite to > make speculations *what* a other person understand. And no it is not sufficent to check that all parameters are numbers. > Typical paramters described by intervals, where the assumptions of > a model are valid. But for this checks one needs more knowlege > about the meaning of the parameters. And one needs the knowlege about > the differntial equations, to find out the eigenvalues of the jacobian > ... > Additionally I think, it is not userfriendly to see the input merely as a > set of 200-250 numbers. > > My suggestion is, that JLink is used, a suggestion Mr. Kusk takes into > consideration, too. That will be fast as lightning ! > But further I suggest, that classes are defined in Java, which represent the > parts of the system. That is notable nonsense! When the differntial equations should be > solved with Mathematica, the parts can't be Java classes. Mathematica's > NDSolve[] need a explicit expression to integrate the equations. That's not nonsense, the Mathematica program does not fetch the classes but the numbers in the classes (or better in the objects). in the Java classes in textform. They can then be fetched from the Mathematica program and transformed into expressions by the Command ToExpression. The aim is, to have a clear separation of the system into components, which are manageable and understandable. OK you can call a Java class member from Mathematica but this will > be incredible slow when the right hand side is evaluated 200-300 > times and every evaluation make several callbacks to the Java source. > Event handler of the Java main program (without some modification in > the event loop) while it is evaluating an other command. My idea is to fetch the values once from the Java objects at the beginning. 200-250 numbers is not so much.. > Constructors of the classes should build objects with default values. That's a great idea. If a simulation run should be documented, one > always > need the full listing of the Java source to find the actual parameter > settings. That is not my opinion. I think not every user of the simulation system should have to know Java and Mathematica. The user must look for the values in the objects. And the values are in the objects, if they come from the constructor or from the graphical user interface. I think, there should be listings of the objects including names of the variables. In the objects the values are in an meaningful environment. > Graphical user interfaces > should give the opportunity to change the data fields in the objects and > check the input for correctness. *and* what has a GUI for 200-250 variables to do with Mathematica ? > BTW one has typical much less variables because many parameters > are fixed and it make no sense to change, for example, material > constants of materials that can't exchanged > The system should give the opportunity, to store the objects on harddisk > (serialization). > > accessed directly. > > Can you be so kind, to explain *how* your posting help a person that > ask How can I build a simulation system with Mathematica ? You *can* say Don't use Mathematica, use Java! but this has nothing > to do with the question or with my reply. It is you, who proposes to solve the problem with C/C++ and not to use Mathematica (see below!) My point of view is: Use Mathematica, for what Mathemtica is good, and Java, for what Java is good. Mathematica is not so good as Java for data entry and Java is better than Mathematica to represent the simulation system (by objects). But I still would suggest to use C/C++ and a numerical > ode-solver, make a fancy GUI/Script > interface and don't use Mathematica for such a simple task. > The ode-solver is the smallest part of such a simulation system. Jens > > > > My name is Nagesh and pursuing research studies in Refrigeration. At > present I am writing a Dynamic Refrigeration System Simulation Package. > I > am using Mathematica as a programming language for the same since last > one > year. I don't have any programming experience before this. I have > following > querries:- > 1. Is any body here have expertise or information about the capability > of > Mathematica as a system simulation tool? > > Since the most system simulation tools are simply solving a system of > ordinary differntial equations it is simple to do this with NDSolve[]. > > 2. Is is possible to program a user friendly interface for my system > simulation package with Mathematica or I have to use some other > software? > > Write a MathLink or J/Link frontend that launch the kernel. But you > should keep > in mind that the user interface is typical 80-90 % of your code. > If you just whant to solve some ode's it is probably easyer to > include one of the excelent ode-solvers from netlib in your C-code > than to call Mathematica to do that. As long as you dont wish to change > the ode's very often (than Mathematica is more flexible) you should > not use Mathematica. > > 3. My refrigeration system simulation package is likely to have > approximately 60 First order Differential equations. Is is possible to > solve these in Mathematica ? > > Sure. > If yes then can anybody here guide me about > this further. > > Write down the equations and call NDSolve[]. > > > I am explaining below in short about the objectives I want to fulfill > from > coding out of my main input file > > 1. Example from Main Input File ( this will contain about 200-250 > variables > which will be entered by the user of this package) > > This sounds like a *very* userfiendly interface ;-) > > > Below is examples of two variables entered into this file, which will be > used in other analysis files for further evaluation. > > 2. Example from other analysis file ( there will be about 20-25 other > such > component analysis files ) where the above mentioned variables from main > input file will be used for further evaluations:- > > Below is one example from this file explaining how the variables from > main > input file will be used in other files. > > I hope that this short information will be useful for guiding me to > solve > the following problems that I am facing. I am facing follwing problems > or > objectives:- > > 1. My 1st Objective:- The user of this package must be able to change > only > the value of the variable in the main input file but he must not be able > to > change the name of the variable itself. For example he must be able to > change the value of the variable but he must not be able to change > the > name of this variable itself. > Here our problem is how to achieve or program it so that our objective > will > be fullfilled. > > Options with defaulf values ? or something like > > {aParam,bParam}={ODEParameter1,ODEParameter2} /. > userRules /. > {ODEParameter1->1,ODEParameter2->2} > > > 2. My 2nd Objective:- How I can program the main input file so that it > will > be user friendly in terms of its visuals and satisfying the constraint > mentioned above in objective1. > > What is *userfiendly* in a file with 250 variables ??? > > > 3. My 3rd Objective:- How can I program the optional values for each > variable in the main input file ? so that there will be always a value > assigned to each variable listed in main input file whenever the user > opens > up this file. If user want to change the values of some variables then > he > can change them and run the simulation otherwise the simulation run will > be > done with optional values assigned to each variable in the input file. > > See above. > > > 4. My 4th Objective:- How can I program the check for correctness of the > input values supplied by the package user ? > > And @@ (NumericQ /@ {aListOfAllYourNumericParameters}) > > > Jens > ==== hi > AFAIK, Mac OS is now BSD or something like that. That makes it almost > certain that it could support QT. As I pointed out in another post, I can > run the KDE on Windows XP. I haven't been in the trenches with the Qt > impression is, it really is 'code once, run everywhere'. i've checked the trolltech hp. qt fully supports the following OS: MS Windows 95/98/Me, NT4, 2000 and XP. Mac OS X. > This is one of the reasons I am such a Mozilla fan. Konqueror works quite > like. But Mozilla runs everywhere with more or less a uniform look and > feel. Yes, Mozilla is written with Gtk and not with Qt, but that just > shows that WRI has options. i'm not sure if it is allowed to create a closed-source product like the mathematica fronend based on a gpl'ed library like gtk. with qt you have the possibility to buy licenses for the commercial version of qt, allowing you to create closed-source apps. > I'm a KDE fan. I've used the KDE since it was in alpha 0.4. I remember > back when it would compile in a few minutes on a pentium II. Now it takes > several hours on a P4. i started with beta1 (if i remember correctly) - sure it is really big now, but i think kde is still far away from being bloated..... imagine the mathematica frontend being seamlessly integrated into the linux ui's look and feel.... > I've always hated motif. The file chooser simply stinks. And that's just a > start. the whole motif ui stinks....:-) gerald ************************************* Gerald Roth M@th Desktop Development ************************************* ==== > hi, > > moving the frontend over to QT would have some neat side effects: > consistent look & feel with the modern linux gui, themeability, source > antialiased > truetype fonts as QT supports Xrender and Xft (looks great - see KDE3). i > think all of those points are of value, but the most important might be > source compatibility. ONE frontend for MOST (or ALL) platforms - sounds > like a dream :-)) AFAIK, Mac OS is now BSD or something like that. That makes it almost certain that it could support QT. As I pointed out in another post, I can run the KDE on Windows XP. I haven't been in the trenches with the Qt impression is, it really is 'code once, run everywhere'. This is one of the reasons I am such a Mozilla fan. Konqueror works quite like. But Mozilla runs everywhere with more or less a uniform look and feel. Yes, Mozilla is written with Gtk and not with Qt, but that just shows that WRI has options. I'm a KDE fan. I've used the KDE since it was in alpha 0.4. I remember back when it would compile in a few minutes on a pentium II. Now it takes several hours on a P4. But if WRI wanted to go the Gtk route, they could achieve the same ends. I've always hated motif. The file chooser simply stinks. And that's just a start. > > gerald > STH ==== Can I solve this inequality with Mathematica? Log[x,a]+Log[a x,a]>0 I've tried all know, but I get get any good result. CeZaR ==== > > First thanks to all, and in particular Bobby Treat, for your help with > this question. > > The best solution was as follows: > > lst = ReadList[c:data.txt, {Number, Number}] > adjacenceMatrix[ > x:{{_, _}..}] := Module[{actors, events}, > {actors, events} = Union /@ Transpose[x]; > Array[If[MemberQ[x, {actors[[#1]], events[[#2]]}], 1, 0] & , > {Length[actors], Length[events]}]] > > a = adjacenceMatrix[lst]; > b = a . Transpose[a]; > c = b (1 - IdentityMatrix[Length[b]]) > > C is the desired symmetric matrix with off diagonal values of >=0, > indicating the number of times two actors participate in the same event. > The diagonal is set to 0. > > A few items in response to Bobby's message, below. While c is, in fact, > a huge matrix with lots of cells equal to zero, that is exactly how we > need it structured for our analysis and research question (not relevant > to the list, but I'd be happy to discuss off list). Processing time is > actually not too bad!! I'm running a PIII 900 with 512 SDRAM, and the > code ran a 177 x 3669 matrix in under 90 seconds. MatrixForm [c] > presented no problems in viewing in the front end, but then it's only > 177 x 177. > > > Tom > > ********************************************** > Thomas P. Moliterno > Graduate School of Management > University of California, Irvine > tmoliter@uci.edu > ********************************************** > [...] There are several ways to go about this and which is best will vary based on relative number of events vs. number of actors. Below I show three variations. The first is a minor recoding of the one above. The second iterates over all pairs of actors. The third looks at all events for common actors. I then show three examples. The first two methods have the advantage that they do not require that events be positive integers. With some extra work the third method could also get around this restriction. toAdjacency0[data:{{_, _}..}] := Module[ {actors, events, mat1, mat2}, {actors, events} = Union /@ Transpose[data]; mat1 = Array[If[MemberQ[data, {actors[[#1]], events[[#2]]}], 1, 0] & , {Length[actors], Length[events]}]; mat2 = mat1 . Transpose[mat1]; mat2 * (1-IdentityMatrix[Length[mat2]]) ] toAdjacency1[origdata_] := Module[ {data=Union[origdata], mat}, data = Map[Last, Split[data,#1[[1]]===#2[[1]]&], {2}]; mat = Table [If [j>k, Length[Intersection[data[[j]],data[[k]]]], 0], {j,Length[data]}, {k,Length[data]}]; mat+Transpose[mat] ] toAdjacency2[origdata_] := Module[ {data=Sort[Map[Reverse,Union[origdata]]], mat, len, event}, data = Map[Last, Split[data,#1[[1]]===#2[[1]]&], {2}]; dim = Length[Union[Flatten[data]]]; len = Length[data]; mat = Table[0, {dim}, {dim}]; Do [ event = data[[j]]; Do [ Do [ mat[[event[[m]],event[[k]]]] += 1; mat[[event[[k]],event[[m]]]] += 1, {m,k-1}], {k,Length[event]}], {j,len}]; mat ] data1 = Table[{Random[Integer,{1,1000}], Random[Integer,50]}, {10000}]; data2 = Table[{Random[Integer,{1,1000}], Random[Integer,100]}, {10000}]; data3 = Table[{Random[Integer,{1,1000}], Random[Integer,200]}, {10000}]; Timings are on a 1.5 GHz machine running the Mathematica 4.2 kernel In[107]:= Timing[m0 = toAdjacency0[data1];] Out[107]= {5.44 Second, Null} In[108]:= Timing[m1 = toAdjacency1[data1];] Out[108]= {10.5 Second, Null} In[109]:= Timing[m2 = toAdjacency2[data1];] Out[109]= {16.24 Second, Null} In[110]:= m0 === m1 === m2 Out[110]= True Note that for this example the result is not terrible sparse (less than 20%). In[112]:= Count[Flatten[m0], 0] Out[112]= 191374 In[115]:= Timing[m0 = toAdjacency0[data2];] Out[115]= {11.51 Second, Null} In[116]:= Timing[m1 = toAdjacency1[data2];] Out[116]= {10.92 Second, Null} In[117]:= Timing[m2 = toAdjacency2[data2];] Out[117]= {9.07 Second, Null} Curiously this was the first example I tried, and all three methods perform about the same in this case. The result, not suprisingly, is more sparse (40%) because we have the same number of actors and pairs as previously, but now with more events to spread out over the pairs. In[118]:= Count[Flatten[m0], 0] Out[118]= 403232 When we get sparser still, the third method begins to dominate and the first is relatively slower. In[119]:= Timing[m0 = toAdjacency0[data3];] Out[119]= {22.73 Second, Null} In[120]:= Timing[m1 = toAdjacency1[data3];] Out[120]= {10.88 Second, Null} In[121]:= Timing[m2 = toAdjacency2[data3];] Out[121]= {4.96 Second, Null} Now sparsity is over 60%. In[122]:= Count[Flatten[m0], 0] Out[122]= 624350 The relative speed of this last method, in this instance, is derived from the fact that individual event lists are on average half the size of the previous case. Hence the main loop is expected to improve on average by a factor of 2 (you get a factor of 4 for iterating over all pairs in each event, but lose a factor of 2 because there are twice as many event lists). My guess is that a preprocessor that assesses number of actors vs. number of events would be the best way to choose between the first and third methods (which, inexplicably, are labelled as methods 0 and 2). It is not clear to me whether the middle approach will ever dominate. I have not given much thought to concocting examples where it would because offhand I suspect they would be pathological as in dense and with large intersections. As a last remark I'll note that these might run significantly faster if coded with Compile. Whether that is viable depends on the form of the data. In the above example where everything is a machine integer that approach would certainly work. Daniel Lichtblau Wolfram Research ==== First thanks to all, and in particular Bobby Treat, for your help with this question. The best solution was as follows: lst = ReadList[c:data.txt, {Number, Number}] adjacenceMatrix[ x:{{_, _}..}] := Module[{actors, events}, {actors, events} = Union /@ Transpose[x]; Array[If[MemberQ[x, {actors[[#1]], events[[#2]]}], 1, 0] & , {Length[actors], Length[events]}]] a = adjacenceMatrix[lst]; b = a . Transpose[a]; c = b (1 - IdentityMatrix[Length[b]]) C is the desired symmetric matrix with off diagonal values of >=0, indicating the number of times two actors participate in the same event. The diagonal is set to 0. A few items in response to Bobby's message, below. While c is, in fact, a huge matrix with lots of cells equal to zero, that is exactly how we need it structured for our analysis and research question (not relevant to the list, but I'd be happy to discuss off list). Processing time is actually not too bad!! I'm running a PIII 900 with 512 SDRAM, and the code ran a 177 x 3669 matrix in under 90 seconds. MatrixForm [c] presented no problems in viewing in the front end, but then it's only 177 x 177. Tom ********************************************** Thomas P. Moliterno Graduate School of Management University of California, Irvine tmoliter@uci.edu ********************************************** -----Original Message----- columns will be numbered from 1 to the number of observed actors or events, and will correspond to actors and events in sorted order. That said, you're asking for a VERY large matrix, and most of its entries will be zero. I'll suggest another way, later. The following indicates AT MOST 13.4% of the entries could be non-zero: lst = ReadList[moliterno-test1996.txt, {Number, Number}]; {actors, events} = Union /@ Transpose[lst]; N[Length[lst]/(Length[actors]*Length[actors])] 0.13350994338800987 However, a random sample shows that less than 1% will be non-zero: Timing[ Count[(MemberQ[lst, {actors[[Random[Integer, Length[actors]]]], events[[Random[Integer, Length[events]]]]}] & ) /@ Range[10000], True]/ 10000.] {7.515999999999998*Second, 0.008} Nevertheless, the following code should build the matrices you want. I'm using a 2.2GHz P4 and 1024MB RDRAM, so if you have a slower machine, be warned. adjacenceMatrix[ x:{{_, _}..}] := Module[{actors, events}, {actors, events} = Union /@ Transpose[x]; Array[If[MemberQ[x, {actors[[#1]], events[[#2]]}], 1, 0] & , {Length[actors], Length[events]}]] Timing[a = adjacenceMatrix[lst]; ] Dimensions[a] {5.671999999999997*Second, Null} {166, 1778} Timing[b = a . Transpose[a]; ] {0.5309999999999988*Second, Null} You don't want to display a or b in MatrixForm. It will crash your anything at all from the result, and use something like b[[Range[20],Range[4]]]//MatrixForm {{47, 0, 0, 0}, {0, 3, 0, 0}, {0, 0, 7, 1}, {0, 0, 1, 59}, {0, 0, 0, 3}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 1}, {0, 0, 0, 0}, {0, 0, 0, 1}, {0, 0, 0, 0}, {0, 0, 0, 0}, {2, 0, 0, 1}, {0, 0, 0, 0}, {0, 1, 0, 0}, {0, 0, 0, 1}, {0, 0, 0, 2}, {0, 0, 0, 0}, {0, 0, 0, 0}} to get a glimpse at some of it. It's the 'a' matrix that's terribly sparse -- the 'b' matrix isn't unreasonable. Elements of the 'a' matrix can be quickly computed by the function aFunction = If[MemberQ[lst, {actors[[#1]], events[[#2]]}], 1, 0] &; That stores a line of code rather than all those ones and zeroes. The b matrix (call it bb this time) can be computed as: Timing[bb = (#1 . Transpose[#1] & ) [Array[aFunction, {Length[actors], Length[events]}]]; ] bb == b {6.1569999999999965*Second, Null} True Bobby Treat -----Original Message----- posting a this was the most helpful solution message to the list, but first I hoped to ask you a follow up question, if I may (and I'll capture your off-line response here in my final posting to the list). I've run the code (copied from you) below, and get the correct output for made-up data, but when I import in real data, I get an error message. Here's the input I'm running: lst = ReadList[c:test1996.txt, {Number, Number}] AdjacenceMatrix[lst : {{_, _} ..}] := Module[{actors, events, adj}, {actors, events} = Union /@ Transpose[lst]; adj = Table[0, {Length[actors]}, {Length[events]}]; Scan[(Part[adj, Sequence @@ #] = 1) &, lst /. MapIndexed[Rule[#1, First[#2]] &, events]]; adj] MatrixForm[a = AdjacenceMatrix[lst]] MatrixForm[b = a.Transpose[a]] And here's what I get for output: Set::partw : Part 300007 of <<1> does not exist. Set::partw : Part 300007 of <<1> does not exist. Set::partw : Part 300007 of <<1> does not exist. General::stop : Further output of Set::partw will be suppressed during this calculation. Then I get the two matrices (a & b as per your code), but they are just filled with zeros. So it gets to about the 4th line of your code, but then doesn't fill-in from my data. Finally, I should note that 30007 is one of the actors in the data that I've read in. In case you want to run this yourself, I've attached the raw data file. There are 166 actors and 1778 events: both actors and events are coded with 6-digit numbers, actors begin with 3's, events with 2's. I'm sure this is a silly question, and that there is an easy answer ... But I sure can't find it. So I really appreciate your help and interest!!!! Tom ********************************************** Thomas P. Moliterno Graduate School of Management University of California, Irvine tmoliter@uci.edu ********************************************** -----Original Message----- If you multiply it by its transpose, you get something else that's useful: lst = {{1, A}, {1, B}, {2, B}, {3, C}, {3, D}, {1, D}, {1, C}}; AdjacenceMatrix[lst : {{_, _} ..}] := Module[{actors, events, adj}, {actors, events} = Union /@ Transpose[lst]; adj = Table[0, {Length[actors]}, {Length[events]}]; Scan[(Part[adj, Sequence @@ #] = 1) &, lst /. MapIndexed[Rule[#1, First[#2]] &, events]]; adj] MatrixForm[a = AdjacenceMatrix[lst]] MatrixForm[b = a.Transpose[a]] Matrix 'b' records how many events two actors have in common. On the diagonal, it shows the total number of events each actor is connected to. It's easy to put zeroes on the diagonal: MatrixForm[c = b (1 - IdentityMatrix[Length[b]])] To get the originally intended incidence matrix, this works: d = c /. {_?Positive -> 1} However, I think matrices 'a' and 'b' are actually more useful, and 'a' easily leads to all the others. Bobby -----Original Message----- AdjacenceMatrix[lst : {{_, _} ..}] := Module[ {actors,events adj}, {events, actors} = Union /@ Transpose[lst]; adj = Table[0, {Length[events]}, {Length[actors]}]; Scan[(Part[adj, Sequence @@ #] = 1) &, lst /. MapIndexed[Rule[#1, First[#2]] &, actors]]; adj ] you get In[]:=AdjacenceMatrix[lst] Out[]={{1, 1, 0, 1}, {0, 1, 0, 0}, {0, 0, 1, 1}} Jens > > I need to create an adjacency matrix from my data, which is currently in > the form of a .txt file and is basically a two column incidence list. > For example: > > 1 A > 1 B > 2 B > 3 C > . . > . . > . . > m n > > Where 1 to m represent actors and A to n represent events. My goal is to > have an (m x m) matrix where cell i,j equals 1 if two actors are > incident to the same event (in the sample above, 1 and 2 are both > incident to B) and 0 otherwise (w/ zeros on the diagonal). > > I'm new to Mathmatica, and so I'm on the steep part of the learning > curve ... All I've been able to figure out so far is how to get my > incidence list into the program using Import[filename.txt]. But then > what? How do I convert to the adjacency matrix? I've found the > ToAdjacencyMatrix[] command in DiscreteMath`Combinatorica`, but I can't > seem to get it to work ... > > > Tom > > ********************************************** > Thomas P. Moliterno > Graduate School of Management > University of California, Irvine > tmoliter@uci.edu > ********************************************** ==== These are working for me. If anybody wants to try this modified keymapping http://66.92.149.152/proprietary/com/wri/proprietary/com/wri/ch05.html http://public.globalsymmetry.com/proprietary/com/wri/KeyEventTranslations.tr .txt STH ==== > These are working for me. If anybody wants to try this modified > keymapping > > http://66.92.149.152/proprietary/com/wri/proprietary/com/wri/ch05.html > http://public.globalsymmetry.com/proprietary/com/wri/KeyEventTranslations.tr .txt > > STH I found a bug in my hack of the KeyEventTranslations.tr file which didn't manifest itself in 4.1, but did in 4.2. I had a trailing ',' which was causing Mathematica to hang on startup after the chched KeyEventTranslations.m was created (second launch with the buggy file.) I also discovered that the file I was trying to share had been chmod'ed to 400. I am not sure if that is a daemon running, or scp which did it. It's open now, and I'll keep an eye on it. I'm attaching it as well, just in case. I put it here on my box: ~/.Mathematica/SystemFiles/FrontEnd/TextResources STH @@resource KeyEventTranslations (* Modifiers can be Shift, Control, Command, Option For Macintosh: Command = Command Key, Option = Option Key For X11: Command = Mod1, Option = Mod2 For Windows: Command = Alt, Option = Alt NOTE: I Hacked this for my purposes. I find it more natural. There may be problems. It comes with all the warranty that GNU software does. *) EventTranslations[{ (* Evaluation *) Item[KeyEvent[Enter], EvaluateCells], Item[KeyEvent[KeypadEnter], EvaluateCells], Item[KeyEvent[Return, Modifiers -> {Shift}], EvaluateCells], Item[KeyEvent[KP_Enter], EvaluateCells], Item[KeyEvent[KeypadEnter, Modifiers -> {Shift}], EvaluateNextCell], Item[KeyEvent[KP_Enter, Modifiers -> {Shift}], EvaluateNextCell], Item[KeyEvent[Enter, Modifiers -> {Shift}], EvaluateNextCell], Item[KeyEvent[Return, Modifiers -> {Command}], Evaluate[All]], Item[KeyEvent[Return, Modifiers -> {Option}], SimilarCellBelow], Item[KeyEvent[Escape], ShortNameDelimiter], (* Cursor control *) Item[KeyEvent[Up], MovePreviousLine], Item[KeyEvent[Down], MoveNextLine], Item[KeyEvent[Left], MovePrevious], Item[KeyEvent[Right], MoveNext], Item[KeyEvent[Up, Modifiers -> {Option}], MovePreviousLine], Item[KeyEvent[Down, Modifiers -> {Option}], MoveNextLine], Item[KeyEvent[Right, Modifiers -> {Option}], MoveNextWord], Item[KeyEvent[Left, Modifiers -> {Option}], MovePreviousWord], Item[KeyEvent[Right, Modifiers->{Control}], MoveNextWord], Item[KeyEvent[Left, Modifiers->{Control}], MovePreviousWord], Item[KeyEvent[End], MoveLineEnd], Item[KeyEvent[Home], MoveLineBeginning], (* Selection *) Item[KeyEvent[Right, Modifiers -> {Shift}], SelectNext], Item[KeyEvent[Left, Modifiers -> {Shift}], SelectPrevious], Item[KeyEvent[Right, Modifiers -> {Control, Shift}], SelectNextWord], Item[KeyEvent[Left, Modifiers -> {Control, Shift}], SelectPreviousWord], Item[KeyEvent[Down, Modifiers -> {Shift}], SelectNextLine], Item[KeyEvent[Up, Modifiers -> {Shift}], SelectPreviousLine], Item[KeyEvent[Home, Modifiers -> {Shift}], SelectLineBeginning], Item[KeyEvent[End, Modifiers -> {Shift}], SelectLineEnd], Item[KeyEvent[., Modifiers -> {Control}], ExpandSelection], (* Notebook window control *) Item[KeyEvent[PageUp], ScrollPageUp], Item[KeyEvent[PageDown], ScrollPageDown], Item[KeyEvent[Prior], ScrollPageUp], Item[KeyEvent[Next], ScrollPageDown], Item[KeyEvent[Home, Modifiers -> {Control}], ScrollNotebookStart], Item[KeyEvent[End, Modifiers -> {Control}], ScrollNotebookEnd], (* Input *) Item[KeyEvent[Return], Linebreak], Item[KeyEvent[Tab], Tab], Item[KeyEvent[i, Modifiers -> {Control}], Tab], Item[KeyEvent[Backspace], DeletePrevious], Item[KeyEvent[Delete], DeleteNext], Item[KeyEvent[ForwardDelete], DeleteNext], (* Typesetting input *) Item[KeyEvent[6, Modifiers -> {Control}], Superscript], Item[KeyEvent[Keypad6, Modifiers -> {Control}], Superscript], Item[KeyEvent[^, Modifiers -> {Control}], Superscript], Item[KeyEvent[-, Modifiers -> {Control}], Subscript], Item[KeyEvent[_, Modifiers ->{Control}], Subscript], Item[KeyEvent[/, Modifiers -> {Control}], Fraction], Item[KeyEvent[KP_Divide, Modifiers -> {Control}], Fraction], Item[KeyEvent[2, Modifiers -> {Control}], Radical], Item[KeyEvent[Keypad2, Modifiers -> {Control}], Radical], Item[KeyEvent[@, Modifiers -> {Control}], Radical], Item[KeyEvent[7, Modifiers -> {Control}], Above], Item[KeyEvent[&, Modifiers -> {Control}], Above], Item[KeyEvent[Keypad7, Modifiers -> {Control}], Above], Item[KeyEvent[=, Modifiers -> {Control}], Below], Item[KeyEvent[+, Modifiers -> {Control}], Below], Item[KeyEvent[,, Modifiers -> {Control}], NewColumn], Item[KeyEvent[Return, Modifiers -> {Control}], NewRow], Item[KeyEvent[9, Modifiers -> {Control}], CreateInlineCell], Item[KeyEvent[(, Modifiers -> {Control}], CreateInlineCell], Item[KeyEvent[Keypad9, Modifiers -> {Control}], CreateInlineCell], Item[KeyEvent[), Modifiers -> {Control}], MoveNextCell], Item[KeyEvent[0, Modifiers -> {Control}], MoveNextCell], Item[KeyEvent[Keypad0, Modifiers -> {Control}], MoveNextCell], Item[KeyEvent[Left, Modifiers -> {Control}, CellClass -> BoxFormData], NudgeLeft], Item[KeyEvent[Right, Modifiers -> {Control}, CellClass -> BoxFormData], NudgeRight], Item[KeyEvent[Down, Modifiers -> {Control}, CellClass -> BoxFormData], NudgeDown], Item[KeyEvent[Up, Modifiers -> {Control}, CellClass -> BoxFormData], NudgeUp], Item[KeyEvent[8, Modifiers -> {Control}], InsertRawExpression], Item[KeyEvent[*, Modifiers -> {Control}], InsertRawExpression], Item[KeyEvent[Keypad8, Modifiers -> {Control}], InsertRawExpression], Item[KeyEvent[5, Modifiers -> {Control}, CellClass -> BoxFormData], Otherscript], Item[KeyEvent[Keypad5, Modifiers -> {Control}, CellClass -> BoxFormData], Otherscript], Item[KeyEvent[%, Modifiers -> {Control}, CellClass -> BoxFormData], Otherscript], (* Typesetting motion commands *) Item[KeyEvent[ , Modifiers -> {Control}], MoveExpressionEnd], Item[KeyEvent[Tab, Modifiers -> {Shift}, CellClass -> BoxFormData], MovePreviousPlaceHolder], Item[KeyEvent[s, Modifiers -> {Command, Control}, CellClass -> BoxFormData], MovePreviousExpression], Item[KeyEvent[S, Modifiers -> {Control, Command, Shift}, CellClass -> BoxFormData], MoveNextExpression], Item[KeyEvent[S, Modifiers -> {Control, Shift}, CellClass -> BoxFormData], DeleteNextExpression], Item[KeyEvent[s, Modifiers -> {Control}, CellClass -> BoxFormData], DeletePreviousExpression], Item[KeyEvent[k, Modifiers -> {Control}], CompleteSelection[True]], (* Miscellaneous menu commands *) Item[KeyEvent[Delete, Modifiers -> {Control}], Cut], Item[KeyEvent[Insert, Modifiers -> {Control}], Copy], Item[KeyEvent[Insert, Modifiers -> {Shift}], Paste[After]], Item[KeyEvent[z, Modifiers -> {Control}], Undo], Item[KeyEvent[c, Modifiers -> {Control}], Copy], Item[KeyEvent[x, Modifiers -> {Control}], Cut], Item[KeyEvent[v, Modifiers -> {Control}], Paste[After]], Item[KeyEvent[F1], SelectionHelpDialog] (* Unsupported features and examples *) (* Item[KeyEvent[v, Modifiers -> {Control}], SelectionSpeakSummary], *) (* Item[KeyEvent[v, Modifiers -> {Control, Shift}], SelectionSpeak] *) }] ==== >particular, the y-axis label is typically rotated by 90deg so that it >reads up the y-axis. This works fine on macs and windoze, but under >linux the label runs up the y-axis; however, the letters are rotated >so that they are the same orientation as that for the x-axis. >Printouts of the NB are fine, but it looks really stupid when using a >video projector to teach or give a talk. I have mentioned this before, >perhaps, but it is also a real problem with Mathematica. I personally >don't care why the label looks peculiar, just that it does and that >there is no easy workaround. ==== >I'm writing to report what I consider to be a bug. First, I want to >show a simplified example of the problem. Consider the following >expression: > >expr=0.22 + x[0] + (3*(-0.16+ x[1]))/4 + (9*(0.546 + x[2]))/16; > >When simplified I expected to get some real number plus >x[0]+3x[1]/4+9x[2]/16, but instead I get the following: > >Simplify[expr] 0.407125 + x[0] + 0.75 x[1] + 0.5625 x[2] > >As you can see, for some reason Mathematica converted the fractions >3/4 and 9/16 to real machine numbers. I consider this to be a bug. You really are not seeing a loss of precision here. When simplify carries out the indicated multiplication such as 9*.546/16 a machine precision number is returned because on of the arguments only has machine precision. It would be incorrect for Mathematica to return a result with greater precision than the arguements. It would also be incorrect for Mathematica to refuse to preform the required multiplications when simplifying this expression. Or said differently, if you want an exact result from Mathematica *all* of the information you supply Mathematica must also be exact. It is not sensible for Mathematica to do otherwise. ==== Bill, See my comments below. There is no logical reason to insist part of the expression to be exact when another part is inexact. You cannot gain more precision than the least precise portion of the expression. Further, there is extra processing overhead associated with maintaining exact epressions as well as additional storage requirements. For a simple expression such as your example the additional overhead is insignificant. But it increases for every exact term in the expression. It doesn't take all that many terms until the overhead associate with exact computation becomes noticeable. > It seems to me that you are arguing that if you have an expression consisting of one term which is very inprecise and another term which is very precise or exact, then the total expression is only as precise as the least precise portion of the expression. This is total nonsense. Consider adding the following terms: 1.234567890123456`16 + 0.00000000000000001`1 consisting of one term with precision 16 and another term with precision 1. By your argument, Mathematica should return an answer with only a single digit of precision. Of course, Mathematica does no such thing. >Even more troubling (to me, at least) is the >following: > >x[0]+3x[1]/4+9x[2]/16+.4//Simplify > >0.4 + x[0] + 0.75 x[1] + 0.5625 x[2] > >I don't want Simplify to change my nice rational numbers to machine >number approximations. If you want exact answers you *must* have *all* terms in the expresssion exact. Simply put either an expression is exact or not. No expression can be exact unless *all* of the terms within it are exact. When did I ever say that I wanted exact answers? In the example above, I wanted Simplify to do nothing, that is, leave the expression as a sum of an inexact quantity with some exact quantities. In the work where this situation arose, the inexact quantities are typically very small and the exact quantities are large, so that the precision of the overall expression when extended precision numbers are substituted for the x[i] is typically the same as the precision of the numbers bei