240
edits
Interval package: Difference between revisions
Jump to navigation
Jump to search
→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 == | ||