Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43384] Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Date: Wed, 27 Aug 2003 04:05:10 -0400 (EDT)
- References: <200308231208.IAA25148@smc.vnet.net> <bi9vfr$cjn$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Dr Bob wrote: > I have to agree with Andrzej here. > > There's no point in endlessly criticising Mathematica unless you have a > better option to present. > > I do wonder what WRI is doing about Maxim's bug list, though. > > Bobby > > Just the same as with any other bug report, I suppose -- sorting the examples to assign them to whoever is in charge of that particular part of Mathematica, then evaluating the examples to decide whether they really constitute bugs, then deciding what should be done about those that are bugs or serious enough inconsistencies etc. It is more interesting to consider some more general issues. For example, 1) some features seem not to be defined clearly enough. What does Limit[f[z],z->z0*Infinity,Direction->1] mean? Is Arg[z] always equal to Arg[z0] (so we move along the straight line from the origin) or the argument of z only tends to this value? Is the real line somehow special? There are many examples like In[1]:= Limit[ArcTan[x, -1], x -> -Infinity] Out[1]= Pi (which is incorrect in any case), and maybe it's not a coincidence that it's just not clear what the expected behaviour of DirectedInfinity should be; 2) some of the older modules probably need updating; thus, in version 4.2 FourierTransform[-Erf[t],t,p] was equal to FourierTransform[1-Erf[t],t,p]; in 5.0 this is fixed but now FourierTransform[1-Erf[t],t,p] is not equal to FourierTransform[Erfc[t],t,p]. Integral transform modules may require a major overhaul; at the same time, some things are just not considered to be important enough to spend significant amounts of time on: thus, no Mathematica symbolic functions can handle branch cuts of elliptic integrals, so Limit and Integrate results will be wrong by definition; 3) there could be some issues with quality assurance; if In[1]:= Limit[Csc[Pi*k],k->k0,Assumptions->Element[k0,Integers]] Out[1]= ComplexInfinity is ok, but not In[2]:= Limit[Csc[Pi*k]*(k-k0),k->k0,Assumptions->Element[k0,Integers]] Out[2]= 0 then it may indicate that testing was performed only for the simplest cases; 4) there are some problematic issues that are inherent in mathematical programming, such as zero testing: what should be done if we have to integrate 1/((z-z1)*(z-z2)) as a function of z and we can't determine if z1 and z2 are equal? Or if we are integrating 1/(z-z0) from z1 to z2 and we can't tell if z0 lies on the segment [z1,z2]? In both examples I'm assuming that z0,z1,z2 are numbers. Ideally, every such possibility should be checked and the function should return unevaluated, because it's impossible to know what the correct answer should be then. At least, such situations should generate warning messages; in practice this isn't always so: In[1]:= Limit[x - Sqrt[Pi], x -> 1915168610923525348065051215542582193157\ 7/10805181810206786582137323831443648757793] Out[1]= 0 Of course, there are also more general issues, both from developer's point of view -- such as memory management, which is always an ordeal, especially in Lisp-like languages, and for a programmer/user -- such as handling a not too formalized output from mathematical functions: suppose you want to determine whether Reduce returned a set of real finite intervals. Maybe Reduce simply returned unevaluated? Or some additional parameters/constants were introduced? Or the result is a set of intervals plus some isolated points? Even if the result is a set of intervals, it can be represented in a quite untrivial way by a combination of inequalities. Maxim Rytin m.r at prontomail.com
- References:
- Re: Re: New version, new bugs
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Re: New version, new bugs