[scilab-Users] intg: results differ substantially from those from Wolfram Alpha, which are correct?

[Michaël Baudin]

Sorry: read "200 decimal digits", and *not* "200 hundred decimal digits".

Michaël

Le 24/05/2011 12:02, Michaël Baudin a écrit :
> Hi,
>
> Please notice that Mathematica and Scilab have very few in common: 
> Scilab is a numerical system, while Wolfram is an algebraic (symbolic) 
> system. Mathematica first computes the exact integral formula, then 
> evaluates it with a given number of digits (by default something like 
> 200 hundred decimal digits, if I remember well). This is completely 
> different in Scilab, which always uses limited precision binary 
> floating point numbers. On one hand, this has drawbacks, on the other 
> hand, this is much faster, given that these floating point 
> computations are supported by the processor (and not by software, as 
> in Mathematica).
>
> We may find another integration algorithm, but this type of problem 
> will always appear, whatever the algorithm we choose. Imagine a 1 
> dimensional function which is nonzero only for 2 of the 2^64 possible 
> doubles. Suppose that we integrate this function with the largest 
> possible bounds, that is with ~ -1.e308 and ~1.e308 as minimum and 
> maximum bounds. To integrate this function, the algorithm would have 
> to parse through all 2^64 doubles to find the only 2 nonzero values: 
> this requires a large amount of time. If Scilab did that, we would 
> complain about it speed...
>
> Best regards,
>
> Michaël Baudin
>
> Le 24/05/2011 09:34, Ginters Bušs a écrit :
>> Thanks. I like your insistance in that discussion, Sam.
>>
>> Although a "known-limitation-of-current-algorithm" might be a correct 
>> description of the current algorithm, it nevertheless does not help 
>> much when one wants the algorithm to give the correct solution and 
>> observes that a guy like Wolfram has apparently has done something 
>> about this issue: for y given function, Scilab's intg/integrate gives 
>> ok value for bounds (-50,50), but screws up for (-100,100) and larger 
>> bounds, which I consider still pretty narrow. On the contrary, 
>> Wolfram Alpha
>>
>> http://www.wolframalpha.com/input/?i=integration&a=*C.integration-_*Calculator.dflt-&f2=%281%2Fsqrt%282*pi%29%29*log%28abs%281%2B.1*x%29%29*exp%28-%28x 
>> <http://www.wolframalpha.com/input/?i=integration&a=*C.integration-_*Calculator.dflt-&f2=%281%2Fsqrt%282*pi%29%29*log%28abs%281%2B.1*x%29%29*exp%28-%28x>^2%29%2F2%29&x=0&y=0&f=Integral.integrand_%281%2Fsqrt%282*pi%29%29*log%28abs%281%2B.1*x%29%29*exp%28-%28x^2%29%2F2%29&f3=-infinity&f=Integral.rangestart_-infinity&f4=%2Binfinity&f=Integral.rangeend_%2Binfinity&a=*FVarOpt.1-_**-.***Integral.variable---.**Integral.rangestart-.*Integral.rangeend--- 
>>
>>
>> gives ok values for bounds (-50,50), (-100,100), (-1000,1000) and it 
>> allows to directly use infinite bounds and get ok result (interim 
>> bounds like (-1e9,1e9) are not ok). I consider this a superior 
>> solution. If Wolfram can, why shouldn't Scilab try? The status quo 
>> might hurt Scilab's reputation in the domain in long run.
>>
>> Gin.
>
>


-- 
Michaël Baudin
Ingénieur de développement
michael.baudin at scilab.org
-------------------------
Consortium Scilab - Digiteo
Domaine de Voluceau - Rocquencourt
B.P. 105 - 78153 Le Chesnay Cedex
Tel. : 01 39 63 56 87 - Fax : 01 39 63 55 94