Re: Uniform design

*To*: mathgroup at smc.vnet.net*Subject*: [mg48416] Re: Uniform design*From*: ab_def at prontomail.com (Maxim)*Date*: Fri, 28 May 2004 00:51:05 -0400 (EDT)*References*: <c8pu2d$kq9$1@smc.vnet.net> <200405251118.HAA03729@smc.vnet.net> <c945gq$r7e$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

"Garbage in, garbage out" (GIGO) is a well-known half-jocular term, but any freshman who wrote his program based on GIGO principle wouldn't get high marks for his work (and even lower marks if he started calling people who "misuse" his program names). Of course, I don't mean to say that Mathematica developers don't know such trivial things, I'm just saying that advocating GIGO approach isn't very wise. Taking the one example you had time to analyze (GIGO doesn't seem to apply to any of the other examples in my post), suppose we have something like SeriesData[n,0,{Cos[n]},0,2,1]. If having Cos[n] in the coefficient list is not legitimate, then -- and that's only one of the possible approaches -- generate a warning message, and that would already be better than GIGO. In fact, Mathematica detects that the list of coefficients depends on n and automatically rewrites the above expression as 1+O[n]^2. This seems to indicate that Mathematica is 'aware' of such possibility, but sometimes doesn't handle it adequately. Maxim Rytin m.r at inbox.ru Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message news:<c945gq$r7e$1 at smc.vnet.net>... > As I do not have the time to discuss or even to consider these examples > in detail I will just comment on one, which I selected at random. > > > z + O[n] /. z -> 1/n + 1 > > I have no idea why you think what you are doing is legitimate. It seems > to me that quite obviously it is not. > Let's first of all just look at the documentation: > > In[6]:= > ?SeriesData > > SeriesData[x, x0, {a0, a1, ... }, nmin, nmax, den] represents \ > a power series in the variable x about the point x0. The ai are the \ > coefficients in the power series. The powers of (x-x0) that appear are \ > nmin/den, (nmin+1)/den, ... , nmax/den. > > Now look at: > > > FullForm[z+O[n]] > > > SeriesData[n,0,List[z],0,1,1] > > To my mind this tell's you clearly that z is now considered as a > independent of n (coefficient of n^0) and obviously a substitution z-> > 1+ 1/n will break things. > > Consider a somewhat different case: > > In[10]:= > f=z[n] + O[n] > > Out[10]= > SeriesData[n, 0, {z[0]}, 0, 1, 1] > > Obviously this assumes that z has no singularities at 0. If you now > define: > > > z[n_]:=1/n > > In[13]:= > f > > Power::"infy" Infinite expression > encountered. > > SeriesData[n, 0, {ComplexInfinity}, 0, 1, 1] > > Is this a bug? Not to my mind. While it is probably not clearly stated > anywhere this sort of thing is not legitimate I think anyone who makes > even a slight effort to investigate how O[n] works and looks at the > SeriesData output would realize that doing any of the above is simply > asking for trouble (nonsense in -> nonsense out). > > Since it seems that some people did not understand the intention of my > comments on Leibniz and Newton I feel I have to put it more bluntly. > I do not think Mathematica was ever meant to be "fool proof". A fool > can easily break it. It is of course even easier to do it for someone > who is not a fool but only pretending to be one. Mathematica offers you > a great deal more freedom than other programs of this kind and any kind > of freedom has costs, particularly for those who choose to turn off > their brains (not to mention those who do not have any). > > Andrzej Kozlowski > > > > > On 25 May 2004, at 20:18, Maxim wrote: > > > Continuing on the topic of uniform design, let's see how well various > > functions handle SeriesData. For instance, series expansions can be > > integrated just like other expressions: > > > > In[1]:= > > Integrate[Log[a] + x + O[a], {x, 0, 1}] > > > > Out[1]= > > a + O[a]^2 > > > > The result is incorrect, probably because Integrate overlooks the > > possibility that SeriesData can contain logarithmic terms. Next, we > > can substitute values into series: > > > > In[2]:= > > z + O[n] /. z -> 1/n + 1 > > z + O[n]^2 /. z -> 1/n + 1 > > > > Out[2]= > > 1 + O[n] > > > > Out[3]= > > 1/n + 1 + O[n]^3 > > > > Only in the first case we lose the 1/n term, in the second case lose > > O[n]^2 term. Let's look at Limit: > > > > In[4]:= > > Limit[O[n]/n^2, n -> 0] > > > > Out[4]= > > ComplexInfinity > > > > Strictly speaking, this is incorrect too, because n^2 is also O[n]. > > Another issue is that Mathematica outputs O[n]/n^2 as 1/O[n], which I > > suppose can be acceptable as a conventional notation, but it's > > questionable in the strict mathematical sense: O(n)/n^2 is O(1/n) and > > not 1/O(n). Limit of 1/O(n) (not Mathematica's 1/O[n]!) would indeed > > be equal to ComplexInfinity. Another example: > > > > In[5]:= > > Limit[z/n + O[n], n -> 0] > > > > Out[5]= > > ComplexInfinity > > > > At least this one is good? Not exactly, because standard Mathematica > > behaviour in such cases is to return z*Infinity. > > > > In[6]:= > > HarmonicNumber[n, 2] + O[n, Infinity] > > -HarmonicNumber[n, 2] + O[n, Infinity] > > > > Out[6]= > > Pi^2/6 + O[1/n]^1 > > > > Out[7]= > > -HarmonicNumber[n, 2] + O[1/n]^1 > > > > The last example demonstrates a different issue: transformation rules > > catch only some of all the possible cases; here changing the sign > > prevents the application of the rule, sometimes f[n]+O[n] and > > Series[f[n],{n,0,0}] work slightly differently. > > > > Lastly, there are some other problems with notation: O[x]^0 is allowed > > in the output, but not as the input; O[1/x] will be output exactly as > > O[x,Infinity] but means something different. > > > > Maxim Rytin > > m.r at inbox.ru > > (don't use the prontomail address anymore please) > > > >

**References**:**Re: Uniform design***From:*ab_def@prontomail.com (Maxim)

**Re: Re: Re: Re: optimally picking one element from each list**

**Re: Re: Re: Re: optimally picking one element from each list**

**Re: Re: Uniform design**

**big imaginary error in region integration**