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