Subject: closing notebook cells As I learned in mathgroup a few years ago I am using the following code to close automatically my graphics groups. CloseAnim[]:=(SelectionMove[EvaluationNotebook[],All,GeneratedCell]; FrontEndTokenExecute[OpenCloseGroup];); CloseAnim::usage = CloseAnim[]; For example: Table[Show[Graphics[ {Hue[Random[] ],Rectangle[{0,0},{1,1}] }]],{3}]; CloseAnim[]; The problem is that when I only generate a single cell OpenCloseGroup will generate a beep. Any idea on how to prevent that beep or test if GeneratedCell selected a single or several cells? Luc === Subject: Re: newbie question on functions Functional programming would be simpler. ratio[mat_?MatrixQ, col1_Integer, col2_Integer] := (Log[2,#[[1]]/#[[2]]]& /@ mat[[All,{col1,col2}]]) /; 1<=col1<=Length[mat[[1]]] && 1<=col2 <= Length[mat[[1]]]; intensity[mat_?MatrixQ, col1_Integer, col2_Integer] := (Log[2,#[[1]]*#[[2]]]& /@ mat[[All,{col1,col2}]]) /; 1<=col1<=Length[mat[[1]]] && 1<=col2 <= Length[mat[[1]]]; fmicroarray=Array[fma,{3,19}]; ratio[fmicroarray,18,19] {Log[fma[1, 18]/fma[1, 19]]/Log[2], Log[fma[2, 18]/fma[2, 19]]/Log[2], Log[fma[3, 18]/fma[3, 19]]/Log[2]} intensity[fmicroarray,18,19] {Log[fma[1, 18]*fma[1, 19]]/Log[2], Log[fma[2, 18]*fma[2, 19]]/Log[2], Log[fma[3, 18]*fma[3, 19]]/Log[2]} Bob Hanlon === > Subject: newbie question on functions > Hi all, > I have what is probably a nieve question, but it is giving me some difficulty. I am trying to generate a function in which I pass two columns of information from a matrix to this function to perform some calculations. I can successfully pass the data and get the resulting calculation......but the problem is the function returns the results but does not save the results in memory to perform subsequent calculations with. How can I get the function to keep the result? Is there a way to assign the function output to a new variable before mathematica discards the results. Does this behavior have anything to do with the Head of the function being symbolic, rather than say a list?? > Below is the relevant code: > SetAttributes[ratio,Listable]; > SetAttributes[intensity,Listable]; > ratio[cy3_,cy5_]:=Table[Log[2,(cy3/cy5)]]//N; > intensity[cy3_,cy5_]:=Table[Log[2,(cy3*cy5)]]//N; > ratio[Table[fmicroarray[[i,18]],{i,1,Length[fmicroarray]}], > Table[fmicroarray[[i,19]],{i,1,Length[fmicroarray]}]] > Todd === Subject: Re: plot variance(s) You left the x-coordinates unspecified so they defaulted to the positive integers. Change your data definition to data=Table[{x,Sin[x]},{x,0,2?}]; Bob Hanlon === > Subject: plot variance(s) > Input1: data = Table[Sin[x], {x, 0, 2[Pi]}]; > Input 2: p1 = ListPlot[data, > PlotStyle -> {Red, PointSize[0.03]}, DisplayFunction -> Identity]; > Input 3: p2 = Plot[Sin[x], {x, 0, 2[Pi]}, DisplayFunction -> Identity]; > Input 4: Show[p1, p2, DisplayFunction -> $DisplayFunction]; > Steven Shippee > slshippee@comcast.net > 360-493-8353 === Subject: Re: plot variance(s) > Input1: data = Table[Sin[x], {x, 0, 2[Pi]}]; > Input 2: p1 = ListPlot[data, > PlotStyle -> {Red, PointSize[0.03]}, DisplayFunction -> Identity]; > Input 3: p2 = Plot[Sin[x], {x, 0, 2[Pi]}, DisplayFunction -> > Identity]; > Input 4: Show[p1, p2, DisplayFunction -> $DisplayFunction]; Construct the ListPlot data using data = Table[{x, Sin[x]}, {x, 0, 2*Pi}]; and everything should be OK. Hugh Walker Gnarly Oaks === Subject: Re: Re: 3D plotting problem I am sorry that I was not clear enough about the nature of my problem, which I will try to illustrate by the following example: If 'Cos' is replaced by 'Cosh' in the command ContourPlot3D[Cos[Sqrt[x^2+y^2+z^2]],{x,-2,2},{y,0,2},{z,-2,2}] an empty plot box appears. It seems to me that it is problematic to make 3D contour plots involving exponential functions, and I hope somebody can suggest a remedy for this. Henning Heiberg-Andersen >I find myself unable to make a 3D plot of the atomic 2p orbital >f_z(2p,x,y,z;a)=z*Exp[-a*Sqrt[x^2+y^2+z^2]]. >As far as I can understand, 'ContourPlot3D' is the only option, but >it gives either an empty plot box or a flat sheet. >Can anyone suggest a way out? > You did not make it clear exactly what you tried to plot. If it was the expression you posted, then try re-writting your function as > f[x_, y_, z_, a_] := z*Exp[-a*Sqrt[x^2 + y^2 + z^2]] > Here, I've eliminated the _z from the function name as Mathematica doesn't allow underscore characters in function names f_z is interpeted by Mathematica to be any expression with Head z given a name f, not what you want. > Changed the ( to [ to corespond to proper Mathematica syntax > dropped 2p from the arguements since it does not appear on the rhs > added a underscore to all of the other arguments. Using x_ is interpreted by Mathematica as being any valid expression and is given a local name of x > Replaced Set (=) with DelayedSet (:=) > -- > To reply via email subtract one hundred and four === Subject: Re: plot variance(s) >> Why doesn't p2 directly overlay the dots in p1? ListPlot assumes the x-coordinates (when you don't specify them) are 1, ..., Length@data. To get the right results, specify the x-coordinates: data = Table[{x, Sin[x]}, {x, 0, 2*Pi}]; p1 = ListPlot[data, PlotStyle -> {Red, PointSize[0.03]}, DisplayFunction -> Identity]; p2 = Plot[Sin[x], {x, 0, 2*Pi}, DisplayFunction -> Identity]; Show[p1, p2, DisplayFunction -> $DisplayFunction]; or data = Table[Sin[x], {x, 0, 2*Pi}]; p1 = ListPlot[Transpose[{Range[0, 2*Pi], data}], PlotStyle -> {Red, PointSize[0.03]}, DisplayFunction -> Identity]; p2 = Plot[Sin[x], {x, 0, 2*Pi}, DisplayFunction -> Identity]; Show[p1, p2, DisplayFunction -> $DisplayFunction]; or just DisplayTogether[Graphics[{PointSize[0.03], Red, Table[Point@{x, Sin[x]}, {x, 0, 2*Pi}]}], Plot[Sin[x], {x, 0, 2*Pi}]]; I don't think ListPlot is very useful, in general. Bobby > Input1: data = Table[Sin[x], {x, 0, 2[Pi]}]; > Input 2: p1 = ListPlot[data, > PlotStyle -> {Red, PointSize[0.03]}, DisplayFunction -> Identity]; > Input 3: p2 = Plot[Sin[x], {x, 0, 2[Pi]}, DisplayFunction -> Identity]; > Input 4: Show[p1, p2, DisplayFunction -> $DisplayFunction]; > Steven Shippee > slshippee@comcast.net > 360-493-8353 -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: plot variance(s) >Input1: data = Table[Sin[x], {x, 0, 2[Pi]}]; >Input 2: p1 = ListPlot[data, PlotStyle -> {Red, PointSize[0.03]}, >DisplayFunction -> Identity]; >Input 3: p2 = Plot[Sin[x], {x, 0, 2[Pi]}, DisplayFunction -> >Identity]; >Input 4: Show[p1, p2, DisplayFunction -> $DisplayFunction]; Because you did not retain the x value in your variable data. With out retaining the x value, ListPlot assumes a starting value of 1 not 0. The result is you are plotting Sin[x-1] with ListPlot and Sin[x] with Plot -- To reply via email subtract one hundred and four === Subject: Re: bimodal ditribution form counting signs of Pi digits differences > Just looking at the distribution of digits {0,1,3,4,5} as -1 > amd {5,6,7,8,9} as 1. Presumably you mean {0,1,2,3,4} and {5,6,7,8,9}? > As cumlative sum function of the same sort as I used with the sign. > It should in the case of equal probability of the digits tend to > a sum of zero. Variaiations as away from zero would probably be > function of Sqrt[n] plus and minus as a friend pointed out for the > other distribution. > Still the > Random [Integer,{0,9}] > would be the logical null hypothesis distribution ( using a random seed > of somesort. > The idea is to try to make a measure for cumlative digit randomness. If I understand you corrrectly this is a very standard test and will not yield anything better than the tests that have alrady been extensively performed in both cases. You can find a number of considerably subtler tests in Chapter 3, Volume II of Knuth's The Art of Computer Programming. Since then many more powerful tests have been designed, particulalry by George Marsaglia. They have all been used on the Wolfram CA generator and on the digits of Pi. > Since it is an interesting question, > comparing two pseudorandom methods would seem > to tell us more about both of them? > It is a thought experient that came up with some strange > results. > I just noticed that they didn't look right. The problem is with the meaning of look right. What size of samples have you used ? What sort of statistical analysis did you subject your results to? Most of all, have you looked at any serious analysis of these algorithms? For example, the statistical properties of the Wolfram CA algorithm (which is what Random[Integer, {0,9}] is) were already analysed in Wolfram's original paper Random Sequence Generation by Cellular Automata, in Advances in Applied Mathematics 1986, reprinted in Wolfram's collected papers Cellular Automata and Complexity, 1994. It's only when you examine such sources and compare that with your results and still find that they don't look right this matter might become interesting. At the moment it looks exaclty like Bobby Treat described it: a waste of time. Andrzej Kozlowski > I had in the past sort of half heartedly counted distribution of > individual digits > with no reall telling effect. > This Sign difference method seemed a better way to test the randomness, > I think I've hit on a better way than that: > Just looking at the distribution of digits {0,1,3,4,5} as -1 > amd {5,6,7,8,9} as 1. > As cumlative sum function of the same sort as I used with the sign. > It should in the case of equal probability of the digits tend to > a sum of zero. Variaiations as away from zero would probably be > function of Sqrt[n] plus and minus as a friend pointed out for the > other distribution. > Still the > Random [Integer,{0,9}] > would be the logical null hypothesis distribution ( using a random seed > of somesort. > The idea is to try to make a measure for cumlative digit randomness. > Since it is an interesting question, > comparing two pseudorandom methods would seem > to tell us more about both of them? > It is a thought experient that came up with some strange > results. > I just noticed that they didn't look right. >> *This message was transferred with a trial version of CommuniGate(tm) >> Pro* >> Actually, Random[Integer,{0,9}] unlike Random[] already uses the >> Wolfram CA algorithm, so it will not benefit form the >> RandomReplacement package. >> On the other hand the Wolfram CA algorithm has undergone very >> demanding testing for randomness (or rather, pseudo-randomness, >> which is the case of computers is essentially the same thing) and as >> far as I know has passed them all with flying colours. Therefore I >> find it hard to believe that someone would find something wrong with >> this famous generator using such simple methods; it's rather like >> finding a trivial counterexample to a long established theorem. >> Still such things do happen from time to time so if it is the case >> this time ... Roger Bagula is going to be famous ;-) >> Of course it is well known that Pi is an extremely good >> pseudo-random number generator, although as far as I know nobody >> can prove anything about it. There has been a long standing >> conjecture that the digits of Pi give an inifinity-distributed >> 10-ary sequence though I don't think anybody ever managed to make >> any progress on this matter. However, my knowledge of these these is >> very dated; in fact it goes back to volume 2 of Knuth's ACP, but I >> assume that if somebody may to prove something spectacular in this >> area I would have heard about it. The same is true of course about >> discovering non-randomness in Wolfram's CA algorithm, though I would >> expect this to be a considerably easier task than proving anything >> at all about the randomness of the digits of Pi. >> Andrzej Kozlowski >> Chiba, Japan >> http://www.akikoz.net/~andrzej/ >> http://www.mimuw.edu.pl/~akoz/ > Like the digits of Pi, Random[Integer,{0,9}] is not random--it's > pseudo-random at best. Google for Andrzej Kozlowski's > RandomReplacement, go to his web-page, download the package, and see > if it helps your situation. > Meanwhile, here's an improvement on Don Taylor's method: > digits = 100000; > h = Rest@# - Most@# &; > Timing[rdpi = RealDigits[Pi, 10, digits][[1]]; > frdpi = Drop[rdpi, -1]; > lrdpi = Drop[rdpi, 1]; > s = Drop[FoldList[Plus, 0, Sign[Thread[Subtract[lrdpi, frdpi]]]], > 1]; > taylor = Table[{n, s[[n + 1]]}, {n, 0, digits - 2}];] > Timing[brt4 = Transpose@{ > Range[0, digits - 2], Rest@FoldList[Plus, 0, > Sign@h@First@RealDigits[Pi, 10, digits]]};] > brt4 == taylor > {0.469 Second,Null} > {0.171 Second,Null} > True >> Don Taylor already improved the timoing with this: >> Timing[rdpi=RealDigits[Pi,10,Digits][[1]]; >> frdpi=Drop[rdpi,-1]; >> lrdpi=Drop[rdpi,1]; >> s=Drop[FoldList[Plus,0,Sign[Thread[Subtract[lrdpi,frdpi]]]],1]; >> Table[{n,s[[n+1]]},{n,0,Digits-2}]] >> rdpi=RealDigits[Pi,10,Digits][[1]];frdpi=Drop[rdpi,-1]; >> lrdpi=Drop[rdpi,1]; >> Drop[FoldList[Plus,{ >> -1,0},Map[{1,#}&,Sign[Thread[Subtract[lrdpi,frdpi]]]]],1] >> >> The problem is when I use >> Random[Integer,{0,9}] >> as a simulation of the Pi digits array, >> I get a worse distribution ... less like what I should get >> theoretically >> for a truly random distribution of digits. >> The Pi digits are more like what probability predicts. >> That's what I asked you help with. >> You definitely know more about statitical distriubutions in some >> ways >> than I do. >> Don and I think it may be that the ca Random of Mathematica isn't >> working right >> in this case. >> Do tried simulationg the Sign[] difference as >> Random[Integer,{-1,1}] >> but that cuts out the bimodal/ trimodal {a,b} probability. >> >> You are an extremely good Mathematica programmer. >> >> > Below I've provided a version of your program using Dynamic > Programming, plus another method of my own. Your code recalculates > the > same summands repeatedly. The first difference > Floor@Mod[10Pi,10]-Floor@Mod[Pi,10] is calculated 2000 times to get > {f[1],..., f[2000]. Dynamic programming eliminates the > duplications. > > In addition, there's a tremendous amount of waste involved because, > for instance, calculating the 2000th term requires computing Pi to > 2000 digits (or so), but getting the 1999th term required computing > only one fewer digits. The two computations are completely > separate, > each of them starting from scratch. My method eliminates THAT > wasted > effort. (It assumes you know in advance how far you'll go, of > course.) > > Here's a timing directly after Quit. Calculating again will give > faster times (because Mathematica caches certain results, I > suppose). > > ClearAll[f, g] > n = 5000; > Timing[mine = > Rest@FoldList[Plus, 0, Sign /@ ListCorrelate[{-1, > 1}, First@RealDigits[Pi, 10, n + 2]]];] > Timing[yours = Block[{$MaxExtraPrecision = n}, > g[i_] := Sign[Floor@Mod[10^(i + 1)*Pi, 10] - > Floor@Mod[10^i*Pi, 10]]; > f[0] = g[0]; > f[m_] := f[m] = f[m - 1] + g@m; > f /@ Range[0, n] > ];] > mine == yours > > {3.797 Second,Null} > > {0.016 Second,Null} > > True > > The original code's Table statement took 10.4 seconds for 500 > terms, > 44 seconds for 1000, 103.6 seconds for 1500, and 195.2 seconds for > 2000. I didn't take it to 5000, as I did in the timing above. > > It's all a waste of time, but at least you can waste a lot LESS > time. > > Bobby > > >> This program is real slow on my machine. >> Show a lean toward positive differences that is slight at 2000 >> digits. >> >> Digits=2000 >> $MaxExtraPrecision = Digits >> (* Sum of the sign of the differences between the first 2000 >> digits >> of Pi*) >> f[m_]=Sum[Sign[Floor[Mod[10^(n+1)*Pi,10]]- >> Floor[Mod[10^n*Pi,10]]],{n,0,m}] >> a=Table[{n,f[n]},{n,0,Digits-1}]; >> ListPlot[a,PlotJoined->True] >> b=Table[a[[n]][[2]],{n,1,Dimensions[a][[1]]}]; >> (* distribution of the noise that results*) >> c=Table[Count[b,m],{m,-12,12}] >> ListPlot[c,PlotJoined->True] >> >> Respectfully, Roger L. Bagula >> tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca >> 92040-2905,tel: >> 619-5610814 : >> alternative email: rlbtftn@netscape.net >> URL : http://home.earthlink.net/~tftn >> >> >> >> > > > >> > -- > DrBob@bigfoot.com > www.eclecticdreams.net > -- > Respectfully, Roger L. Bagula > tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: > 619-5610814 : > alternative email: rlbtftn@netscape.net > URL : http://home.earthlink.net/~tftn === Subject: Re: bimodal ditribution form counting signs of Pi digits differences re :b-normal->Prng pseudorandomness - Pi-Hacks post: 1. Re: Digest Number 488 ________________________________________________________________________ ________________________________________________________________________ Message: 1 === Subject: Re: Digest Number 488 > My primary post egroup is my own true number theory group. > Roger, I'm curious how pi/2 can be related to an infinite sum of the orbital trajectories of the quadratic iterator in its chaotic regime but can't find a reference to this. I understand you work in this field. Do you know about this? I thought David Bailey might so I contacted him as he deals with this. Perhaps you are aware already of his work. These are the references he sent me which you might be interested in if not (I didn't see any mention of the quadratic iterator at least in the first paper). http://crd.lbl.gov/~dhbailey/dhbpapers/baicran.pdf A related paper is: http://crd.lbl.gov/~dhbailey/dhbpapers/bcnormal.pdf Dominic >>Just looking at the distribution of digits {0,1,3,4,5} as -1 >>amd {5,6,7,8,9} as 1. >> >Presumably you mean {0,1,2,3,4} and {5,6,7,8,9}? >>As cumlative sum function of the same sort as I used with the sign. >>It should in the case of equal probability of the digits tend to >>a sum of zero. Variaiations as away from zero would probably be >>function of Sqrt[n] plus and minus as a friend pointed out for the >>other distribution. >>Still the >>Random [Integer,{0,9}] >>would be the logical null hypothesis distribution ( using a random seed >>of somesort. >>The idea is to try to make a measure for cumlative digit randomness. >> >If I understand you corrrectly this is a very standard test and will >not yield anything better than the tests that have alrady been >extensively performed in both cases. You can find a number of >considerably subtler tests in Chapter 3, Volume II of Knuth's The Art >of Computer Programming. Since then many more powerful tests have been >designed, particulalry by George Marsaglia. They have all been used on >the Wolfram CA generator and on the digits of Pi. >>Since it is an interesting question, >>comparing two pseudorandom methods would seem >>to tell us more about both of them? >>It is a thought experient that came up with some strange >>results. >>I just noticed that they didn't look right. >> >The problem is with the meaning of look right. What size of samples >have you used ? What sort of statistical analysis did you subject your >results to? Most of all, have you looked at any serious analysis of >these algorithms? For example, the statistical properties of the >Wolfram CA algorithm (which is what Random[Integer, {0,9}] is) were >already analysed in Wolfram's original paper Random Sequence >Generation by Cellular Automata, in Advances in Applied Mathematics >1986, reprinted in Wolfram's collected papers Cellular Automata and >Complexity, 1994. It's only when you examine such sources and compare >that with your results and still find that they don't look right this >matter might become interesting. At the moment it looks exaclty like >Bobby Treat described it: a waste of time. >Andrzej Kozlowski >>I had in the past sort of half heartedly counted distribution of >>individual digits >>with no reall telling effect. >>This Sign difference method seemed a better way to test the randomness, >>I think I've hit on a better way than that: >>Just looking at the distribution of digits {0,1,3,4,5} as -1 >>amd {5,6,7,8,9} as 1. >>As cumlative sum function of the same sort as I used with the sign. >>It should in the case of equal probability of the digits tend to >>a sum of zero. Variaiations as away from zero would probably be >>function of Sqrt[n] plus and minus as a friend pointed out for the >>other distribution. >>Still the >>Random [Integer,{0,9}] >>would be the logical null hypothesis distribution ( using a random seed >>of somesort. >>The idea is to try to make a measure for cumlative digit randomness. >>Since it is an interesting question, >>comparing two pseudorandom methods would seem >>to tell us more about both of them? >>It is a thought experient that came up with some strange >>results. >>I just noticed that they didn't look right. >> >*This message was transferred with a trial version of CommuniGate(tm) >Pro* >Actually, Random[Integer,{0,9}] unlike Random[] already uses the >Wolfram CA algorithm, so it will not benefit form the >RandomReplacement package. >On the other hand the Wolfram CA algorithm has undergone very >demanding testing for randomness (or rather, pseudo-randomness, >which is the case of computers is essentially the same thing) and as >far as I know has passed them all with flying colours. Therefore I >find it hard to believe that someone would find something wrong with >this famous generator using such simple methods; it's rather like >finding a trivial counterexample to a long established theorem. >Still such things do happen from time to time so if it is the case >this time ... Roger Bagula is going to be famous ;-) >Of course it is well known that Pi is an extremely good >pseudo-random number generator, although as far as I know nobody >can prove anything about it. There has been a long standing >conjecture that the digits of Pi give an inifinity-distributed >10-ary sequence though I don't think anybody ever managed to make >any progress on this matter. However, my knowledge of these these is >very dated; in fact it goes back to volume 2 of Knuth's ACP, but I >assume that if somebody may to prove something spectacular in this >area I would have heard about it. The same is true of course about >discovering non-randomness in Wolfram's CA algorithm, though I would >expect this to be a considerably easier task than proving anything >at all about the randomness of the digits of Pi. >Andrzej Kozlowski >Chiba, Japan >http://www.akikoz.net/~andrzej/ >http://www.mimuw.edu.pl/~akoz/ > >>Like the digits of Pi, Random[Integer,{0,9}] is not random--it's >>pseudo-random at best. Google for Andrzej Kozlowski's >>RandomReplacement, go to his web-page, download the package, and see >> if it helps your situation. >> >>Meanwhile, here's an improvement on Don Taylor's method: >> >>digits = 100000; >>h = Rest@# - Most@# &; >>Timing[rdpi = RealDigits[Pi, 10, digits][[1]]; >> frdpi = Drop[rdpi, -1]; >> lrdpi = Drop[rdpi, 1]; >> s = Drop[FoldList[Plus, 0, Sign[Thread[Subtract[lrdpi, frdpi]]]], >> 1]; >> taylor = Table[{n, s[[n + 1]]}, {n, 0, digits - 2}];] >>Timing[brt4 = Transpose@{ >> Range[0, digits - 2], Rest@FoldList[Plus, 0, >> Sign@h@First@RealDigits[Pi, 10, digits]]};] >>brt4 == taylor >> >>{0.469 Second,Null} >> >>{0.171 Second,Null} >> >>True >> >> >> >> >Don Taylor already improved the timoing with this: >Timing[rdpi=RealDigits[Pi,10,Digits][[1]]; > frdpi=Drop[rdpi,-1]; > lrdpi=Drop[rdpi,1]; > s=Drop[FoldList[Plus,0,Sign[Thread[Subtract[lrdpi,frdpi]]]],1]; > Table[{n,s[[n+1]]},{n,0,Digits-2}]] > rdpi=RealDigits[Pi,10,Digits][[1]];frdpi=Drop[rdpi,-1]; >lrdpi=Drop[rdpi,1]; >Drop[FoldList[Plus,{ >-1,0},Map[{1,#}&,Sign[Thread[Subtract[lrdpi,frdpi]]]]],1] > >The problem is when I use >Random[Integer,{0,9}] >as a simulation of the Pi digits array, >I get a worse distribution ... less like what I should get >theoretically >for a truly random distribution of digits. >The Pi digits are more like what probability predicts. >That's what I asked you help with. >You definitely know more about statitical distriubutions in some >ways >than I do. >Don and I think it may be that the ca Random of Mathematica isn't >working right >in this case. >Do tried simulationg the Sign[] difference as >Random[Integer,{-1,1}] >but that cuts out the bimodal/ trimodal {a,b} probability. > >You are an extremely good Mathematica programmer. > > > > >>Below I've provided a version of your program using Dynamic >>Programming, plus another method of my own. Your code recalculates >> the >>same summands repeatedly. The first difference >>Floor@Mod[10Pi,10]-Floor@Mod[Pi,10] is calculated 2000 times to get >>{f[1],..., f[2000]. Dynamic programming eliminates the >>duplications. >> >>In addition, there's a tremendous amount of waste involved because, >>for instance, calculating the 2000th term requires computing Pi to >>2000 digits (or so), but getting the 1999th term required computing >>only one fewer digits. The two computations are completely >>separate, >>each of them starting from scratch. My method eliminates THAT >>wasted >>effort. (It assumes you know in advance how far you'll go, of >>course.) >> >>Here's a timing directly after Quit. Calculating again will give >>faster times (because Mathematica caches certain results, I >>suppose). >> >>ClearAll[f, g] >>n = 5000; >>Timing[mine = >> Rest@FoldList[Plus, 0, Sign /@ ListCorrelate[{-1, >> 1}, First@RealDigits[Pi, 10, n + 2]]];] >>Timing[yours = Block[{$MaxExtraPrecision = n}, >> g[i_] := Sign[Floor@Mod[10^(i + 1)*Pi, 10] - >>Floor@Mod[10^i*Pi, 10]]; >> f[0] = g[0]; >> f[m_] := f[m] = f[m - 1] + g@m; >> f /@ Range[0, n] >> ];] >>mine == yours >> >>{3.797 Second,Null} >> >>{0.016 Second,Null} >> >>True >> >>The original code's Table statement took 10.4 seconds for 500 >>terms, >>44 seconds for 1000, 103.6 seconds for 1500, and 195.2 seconds for >>2000. I didn't take it to 5000, as I did in the timing above. >> >>It's all a waste of time, but at least you can waste a lot LESS >>time. >> >>Bobby >> >> >> >> >This program is real slow on my machine. >Show a lean toward positive differences that is slight at 2000 >digits. > >Digits=2000 >$MaxExtraPrecision = Digits >(* Sum of the sign of the differences between the first 2000 >digits >of Pi*) >f[m_]=Sum[Sign[Floor[Mod[10^(n+1)*Pi,10]]- >Floor[Mod[10^n*Pi,10]]],{n,0,m}] >a=Table[{n,f[n]},{n,0,Digits-1}]; >ListPlot[a,PlotJoined->True] >b=Table[a[[n]][[2]],{n,1,Dimensions[a][[1]]}]; >(* distribution of the noise that results*) >c=Table[Count[b,m],{m,-12,12}] >ListPlot[c,PlotJoined->True] > >Respectfully, Roger L. Bagula >tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca >92040-2905,tel: >619-5610814 : >alternative email: rlbtftn@netscape.net >URL : http://home.earthlink.net/~tftn > > > > > > >> >> >> >> >>-- >>DrBob@bigfoot.com >>www.eclecticdreams.net >> >> >> >> > >>-- >>Respectfully, Roger L. Bagula >>tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: >>619-5610814 : >>alternative email: rlbtftn@netscape.net >>URL : http://home.earthlink.net/~tftn >> -- Respectfully, Roger L. Bagula tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: 619-5610814 : alternative email: rlbtftn@netscape.net URL : http://home.earthlink.net/~tftn === Subject: Re: bimodal ditribution form counting signs of Pi digits differences >The built-in Random[] function has a bit of serial autocorrelation, >too. (Google RandomReplacement.) I think most of what you're seeing >is because of Sum, however. My understanding this is not true for those cases where Mathematica uses the Wolfram Rule 30 cellular automata to generate random numbers which would be the case with Random[Integer, {0,9}]. And in fact, Andre's RandomReplacement makes use of Random[Integer, 2^30-1] to work around the issue with Random[Real]. -- To reply via email subtract one hundred and four === Subject: Re: Re: New version, new bugs This was fixed in version 5.0, but it's broken again in 5.0.1: N[Pi,20] InputForm[%] 3.1415926535897932385 3.14159265358979323846264338358737222874`20. InputForm[%, NumberMarks -> False] 3.14159265358979323846264338358737222874 We're supposed to see 20 digits in the last output, according to the Book, section 3.1.4. Bobby > In version 5: > N[Pi,20] > InputForm@% > 3.1415926535897932385 > 3.141592653589793238462643383 > 58737222874`20. > InputForm[%,NumberMarks[Rule]False] > 3.1415926535897932385 > But I agree the bug-reporting and repair process is broken. > It needs to be much more transparent -- if what we think and feel countsfor anything. > Bobby >> I agree that the other bugs you mention are awful and ought to have been >> fixed long ago. Some of them at least seem pretty trivial to fix and it >> seems that the only reason why they haven't been fixed is that they were >> never recorded on a to be done list. I feel that something is seriously >> amiss when a reported bug that does not require a major re-write of the >> kernel is not fixed: at least the person who reported it ought to begiven >> an explanation why it has not been done. It looks to me that Wolfram's >> entire bug-reporting system needs a serious reconsideration. ------------- >> ------- >> The Wolfram Research process for testing and fixing bugs is badly brokenat >> Wolfram Research. For more evidence of this consider the following. The >> Mathematica Book (4th edition) section 3.1.4 gives the following on page >> 722. >> In[11]:=N[Pi,20] >> Out[11]= 3.1415926535897932385 >> In[12]:=InputForm[%] >> Out[12]//InputForm = 3.141592653589793238462643383279503`20 >> In[13]:= InputForm[%,NumberMarks->False] >> Out[13]//InputForm = 3.1415926535897932385 >> I am using Mathematica 4.1 under Windows 98, and I get Out[13]//InputForm= InputForm[3.141592653589793238462643383279503`20, NumberMarks -> False] >> from the last line above. >> Someone at Wolfram said this probably works on the platform that was usedto >> make The Mathematica Book. I reported this problem several months before >> version 4.0 was released, and it still wasn't fixed even in version 4.1. I >> don't know if it works in version 4.2 or 5.0, but I wouldn't bet on it. >> Shouldn't they be embarrassed that some versions of Mathematica can't do >> something that is demonstrated in The Mathematica Book? I can't believe >> fixing this would require a great deal of effort, and I find it appalling >> that they can't be bothered to fix it. >> Ted Ersek -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Re: Zero divided by a number... Amen, Richard. Mathematics doesn't deal with nothing. Zero and the empty set, yes, but nothing? No. Bobby > I think that you have been mislead about mathematics in general. > Mathematics has nothing to do with God or nature. Mathematics is > defined by man and has only the requirement that it be internally > consistent. > Zero is NOT nothing. It is a number. Mathematitians have made > definitions and rules regarding 0. Those rules define 0, not nature. > Mathematica handles 0 appropriately. x/0 is undefined for any number > x. > This is extremely simple to see if only you view division as the > opposite of multipication. > A/B = C implies that C * B = A. > 12/4 = 3 because 3*4 = 12. > 0/7 = 0 because 0*7 = 0. > 7/0 is undefined because x*0 does not equal 7 for any number x. > Therefore it has no answer (except undefined). > You were exactly wrong when you said, logic goes out the window with > mathematics. It is just the opposite. Mathematics IS logic and vice > versa. What mathematics is NOT is tricks with numbers or anything to > do with God or nature. > Logic takes rules and definitions and builds upon them. Division by > zero is undefined, and when Mathematica tells you that something is > undefined, it is not just a glitch or a failure to understand > something. It is telling you that you have evaluated something that is > truely undefined. And that means undefined logically and > intentionally--not as an oversight. > -Richard >> why is it logical to divide zero by a number, but it is not logical > to >> divide a number by zero? It seems to me like dividing nothing by a >> number should be undefined, and dividing a number by nothing should > be >> that number, lest it also be undefined because of the fact that the >> number is divided into zero parts, which is difficult to imagine. > Does >> the number cease to exist, or does it just mean that the number > doen't >> get divided at all? Of course I could argue that Zero itself is not >> defined by nature. Zero is just a place holder representing nothing. >> Logic seems to go out the window when it comes to mathmatics. When >> something doesn't follow the rules of the mathematics game its >> thrown out, or just called undefined. >> Mathematics is only just tricks with numbers. Its not a perfect >> system, and those who believe it to be god are only just fooling >> themselves. Arg...*deep breath* ....sorry. I was abused by a math >> teacher, can you tell? *laughs* -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Zero divided by a number... I think that you have been mislead about mathematics in general. Mathematics has nothing to do with God or nature. Mathematics is defined by man and has only the requirement that it be internally consistent. Zero is NOT nothing. It is a number. Mathematitians have made definitions and rules regarding 0. Those rules define 0, not nature. Mathematica handles 0 appropriately. x/0 is undefined for any number x. This is extremely simple to see if only you view division as the opposite of multipication. A/B = C implies that C * B = A. 12/4 = 3 because 3*4 = 12. 0/7 = 0 because 0*7 = 0. 7/0 is undefined because x*0 does not equal 7 for any number x. Therefore it has no answer (except undefined). You were exactly wrong when you said, logic goes out the window with mathematics. It is just the opposite. Mathematics IS logic and vice versa. What mathematics is NOT is tricks with numbers or anything to do with God or nature. Logic takes rules and definitions and builds upon them. Division by zero is undefined, and when Mathematica tells you that something is undefined, it is not just a glitch or a failure to understand something. It is telling you that you have evaluated something that is truely undefined. And that means undefined logically and intentionally--not as an oversight. -Richard >why is it logical to divide zero by a number, but it is not logical to >divide a number by zero? It seems to me like dividing nothing by a >number should be undefined, and dividing a number by nothing should be >that number, lest it also be undefined because of the fact that the >number is divided into zero parts, which is difficult to imagine. Does >the number cease to exist, or does it just mean that the number doen't >get divided at all? Of course I could argue that Zero itself is not >defined by nature. Zero is just a place holder representing nothing. >Logic seems to go out the window when it comes to mathmatics. When >something doesn't follow the rules of the mathematics game its >thrown out, or just called undefined. >Mathematics is only just tricks with numbers. Its not a perfect >system, and those who believe it to be god are only just fooling >themselves. Arg...*deep breath* ....sorry. I was abused by a math >teacher, can you tell? *laughs* === Subject: Re: Re: Zero divided by a number... > In Mathematica, it is _not_ true that x/0 is undefined for any number x. > Rather, for any nonzero x, x/0 is defined as ComplexInfinity. You mean for any x, zero or not. Let's not confuse Mathematica's result for an expression with a useful mathematical definition of it. x/0 is undefined, no matter WHAT Mathemematica does with the expression. Consider this: Simplify[x y/x] y Simplify[ComplexInfinity y/ComplexInfinity] Indeterminate As you can see, ComplexInfinity isn't a full-fledged member of the algebraic system. The same conclusion follows from the fact that 0*ComplexInfinity isn't zero. (Zero times ANYTHING meaningful is zero.) As another example, Gamma[-5] returns ComplexInfinity, but that doesn't mean defining Gamma that way (into the extended complex plane) removes the discontinuity -- which is what we'd like from a meaningful extension of Gamma. Bobby >> Mathematica handles 0 appropriately. x/0 is undefined for any number >> x. > In Mathematica, it is _not_ true that x/0 is undefined for any number x. > Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> This is extremely simple to see if only you view division as the >> opposite of multipication. > That view of division is simply inadequate in number systems (such as the > extended complex numbers) in which division of nonzero quantities by zero > is defined. >> A/B = C implies that C * B = A. >> 12/4 = 3 because 3*4 = 12. >> 0/7 = 0 because 0*7 = 0. >> 7/0 is undefined because x*0 does not equal 7 for any number x. >> Therefore it has no answer (except undefined). > In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not > imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is > Indeterminate in Mathematica.) > David Cantrell -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Zero divided by a number... > In Mathematica, it is _not_ true that x/0 is undefined for any number > x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. > You mean for any x, zero or not. No. I meant precisely what I said. If x = 0, then x/0 is Indeterminate, rather than ComplexInfinity. > Let's not confuse Mathematica's result for an expression with a useful > mathematical definition of it. ??? But Mathematica's result of ComplexInfinity _is_ correct mathematically (in the extended complex number system, of course). > x/0 is undefined, no matter WHAT > Mathemematica does with the expression. Wrong. > Consider this: > Simplify[x y/x] > Simplify[ComplexInfinity y/ComplexInfinity] > Indeterminate > As you can see, ComplexInfinity isn't a full-fledged member of the > algebraic system. Not a good argument. By precisely that same reasoning, 0 shouldn't be a full-fledged member of the algebraic system either: In[1]:= Simplify[0 x/0] Out[1]= Indeterminate > As another example, Gamma[-5] returns ComplexInfinity, but that doesn't > mean defining Gamma that way (into the extended complex plane) removes > the discontinuity -- which is what we'd like from a meaningful extension > of Gamma. In fact, defining Gamma[-5] in that way _does_ remove the discontinuity. [As z -> -5, regardless of the path in the complex plane, |Gamma[z]| increases without bound.] David Cantrell >> Mathematica handles 0 appropriately. x/0 is undefined for any number >> x. > In Mathematica, it is _not_ true that x/0 is undefined for any number > x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> This is extremely simple to see if only you view division as the >> opposite of multipication. > That view of division is simply inadequate in number systems (such as > the extended complex numbers) in which division of nonzero quantities > by zero is defined. >> A/B = C implies that C * B = A. >> >> 12/4 = 3 because 3*4 = 12. >> 0/7 = 0 because 0*7 = 0. >> 7/0 is undefined because x*0 does not equal 7 for any number x. >> Therefore it has no answer (except undefined). > In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not > imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is > Indeterminate in Mathematica.) > David Cantrell === Subject: Re: Zero divided by a number... > Mathematica handles 0 appropriately. x/0 is undefined for any number > x. In Mathematica, it is _not_ true that x/0 is undefined for any number x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. > This is extremely simple to see if only you view division as the > opposite of multipication. That view of division is simply inadequate in number systems (such as the extended complex numbers) in which division of nonzero quantities by zero is defined. > A/B = C implies that C * B = A. > 12/4 = 3 because 3*4 = 12. > 0/7 = 0 because 0*7 = 0. > 7/0 is undefined because x*0 does not equal 7 for any number x. > Therefore it has no answer (except undefined). In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is Indeterminate in Mathematica.) David Cantrell === Subject: PartitionsP The implementation of PartitionsP uses Euler's pentagonal formula for small n, and the non-recursive Hardy-Ramanujan-Rademacher method for larger n. Does anyone know what large means? I speculate that it's n>5000. --Robert === Subject: Mathematica and TeX I've been trying to generate TeX files from my notebooks, but the result is not as I would like to see it. The resulting ps or pdf layout is not good. It has overfull hboxes and vboxes: the text is not wrapped properly. Is this some setting in Mathematica that I should change? Or do I need to use a different stylesheet for TeX? (I noticed that with saving to HTML it has the same behaviour.) The question thus is: how can I make sure text in a notebook is word wrapped over lines when exporting to TeX or HTML? Erik === Subject: Question about Gomory-Cut for an application I have to find an integer solution. I use the simplex-algorithm and the Gomory-cut. It works fine, but it is to slowly. There are multiply opportunities to make a Gomory-cut. Which Gomory-cuts should I take, to get a solution in shortest time ? Where can I get information about that (in the internet) ? Ulrich === Subject: Null entry in a Graphics list? Is there a Null or a None for Graphics? If I want to accomplish something like g1 = Graphics[---]; g2 = Graphics[---] g3 = If[test, Graphics[---], NoGraphics ]; Show[g1, g2, g3 ]; is there something I can put in for NoGraphics (other than an offscreen Point or a zero-size Point or . . . ) that will be acceptable in subsequent graphics commands === Subject: Re: Null entry in a Graphics list? This is what you want: g3=If[test, Graphics[---], Graphics[{}] ]; Steve Luttrell > Is there a Null or a None for Graphics? > If I want to accomplish something like > g1 = Graphics[---]; > g2 = Graphics[---] > g3 = If[test, Graphics[---], NoGraphics ]; > Show[g1, g2, g3 ]; > is there something I can put in for NoGraphics (other than an > offscreen Point or a zero-size Point or . . . ) that will be acceptable > in subsequent graphics commands === Subject: Re: Null entry in a Graphics list? > Is there a Null or a None for Graphics? > If I want to accomplish something like > g1 = Graphics[---]; > g2 = Graphics[---] > g3 = If[test, Graphics[---], NoGraphics ]; > > Show[g1, g2, g3 ]; > is there something I can put in for NoGraphics (other than an > offscreen Point or a zero-size Point or . . . ) that will be acceptable > in subsequent graphics commands Simply using Graphics[{}] seems to work fine. I was not sure if Mathematica would 'like' a graphical object like that which contains absolutely nothing on which to determine a scale - but it seems to understand! David Bailey === Subject: Re: Null entry in a Graphics list? and the rule NoGraphics :> Sequence[] does not work ? Jens AES/newspost schrieb im Newsbeitrag > Is there a Null or a None for Graphics? > If I want to accomplish something like > g1 = Graphics[---]; > g2 = Graphics[---] > g3 = If[test, Graphics[---], NoGraphics ]; > Show[g1, g2, g3 ]; > is there something I can put in for NoGraphics (other than an > offscreen Point or a zero-size Point or . . . ) that will be acceptable > in subsequent graphics commands === Subject: Graphics and Random[] questions Hi Everyone, Well I have 2 questions: 1) I have a notebook which involves manipulating 3d plots. However everytime I run the notebook, after a while I get some kernel errors, and the mathematica kernel just quits. It crashs after a while and does not finsih evaluating all the cells. Is there a problem with my computer? or is it because of the limitation to process (huge amount of) graphics by Mathematica? 2) Random[Real, {-4,4}] gives a uniform distribution. However if I would like to have a binomial distribution or any other kind of distribution, would this be possible as well? If so then how is it done? Namrata Khemka === Subject: Re: Graphics and Random[] questions > 1) I have a notebook which involves manipulating 3d plots. However > everytime I run the notebook, after a while I get some kernel errors, > and the mathematica kernel just quits. It crashs after a while and > does not finsih evaluating all the cells. Is there a problem with my > computer? or is it because of the limitation to process (huge amount > of) graphics by Mathematica? hard to tell without seeing the code... > 2) Random[Real, {-4,4}] gives a uniform distribution. However if I > would like to have a binomial distribution or any other kind of > distribution, would this be possible as well? If so then how is it > done? from the help file. In[2]:= < schrieb im Newsbeitrag > Hi Everyone, > Well I have 2 questions: > 1) I have a notebook which involves manipulating 3d plots. However > everytime I run the notebook, after a while I get some kernel errors, > and the mathematica kernel just quits. It crashs after a while and > does not finsih evaluating all the cells. Is there a problem with my > computer? or is it because of the limitation to process (huge amount > of) graphics by Mathematica? > 2) Random[Real, {-4,4}] gives a uniform distribution. However if I > would like to have a binomial distribution or any other kind of > distribution, would this be possible as well? If so then how is it > done? > Namrata Khemka === Subject: Re: closing notebook cells > As I learned in mathgroup a few years ago I am using the following code > to close automatically my graphics groups. > CloseAnim[]:=(SelectionMove[EvaluationNotebook[],All,GeneratedCell]; > FrontEndTokenExecute[OpenCloseGroup];); > CloseAnim::usage = CloseAnim[]; > For example: > Table[Show[Graphics[ > {Hue[Random[] ],Rectangle[{0,0},{1,1}] > }]],{3}]; > CloseAnim[]; > The problem is that when I only generate a single cell OpenCloseGroup > will generate a beep. > Any idea on how to prevent that beep or test if GeneratedCell selected a > single or several cells? > Luc LinkWrite[$ParentLink, CellInformation[EvaluationNotebook[]]]; Length[LinkRead[$ParentLink]] If the length is greater than 1, then you can use the OpenCloseGroup token. CellInformation[] is new to version 5 and is, in general, a very good way to test various properties of the selection without having to do a NotebookRead[] (which could get very expensive if you have a selection which consumes a lot of memory). John Fultz jfultz@wolfram.com User Interface Group Wolfram Research, Inc. === Subject: Re: Univers font for PDF files Unzip the files to your HD, and then copy them one by one to your fonts directory. >I need help, i was able to download the zip file containing the >univers fonts. Then what? >If anyone still needs it: >>href=http://vbnet.mvps.org/files/misc/univers.zip>http://vbnet.mvps.org/ files/misc/univers.zip >>I have the font but cannot find a way to extract it from my PC >>THANK YOU VERY MUCH FOR THE HELP, IT WORKED ON MY PC, THANKS, GOD >>BLESS YOU === Subject: Re: Univers font for PDF files I need help, i was able to download the zip file containing the univers fonts. Then what? >>If anyone still needs it: >>href=http://vbnet.mvps.org/files/misc/univers.zip>http://vbnet.mvps.org /files/misc/univers.zip >I have the font but cannot find a way to extract it from my PC >THANK YOU VERY MUCH FOR THE HELP, IT WORKED ON MY PC, THANKS, GOD >BLESS YOU === Subject: NMaximize woes Hi! I have a function called FindQuality that takes two real parameters and outputs a real value. It is a very complicated set of loops, and it includes an integral which cannot be evaluated analytically (thus, NIntegrate is used). Unfortunately, when I try to call NMaximize[{FindQuality[x,y],GStart<=x<=GEnd,CStart<=y<=CEnd},{x,y}] I get - NIntegrate::inum: Integrand T1[Enr] T2[Enr,(0. y)/(x^2)] Log[(1+e^((U-Enr)/(k_b*T)))/(1+e^((U-Enr-e*V)/(k_b*T)))] is not numerical at {Enr} = {4.69691*10^-19} until the errors are forced to stop. I set the first line of FindQuality to print out its parameters, and, when calling it, the two values(?) printed are x and y. Why doesn't NMaximize call FindQuality with floating point values ? Why does it pass symbols to the function ? As you can see, x and y eventually end up in the integrand, so it's no surprise that the integrand is not numerical, right ? If I call NMaximize and my function prints out its parameters, shouldn't it end up printing out real numbers rather than symbol names ? === Subject: dashing the lines make the plot looks so bad for example, Show[Graphics[{AbsoluteDashing[{10, 5}], Line[{{0, 1}, {1, 0}}], Thickness[0.02], AbsoluteDashing[{5, 10}], Line[{{0, 0}, {1, 1}}]}]]; making it thicker shows the problem even more severely. but it appears to me there is some kinda pattern... i just don't know what it is. below shows this pattern (i think) of dashes showing up rotated every so often. Needs[Graphics`Legend`]; Needs[Graphics`Colors`]; << Graphics`Graphics` Plot[{Sin[x], Cos[x]}, {x, 0, 5Pi}, PlotStyle -> {Red, {Blue, Thickness[0.02] , AbsoluteDashing[{1, 10}]}}, LegendLabel -> this stuff nlooks weird, PlotLegend -> {Sin, Cos}, LegendPosition -> {1.1, -.25}, LegendShadow -> {0, 0}, ImageSize -> 500]; maybe if we get rid of the rotations, then the dashing will improve in appearance. so... is that possible? sean __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com === Subject: Re: dashing the lines make the plot looks so bad on screen or in the printout by a PostScript printer ? Jens sean kim schrieb im Newsbeitrag > for example, > Show[Graphics[{AbsoluteDashing[{10, 5}], Line[{{0, 1}, > {1, 0}}], Thickness[0.02], AbsoluteDashing[{5, 10}], > Line[{{0, 0}, {1, 1}}]}]]; > making it thicker shows the problem even more > severely. > but it appears to me there is some kinda pattern... i > just don't know what it is. > below shows this pattern (i think) of dashes showing > up rotated every so often. > Needs[Graphics`Legend`]; > Needs[Graphics`Colors`]; > << Graphics`Graphics` > Plot[{Sin[x], Cos[x]}, {x, 0, 5Pi}, PlotStyle -> {Red, > {Blue, Thickness[0.02] , AbsoluteDashing[{1, 10}]}}, > LegendLabel -> this stuff nlooks weird, PlotLegend > -> {Sin, Cos}, LegendPosition -> {1.1, -.25}, > LegendShadow -> {0, 0}, ImageSize -> 500]; > maybe if we get rid of the rotations, then the dashing > will improve in appearance. so... is that possible? > sean > __________________________________ > Do you Yahoo!? > Check out the new Yahoo! Front Page. > www.yahoo.com === Subject: Re: dashing the lines make the plot looks so bad hi jens i just realized that i didn't reply to this. ok it prints much btter on paper. will it be the same if i export the graphic into word. for example? i forgot to try it... i guess i could just try it next week. what is the reason for such poor display on monitor? maybe it's the frontend deal... > on screen or in the printout by a PostScript > printer ? > Jens > sean kim schrieb im Newsbeitrag > for example, > Show[Graphics[{AbsoluteDashing[{10, 5}], Line[{{0, 1}, > {1, 0}}], Thickness[0.02], AbsoluteDashing[{5, 10}], > Line[{{0, 0}, {1, 1}}]}]]; > making it thicker shows the problem even more > severely. > but it appears to me there is some kinda pattern... i > just don't know what it is. > below shows this pattern (i think) of dashes showing > up rotated every so often. > Needs[Graphics`Legend`]; > Needs[Graphics`Colors`]; > << Graphics`Graphics` > Plot[{Sin[x], Cos[x]}, {x, 0, 5Pi}, PlotStyle -> {Red, > {Blue, Thickness[0.02] , AbsoluteDashing[{1, 10}]}}, > LegendLabel -> this stuff nlooks weird, PlotLegend > -> {Sin, Cos}, LegendPosition -> {1.1, -.25}, > LegendShadow -> {0, 0}, ImageSize -> 500]; > maybe if we get rid of the rotations, then the dashing > will improve in appearance. so... is that possible? > sean > __________________________________ > Do you Yahoo!? > Check out the new Yahoo! Front Page. > www.yahoo.com === Subject: Garbage collection problem To anyone who can help me, I've written a small simulator to model the system I'm studying. It works nicely. Now I'm wrapping that simulator in a set of Do[] loops to generate maps of its behavior. Unfortunately, long runs quickly fill my After a good bit of debugging, I have isolated (at least half of of) the memory problem to my use of a StoppingTest inside NDSolve. Example: (* Setup *) eq={9.8*(0.99*Cos[qS[t]] + 0.01*Cos[qH[t] + qS[t]]) - 0.01*Sin[qH[t]]*qH'[t]*qS'[t] - 0.01*Sin[qH[t]]* qH'[t]*(qH'[t] + qS'[t]) + (0.001 + 0.01*Cos[qH[t]])* qH''[t] + (0.982 + 0.02*Cos[qH[t]])*qS''[t] == 0, 0.1*Cos[qH[t] + qS[t]] + 0.01*Sin[qH[t]]*qS'[t]^2 + 0.001*qH''[t] + (0.001 + 0.01*Cos[qH[t]])*qS''[t] == 0, qS[0] == 1.71, qS'[0] == -1.01, qH[0] == 2.84, qH'[0] == 1.1}; vars={qS[t], qH[t], qS'[t], qH'[t]}; test=qH[t] >= Pi && 2*Cos[qH[t]/2]*Cos[qH[t]/2 + qS[t]]*Sin[Pi/180] + Cos[Pi/180]*(Cos[qS[t]]*Sin[qH[t]] + (1 + Cos[qH[t]])* Sin[qS[t]]) < -0.01 && Cos[qH[t] + qS[t]]* Derivative[1][qH][t] + (Cos[qS[t]] + Cos[qH[t] + qS[t]])* Derivative[1][qS][t] < -0.01 || Abs[qH[t]] < Pi/6 || Sin[qS[t]] < 1/4; $HistoryLength=0; (* end *) (* example a *) Do[ soln=NDSolve[eq,vars,{t,0,2}][[1]]; , {20}]; MemoryInUse[] (* end *) (* example b *) Do[ soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; , {20}]; MemoryInUse[] (* end *) To reproduce this, start a fresh kernel. Execute the setup code, and then repeatedly run example a or b. When I repeatedly run example a, MemoryInUse[] quickly converges to a constant value, as expected. However, each run of example b results in an increase in memory consumption. Why? How can I fix/avoid this behavior? I stripped out some other logic, but all I really want are a few numbers from the last several solns of each run, to observe convergence properties. Daniel === Subject: Re: Re: Garbage collection problem That's an odd bug; but I kind of doubt StoppingTest is working well for you ANYWAY. If I'm wrong, I'd like to hear about it. Bobby > and example b. > In[34]:= > run[do_]:= Module[{}, > Do[ soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; , {do}]] > In[37]:= > run[200] > MemoryInUse[] > Out[38]= > 8540856 > In[34]:= > run[do_]:= Module[{}, > Do[ soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; , {do}]] > In[39]:= > run[20] > MemoryInUse[] > Out[40]= > 8625976 -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Re: Garbage collection problem I stand corrected. A stopping test is a good idea in this application. Bobby >> That's an odd bug; but I kind of doubt StoppingTest is working well for you ANYWAY. > I don't know what you mean by that... StoppingTest is a bit awkward to > work with, but I've found ways to manage, and its performing beautifully > - if you can ignore the memory leak. > Essentially, I have a dynamical system that regularly impacts with a > rigid surface. By setting the StoppingTest to halt NDSolve shortly > *after* the impact has occurred, I can save a lot of simulation time, > and it makes it easier to find the exact impact point. > I'm essentially doing the following: > (* Expect impact around 0.5; but can happen after 2 *) > soln=NDSolve[eqn, vars, {t, 0, 3}, StoppingTest->test]; > (* Detect where NDSolve stopped *) > tau=(vars[[1]]/.soln)[[0, 1, 1, 2]] > (* Find the exact surface intersection *) > tImpact=FindRoot[surface/.soln, {t, tau}]; > Because of the highly nonlinear behavior of my system, FindRoot won't > converge unless I give it a reasonably good estimate of the intersection > time. StoppingTest gives me that and stops NDSolve as soon as possible. > If you have any better ideas, I'm all ears. > Daniel -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Garbage collection problem > That's an odd bug; but I kind of doubt StoppingTest is working well for you ANYWAY. I don't know what you mean by that... StoppingTest is a bit awkward to work with, but I've found ways to manage, and its performing beautifully - if you can ignore the memory leak. Essentially, I have a dynamical system that regularly impacts with a rigid surface. By setting the StoppingTest to halt NDSolve shortly *after* the impact has occurred, I can save a lot of simulation time, and it makes it easier to find the exact impact point. I'm essentially doing the following: (* Expect impact around 0.5; but can happen after 2 *) soln=NDSolve[eqn, vars, {t, 0, 3}, StoppingTest->test]; (* Detect where NDSolve stopped *) tau=(vars[[1]]/.soln)[[0, 1, 1, 2]] (* Find the exact surface intersection *) tImpact=FindRoot[surface/.soln, {t, tau}]; Because of the highly nonlinear behavior of my system, FindRoot won't converge unless I give it a reasonably good estimate of the intersection time. StoppingTest gives me that and stops NDSolve as soon as possible. If you have any better ideas, I'm all ears. Daniel === Subject: Re: Garbage collection problem and example b. In[34]:= run[do_]:= Module[{}, Do[ soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; , {do}]] In[37]:= run[200] MemoryInUse[] Out[38]= 8540856 In[34]:= run[do_]:= Module[{}, Do[ soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; , {do}]] In[39]:= run[20] MemoryInUse[] Out[40]= 8625976 === Subject: Re: Re: Garbage collection problem G'day, > Does anyone know of an equivalent for ls -l that I could run on > Mathematica to track down the memory hog? I tried several things, but > it looks like this memory is out of my reach. What platform are you on? If it is Mac, Linux, Solaris etc, open a terminal and run top instead of ls -l. Maybe this'll help you pinpoint your woes. There must be something equivalent for Windows. Yas === Subject: Re: Garbage collection problem > G'day, >>Does anyone know of an equivalent for ls -l that I could run on >>Mathematica to track down the memory hog? I tried several things, but >>it looks like this memory is out of my reach. > What platform are you on? If it is Mac, Linux, Solaris etc, open a > terminal and run top instead of ls -l. Maybe this'll help you > pinpoint your woes. There must be something equivalent for Windows. > Yas Hi Yas, I'm running Linux. Yes, I've been running top (and free) on the command line to monitor memory usage with the OS. I was just looking for something I could run *inside* Mathematica to see *where* in Mathematica my memory was going. I know Mathematica is bleeding memory. I was trying to figure out how to staunch the flow. Daniel === Subject: Re: Garbage collection problem Hi Sean, things worse. Now, my memory usage increases each time I run example a, as well as example b. Is this problem related to my version/platform of Mathematica? Does anyone know of an equivalent for ls -l that I could run on Mathematica to track down the memory hog? I tried several things, but it looks like this memory is out of my reach. For example, (* begin *) objects = Names[]; sizes = Table[ByteCount[objects[[i]]], {i, Length[objects]}]; Total[sizes] (* end *) Running this code snippet doesn't show any increase in the memory used by my objects, even though MemoryInUse[] does. Therefore, I want to know, where is my memory going? Later, Daniel === Subject: Re: Garbage collection problem > things worse. Now, my memory usage increases each time I run example > a, as well as example b. are you monitoring it as the module is running? like by use of task manager type of program? try this... In[25]:= (*Setup*)eq={9.8*(0.99*Cos[qS[t]]+0.01*Cos[qH[t]+qS[t]])-0.01*Sin[qH[t]]* qH'[ t]*qS'[t]-0.01*Sin[qH[t]]* qH'[t]*( qH'[t]+qS'[t])+(0.001+0.01*Cos[qH[t]])* qH''[t]+( 0.982+0.02*Cos[qH[t]])* qS''[t][Equal]0, 0.1*Cos[qH[t]+ qS[t]]+0.01*Sin[qH[t]]*qS'[t]^2+0.001* qH''[t]+(0.001+0.01*Cos[qH[t]])*qS''[t][Equal]0, qS[0][Equal]1.71,qS'[0][Equal]-1.01,qH[0][Equal]2.84, qH'[0] [Equal]1.1}; vars={qS[t],qH[t],qS'[ t],qH'[t]}; test=qH[t]≥Pi&& 2*Cos[qH[t]/2]* Cos[qH[t]/2+qS[t]]*Sin[Pi/180]+ Cos[Pi/180]*(Cos[ qS[t]]*Sin[qH[ t]]+(1+Cos[ qH[t]])* Sin[qS[t]])<-0.01&& Cos[qH[t]+qS[t]]*Derivative[1][qH][ t]+(Cos[qS[t]]+Cos[qH[t]+qS[t]])* Derivative[1][qS][t]<-0.01|| Abs[qH[t]]test][[1]]; , {do}]] In[43]:= brun[20] MemoryInUse[] Share[] Share[] brun[200] MemoryInUse[] Out[44]= 3057560 Out[45]= 456 Out[46]= 0 Out[48]= 3908176 > Is this problem related to my version/platform of Mathematica? i'm running windoze xp Mathematica 5.0 > Does anyone know of an equivalent for ls -l that I could run on > Mathematica to track down the memory hog? I tried several things, but > it looks like this memory is out of my reach. > For example, > (* begin *) > objects = Names[]; > sizes = Table[ByteCount[objects[[i]]], {i, Length[objects]}]; > Total[sizes] > (* end *) > Running this code snippet doesn't show any increase in the memory used > by my objects, even though MemoryInUse[] does. Therefore, I want to > know, where is my memory going? === Subject: Re: Garbage collection problem Hi Sean, You're missing the error. I did too until my computer ran out of memory (512MB gone). > are you monitoring it as the module is running? like by use of task > manager type of program? yep. the top and free commands on Linux. These give me the same info as the MSWindows task manager. > try this... .... > In[26]:= > arun[do_]:= Module[{}, Do[ soln=NDSolve[eq,vars,{t,0,2}][[1]];, {do}] > In[36]:= > arun[20] > MemoryInUse[] .... > arun[200] > MemoryInUse[] > Out[37]= > 2999248 .... > Out[41]= > 2998864 This is good. 2998864-2999248 < 0 so memory was actually recovered. > above shows that once you use Module in combination with Share[] ( > twice), the memory usage between runnign the module 20x vs 200x is > relatively miniscule. yep. I agree. > similar with the example b. I disagree. Look again. > In[42]:= > brun[do_]:= Module[{}, Do[ soln=NDSolve[eq,vars,{t,0, > 2},StoppingTest->test][[1]]; , {do}]] > In[43]:= > brun[20] > MemoryInUse[] .... > brun[200] > MemoryInUse[] > Out[44]= > 3057560 .... > Out[48]= > 3908176 Now check the memory usage. 3908176-3057560 = 850616 !! That's nearly one more MB used, but no new variables created. On my machine, every time I run brun[20], I lose even more memory - even though no new information is being created. Share[] does not help me. $HistoryLength=0 does not help... Ideas? >>Is this problem related to my version/platform of Mathematica? > i'm running windoze xp Mathematica 5.0 Daniel === Subject: Re: Garbage collection problem actually it should have been In[1]:= (*Setup*)eq={9.8*(0.99*Cos[qS[t]]+0.01*Cos[qH[t]+qS[t]])-0.01*Sin[qH[t]]* qH'[t]*qS'[t]-0.01*Sin[qH[t]]* qH'[t]*(qH'[t]+qS'[t])+(0.001+0.01*Cos[qH[t]])* qH''[t]+(0.982+0.02*Cos[qH[t]])*qS''[t][Equal]0, 0.1*Cos[qH[t]+qS[t]]+0.01*Sin[qH[t]]*qS'[t]^2+0.001* qH''[t]+(0.001+0.01*Cos[qH[t]])*qS''[t][Equal]0, qS[0][Equal]1.71,qS'[0][Equal]-1.01,qH[0][Equal]2.84, qH'[0][Equal]1.1}; vars={qS[t],qH[t],qS'[t],qH'[t]}; test=qH[t][GreaterEqual]Pi&& 2*Cos[qH[t]/2]*Cos[qH[t]/2+qS[t]]*Sin[Pi/180]+ Cos[Pi/180]*(Cos[qS[t]]*Sin[qH[t]]+(1+Cos[qH[t]])* Sin[qS[t]])<-0.01&& Cos[qH[t]+qS[t]]*Derivative[1][qH][t]+(Cos[qS[t]]+Cos[qH[t]+qS[t]])* Derivative[1][qS][t]<-0.01||Abs[qH[t]]test][[1]]; , {do}]] In[27]:= brun[20] MemoryInUse[] Out[28]= 2800832 === Subject: Re: Garbage collection problem flank the routine in Module[] and keep things local. In[13]:= (* Setup *) run[do_]:=Do[ Module[{}, eq={9.8*(0.99*Cos[qS[t]] + 0.01*Cos[qH[t] + qS[t]]) - 0.01*Sin[qH[t]]*qH'[t]*qS'[t] - 0.01*Sin[qH[t]]* qH'[t]*(qH'[t] + qS'[t]) + (0.001 + 0.01*Cos[qH[t]])* qH''[t] + (0.982 + 0.02*Cos[qH[t]])*qS''[t] == 0, 0.1*Cos[qH[t] + qS[t]] + 0.01*Sin[qH[t]]*qS'[t]^2 + 0.001*qH''[t] + (0.001 + 0.01*Cos[qH[t]])*qS''[t] == 0, qS[0] == 1.71, qS'[0] == -1.01, qH[0] == 2.84, qH'[0] == 1.1}; vars={qS[t], qH[t], qS'[t], qH'[t]}; test=qH[t] >= Pi && 2*Cos[qH[t]/2]*Cos[qH[t]/2 + qS[t]]*Sin[Pi/180] + Cos[Pi/180]*(Cos[qS[t]]*Sin[qH[t]] + (1 + Cos[qH[t]])* Sin[qS[t]]) < -0.01 && Cos[qH[t] + qS[t]]* Derivative[1][qH][t] + (Cos[qS[t]] + Cos[qH[t] + qS[t]])* Derivative[1][qS][t] < -0.01 || Abs[qH[t]] < Pi/6 || Sin[qS[t]] < 1/4; $HistoryLength=0; ], {do}] (* end *) In[20]:= run[2000]; MemoryInUse[] Out[21]= 2944448 In[24]:= run[2]; MemoryInUse[] Out[25]= 2944448 > To anyone who can help me, > I've written a small simulator to model the system I'm studying. It > works nicely. Now I'm wrapping that simulator in a set of Do[] loops to > generate maps of its behavior. Unfortunately, long runs quickly fill my > After a good bit of debugging, I have isolated (at least half of of) the > memory problem to my use of a StoppingTest inside NDSolve. > Example: > (* Setup *) > eq={9.8*(0.99*Cos[qS[t]] + 0.01*Cos[qH[t] + qS[t]]) - > 0.01*Sin[qH[t]]*qH'[t]*qS'[t] - > 0.01*Sin[qH[t]]* > qH'[t]*(qH'[t] + qS'[t]) + (0.001 + 0.01*Cos[qH[t]])* > qH''[t] + (0.982 + 0.02*Cos[qH[t]])*qS''[t] == 0, > 0.1*Cos[qH[t] + qS[t]] + 0.01*Sin[qH[t]]*qS'[t]^2 + > 0.001*qH''[t] + (0.001 + 0.01*Cos[qH[t]])*qS''[t] == 0, > qS[0] == 1.71, > qS'[0] == -1.01, > qH[0] == 2.84, > qH'[0] == 1.1}; > vars={qS[t], qH[t], qS'[t], qH'[t]}; > test=qH[t] >= Pi && > 2*Cos[qH[t]/2]*Cos[qH[t]/2 + qS[t]]*Sin[Pi/180] + > Cos[Pi/180]*(Cos[qS[t]]*Sin[qH[t]] + (1 + Cos[qH[t]])* > Sin[qS[t]]) < -0.01 && > Cos[qH[t] + qS[t]]* > Derivative[1][qH][t] + (Cos[qS[t]] + Cos[qH[t] + qS[t]])* > Derivative[1][qS][t] < -0.01 || Abs[qH[t]] < Pi/6 || > Sin[qS[t]] < 1/4; > $HistoryLength=0; > (* end *) > (* example a *) > Do[ > soln=NDSolve[eq,vars,{t,0,2}][[1]]; > , > {20}]; > MemoryInUse[] > (* end *) > (* example b *) > Do[ > soln=NDSolve[eq,vars,{t,0,2},StoppingTest->test][[1]]; > , > {20}]; > MemoryInUse[] > (* end *) > To reproduce this, start a fresh kernel. Execute the setup code, and > then repeatedly run example a or b. When I repeatedly run example a, > MemoryInUse[] quickly converges to a constant value, as expected. > However, each run of example b results in an increase in memory > consumption. Why? How can I fix/avoid this behavior? I stripped out > some other logic, but all I really want are a few numbers from the last > several solns of each run, to observe convergence properties. > Daniel === Subject: Re: bimodal ditribution form counting signs of Pi digits differences >I did it to the maximum my version/ machine lets me using the >method I understood best. The two lists of digits are not the same( >Pi digits seem to vary more than the Random[Integer,{0.9}] do at >this level). I'm sure somebody with a later version 5.0 and a >faster machine can do better, but it still appears that Pi is a >better pseudorandom than the built in, I think ot at least >different in kind. What you showed was the output from your manipulation of the output from Random[Integer, {0,9}] is decidedly not equivalent to a uniform distribution. But there is no reason to expect this to be uniform. And this in no way supports your comment Pi is a better pseudorandom than the built in. One way (not the best way) to test whether the digits of Pi are random would be to compare these digits to the output of pseudorandom number generator. And while this method was apparently what you intended to do based on your comments, that is not what your code did. Your code considered the distribution of cummulative sums of Sign[u1-u2] where u1, u2 were randomly chosen from 0-9. If you want to compare the distribution of the digits of Pi to the output of Random[Integer, {0,9}] a reasonably test would be a two sample Kolmogorov-Smirnov test. This test is specifically designed to test whether two samples come from the same distribution or not. There are several reasons why comparing the digits of Pi to the output of a given psuedorandom number generator is not the best approach to determining whether the digits of Pi are random or not. The most important is not knowing how closely the output of the pseudorandom number generator matches a uniform distribution. Since the uniform distribution is well known and has easily computed properties, the better approach would be to test the digits of Pi to see if they have properties in common with what should be expected. Knuth in ACP Vol 2 discusses several different empirical and theoretical tests that can be used to compare the output of any given pseudorandom number generator to a uniform distribution. The same test could be used to test the hypothesis the digits of Pi are random. For example, looking at the first 1000 digits of Pi and using a one sample KS test, the relevant test statistic is: d = ({First[#1], Length[#1]} & ) /@ Split[Sort[First[RealDigits[N[Pi, 1000]]]]]; N[Sqrt[1000]*Max[Abs[Rest[FoldList[ Plus, 0, Last /@ d/1000]] - Range[10]/10]]] 0.4743416490252569 And from a table of the KS statistic 90% of the test statistic will be less than 1.068 So, the conclusion has to be the first 1000 digits of Pi show no evidence of not being from a uniform distribution. Do note, the KS test is one of many that could be used and is not the most efficient. -- To reply via email subtract one hundred and four === Subject: Re: Null entry in a Graphics list? do you mean DisplayFunction-> Identity ? then to recover it in show. DisplayFunction->$DisplayFunction > Is there a Null or a None for Graphics? > If I want to accomplish something like > g1 = Graphics[---]; > g2 = Graphics[---] > g3 = If[test, Graphics[---], NoGraphics ]; > > Show[g1, g2, g3 ]; > is there something I can put in for NoGraphics > (other than an > offscreen Point or a zero-size Point or . . . ) that > will be acceptable > in subsequent graphics commands __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com === Subject: How to include images and graphics in Mathematica How do one include graphics into mathematica without using Import[...] and Show[]? I've seen several Wolfram screendumps showing notebooks with images but no input-line to insert the image. The reason why I want this is to write design reports with images and math in dosument with nice formatting. Christopher Grinde === Subject: Re: How to include images and graphics in Mathematica >How do one include graphics into mathematica without using Import[...] >and Show[]? >I've seen several Wolfram screendumps showing notebooks with images but no >input-line to insert the image. >The reason why I want this is to write design reports with images and math >in dosument with nice formatting. Use Import[] and Show[] and then delete the input lines. : ) A nicer way would be: define the code to generate and import pictures, enclose it in a separate section of the notebook, add the calls to show specific pictures wherever needed and make all this code initializable. Evaluating the initialization cells will 'inflate' the notebook with graphics and pictures (they could be stored in gif, jpg or png format in a separate folder). I have used this approach to keep notebook sizes low and it has the plus that it is possibile to update the pictures without even having to fire up Mathematica. File locations can be made relative to the currently open notebook. I *think* it is also possibile to delete the input cells used to do the job, leaving a clean notebook with only the pictures in the right places. This is a one time only process since it destroys the code to actually show the pictures and for this reason the 'deleteCode' line should be added only to the finale versione of the notebook. cheers, Peltio and his two cents. === Subject: Re: How to include images and graphics in Mathematica > How do one include graphics into mathematica without using Import[...] > and Show[]? > I've seen several Wolfram screendumps showing notebooks with images but no > input-line to insert the image. > The reason why I want this is to write design reports with images and math > in dosument with nice formatting. You can copy and paste graphics (use the cell bracket to select) from one Mathematica notebook into another, or from some other graphics program into Mathematica. -- Helen Read University of Vermont === Subject: Problems about Graphics I used to paste the graphics generated by Mathematica on my reports written with Microsoft Word, but I also have two problem : 1. The graphics always become bigger than it is in Mathematica notebook, and I'll have to resize it to 85% so that it will looks just the same size as it is in Mathematica. But at the beginning as I used Mathematica there's no such problem; I can't remember exactly when this problem first happened. 2. The curves are not as smooth as they should be. No matter what I do there's always sawtooth with it. === Subject: Re: Problems about Graphics > I used to paste the graphics generated by Mathematica on my reports written > with Microsoft Word, but I also have two problem : > 1. The graphics always become bigger than it is in Mathematica notebook, and > I'll have to resize it to 85% so that it will looks just the same size as it > is in Mathematica. But at the beginning as I used Mathematica there's no > such problem; I can't remember exactly when this problem first happened. > 2. The curves are not as smooth as they should be. No matter what I do > there's always sawtooth with it. 1.Are you sure the magnification is 100%? 2.Select the graphic, then Edit->Copy As->Metafile and paste it into Word. You can also Export[] the graphics as Windows metafile format (.wmf). --Urijah Kaplan === Subject: Re: Problems about Graphics > I used to paste the graphics generated by Mathematica on my reports written > with Microsoft Word, but I also have two problem : > > 1. The graphics always become bigger than it is in Mathematica notebook, > and I'll have to resize it to 85% so that it will looks just the same size as > it is in Mathematica. But at the beginning as I used Mathematica there's no > such problem; I can't remember exactly when this problem first happened. If you do Format | Edit Style Sheet... for the Notebook, select the Graphics/Printout Style, then use Format | Option Inspector... type in magn (or any part of the word magnification) and hit return, I expect you will find that Magnification -> 0.85 for your StyleSheet. In other words, the StyleSheet automatically reduces the size of graphics for printout, which is usually what you want, especially if you are printing directly from a Notebook. Note that if you have Format | Show Page Breaks selected you will automatically be in the Printout Style. > 2. The curves are not as smooth as they should be. No matter what I do > there's always sawtooth with it. > > > > 1.Are you sure the magnification is 100%? > 2.Select the graphic, then Edit->Copy As->Metafile and paste it into Word. > You can also Export[] the graphics as Windows metafile format (.wmf). This, of course, assumes that you are using Windows. Under OS X you should use Edit | Copy As | PICT with embedded PostScript Paul -- Paul Abbott Phone: +61 8 6488 2734 School of Physics, M013 Fax: +61 8 6488 1014 The University of Western Australia (CRICOS Provider No 00126G) 35 Stirling Highway Crawley WA 6009 mailto:paul@physics.uwa.edu.au AUSTRALIA http://physics.uwa.edu.au/~paul === Subject: Re: Problems about Graphics > If you do > Format | Edit Style Sheet... > for the Notebook, select the Graphics/Printout Style, then use > Format | Option Inspector... > type in > magn > (or any part of the word magnification) and hit return, I expect you > will find that > Magnification -> 0.85 Well, what I see is 0.8 instead. > for your StyleSheet. In other words, the StyleSheet automatically > reduces the size of graphics for printout, which is usually what you > want, especially if you are printing directly from a Notebook. Note that > if you have > Format | Show Page Breaks > selected you will automatically be in the Printout Style. So what should I do now? I've tried to change the magnification into different number, but the problem remains. >> 2. The curves are not as smooth as they should be. No matter what I do >> there's always sawtooth with it. > This, of course, assumes that you are using Windows. Under OS X you > should use > Edit | Copy As | PICT with embedded PostScript > Paul So there's no way I can get rid of it under Windows? === Subject: Re: Problems about Graphics >> I used to paste the graphics generated by Mathematica on my reports >> written >> with Microsoft Word, but I also have two problem : >> 1. The graphics always become bigger than it is in Mathematica notebook, >> and >> I'll have to resize it to 85% so that it will looks just the same size as >> it >> is in Mathematica. But at the beginning as I used Mathematica there's no >> such problem; I can't remember exactly when this problem first happened. >> 2. The curves are not as smooth as they should be. No matter what I do >> there's always sawtooth with it. > 1.Are you sure the magnification is 100%? Yes, quite sure. I'm not sure if the problem is due to the different using of DPI between Word and Mathematica, as Word is using 96DPI but Mathematica is 72DPI. It's the only possible cause I can come up with. > 2.Select the graphic, then Edit->Copy As->Metafile and paste it into Word. > You can also Export[] the graphics as Windows metafile format (.wmf). I've tried that, but the metafile it exports already has sawtooth on it. Of course it's not that obvious on the screen, but it does after printed out or as I zoom in on the screen. I don't know why can't mathematica just generate some smoother metafile. === Subject: Re: Re: newbie question on functions >> Yes, of course you can save the result of a calculation. For example: >> result=intensity[4.,5.] > For the original newbie poster: > For newbies, or less expert users like me, it's easy to think that > something like > AppendTo[list, expr] > is a command that will do what it says: append expr to list. Takes a > few bad experiences to realize that you actually have to say > list = AppendTo[list,expr] > Same general principle applies more broadly. Actually in this particular case you are wrong. You are confusing AppendTo with simple Append. AppendTo[list, expr] is in fact enough and is equivalent to list=Append[list,expr] Andrzej Kozlowski Chiba, Japan http://www.akikoz.net/~andrzej/ http://www.mimuw.edu.pl/~akoz/ === Subject: Re: NMaximize woes You do not provide enough code to be sure. However, try changing your deinition of FindQuality to FindQuality[LoopVar_?NumericQ, Imax_??NumericQ]:= ... and see if it works better now. Andrzej Kozlowski Andrzej Kozlowski Chiba, Japan http://www.akikoz.net/~andrzej/ http://www.mimuw.edu.pl/~akoz/ > Hi! > I'm sorry if this is a repost - I don't think my previous message got > posted, but it may have been. > I have a function called FindQuality which takes two real values and > outputs a single real value. It is a complex collection of loops > (things are iterated until convergence) and includes an integral that > cannot be evaluated analytically. > When I try running it through NMaximize, I get the following error: > NIntegrate::inum: Integrand T1[Enr] T2[Enr,(0.y)/(x^2)] > Log[(1+e^((U-Enr)/(k_b*T)))/(1+e^((U-Enr-eV)/(k_B*T)))] > Except for Enr, which is the variable being integrated over, x, and y, > all other variables are constants. > NMaximize is called as follows: > NMaximize[{FindQuality[x,y],GStart <= x <= GEnd,CStart <= y <= > CEnd},{x,y}] > FindQuality is defined (partially) as follows: > FindQuality[LoopVar_, Imax_] := ( > Print[LoopVar, , Imax]; > ... > As you can see from the error message, the symbols x and y make it > all the way into the integrand. > The Print statement also outputs x y. > Why does NMaximize pass symbols(?) into FindQuality rather than > floating > point values ? I mean, no wonder the function doesn't work ! Or, am I > completely wrong ? Shouldn't the Print statement print out two floating > point values instead of two letters I passed into it anyway ? > I would appreciate any help you can give me ! === Subject: NMaximize woes Hi! I'm sorry if this is a repost - I don't think my previous message got posted, but it may have been. I have a function called FindQuality which takes two real values and outputs a single real value. It is a complex collection of loops (things are iterated until convergence) and includes an integral that cannot be evaluated analytically. When I try running it through NMaximize, I get the following error: NIntegrate::inum: Integrand T1[Enr] T2[Enr,(0.y)/(x^2)] Log[(1+e^((U-Enr)/(k_b*T)))/(1+e^((U-Enr-eV)/(k_B*T)))] Except for Enr, which is the variable being integrated over, x, and y, all other variables are constants. NMaximize is called as follows: NMaximize[{FindQuality[x,y],GStart <= x <= GEnd,CStart <= y <= CEnd},{x,y}] FindQuality is defined (partially) as follows: FindQuality[LoopVar_, Imax_] := ( Print[LoopVar, , Imax]; ... As you can see from the error message, the symbols x and y make it all the way into the integrand. The Print statement also outputs x y. Why does NMaximize pass symbols(?) into FindQuality rather than floating point values ? I mean, no wonder the function doesn't work ! Or, am I completely wrong ? Shouldn't the Print statement print out two floating point values instead of two letters I passed into it anyway ? I would appreciate any help you can give me ! === Subject: Re: NMaximize woes > Hi! > I'm sorry if this is a repost - I don't think my previous message got > posted, but it may have been. > I have a function called FindQuality which takes two real values and > outputs a single real value. It is a complex collection of loops > (things are iterated until convergence) and includes an integral that > cannot be evaluated analytically. > When I try running it through NMaximize, I get the following error: > NIntegrate::inum: Integrand T1[Enr] T2[Enr,(0.y)/(x^2)] > Log[(1+e^((U-Enr)/(k_b*T)))/(1+e^((U-Enr-eV)/(k_B*T)))] > Except for Enr, which is the variable being integrated over, x, and y, > all other variables are constants. > NMaximize is called as follows: > NMaximize[{FindQuality[x,y],GStart <= x <= GEnd,CStart <= y <= CEnd},{x,y}] > FindQuality is defined (partially) as follows: > FindQuality[LoopVar_, Imax_] := ( > Print[LoopVar, , Imax]; > ... > As you can see from the error message, the symbols x and y make it > all the way into the integrand. > The Print statement also outputs x y. > Why does NMaximize pass symbols(?) into FindQuality rather than floating > point values ? I mean, no wonder the function doesn't work ! Or, am I > completely wrong ? Shouldn't the Print statement print out two floating > point values instead of two letters I passed into it anyway ? > I would appreciate any help you can give me ! As others have said, you may need to supply more information on this one, however, I notice 'variables' like k_b and k_B in the expression being printed out as part of the diagnostic. You can't use and underscore in a variable name because it denotes a pattern. I suggest you correct this and try again. David Bailey === Subject: Re: Re: Zero divided by a number... all these statements are true as statements about *complex numbers*. Thus instead of saying x/0 is undefined ... he should have said is undefined as a complex number or is not a complex number etc. The word number is ambiguous, and there are some strange people, even some mathematicians, who call things like Infinity numbers but I have never heard of anyone refer to them as complex numbers'. (Complex of course includes real). (Besides, I don't believe that there is anyone, including yourself, who really did not understand what Richard meant.) Andrzej Kozlowski Andrzej Kozlowski Chiba, Japan http://www.akikoz.net/~andrzej/ http://www.mimuw.edu.pl/~akoz/ >> Mathematica handles 0 appropriately. x/0 is undefined for any number >> x. > In Mathematica, it is _not_ true that x/0 is undefined for any number > x. > Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> This is extremely simple to see if only you view division as the >> opposite of multipication. > That view of division is simply inadequate in number systems (such as > the > extended complex numbers) in which division of nonzero quantities by > zero > is defined. >> A/B = C implies that C * B = A. >> 12/4 = 3 because 3*4 = 12. >> 0/7 = 0 because 0*7 = 0. >> 7/0 is undefined because x*0 does not equal 7 for any number x. >> Therefore it has no answer (except undefined). > In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not > imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is > Indeterminate in Mathematica.) > David Cantrell === Subject: Re: Re: Zero divided by a number... On the one hand, I claim ComplexInfinity is a subspecies of undefined. If not, on the other hand, then Mathematica improperly defines 1/0, which really should be undefined. Bobby >> all these statements are true as statements about *complex numbers*. >> Thus instead of saying x/0 is undefined ... he should have said is >> undefined as a complex number or is not a complex number etc. The >> word number is ambiguous, and there are some strange people, even >> some mathematicians, who call things like Infinity numbers but I have >> never heard of anyone refer to them as complex numbers'. > Perhaps you would be amused to know that Bertrand Russell, in constructing > what we might nowadays call the positive extended reals from the positive > rationals, refers to the real number infinity. But that is merely of > historical interest. The real and complex number systems, as we know them > today, contain no infinite elements, of course. >> (Complex of course includes real). >> (Besides, I don't believe that there is anyone, including yourself, who >> really did not understand what Richard meant.) > I thought and I still think that I understood exactly what Richard meant. > Not only is this a _Mathematica_ newsgroup, but Richard himself _supplied > context_. He said Mathematica handles 0 appropriately. x/0 is undefined > for any number x. So it seems clear to me that he thought, incorrectly, > that _in Mathematica_ x/0 is always undefined. > Indeed, I would not be at all surprised if Richard -- after realizing that > 1/0 is ComplexInfinity, rather than undefined, in Mathematica -- now thinks > that Mathematica does _not_ handle division by 0 appropriately. > David Cantrell >> >>> Mathematica handles 0 appropriately. x/0 is undefined for any number >>> x. >> >> In Mathematica, it is _not_ true that x/0 is undefined for any number >> x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> >>> This is extremely simple to see if only you view division as the >>> opposite of multipication. >> >> That view of division is simply inadequate in number systems (such as >> the extended complex numbers) in which division of nonzero quantities >> by zero is defined. >> >>> A/B = C implies that C * B = A. >>> >>> 12/4 = 3 because 3*4 = 12. >>> 0/7 = 0 because 0*7 = 0. >>> 7/0 is undefined because x*0 does not equal 7 for any number x. >>> Therefore it has no answer (except undefined). >> >> In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not >> imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is >> Indeterminate in Mathematica.) -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Zero divided by a number... >> If x = 0, then x/0 is Indeterminate, rather than ComplexInfinity. You got me on that one, but it's a non-difference unless you can show me a use for ComplexInfinity that doesn't apply just as well to Indeterminate. Besides, if x/0 is Indeterminate but 1/0 is ComplexInfinity, what if x = 1? That doesn't seem very consistent, and in fact it leads to problems like a recent poster's issue with a Sum of Binomials. > But Mathematica's result of ComplexInfinity _is_ correct mathematically (in > the extended complex number system, of course). Not of course. ComplexInfinity isn't a number if you can't do arithmetic with it, and the documentation doesn't explain what we should expect from the concept. > Not a good argument. By precisely that same reasoning, 0 shouldn't be a > full-fledged member of the algebraic system either 0 is the only thing in a Field that has no multiplicative inverse (it's part of the DEFINITION of a field -- not an exception to the rules). If ComplexInfinity also has no inverse, your extended complex number system isn't a field, and the non-zero elements are not a group. Topologically the point at Infinity can be a useful concept, but we don't do much topology in Mathematica. Defining Gamma so that 1/Gamma[z] is entire would be useful, but Mathematica doesn't accomplish that. I'm not sure why Plot doesn't hiccup on this, for instance: Plot[Evaluate@D[1/Gamma[x], x], {x, -3, -1}] since evaluating the first argument at either endpoint gets us an error message. D[1/Gamma[x],x] /. x -> -3. (error message) Indeterminate That happens because Gamma is ComplexInfinity at the -3 and 0*ComplexInfinity == Indeterminate (use Trace). So again, using Gamma[-3] = ComplexInfinity doesn't help us -- just as it didn't help us in that Sum of Binomials. >> In fact, defining Gamma[-5] in that way _does_ remove the discontinuity. >> [As z -> -5, regardless of the path in the complex plane, |Gamma[z]| >> increases without bound.] True enough, if increases without bound is all it takes, and the definition makes Gamma act like a continuous function in some useful sense. But it doesn't. 1/Gamma[z] should be entire in the extended plane, but in Mathematica, it isn't. The only usage I've found that works the way we might expect seems to be x / ComplexInfinity (with undefined x), which evaluates to 0 -- but that's not actually right, since: ComplexInfinity/ComplexInfinity (error message) Indeterminate Hence x / ComplexInfinity (with undefined x) should be left unevaluated or replaced with Indeterminate. Similiarly, ComplexInfinity - ComplexInfinity (error) Indeterminate Once again, ComplexInfinity fails to act like a number. If it were a non-zero number in a field, the ratio would be one and the difference would be zero. We'd get the same answers (Indeterminate) in both cases if we replaced ComplexInfinity with Indeterminate, so why not use Indeterminate? So... ComplexInfinity may be a member of the extended complex plane, but it dosn't walk or quack like a NUMBER. Whenever I see ComplexInfinity, I'll read it as Indeterminate and lose absolutely nothing. But it's still there in the background, mucking things up. Bobby >> In Mathematica, it is _not_ true that x/0 is undefined for any number >> x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> You mean for any x, zero or not. > No. I meant precisely what I said. If x = 0, then x/0 is Indeterminate, > rather than ComplexInfinity. >> Let's not confuse Mathematica's result for an expression with a useful >> mathematical definition of it. > ??? > But Mathematica's result of ComplexInfinity _is_ correct mathematically (in > the extended complex number system, of course). >> x/0 is undefined, no matter WHAT >> Mathemematica does with the expression. > Wrong. >> Consider this: >> Simplify[x y/x] >> y >> Simplify[ComplexInfinity y/ComplexInfinity] >> Indeterminate >> As you can see, ComplexInfinity isn't a full-fledged member of the >> algebraic system. > Not a good argument. By precisely that same reasoning, 0 shouldn't be a > full-fledged member of the algebraic system either: > In[1]:= Simplify[0 x/0] > Out[1]= Indeterminate >> As another example, Gamma[-5] returns ComplexInfinity, but that doesn't >> mean defining Gamma that way (into the extended complex plane) removes >> the discontinuity -- which is what we'd like from a meaningful extension >> of Gamma. > In fact, defining Gamma[-5] in that way _does_ remove the discontinuity. > [As z -> -5, regardless of the path in the complex plane, |Gamma[z]| > increases without bound.] > David Cantrell >>> Mathematica handles 0 appropriately. x/0 is undefined for any number >>> x. >> >> In Mathematica, it is _not_ true that x/0 is undefined for any number >> x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> >>> This is extremely simple to see if only you view division as the >>> opposite of multipication. >> >> That view of division is simply inadequate in number systems (such as >> the extended complex numbers) in which division of nonzero quantities >> by zero is defined. >> >>> A/B = C implies that C * B = A. >>> >>> 12/4 = 3 because 3*4 = 12. >>> 0/7 = 0 because 0*7 = 0. >>> 7/0 is undefined because x*0 does not equal 7 for any number x. >>> Therefore it has no answer (except undefined). >> >> In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not >> imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is >> Indeterminate in Mathematica.) >> >> David Cantrell -- DrBob@bigfoot.com www.eclecticdreams.net === Subject: Re: Re: Zero divided by a number... > BTW, concerning whether an improper element of an extended number > system > should be called a number or not, it might be noted that: > Floating-point > arithmetic is surely the most widely used number system in the world, > in > terms of the number of computations performed per day. There is an > internationally accepted standard for that arithmetic. The standard > clearly > distinguishes between those floating-point objects which are numbers > and > those which aren't (the NaNs). According to the standard, -Infinity and > +Infinity are numbers (while things such as 0*Infinity yield NaN). According to Mathematica: NumericQ[ComplexInfinity] False NumericQ[Infinity] False It is to say the least controversial if numbers are what complex analysts deal with. ComplexInfintiy and Infinity do not belong to any family of numbers known to number theorists (who ought to be the people who know best what numbers are), e.g. algebraic numbers, transcendental numbers, or even computable numbers. A point on the Riemann sphere is not a number. But I found this reply of yours to Bob particulalry incredible : >> ComplexInfinity isn't a number if you can't do >> arithmetic with it, > But you can do arithmetic with it. Really? And presumably algebra too? I am curious how, given that this is the only number about which Mathematica does not even know if it is equal to itself: ComplexInfinity==ComplexInfinity ComplexInfinity==ComplexInfinity But then perhaps analysts mean something different by arithmetic and algebra from the rest of us ;-) Andrzej Kozlowski Chiba, Japan http://www.akikoz.net/~andrzej/ http://www.mimuw.edu.pl/~akoz/ === Subject: Re: Re: Zero divided by a number... According to Caratheodory, The infinity as a entity was intoduced as a result of studying Mobius Transformation, because in the mapping from z to w plane there were some points in z which did not have image points (when the denominator of the trasnformation =0) the following is a quote from The Theory of Functions by Caratheodory In every complex plane, we shall adjoin to the complex numbers an improper number (or improper point, also ideal number or point), which we shall calll the point at infinity denoted by <>........It is easy to verify that the above extension of the complex plane by an improper number leaves intact the group theory of Moebius transformation under the operation of composition........The above aggreements can be rephrased in the form of rules of operation with the number infinity as follows: a+infinity=infinity a/infinity=0 Second if b is any complex number other than infinity, we agree that b*infinity=infinity b/0=infinity (b not equal to zero) and here comes the best part infinity+infinity, 0*infinity,infinity/infinity and 0/0 have no meaning whatsover Finally, A complex plane to which the point at infinity has been adjoined will be called, in the sequel, a complete or extended complex plane Also the Reimannian sphere is a sterographic projection of the complex plane with the z=0 is the south pole and z=oo being the northpole What this has to do with mathematica is a unclear to me. Then.. what do I know..I am just an engineer (: ----- Original Message ----- === Subject: Re: Zero divided by a number... > Historically complex numbers or sometimes hypercomplex numbers > referred to any extension of the reals--field or no. I. M. Yaglom > Geometry. In it he describes three systems of complex numbers and > and uses each system to prove a theorem in plane geometry (one > Euclidean and two non-Euclidean theorems). As I recall (I no longer > have the book and cannot find any reference to it on the web) he first > shows that, up to ring isomorphism, there are exactly three rings of > the of the form R[x]/ where p(x) is a quadratic polynomial. The > three distinct types are obtained by taking p(x) to be x^2+1, x^2, and > x^2-1. He then extends each system of complex numbers by adding > infinite elements--a single infinity for x^2+1 and an infinity of > infinities in (both?) of the other two cases. He then states and proves > the same plane geometry theorem in each of the three contexts using the > arithmetic of the three number systems. > Discussions as to whether these systems are really numbers--or > complex numbers--are more suited to a discussion group for lawyers than > a discussion group for mathematicians. > --Garry Helzer >> BTW, concerning whether an improper element of an extended number >> system should be called a number or not, it might be noted that: >> Floating-point arithmetic is surely the most widely used number >> system >> in the world, in terms of the number of computations performed per >> day. >> There is an internationally accepted standard for that arithmetic. >> The >> standard clearly distinguishes between those floating-point objects >> which are numbers and those which aren't (the NaNs). According to >> the standard, -Infinity and +Infinity are numbers (while things such >> as 0*Infinity yield NaN). > According to Mathematica: > NumericQ[ComplexInfinity] > False > NumericQ[Infinity] > False >> I was either unaware or had forgotten that Mathematica considers >> that >> out. And knowing that can indeed be important when programming in >> Mathematica. But as far as _mathematics itself_ is concerned, I had >> already >> said >> Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. >> And if >> you don't want to call ComplexInfinity a number, that's just fine. But >> it's essentially irrelevant whether we call it a 'number' or not. It's >> an >> element of C*, and what's important is knowing what you can (and >> can't) do >> with it. >> On second reading, perhaps it was not clear that I was talking about >> mathematics itself, rather than Mathematica, but C* was what I had in >> mind > It is to say the least controversial if numbers are what complex > analysts deal with. >> It would be absurd to suggest that numbers be _restricted_ to what's >> used >> in complex analysis. But I gather that that is not your point. > ComplexInfintiy and Infinity do not belong to any > family of numbers known to number theorists (who ought to be the > people > who know best what numbers are), e.g. algebraic numbers, > transcendental > numbers, or even computable numbers. >> Number theory is a specific branch of mathematics, as you know. There >> are >> types of objects used in mathematics which are often called numbers but >> which are not normally considered in number theory itself. Cantor's >> cardinal and ordinal numbers come to mind, for example. DrBob has >> objected >> previously in this thread that ComplexInfinity doesn't behave like a >> number; I'd say, rather, that it doesn't behave like a _finite_ number. >> Transfinite numbers do not behave like finite numbers; that's to be >> expected, of course. The mathematicians' drinking song Aleph_nought >> bottles of beer on the wall never ends (well, at least, in theory; in >> practice, we'd get too drunk to continue singing, I suppose). And 1 + >> omega >> is not the same as omega + 1. >> Earlier in this thread, you said The word 'number' is ambiguous... >> That's >> certainly true. There is no generally accepted definition of number. >> There >> are, of course, generally accepted definitions for _specific_ number >> systems. > A point on the Riemann sphere is not a number. >> Are you being pedantic? If so, I agree with you. We may say that the >> Riemann sphere is merely a way to visualize C*, just as the number >> line is >> a way to visualize R. And no point on the line or the sphere _is_ a >> number. >> But there is an obvious _correspondence_ between the points of the >> line and >> the elements of R and between the points of the sphere and the >> elements of >> C*. >> Each point on the Riemann sphere, except its North Pole, corresponds >> with >> an element of C, that is, with a complex number. The North Pole >> corresponds >> with oo, an element of C*. Whether we wish to call that element a >> number >> or not is essentially irrelevant, as I've said before. Please note >> that I >> have not said anywhere in this thread that I think it _should_ be >> called a >> number. It's adequate, as far as I'm concerned, merely to say that oo >> is an >> element of C*. > But I found this reply of yours to Bob particulalry incredible : > ComplexInfinity isn't a number if you can't do > arithmetic with it, >> >> But you can do arithmetic with it. > Really? And presumably algebra too? I am curious how, >> Really! (And I can't imagine why you thought that was particulalry >> incredible.) In C*, we have oo + 1 = oo and 1/oo = 0, for example. >> That's >> doing arithmetic involving oo. Correspondingly, in Mathematica, we have >> In[1]:= ComplexInfinity + 1 >> Out[1]= ComplexInfinity >> In[2]:= 1/ComplexInfinity >> Out[2]= 0 > given that this > is the only number about which Mathematica does not even know if it > is equal to itself: >> First, note that I never said it was a number. And as you pointed out >> above, Mathematica considers it to be nonnumeric. > ComplexInfinity==ComplexInfinity > ComplexInfinity==ComplexInfinity >> In C*, oo = oo is true, of course. The fact that Mathematica cannot at >> present decide about ComplexInfinity==ComplexInfinity is, in my >> opinion, a >> deficiency. But of course, the designers may have had a good reason, >> unknown to me, for leaving ComplexInfinity==ComplexInfinity >> unevaluated. > But then perhaps analysts mean something different by arithmetic and > algebra from the rest of us ;-) >> Not that I'm aware of. >> Perhaps it would be helpful if I discuss the construction of C*. I'll >> also >> construct a more flexible system, much like the one that Mathematica >> uses. >> Of course, to keep this post to a reasonable length, this must be a >> discussion in a nutshell, just a bare-bones outline. I hope that >> readers >> will be able to follow it if they're familiar with the constructions >> of the >> reals from the rationals via Dedekind cuts and via equivalence classes >> of >> Cauchy sequences. (BTW, the constructions outlined will not be >> aesthetically optimal IMO, but rather optimal for speed of presentation >> here.) >> Assume that the positive rationals have already been constructed. We >> may >> then construct the nonnegative extended reals, [0, +oo], from the >> positive >> rationals either by cuts or by equivalence classes of appropriate >> rational >> sequences. Bertrand Russell used the former construction with the cut >> having lower class {q | q in Q, q > 0} being the real number >> infinity, to >> use his own words. For the other method of construction, we proceed as >> usual except that we also include an equivalence class which consists >> of >> all rational sequences which increase without bound. That equivalence >> class >> is +oo. [Those reading closely may protest that the sequences in that >> equivalence aren't Cauchy. But in fact, if desired, they can easily be >> made >> Cauchy simply by using an appropriate metric.] Note that, regardless >> of the >> method of construction chosen, +oo is the same type of object as the >> nonnegative reals which were constructed along with it. In that light, >> it >> would certainly not be unreasonable to call +oo a number. >> The (signed) reals, R, may then be constructed easily from the >> nonnegative >> reals. >> An extended complex number system may then be constructed in which the >> elements are equivalence classes of ordered pairs (r, theta) with r in >> [0, +oo] and theta in R, with ordered pairs (r, theta_1) and (r, >> theta_2) >> being in the same equivalence class whenever theta_1 = theta_2 mod(2 >> Pi). >> This system should in essence be the same as Mathematica's system of >> complex numbers together with _directed infinities_. (The only web >> reference I know to such a system is A family of compactifications >> accounting for all arguments of infinity by Gingold and Gingold at >> .) >> OTOH, if we lump all of the ordered pairs having r = +oo into a single >> equivalence class (without regard to theta), we get C*, which should in >> essence be Mathematica's system of complex numbers together with >> ComplexInfinity. [Note of course that, in C*, the undirected infinity >> oo is >> defined as a specific equivalence class, and so there is no doubt that >> oo = oo is true. That's why I'm surprised that Mathematica does not >> assert >> that ComplexInfinity==ComplexInfinity is true.] >> The system which Mathematica actually uses is equivalent neither to C >> with >> just directed infinities nor to C with just the undirected infinity. >> Rather, Mathematica uses a hybrid system having both the directed >> infinities and the undirected infinity available. This is laudable IMO, >> allowing a specific directed infinity to be given whenever feasible >> (and >> thereby retaining as much information as possible), but also allowing >> the >> undirected infinity to be given in cases when no direction can be >> specified. >> In this brief outline, I haven't yet mentioned the definitions of the >> arithmetic operations, but they can be defined in fairly obvious ways. >> Let's go back to the system [0, +oo], for example, and consider, say, >> 1/(+oo). To compute that, take a representative sequence of >> nonnegative rationals in the equivalence class 1 and a representative >> sequence of nonnegative rationals in the equivalence class +oo. >> The >> desired quotient is then the equivalence class containing the sequence >> . Since a_n converges to 1 and b_n increases without bound, >> a_n/b_n must converge to 0. Thus, 1/(+oo) = 0 in the system [0, +oo]. >> But >> what if we similarly attempt to compute, say, 0/0. We must consider two >> representative sequences, and , in the equivalence class 0, >> and >> look at . Alas, that sequence may very well not reside in >> _any_ of >> the equivalence classes constituting [0, +oo], and so we must say that >> 0/0 >> is undefined in this system. In floating-point arithmetic, when this >> situation arises, the result is called NaN (Not a Number); in >> Mathematica, >> it's called Indeterminate. >> Someone had asked me, in a private email concerning this thread, if >> such >> systems aren't fields, then what are they? Well, for a system like C* >> with >> another element (like NaN or Indeterminate) adjoined to handle cases >> such >> as 0/0, the term is wheel (and that extra element is often called >> bottom). The best source (known to me) of information on wheels is >> Jesper >> Carlstrom's thesis Wheels -- On Division by Zero, available at >> . >> Sorry that I didn't have time to go into more detail. >> David W. Cantrell > Garry Helzer > gah@math.umd.edu === Subject: Re: Re: Zero divided by a number... You might as well argue that there is no distinction between projective spaces and affine spaces, manifolds and euclidean spaces, schemes and rings and so on. Obviously you will can can always call each of the concepts an extension of the other and then just decide that, you might as well call them both by the same name. It still won't make them the same. In any case, this has completely no relevance to how this discussion started and what it was originally about. I think before one joins a thread it would be a good idea to start by looking at the original posting that began it. Andrzej Kozlowski Chiba, Japan > *This message was transferred with a trial version of CommuniGate(tm) > Pro* > Historically complex numbers or sometimes hypercomplex numbers > referred to any extension of the reals--field or no. I. M. Yaglom > Geometry. In it he describes three systems of complex numbers and > and uses each system to prove a theorem in plane geometry (one > Euclidean and two non-Euclidean theorems). As I recall (I no longer > have the book and cannot find any reference to it on the web) he first > shows that, up to ring isomorphism, there are exactly three rings of > the of the form R[x]/ where p(x) is a quadratic polynomial. The > three distinct types are obtained by taking p(x) to be x^2+1, x^2, and > x^2-1. He then extends each system of complex numbers by adding > infinite elements--a single infinity for x^2+1 and an infinity of > infinities in (both?) of the other two cases. He then states and proves > the same plane geometry theorem in each of the three contexts using the > arithmetic of the three number systems. > Discussions as to whether these systems are really numbers--or > complex numbers--are more suited to a discussion group for lawyers than > a discussion group for mathematicians. > --Garry Helzer >> BTW, concerning whether an improper element of an extended number >> system should be called a number or not, it might be noted that: >> Floating-point arithmetic is surely the most widely used number >> system >> in the world, in terms of the number of computations performed per >> day. >> There is an internationally accepted standard for that arithmetic. >> The >> standard clearly distinguishes between those floating-point objects >> which are numbers and those which aren't (the NaNs). According to >> the standard, -Infinity and +Infinity are numbers (while things such >> as 0*Infinity yield NaN). > According to Mathematica: > NumericQ[ComplexInfinity] > False > NumericQ[Infinity] > False >> I was either unaware or had forgotten that Mathematica considers >> that >> out. And knowing that can indeed be important when programming in >> Mathematica. But as far as _mathematics itself_ is concerned, I had >> already >> said >> Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. >> And if >> you don't want to call ComplexInfinity a number, that's just fine. But >> it's essentially irrelevant whether we call it a 'number' or not. It's >> an >> element of C*, and what's important is knowing what you can (and >> can't) do >> with it. >> On second reading, perhaps it was not clear that I was talking about >> mathematics itself, rather than Mathematica, but C* was what I had in >> mind > It is to say the least controversial if numbers are what complex > analysts deal with. >> It would be absurd to suggest that numbers be _restricted_ to what's >> used >> in complex analysis. But I gather that that is not your point. > ComplexInfintiy and Infinity do not belong to any > family of numbers known to number theorists (who ought to be the > people > who know best what numbers are), e.g. algebraic numbers, > transcendental > numbers, or even computable numbers. >> Number theory is a specific branch of mathematics, as you know. There >> are >> types of objects used in mathematics which are often called numbers >> but >> which are not normally considered in number theory itself. Cantor's >> cardinal and ordinal numbers come to mind, for example. DrBob has >> objected >> previously in this thread that ComplexInfinity doesn't behave like a >> number; I'd say, rather, that it doesn't behave like a _finite_ >> number. >> Transfinite numbers do not behave like finite numbers; that's to be >> expected, of course. The mathematicians' drinking song Aleph_nought >> bottles of beer on the wall never ends (well, at least, in theory; in >> practice, we'd get too drunk to continue singing, I suppose). And 1 + >> omega >> is not the same as omega + 1. >> Earlier in this thread, you said The word 'number' is ambiguous... >> That's >> certainly true. There is no generally accepted definition of number. >> There >> are, of course, generally accepted definitions for _specific_ number >> systems. > A point on the Riemann sphere is not a number. >> Are you being pedantic? If so, I agree with you. We may say that the >> Riemann sphere is merely a way to visualize C*, just as the number >> line is >> a way to visualize R. And no point on the line or the sphere _is_ a >> number. >> But there is an obvious _correspondence_ between the points of the >> line and >> the elements of R and between the points of the sphere and the >> elements of >> C*. >> Each point on the Riemann sphere, except its North Pole, corresponds >> with >> an element of C, that is, with a complex number. The North Pole >> corresponds >> with oo, an element of C*. Whether we wish to call that element a >> number >> or not is essentially irrelevant, as I've said before. Please note >> that I >> have not said anywhere in this thread that I think it _should_ be >> called a >> number. It's adequate, as far as I'm concerned, merely to say that oo >> is an >> element of C*. > But I found this reply of yours to Bob particulalry incredible : > ComplexInfinity isn't a number if you can't do > arithmetic with it, >> >> But you can do arithmetic with it. > Really? And presumably algebra too? I am curious how, >> Really! (And I can't imagine why you thought that was particulalry >> incredible.) In C*, we have oo + 1 = oo and 1/oo = 0, for example. >> That's >> doing arithmetic involving oo. Correspondingly, in Mathematica, we >> have >> In[1]:= ComplexInfinity + 1 >> Out[1]= ComplexInfinity >> In[2]:= 1/ComplexInfinity >> Out[2]= 0 > given that this > is the only number about which Mathematica does not even know if it > is equal to itself: >> First, note that I never said it was a number. And as you pointed out >> above, Mathematica considers it to be nonnumeric. > ComplexInfinity==ComplexInfinity > ComplexInfinity==ComplexInfinity >> In C*, oo = oo is true, of course. The fact that Mathematica cannot at >> present decide about ComplexInfinity==ComplexInfinity is, in my >> opinion, a >> deficiency. But of course, the designers may have had a good reason, >> unknown to me, for leaving ComplexInfinity==ComplexInfinity >> unevaluated. > But then perhaps analysts mean something different by arithmetic > and > algebra from the rest of us ;-) >> Not that I'm aware of. >> Perhaps it would be helpful if I discuss the construction of C*. I'll >> also >> construct a more flexible system, much like the one that Mathematica >> uses. >> Of course, to keep this post to a reasonable length, this must be a >> discussion in a nutshell, just a bare-bones outline. I hope that >> readers >> will be able to follow it if they're familiar with the constructions >> of the >> reals from the rationals via Dedekind cuts and via equivalence classes >> of >> Cauchy sequences. (BTW, the constructions outlined will not be >> aesthetically optimal IMO, but rather optimal for speed of >> presentation >> here.) >> Assume that the positive rationals have already been constructed. We >> may >> then construct the nonnegative extended reals, [0, +oo], from the >> positive >> rationals either by cuts or by equivalence classes of appropriate >> rational >> sequences. Bertrand Russell used the former construction with the cut >> having lower class {q | q in Q, q > 0} being the real number >> infinity, to >> use his own words. For the other method of construction, we proceed as >> usual except that we also include an equivalence class which consists >> of >> all rational sequences which increase without bound. That equivalence >> class >> is +oo. [Those reading closely may protest that the sequences in that >> equivalence aren't Cauchy. But in fact, if desired, they can easily be >> made >> Cauchy simply by using an appropriate metric.] Note that, regardless >> of the >> method of construction chosen, +oo is the same type of object as the >> nonnegative reals which were constructed along with it. In that light, >> it >> would certainly not be unreasonable to call +oo a number. >> The (signed) reals, R, may then be constructed easily from the >> nonnegative >> reals. >> An extended complex number system may then be constructed in which the >> elements are equivalence classes of ordered pairs (r, theta) with r in >> [0, +oo] and theta in R, with ordered pairs (r, theta_1) and (r, >> theta_2) >> being in the same equivalence class whenever theta_1 = theta_2 mod(2 >> Pi). >> This system should in essence be the same as Mathematica's system of >> complex numbers together with _directed infinities_. (The only web >> reference I know to such a system is A family of compactifications >> accounting for all arguments of infinity by Gingold and Gingold at >> > gammasphere.pdf>.) >> OTOH, if we lump all of the ordered pairs having r = +oo into a single >> equivalence class (without regard to theta), we get C*, which should >> in >> essence be Mathematica's system of complex numbers together with >> ComplexInfinity. [Note of course that, in C*, the undirected infinity >> oo is >> defined as a specific equivalence class, and so there is no doubt that >> oo = oo is true. That's why I'm surprised that Mathematica does not >> assert >> that ComplexInfinity==ComplexInfinity is true.] >> The system which Mathematica actually uses is equivalent neither to C >> with >> just directed infinities nor to C with just the undirected infinity. >> Rather, Mathematica uses a hybrid system having both the directed >> infinities and the undirected infinity available. This is laudable >> IMO, >> allowing a specific directed infinity to be given whenever feasible >> (and >> thereby retaining as much information as possible), but also allowing >> the >> undirected infinity to be given in cases when no direction can be >> specified. >> In this brief outline, I haven't yet mentioned the definitions of the >> arithmetic operations, but they can be defined in fairly obvious ways. >> Let's go back to the system [0, +oo], for example, and consider, say, >> 1/(+oo). To compute that, take a representative sequence of >> nonnegative rationals in the equivalence class 1 and a representative >> sequence of nonnegative rationals in the equivalence class +oo. >> The >> desired quotient is then the equivalence class containing the sequence >> . Since a_n converges to 1 and b_n increases without bound, >> a_n/b_n must converge to 0. Thus, 1/(+oo) = 0 in the system [0, +oo]. >> But >> what if we similarly attempt to compute, say, 0/0. We must consider >> two >> representative sequences, and , in the equivalence class 0, >> and >> look at . Alas, that sequence may very well not reside in >> _any_ of >> the equivalence classes constituting [0, +oo], and so we must say that >> 0/0 >> is undefined in this system. In floating-point arithmetic, when this >> situation arises, the result is called NaN (Not a Number); in >> Mathematica, >> it's called Indeterminate. >> Someone had asked me, in a private email concerning this thread, if >> such >> systems aren't fields, then what are they? Well, for a system like C* >> with >> another element (like NaN or Indeterminate) adjoined to handle cases >> such >> as 0/0, the term is wheel (and that extra element is often called >> bottom). The best source (known to me) of information on wheels is >> Jesper >> Carlstrom's thesis Wheels -- On Division by Zero, available at >> . >> Sorry that I didn't have time to go into more detail. >> David W. Cantrell > Garry Helzer > gah@math.umd.edu === Subject: Re: Re: Zero divided by a number... Historically complex numbers or sometimes hypercomplex numbers referred to any extension of the reals--field or no. I. M. Yaglom Geometry. In it he describes three systems of complex numbers and and uses each system to prove a theorem in plane geometry (one Euclidean and two non-Euclidean theorems). As I recall (I no longer have the book and cannot find any reference to it on the web) he first shows that, up to ring isomorphism, there are exactly three rings of the of the form R[x]/ where p(x) is a quadratic polynomial. The three distinct types are obtained by taking p(x) to be x^2+1, x^2, and x^2-1. He then extends each system of complex numbers by adding infinite elements--a single infinity for x^2+1 and an infinity of infinities in (both?) of the other two cases. He then states and proves the same plane geometry theorem in each of the three contexts using the arithmetic of the three number systems. Discussions as to whether these systems are really numbers--or complex numbers--are more suited to a discussion group for lawyers than a discussion group for mathematicians. --Garry Helzer > BTW, concerning whether an improper element of an extended number > system should be called a number or not, it might be noted that: > Floating-point arithmetic is surely the most widely used number > system > in the world, in terms of the number of computations performed per > day. > There is an internationally accepted standard for that arithmetic. > The > standard clearly distinguishes between those floating-point objects > which are numbers and those which aren't (the NaNs). According to > the standard, -Infinity and +Infinity are numbers (while things such > as 0*Infinity yield NaN). >> According to Mathematica: >> NumericQ[ComplexInfinity] >> False >> NumericQ[Infinity] >> False > I was either unaware or had forgotten that Mathematica considers > that > out. And knowing that can indeed be important when programming in > Mathematica. But as far as _mathematics itself_ is concerned, I had > already > said > Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. > And if > you don't want to call ComplexInfinity a number, that's just fine. But > it's essentially irrelevant whether we call it a 'number' or not. It's > an > element of C*, and what's important is knowing what you can (and > can't) do > with it. > On second reading, perhaps it was not clear that I was talking about > mathematics itself, rather than Mathematica, but C* was what I had in > mind >> It is to say the least controversial if numbers are what complex >> analysts deal with. > It would be absurd to suggest that numbers be _restricted_ to what's > used > in complex analysis. But I gather that that is not your point. >> ComplexInfintiy and Infinity do not belong to any >> family of numbers known to number theorists (who ought to be the >> people >> who know best what numbers are), e.g. algebraic numbers, >> transcendental >> numbers, or even computable numbers. > Number theory is a specific branch of mathematics, as you know. There > are > types of objects used in mathematics which are often called numbers but > which are not normally considered in number theory itself. Cantor's > cardinal and ordinal numbers come to mind, for example. DrBob has > objected > previously in this thread that ComplexInfinity doesn't behave like a > number; I'd say, rather, that it doesn't behave like a _finite_ number. > Transfinite numbers do not behave like finite numbers; that's to be > expected, of course. The mathematicians' drinking song Aleph_nought > bottles of beer on the wall never ends (well, at least, in theory; in > practice, we'd get too drunk to continue singing, I suppose). And 1 + > omega > is not the same as omega + 1. > Earlier in this thread, you said The word 'number' is ambiguous... > That's > certainly true. There is no generally accepted definition of number. > There > are, of course, generally accepted definitions for _specific_ number > systems. >> A point on the Riemann sphere is not a number. > Are you being pedantic? If so, I agree with you. We may say that the > Riemann sphere is merely a way to visualize C*, just as the number > line is > a way to visualize R. And no point on the line or the sphere _is_ a > number. > But there is an obvious _correspondence_ between the points of the > line and > the elements of R and between the points of the sphere and the > elements of > C*. > Each point on the Riemann sphere, except its North Pole, corresponds > with > an element of C, that is, with a complex number. The North Pole > corresponds > with oo, an element of C*. Whether we wish to call that element a > number > or not is essentially irrelevant, as I've said before. Please note > that I > have not said anywhere in this thread that I think it _should_ be > called a > number. It's adequate, as far as I'm concerned, merely to say that oo > is an > element of C*. >> But I found this reply of yours to Bob particulalry incredible : >> ComplexInfinity isn't a number if you can't do >> arithmetic with it, > But you can do arithmetic with it. >> Really? And presumably algebra too? I am curious how, > Really! (And I can't imagine why you thought that was particulalry > incredible.) In C*, we have oo + 1 = oo and 1/oo = 0, for example. > That's > doing arithmetic involving oo. Correspondingly, in Mathematica, we have > In[1]:= ComplexInfinity + 1 > Out[1]= ComplexInfinity > In[2]:= 1/ComplexInfinity > Out[2]= 0 >> given that this >> is the only number about which Mathematica does not even know if it >> is equal to itself: > First, note that I never said it was a number. And as you pointed out > above, Mathematica considers it to be nonnumeric. >> ComplexInfinity==ComplexInfinity >> ComplexInfinity==ComplexInfinity > In C*, oo = oo is true, of course. The fact that Mathematica cannot at > present decide about ComplexInfinity==ComplexInfinity is, in my > opinion, a > deficiency. But of course, the designers may have had a good reason, > unknown to me, for leaving ComplexInfinity==ComplexInfinity > unevaluated. >> But then perhaps analysts mean something different by arithmetic and >> algebra from the rest of us ;-) > Not that I'm aware of. > Perhaps it would be helpful if I discuss the construction of C*. I'll > also > construct a more flexible system, much like the one that Mathematica > uses. > Of course, to keep this post to a reasonable length, this must be a > discussion in a nutshell, just a bare-bones outline. I hope that > readers > will be able to follow it if they're familiar with the constructions > of the > reals from the rationals via Dedekind cuts and via equivalence classes > of > Cauchy sequences. (BTW, the constructions outlined will not be > aesthetically optimal IMO, but rather optimal for speed of presentation > here.) > Assume that the positive rationals have already been constructed. We > may > then construct the nonnegative extended reals, [0, +oo], from the > positive > rationals either by cuts or by equivalence classes of appropriate > rational > sequences. Bertrand Russell used the former construction with the cut > having lower class {q | q in Q, q > 0} being the real number > infinity, to > use his own words. For the other method of construction, we proceed as > usual except that we also include an equivalence class which consists > of > all rational sequences which increase without bound. That equivalence > class > is +oo. [Those reading closely may protest that the sequences in that > equivalence aren't Cauchy. But in fact, if desired, they can easily be > made > Cauchy simply by using an appropriate metric.] Note that, regardless > of the > method of construction chosen, +oo is the same type of object as the > nonnegative reals which were constructed along with it. In that light, > it > would certainly not be unreasonable to call +oo a number. > The (signed) reals, R, may then be constructed easily from the > nonnegative > reals. > An extended complex number system may then be constructed in which the > elements are equivalence classes of ordered pairs (r, theta) with r in > [0, +oo] and theta in R, with ordered pairs (r, theta_1) and (r, > theta_2) > being in the same equivalence class whenever theta_1 = theta_2 mod(2 > Pi). > This system should in essence be the same as Mathematica's system of > complex numbers together with _directed infinities_. (The only web > reference I know to such a system is A family of compactifications > accounting for all arguments of infinity by Gingold and Gingold at > .) > OTOH, if we lump all of the ordered pairs having r = +oo into a single > equivalence class (without regard to theta), we get C*, which should in > essence be Mathematica's system of complex numbers together with > ComplexInfinity. [Note of course that, in C*, the undirected infinity > oo is > defined as a specific equivalence class, and so there is no doubt that > oo = oo is true. That's why I'm surprised that Mathematica does not > assert > that ComplexInfinity==ComplexInfinity is true.] > The system which Mathematica actually uses is equivalent neither to C > with > just directed infinities nor to C with just the undirected infinity. > Rather, Mathematica uses a hybrid system having both the directed > infinities and the undirected infinity available. This is laudable IMO, > allowing a specific directed infinity to be given whenever feasible > (and > thereby retaining as much information as possible), but also allowing > the > undirected infinity to be given in cases when no direction can be > specified. > In this brief outline, I haven't yet mentioned the definitions of the > arithmetic operations, but they can be defined in fairly obvious ways. > Let's go back to the system [0, +oo], for example, and consider, say, > 1/(+oo). To compute that, take a representative sequence of > nonnegative rationals in the equivalence class 1 and a representative > sequence of nonnegative rationals in the equivalence class +oo. > The > desired quotient is then the equivalence class containing the sequence > . Since a_n converges to 1 and b_n increases without bound, > a_n/b_n must converge to 0. Thus, 1/(+oo) = 0 in the system [0, +oo]. > But > what if we similarly attempt to compute, say, 0/0. We must consider two > representative sequences, and , in the equivalence class 0, > and > look at . Alas, that sequence may very well not reside in > _any_ of > the equivalence classes constituting [0, +oo], and so we must say that > 0/0 > is undefined in this system. In floating-point arithmetic, when this > situation arises, the result is called NaN (Not a Number); in > Mathematica, > it's called Indeterminate. > Someone had asked me, in a private email concerning this thread, if > such > systems aren't fields, then what are they? Well, for a system like C* > with > another element (like NaN or Indeterminate) adjoined to handle cases > such > as 0/0, the term is wheel (and that extra element is often called > bottom). The best source (known to me) of information on wheels is > Jesper > Carlstrom's thesis Wheels -- On Division by Zero, available at > . > Sorry that I didn't have time to go into more detail. > David W. Cantrell Garry Helzer gah@math.umd.edu === Subject: Re: Zero divided by a number... > BTW, concerning whether an improper element of an extended number > system should be called a number or not, it might be noted that: > Floating-point arithmetic is surely the most widely used number system > in the world, in terms of the number of computations performed per day. > There is an internationally accepted standard for that arithmetic. The > standard clearly distinguishes between those floating-point objects > which are numbers and those which aren't (the NaNs). According to > the standard, -Infinity and +Infinity are numbers (while things such > as 0*Infinity yield NaN). > According to Mathematica: > NumericQ[ComplexInfinity] > False > NumericQ[Infinity] > False I was either unaware or had forgotten that Mathematica considers out. And knowing that can indeed be important when programming in Mathematica. But as far as _mathematics itself_ is concerned, I had already said Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. And if you don't want to call ComplexInfinity a number, that's just fine. But it's essentially irrelevant whether we call it a 'number' or not. It's an element of C*, and what's important is knowing what you can (and can't) do with it. On second reading, perhaps it was not clear that I was talking about mathematics itself, rather than Mathematica, but C* was what I had in mind > It is to say the least controversial if numbers are what complex > analysts deal with. It would be absurd to suggest that numbers be _restricted_ to what's used in complex analysis. But I gather that that is not your point. > ComplexInfintiy and Infinity do not belong to any > family of numbers known to number theorists (who ought to be the people > who know best what numbers are), e.g. algebraic numbers, transcendental > numbers, or even computable numbers. Number theory is a specific branch of mathematics, as you know. There are types of objects used in mathematics which are often called numbers but which are not normally considered in number theory itself. Cantor's cardinal and ordinal numbers come to mind, for example. DrBob has objected previously in this thread that ComplexInfinity doesn't behave like a number; I'd say, rather, that it doesn't behave like a _finite_ number. Transfinite numbers do not behave like finite numbers; that's to be expected, of course. The mathematicians' drinking song Aleph_nought bottles of beer on the wall never ends (well, at least, in theory; in practice, we'd get too drunk to continue singing, I suppose). And 1 + omega is not the same as omega + 1. Earlier in this thread, you said The word 'number' is ambiguous... That's certainly true. There is no generally accepted definition of number. There are, of course, generally accepted definitions for _specific_ number systems. > A point on the Riemann sphere is not a number. Are you being pedantic? If so, I agree with you. We may say that the Riemann sphere is merely a way to visualize C*, just as the number line is a way to visualize R. And no point on the line or the sphere _is_ a number. But there is an obvious _correspondence_ between the points of the line and the elements of R and between the points of the sphere and the elements of C*. Each point on the Riemann sphere, except its North Pole, corresponds with an element of C, that is, with a complex number. The North Pole corresponds with oo, an element of C*. Whether we wish to call that element a number or not is essentially irrelevant, as I've said before. Please note that I have not said anywhere in this thread that I think it _should_ be called a number. It's adequate, as far as I'm concerned, merely to say that oo is an element of C*. > But I found this reply of yours to Bob particulalry incredible : >> ComplexInfinity isn't a number if you can't do >> arithmetic with it, > But you can do arithmetic with it. > Really? And presumably algebra too? I am curious how, Really! (And I can't imagine why you thought that was particulalry incredible.) In C*, we have oo + 1 = oo and 1/oo = 0, for example. That's doing arithmetic involving oo. Correspondingly, in Mathematica, we have In[1]:= ComplexInfinity + 1 Out[1]= ComplexInfinity In[2]:= 1/ComplexInfinity Out[2]= 0 > given that this > is the only number about which Mathematica does not even know if it > is equal to itself: First, note that I never said it was a number. And as you pointed out above, Mathematica considers it to be nonnumeric. > ComplexInfinity==ComplexInfinity > ComplexInfinity==ComplexInfinity In C*, oo = oo is true, of course. The fact that Mathematica cannot at present decide about ComplexInfinity==ComplexInfinity is, in my opinion, a deficiency. But of course, the designers may have had a good reason, unknown to me, for leaving ComplexInfinity==ComplexInfinity unevaluated. > But then perhaps analysts mean something different by arithmetic and > algebra from the rest of us ;-) Not that I'm aware of. Perhaps it would be helpful if I discuss the construction of C*. I'll also construct a more flexible system, much like the one that Mathematica uses. Of course, to keep this post to a reasonable length, this must be a discussion in a nutshell, just a bare-bones outline. I hope that readers will be able to follow it if they're familiar with the constructions of the reals from the rationals via Dedekind cuts and via equivalence classes of Cauchy sequences. (BTW, the constructions outlined will not be aesthetically optimal IMO, but rather optimal for speed of presentation here.) Assume that the positive rationals have already been constructed. We may then construct the nonnegative extended reals, [0, +oo], from the positive rationals either by cuts or by equivalence classes of appropriate rational sequences. Bertrand Russell used the former construction with the cut having lower class {q | q in Q, q > 0} being the real number infinity, to use his own words. For the other method of construction, we proceed as usual except that we also include an equivalence class which consists of all rational sequences which increase without bound. That equivalence class is +oo. [Those reading closely may protest that the sequences in that equivalence aren't Cauchy. But in fact, if desired, they can easily be made Cauchy simply by using an appropriate metric.] Note that, regardless of the method of construction chosen, +oo is the same type of object as the nonnegative reals which were constructed along with it. In that light, it would certainly not be unreasonable to call +oo a number. The (signed) reals, R, may then be constructed easily from the nonnegative reals. An extended complex number system may then be constructed in which the elements are equivalence classes of ordered pairs (r, theta) with r in [0, +oo] and theta in R, with ordered pairs (r, theta_1) and (r, theta_2) being in the same equivalence class whenever theta_1 = theta_2 mod(2 Pi). This system should in essence be the same as Mathematica's system of complex numbers together with _directed infinities_. (The only web reference I know to such a system is A family of compactifications accounting for all arguments of infinity by Gingold and Gingold at .) OTOH, if we lump all of the ordered pairs having r = +oo into a single equivalence class (without regard to theta), we get C*, which should in essence be Mathematica's system of complex numbers together with ComplexInfinity. [Note of course that, in C*, the undirected infinity oo is defined as a specific equivalence class, and so there is no doubt that oo = oo is true. That's why I'm surprised that Mathematica does not assert that ComplexInfinity==ComplexInfinity is true.] The system which Mathematica actually uses is equivalent neither to C with just directed infinities nor to C with just the undirected infinity. Rather, Mathematica uses a hybrid system having both the directed infinities and the undirected infinity available. This is laudable IMO, allowing a specific directed infinity to be given whenever feasible (and thereby retaining as much information as possible), but also allowing the undirected infinity to be given in cases when no direction can be specified. In this brief outline, I haven't yet mentioned the definitions of the arithmetic operations, but they can be defined in fairly obvious ways. Let's go back to the system [0, +oo], for example, and consider, say, 1/(+oo). To compute that, take a representative sequence of nonnegative rationals in the equivalence class 1 and a representative sequence of nonnegative rationals in the equivalence class +oo. The desired quotient is then the equivalence class containing the sequence . Since a_n converges to 1 and b_n increases without bound, a_n/b_n must converge to 0. Thus, 1/(+oo) = 0 in the system [0, +oo]. But what if we similarly attempt to compute, say, 0/0. We must consider two representative sequences, and , in the equivalence class 0, and look at . Alas, that sequence may very well not reside in _any_ of the equivalence classes constituting [0, +oo], and so we must say that 0/0 is undefined in this system. In floating-point arithmetic, when this situation arises, the result is called NaN (Not a Number); in Mathematica, it's called Indeterminate. Someone had asked me, in a private email concerning this thread, if such systems aren't fields, then what are they? Well, for a system like C* with another element (like NaN or Indeterminate) adjoined to handle cases such as 0/0, the term is wheel (and that extra element is often called bottom). The best source (known to me) of information on wheels is Jesper Carlstrom's thesis Wheels -- On Division by Zero, available at . Sorry that I didn't have time to go into more detail. David W. Cantrell === Subject: Re: Zero divided by a number... >> If x = 0, then x/0 is Indeterminate, rather than ComplexInfinity. > You got me on that one, but it's a non-difference unless you can show me > a use for ComplexInfinity that doesn't apply just as well to > Indeterminate. A simple example: 1/Indeterminate is again Indeterminate, while 1/ComplexInfinity yields 0. This is as it should be: Reciprocation is an involution on C* (the one-point extension of C), that is, we have 1/(1/z) = z for _all_ z in C*. In case the usefulness of that isn't immediately obvious, and since you mentioned the Gamma function later, let me mention two related applications. Using C* as the codomain of Gamma, so that Gamma[z] is ComplexInfinity whenever z is a nonpositive integer, the important identities Gamma[z] = Gamma[z + 1]/z and Gamma[z] Gamma[1 - z] = Pi/Sin[Pi z] now hold _throughout_ the complex plane. (Of course, that would not be the case if just C were used for the codomain of Gamma.) > Besides, if x/0 is Indeterminate It's Indeterminate if x=0; it isn't Indeterminate in general. > but 1/0 is ComplexInfinity, what if x = > 1? That doesn't seem very consistent, I don't see any inconsistency. > and in fact it leads to problems > like a recent poster's issue with a Sum of Binomials. There were bugs revealed in that thread, yes. But it is not clear that they had anything to do with how ComplexInfinity is treated in Mathematica. > But Mathematica's result of ComplexInfinity _is_ correct mathematically > (in the extended complex number system, of course). > Not of course. Of course of course! I was just being explicit about the context. But the parenthetical comment should not have been needed. After all, do you know any _other_ number system having ComplexInfinity as an element? > ComplexInfinity isn't a number if you can't do > arithmetic with it, But you can do arithmetic with it. > and the documentation doesn't explain what we should > expect from the concept. You can't expect Mathematica's documentation to teach such things. We're not actually talking about something peculiar to Mathematica; we're talking about something which should have been covered in a beginning course in complex analysis. > Not a good argument. By precisely that same reasoning, 0 shouldn't be > a full-fledged member of the algebraic system either > 0 is the only thing in a Field that has no multiplicative inverse (it's > part of the DEFINITION of a field -- not an exception to the rules). Right, it's not an exception to the rules. But that's merely because the exception for zero is written _into_ the rules. > If ComplexInfinity also has no inverse, your extended complex number > system isn't a field, Nobody ever said it's a field. > Defining Gamma so that 1/Gamma[z] is entire would be useful, but > Mathematica doesn't accomplish that. Why not? > I'm not sure why Plot doesn't hiccup > on this, for instance: > Plot[Evaluate@D[1/Gamma[x], x], {x, -3, -1}] > since evaluating the first argument at either endpoint gets us an error > message. I wouldn't have expected Plot to hiccup, and I'm quite glad it doesn't. Similarly Plot[Sin[x]/x, {x, 0, 5}] causes no hiccup, despite the fact that Sin[x]/x is Indeterminate at x=0. > D[1/Gamma[x],x] /. x -> -3. > (error message) > Indeterminate Unfortunately, that derivative is not expressible in a nice way in Mathematica. For an analogous case, consider the derivative of SinIntegral[x]. That derivative is just the sine cardinal function sinc(x) = 1 if x = 0, sin(x)/x otherwise. But Mathematica doesn't implement sinc(x) at present, and so it says In[3]:= D[SinIntegral[x], x] Out[3]= Sin[x]/x Taken literally (as computers are wont to do), that's not right at x=0. The derivative should have the value 1 there, rather than being Indeterminate. (Of course, Mathematica _could_ have given a correct answer for the derivative if sinc(x) had been implementing or, in lieu of that, by expressing the answer piecewise. But the latter is perhaps considered to be too messy for practicality.) For the derivative of 1/Gamma[x], things are messier in that there is no standard function -- at least, none known to me -- like sinc, which could be implemented so as to make the derivative expressible neatly. Experienced users should be aware that, in such situations, we need to look at the limit: In[4]:= Limit[D[SinIntegral[x], x], x -> 0] Out[4]= 1 In[5]:= Limit[D[1/Gamma[x], x] , x -> -3] Out[5]= -6 Of course, I agree that it's unfortunate that we need to look at the limit, rather than just at the value at the point. But there may not be any alternative which meets the demand of practicality for a CAS. > That happens because Gamma is ComplexInfinity at the -3 and > 0*ComplexInfinity == Indeterminate (use Trace). So again, using Gamma[-3] > = ComplexInfinity doesn't help us Right. Here, it doesn't help us. But it's not the source of the trouble either. >> In fact, defining Gamma[-5] in that way _does_ remove the >> discontinuity. [As z -> -5, regardless of the path in the complex >> plane, |Gamma[z]| increases without bound.] > True enough, if increases without bound is all it takes, That's all it takes. > and the > definition makes Gamma act like a continuous function in some useful > sense. But it doesn't. IMO, it does. (What's useful is a matter of opinion.) > 1/Gamma[z] should be entire in the extended plane, > but in Mathematica, it isn't. Again, why not? > The only usage I've found that works the way we might expect seems to be > x / ComplexInfinity (with undefined x), which evaluates to 0 -- but > that's not actually right, Just as you say, that's not actually right. > since: > ComplexInfinity/ComplexInfinity > (error message) > Indeterminate > Hence x / ComplexInfinity (with undefined x) should be left unevaluated > or replaced with Indeterminate. compactification of C), it would be better to have x/ComplexInfinity simplify to If[x==ComplexInfinity, Indeterminate, 0]. But whether Mathematica or any CAS _should_ do something like that is questionable due to matters of practicality. As a similar example, you might consider simplifying x/x. Mathematica just gives 1, without any caveats. But in C*, it would be better to have x/x simplify to If[x==0 || x==ComplexInfinity, Indeterminate, 1]. But again, whether Mathematica or any CAS _should_ do something like that is questionable due to matters of practicality. > So... ComplexInfinity may be a member of the extended complex plane, > but it dosn't walk or quack like a NUMBER. Well, I suppose I could just toss off that comment by saying that I've never seen or heard any number walk or quack, but that would clearly be ducking the issue. Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. And if you don't want to call ComplexInfinity a number, that's just fine. But it's essentially irrelevant whether we call it a number or not. It's an element of C*, and what's important is knowing what you can (and can't) do with it. BTW, concerning whether an improper element of an extended number system should be called a number or not, it might be noted that: Floating-point arithmetic is surely the most widely used number system in the world, in terms of the number of computations performed per day. There is an internationally accepted standard for that arithmetic. The standard clearly distinguishes between those floating-point objects which are numbers and those which aren't (the NaNs). According to the standard, -Infinity and +Infinity are numbers (while things such as 0*Infinity yield NaN). > Whenever I see ComplexInfinity, I'll read it as Indeterminate and lose > absolutely nothing. But it's still there in the background, mucking > things up. I disagree. The designers of floating-point arithmetic (W. Kahan, in particular, comes to mind) didn't implement arithmetic with infinities for absolutely nothing. The same can be said for symbolic implementations of infinity arithmetic in CAS. David W. Cantrell === Subject: Re: Zero divided by a number... > all these statements are true as statements about *complex numbers*. > Thus instead of saying x/0 is undefined ... he should have said is > undefined as a complex number or is not a complex number etc. The > word number is ambiguous, and there are some strange people, even > some mathematicians, who call things like Infinity numbers but I have > never heard of anyone refer to them as complex numbers'. Perhaps you would be amused to know that Bertrand Russell, in constructing what we might nowadays call the positive extended reals from the positive rationals, refers to the real number infinity. But that is merely of historical interest. The real and complex number systems, as we know them today, contain no infinite elements, of course. > (Complex of course includes real). > (Besides, I don't believe that there is anyone, including yourself, who > really did not understand what Richard meant.) I thought and I still think that I understood exactly what Richard meant. Not only is this a _Mathematica_ newsgroup, but Richard himself _supplied context_. He said Mathematica handles 0 appropriately. x/0 is undefined for any number x. So it seems clear to me that he thought, incorrectly, that _in Mathematica_ x/0 is always undefined. Indeed, I would not be at all surprised if Richard -- after realizing that 1/0 is ComplexInfinity, rather than undefined, in Mathematica -- now thinks that Mathematica does _not_ handle division by 0 appropriately. David Cantrell >> Mathematica handles 0 appropriately. x/0 is undefined for any number >> x. > In Mathematica, it is _not_ true that x/0 is undefined for any number > x. Rather, for any nonzero x, x/0 is defined as ComplexInfinity. >> This is extremely simple to see if only you view division as the >> opposite of multipication. > That view of division is simply inadequate in number systems (such as > the extended complex numbers) in which division of nonzero quantities > by zero is defined. >> A/B = C implies that C * B = A. >> >> 12/4 = 3 because 3*4 = 12. >> 0/7 = 0 because 0*7 = 0. >> 7/0 is undefined because x*0 does not equal 7 for any number x. >> Therefore it has no answer (except undefined). > In Mathematica, 7/0 yields ComplexInfinity, but that certainly does not > imply that 0 * ComplexInfinity = 7. (In fact, 0 * ComplexInfinity is > Indeterminate in Mathematica.) === Subject: LogListPlot I used MultipleListPlot to plot many list , but how i can change the shape of my points with LogListPlot? === Subject: Re: Re: newbie question on functions AppendTo and PrependTo do change their original lists alpha = {a,b,c}; AppendTo[alpha, d]; alpha {a, b, c, d} PrependTo[alpha, a]; alpha {a, a, b, c, d} Bob Hanlon === > Subject: Re: newbie question on functions > Yes, of course you can save the result of a calculation. For example: > > result=intensity[4.,5.] > For the original newbie poster: > For newbies, or less expert users like me, it's easy to think that > something like > AppendTo[list, expr] > is a command that will do what it says: append expr to list. Takes a > few bad experiences to realize that you actually have to say > list = AppendTo[list,expr] > Same general principle applies more broadly. Bob Hanlon Chantilly, VA === Subject: Re: Null entry in a Graphics list? g1 = Graphics[Line[{{0,0},{0,.5}}]]; g2 = Graphics[Line[{{0,0},{1,0}}]]; g3=If[False,Graphics[Line[{{0,0},{1,.5}}]],Graphics[{}]]; Show[g1,g2,g3]; Bob Hanlon === > Subject: Null entry in a Graphics list? > Is there a Null or a None for Graphics? > If I want to accomplish something like > g1 = Graphics[---]; > g2 = Graphics[---] > g3 = If[test, Graphics[---], NoGraphics ]; > > Show[g1, g2, g3 ]; > is there something I can put in for NoGraphics (other than an > offscreen Point or a zero-size Point or . . . ) that will be acceptable > in subsequent graphics commands === Subject: Re: questions Re your question 2: The Statistics packages have many built-in distributions. Needs[Statistics`DiscreteDistributions`]; Needs[Graphics`Graphics`]; n=100; p=1/10; dist= BinomialDistribution[n, p]; Mean[dist] 10 data1=Table[Random[dist], {200}]; Mean[data1]//N 10.26 Histogram[data1]; data2=RandomArray[dist, {200}]; Mean[data2]//N 10.015 Histogram[data2]; Bob Hanlon === > Subject: questions > Hi Everyone, > Well I have 2 questions: > 1) I have a notebook which involves manipulating 3d plots. However > everytime I run the notebook, after a while I get some kernel errors, > and the mathematica kernel just quits. It crashs after a while and > does not finsih evaluating all the cells. Is there a problem with my > computer? or is it because of the limitation to process (huge amount > of) graphics by Mathematica? > 2) Random[Real, {-4,4}] gives a uniform distribution. However if I > would like to have a binomial distribution or any other kind of > distribution, would this be possible as well? If so then how is it > done? > Namrata Khemka === Subject: fractal image compression I have a presentation on image compression to give and I 'd like to present (among others), the now forgotten fractal image compression method. Does anyone know a link or a mathematica notebook with this kind of stuff? Any information on fractal image compression in mathematica context would be highly appreciated. === Subject: Re: fractal image compression New stuff in 5.0 about image compression: http://usm.maine.edu/~mjankowski/docs/ele489/labs/index.htm ELE489: Digital Image Processing Mathematica Notebooks Instructor: Professor Mariusz Jankowski E-mail: mjkcc@usm.maine.edu Each Mathematica notebook deals with a selected course topic. The notebooks accompany the course and are used during regularly scheduled class sessions in JMC 109 (Mathematica classroom ). If you have Mathematica (or MathReader , a free product available from Wolfram Research ) installed on your computer, click on the Mathematica symbol to download a file. * DownLoad Notebook 1: Digital image representation * DownLoad Notebook 2: Elements of matrix theory * DownLoad Notebook 3: Image histogram * DownLoad Notebook 4: Luminance quantization * DownLoad Notebook 5: Point operations * DownLoad Notebook 6: Geometric operations * DownLoad Notebook 7: Linear filtering and convolution * Notebook 8 is not available at the present time * DownLoad Notebook 9: Image morphology * DownLoad Notebook 10: Edge detection * DownLoad Notebook 11: Image transforms: DFT * DownLoad Notebook 12: Image transforms: DCT * Notebooks 13 and 14 are not available at the present time * DownLoad Notebook 15: Differential coding (unfinished) * DownLoad Bibliography ------------------------------------------------------------------------ Resources: * All notebooks have been collected in a single WinZip archive. Click here to download. You will need a WinZip compatible extractor on your system to open the archive. * Visit our download page for useful Mathematica code. * Mathematica Courseware Catalog Last revised: 07/11/2001 Return to ELE489 home page >I have a presentation on image compression to give and >I 'd like to present (among others), the now forgotten fractal image >compression method. Does anyone know a link or a mathematica >notebook with this kind of stuff? Any information on fractal >image compression in mathematica context would be highly >appreciated. -- Respectfully, Roger L. Bagula tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: 619-5610814 : alternative email: rlbtftn@netscape.net URL : http://home.earthlink.net/~tftn === Subject: Re: fractal image compression Only Mathematica stuff I found is in these two links: http://library.wolfram.com/infocenter/Articles/1583/ http://library.wolfram.com/infocenter/Demos/397/ >I have a presentation on image compression to give and >I 'd like to present (among others), the now forgotten fractal image >compression method. Does anyone know a link or a mathematica >notebook with this kind of stuff? Any information on fractal >image compression in mathematica context would be highly >appreciated. -- Respectfully, Roger L. Bagula tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: 619-5610814 : alternative email: rlbtftn@netscape.net URL : http://home.earthlink.net/~tftn === Subject: Re: fractal image compression The best page on the web that I know about is: Yuval Fisher: http://inls.ucsd.edu/~fisher/Fractals/ I've never seen Mathematica code in this area and believe me I've looked at just about everything in Google. >I have a presentation on image compression to give and >I 'd like to present (among others), the now forgotten fractal image >compression method. Does anyone know a link or a mathematica >notebook with this kind of stuff? Any information on fractal >image compression in mathematica context would be highly >appreciated. -- Respectfully, Roger L. Bagula tftn@earthlink.net, 11759Waterhill Road, Lakeside,Ca 92040-2905,tel: 619-5610814 : alternative email: rlbtftn@netscape.net URL : http://home.earthlink.net/~tftn === Subject: Re: Re: Hide Mathematica kernel window Err, isn't there a button on the top right hand side of your window which when pressed minimizes the window??? If you are talking about the Messages window that keeps popping up, then have a look at Edit->Preferences->GlobalOptions->MessageOptions{WarningAction} and associated settings. Yas > Open windows cramp my desktop. Is there a way to hide mathematica > Anyone? -- === Subject: Re: Null entry in a Graphics list? g1 = Plot[Sin[x], {x, 0, 8}]; g2 = Plot[Cos[x], {x, 0, 8}]; g3 := If[test, Plot[x^2/64, {x, 0, 8}], Graphics[{}]]; but this also seems to work... g3 := If[test, Plot[x^2/64, {x, 0, 8}], {}]; test = True; Show[g1, g2, g3]; test = False; Show[g1, g2, g3]; David Park djmp@earthlink.net http://home.earthlink.net/~djmp/ Is there a Null or a None for Graphics? If I want to accomplish something like g1 = Graphics[---]; g2 = Graphics[---] g3 = If[test, Graphics[---], NoGraphics ]; Show[g1, g2, g3 ]; is there something I can put in for NoGraphics (other than an offscreen Point or a zero-size Point or . . . ) that will be acceptable in subsequent graphics commands === Subject: Re: Re: Hide Mathematica kernel window When I work on Windows98 the KERNEL window is always automatically minimized. So I don't understand the reason for your question. A front end notebook window can be minimized just by clicking the minimize button in the title bar. It doesn't go to the task bar but goes to a button right next to the task bar. Maybe you could give more information? David Park djmp@earthlink.net http://home.earthlink.net/~djmp/ > Open windows cramp my desktop. Is there a way to hide mathematica Anyone? === Subject: How to force Mathematica to treat a number as positive and real? I'd like to do some symbolic computation with parameters. These parameters (named, e.g. a) are always *real-valued* and positive. I managed to tell Mathematica that a is a real number by using: a/:Im[a]=0; This works since the response to Re[a] is now a (and not Re[a] which is the general result when one does not use the above definition of a). Now, I would like to do a similar thing, forcing Mathematica to assume that a is a positive number. I want that the result of Abs[a] is equal to a. I tried: a/:Positive[a]=True; but it does not work. Does anybody know how I can do this? Rainer === Subject: Re: How to force Mathematica to treat a number as positive and real? This works: Simplify[Abs[a],a>0] and this does too: Assuming[a>0,Simplify[Abs[a]]] Have a look at the Help Browser for more information on Assuming. Steve Luttrell > I'd like to do some symbolic computation with parameters. These > parameters (named, e.g. a) are always *real-valued* and positive. I > managed to tell Mathematica that a is a real number by using: > a/:Im[a]=0; > This works since the response to Re[a] is now a (and not Re[a] > which is the general result when one does not use the above definition > of a). > Now, I would like to do a similar thing, forcing Mathematica to assume > that a is a positive number. I want that the result of Abs[a] is equal > to a. I tried: > a/:Positive[a]=True; > but it does not work. Does anybody know how I can do this? > Rainer === Subject: Re: How to force Mathematica to treat a number as positive and real? > I'd like to do some symbolic computation with parameters. These > parameters (named, e.g. a) are always *real-valued* and positive. I > managed to tell Mathematica that a is a real number by using: > a/:Im[a]=0; > This works since the response to Re[a] is now a (and not Re[a] > which is the general result when one does not use the above definition > of a). > Now, I would like to do a similar thing, forcing Mathematica to assume > that a is a positive number. I want that the result of Abs[a] is equal > to a. I tried: > a/:Positive[a]=True; > but it does not work. Does anybody know how I can do this? > Rainer You can use the Assumptions option in Simplify and FullSimplify to specify that a number belongs to a particular field - Reals in your case - and also to supply additional information, e.g. Simplify[{Abs[a], Re[a]}, Assumptions -> {a .89รร Reals, a >= 0}] {a,a} You might find it convenient to define your own simplification function with the necessary assumptions built in: MySimplify[x_] := Simplify[x, Assumptions -> {a .89รร Reals, a .89ลด 0}] {Abs[a], Re[a], Min[a, 0]} // MySimplify {a, a, 0} David Bailey === Subject: Re: How to force Mathematica to treat a number as positive and real? Sorry, I notice that a special character in my reply has got scrambled in the email. The character in question is the one you obtain by typing [Element] So, for example I meant to write: Simplify[{Abs[a], Re[a]}, Assumptions -> {a [Element] Reals, a >= 0}] David Bailey === Subject: Re: closing notebook cells CellInformation[] - that sounds wonderful. But I have searched in help, the Wolfram site and Google, and also entered ??CellInformation, and I do not find any information anywhere! Please inform, how do I use it? Ingolf Dahl Sweden >-----Original Message----- === >Subject: closing notebook cells >> As I learned in mathgroup a few years ago I am using the following code >> to close automatically my graphics groups. >> CloseAnim[]:=(SelectionMove[EvaluationNotebook[],All,GeneratedCell]; >> FrontEndTokenExecute[OpenCloseGroup];); >> CloseAnim::usage = CloseAnim[]; >> For example: >> Table[Show[Graphics[ >> {Hue[Random[] ],Rectangle[{0,0},{1,1}] >> }]],{3}]; >> CloseAnim[]; >> The problem is that when I only generate a single cell OpenCloseGroup >> will generate a beep. >> Any idea on how to prevent that beep or test if GeneratedCell selected a >> single or several cells? >> Luc >LinkWrite[$ParentLink, CellInformation[EvaluationNotebook[]]]; >Length[LinkRead[$ParentLink]] >If the length is greater than 1, then you can use the OpenCloseGroup token. >CellInformation[] is new to version 5 and is, in general, a very good way >to test various properties of the selection without having to do a >NotebookRead[] (which could get very expensive if you have a selection >which consumes a lot of memory). >John Fultz >jfultz@wolfram.com >User Interface Group >Wolfram Research, Inc.