quasi wrote:
> On Sat, 26 Jan 2008 15:34:54 +0100, Axel Vogt <&noreply@[EMAIL PROTECTED]
>
> wrote:
>
>> quasi wrote:
>>> On Sat, 26 Jan 2008 06:39:09 -0500, quasi <quasi@[EMAIL PROTECTED]
> wrote:
>>>
>>>> On Sat, 26 Jan 2008 03:07:45 -0800 (PST), Vladimir Bondarenko
>>>> <vb@[EMAIL PROTECTED]
> wrote:
>>>>
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> An exact 1-D integration challenge - 48 -
>>>>> (go and give a kick to all stupid CASs!)
>>>>>
>>>>>
http://groups.google.com/group/sci.math.symbolic/browse_thread/thread/28416525f0de8f90/1d8cd83e96cb7f63?#1d8cd83e96cb7f63
>>>>>
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> N[Integrate[
>>>>>
>>>>> Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z] + 2 z]],
>>>>>
>>>>> {z, 0, 1}]]
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> VERSION OUTPUT RESOLUTION
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> Mathematica 6.0 2.67602 <-------------------------------- BUG
>>>>>
>>>>> Mathematica 5.2 3.66533 <-------------------------------- BUG
>>>> Let f(z) = sqrt(sqrt(2) + sqrt(z) + sqrt(2 + 2*sqrt(2)*sqrt(z) +
2*z))
>>>>
>>>> Then it's completely obvious that f has domain [0,infinity) and that
>>>> is strictly increasing.
>>>>
>>>> Hence the integral of f on the interval [0,1] must be strictly
between
>>>> f(0) and f(1).
>>>>
>>>> Approximately, we have
>>>>
>>>> f(0) = 1.681792831
>>>>
>>>> and
>>>>
>>>> f(1) = 2.242172940
>>>>
>>>> which makes it clear that Mathematica's outputs are ridiculous.
>>>>
>>>> Maple 9.5 gives a result of 2.062759840, which at least seems
>>>> reasonable. Whether it's correct or not, I'm not sure.
>>>>
>>>> quasi
>>> A CAS should never return a wrong answer. Returning no answer is
>>> better than a wrong one.
>>>
>>> For this example in particular, Mathematica really has no excuse for
>>> getting it wrong. It's not like the function has wild variations which
>>> might throw off a numerical integration. This is a positive,
>>> increasing function, easily evaluated. For a CAS, the numerical
>>> integration of such a function should be effortless.
>>>
>>> quasi
>> Finding a possible (numerical) error is only half the job
>> of a tester.
>
> I disagree -- a tester needs to find a reproducible bug -- period. An
> instance is sufficient, the simpler, the better.
>
> The fixers (on the Mathematica side) are the ones who need to
> investigate further.
>
>> I would expect him to locate it closer by deforming the situation,
>> easiest would be the bounds.
>
> I would expect that Mathematica should sense a possible problem and
> deform the function and/or the bounds automatically, if needed.
>
>> Then one could say something whether MMA is disturbed
>> by the vertical tangent in 0.
>
> If a vertical (or near vertical) tangent is an im****tant consideration
> for the internal algorithm, then the CAS implementation should
> incor****ate a way to automatically detect and deal with that
> contingency.
>
>> Changing z ---> t^2 should do it.
>
> If the user gets an actual answer, why should the user have to check
> to see if it's correct? Worse, if the integral is used as part of a
> user-written program, the user doesn't even get to look at the answer
> -- it just gets fed to the next piece of the program. Shouldn't a
> supposed world-class CAS at least offer an option to automatically
> verify/certify numerical calculations to within a specified accuracy?
>
> quasi
We talk about commercial software development. And there seems to
be no complex and growing SW system, which is free of bugs.
Especially testing is not "found your error, so repair it", this
is only acceptable for a user doing tests, not a professional (by
this I do not want to insult Bondarenko, he does not get money or
s.th. close equivalent ... I guess).
For this there are several reasons, here are 2: the one who codes
does it because he can do that best, the other does something else.
You have a project with several hundred man years and have to share
tasks. It is not a question of sin and atonement - both sides are
supposed to do more then the obvious.
Usually that even is done in cascading, only "3rd level" begins to
care for errors.
Besides organizing work these are fairly complex systems and 'the'
error may not be due to some new lines of code, deeper testing is
a help on that and someone who refuses to contribute to that just
has the false job as a tester in quality assurance.
If you are aware that the whole system contains bugs the coder and
the tester are in a similar situation like you. Which conversely
tells you: there is no reason to trust your program, because it
depends on stuff of others.
For the other thing "automatically verify" ... well, the above will
apply as well, it will not give you a break off that vicious circle.
|
