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!). 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?
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!
What people really need is an arithmetic with more precision and that already exists in several versions including freeware (see gmp)
Frank Braun
Date sent: Thu, 3 Jul 2003 18:21:16 +0200 (CEST) From: Mirsad Todorovac mtodorov@alu.hr To: jerabek@math.cas.cz Copies to: gpc@gnu.de Subject: Re: Real with attributes (...)
On Thu, 3 Jul 2003, Emil Jerabek wrote:
On Thu, Jul 03, 2003 at 02:16:18PM +0200, Mirsad Todorovac wrote:
On Thu, 3 Jul 2003, Emil Jerabek wrote:
On Wed, Jul 02, 2003 at 10:14:22PM +0200, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
Anyway, I propose we put thing of this sort on a WISH-LIST, w priorities, so we'd don't forget about it and propose it again.
Many items on the to-do list are "wishes", and the mentioned `SELECTED_REAL_KIND' is already there. (Though it may refer to a feature to choose between the available standard real types according to some parameters -- as I said, I don't know it exactly.)
I don't know much about Fortran either, but I'm afraid that "KIND" has the meaning you put in parenthesis, not a handcrafted user-defined type. See `info g77', for example.
Err, well, it's not a "handcrafted user-defined" type, it's actually meant to be IEEE-form floating point number, it's just that exponent and mantissa size is customizable.
I doubt that there is such a thing as IEEE float with customizable sizes, AFAIK IEEE 754 specifies both the general layout _and_ exponent and mantissa sizes for its types. Anyway, this is just playing with words, it doesn't matter whether it's called "customizable" or "user-defined".
What I had in mind is the number with exact IEEE layout and semantics, except for the difference in the number of exponent/mantissa (significand) bits. In this sense, "customizable" may be when you add extra 32 bits for mantissa precission, not changing anything else; while user-defined might be something that doesn't resemlbe IEEE 754 layout even distantly, if one can imagine such a thing.
What I was trying to say is that the "SELECTED_REAL_KIND" entry on the TODO list is something different from these customizable real types, thus a new entry would be appropriate for your proposal. (In Fortran "REAL(KIND=N)", the number N has nothing to do with the size of the type, it is just an (almost) arbitrary index chosen by the implementation to select from the set of available _built-in_ types.)
I looked at that, and it appears that this (KIND=..) has the same meaning as "long" or "long long" in C ...
To be realistic, Frank has made it very clear so far that excess precision doesn't make much sense if i.e. Sin(x) is calculated in (only) double precision, and depends on the quality of implementation in system's C library -- otherwise we're depending on GNU GMP lib or something like that. Or, we'd have to instantiate compiled math library for every given (Exponent, mantissa) combination and requested range/precision.
So, having all this limitations in mind customized Reals could serve for the same purpose as customized Integers - yet we'd better estimate cost/benefit in this case. If it's month of compiler writter's work, then it's expensive; and Frank is right when he says as much as possible should be done on user level.
The only problem lies in (lack of) automatic promotions/conversions/interoperability with other types.
Mirsad
-- "I have a dream!" -- Martin Luther King Jr.
Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany
Tel.: +49-941-943-4891
email: frank.braun@rz.uni-regensburg.de