Interval package: Difference between revisions

Jump to navigation Jump to search
1,763 bytes added ,  6 January 2015
→‎What to expect: added notes on speed and accuracy
m (→‎What to expect: added section and a few lines of text)
(→‎What to expect: added notes on speed and accuracy)
Line 46: Line 46:


''Why is the interval package slow?''
''Why is the interval package slow?''
All arithmetic interval operations are simulated in high-level octave language using floating-point routines, which is a lot slower than hardware implementations [https://books.google.de/books?id=JTc4XdXFnQIC&pg=PA61]. For example, for some tightly rounded results of vector and matrix operations the interval package has to simulate a [http://books.google.de/books?hl=de&id=I7X9EVfeV5EC&q=accumulator Kulisch accumulator], which introduces a computational overhead of factor 10. However, the Kulisch accumulator could be implemented in hardware and then outperform floating-point operations.
All arithmetic interval operations are simulated in high-level octave language using C99 floating-point routines, which is a lot slower than hardware implementations [https://books.google.de/books?id=JTc4XdXFnQIC&pg=PA61]. Building interval arithmetic operations from floating-point routines is easy for simple monotonic functions, e. g., addition and subtraction, but is complex for others, e. g., [http://exp.ln0.de/heimlich-power-2011.htm interval power function], atan2, or [[#Reverse_arithmetic_operations|reverse functions]]. For some interval operations it is not even possible to rely on floating-point routines, since not all required routines are available in C99 or BLAS.
 
For example, for some tightly rounded results of vector and matrix operations the interval package has to simulate a [http://books.google.de/books?hl=de&id=I7X9EVfeV5EC&q=accumulator Kulisch accumulator], which introduces a computational overhead of factor 10. However, the Kulisch accumulator could be implemented in hardware and then outperform floating-point routines.
 
Great algorithms and optimizations exist for matrix arithmetic in GNU octave. Good interval versions of these still have to be found and implemented.
 
''Why is the interval package not accurate?''
Some basic operations are provided with best possible accuracy, i. e., tightest results. Some arithmetic functions are not. Again, this is because interval operations are based on C99 floating-point routines. The latter are not guaranteed to be accurate and their results can depend on hardware, system libraries and compilation options. [http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions]
 
The most complete and conservative information on worst-case error boundaries of floating-point routines has been found in a [http://www.lehman.cuny.edu/cgi-bin/man-cgi?libm+3 man page for a C99 implementation on SunOS] and is assumed to hold for all systems where the interval package is used. Worst-case error estimations are added to the results of several interval arithmetic operations, which decreases their accuracy but tries to make the results contain the correct answer.
 
Possibly, the accuracy is going to be improved in a future release with the [http://sourceforge.net/p/octave/multi-precision/ multi-precision package] or a similar approach.


== Quick start introduction ==
== Quick start introduction ==
240

edits

Navigation menu