Version: 1.2.0 (using KDE KDE 3.5.0) Installed from: Gentoo Packages Compiler: gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include/g++-v3 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu OS: Linux when try to calculate integral of function f(x)=x from -8 to 8 value 0.163 is reported, but exact value iz 0. when increase integration interval error increases. even simple numerical integration for such a simple function should give proper value...
Have you tried to decrease the step width in the Configure->Configure Kmplot dialog? I get the result 0 if I set the stepping to 0.5.
you mean "point per pixel"? it is not obvious from the name that it is integration step... anyway, you are right, when this value set up to 0.5 result is correct. if you increase limits to -80 and 80 result incorrect again! for this limits I've got correct result using step of 0.4, but this step gives incorrect result in case of -8 to 8 limits! additionally, decreasing of the step do not approach me to the correct result (essentially non-linear behavior) how integral is computed? from the image? if so, it is totally wrong way!!!
Now fixed. The bug was caused by the intervals used to calculate the integral numerically not perfectly tiling the range [-8,8]. (e.g. in your example, the step size was approximately (8-(-8))/(800 pixels) = 0.02, and the numerical integration missed out a chunk at the end of the plot of value 8, giving an inaccuracy of 0.02 * 8 = 0.16).
Most probably David's fix caused bug 136479.