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

[Michaël Baudin]

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