On Fri, 4 Jul 2003, Frank Thomas Braun wrote:
IEEE defines only two real formats with 32 and 64 bits. These are implemented in the backend. There is absolutely no need to implement further IEEE- analogue formats with different bitnumbers.
It would be dangerous to give programmers the possibility to change the number of bits in the exponent and mantissa (even if everything is correctly implemented!).
With all due respect, please let me quote an article on floating-point:
"Computer owner derive scant benefit from advantageous harware features they have paid for since these are practically inaccessible through commercially dominant compilers and computer languages."
"The improved capabilities are features of IEEE Standard 754 for Binary Floating-Point Arithmetic mistakenly deemed arcane, as if intended for only a few specialists"
(John von Neumann Lecture on Baleful Effect of Computer Languages and Benchmarks upon Applied Mathematics, Physics and Chemistry, presented by Prof. W. Kahan, 45th Annual Meeting of SIAM, July 1997, URL: http://cch.loria.fr/documentation/IEEE754/wkahan/SIAMjvnl.ps
Would you immediately see, that real numbers with 8 bits in the exponent and more than 256 bits in the mantissa would loose precision for example when calculating a cos?
Of course, if we do not recompile math library in given precision, or have such an implementation that could suffer variable precisions.
The mathematical challenges of an IEEE-like number with i.e. 15-bit-exponents and 93-bit-mantissae are immense especially when considering the problems of nonnormalized numbers AND the result is absolutly not worth the labours put into! The problem of correctly calculating elementary functions (sin..) has to be solved too!
Of course.
What people really need is an arithmetic with more precision and that already exists in several versions including freeware (see gmp)
Certainly. Yet please note how for example a version of M$ CC started to map long double calculations into simple 64-bit double, throwing 16 bits of precision customers have paid for not into recycle bin, but into /dev/null ...
IMVHO we should not limit programmer by language this much, we should offer both variants (extended precision and saving of memory for special purposes)
New epsilon for given p precision bits and ß = 2 is easily detemined (http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf), while about sin(), cos(9 etc. it isn't quite certain how things go on about it even with standard C libm math, we're depending on provider ...
I'm certain that GPC team is able to do the task correctly, to the last theoretically achievable bit of precision, it's only the matter whether it is worthwhile the effort. If Frank's idea of typecast operators is achivable, it might be a more general solution, and this way probably a better one ...
Mirsad Todorovac
Frank Braun