On 6/27/22 9:41 AM, Arjen Markus wrote:
On Saturday, June 25, 2022 at 10:13:18 AM UTC+2, gah4 wrote:
On Friday, June 24, 2022 at 11:05:10 PM UTC-7, Ron Shepard wrote:
(snip, I wrote)
REAL*1
I once worked on a lossy data compression method for iterative
procedures that required only 3 or 4 bits of precision each iteration. I >>> implemented it in fixed-point arithmetic, packed into integer words, but >>> floating point would have also worked alright. In this 8-bit
representation, that would have been 1 sign bit, 4 exponent bits, and 3
mantissa bits (4 counting the hidden bit). The final result was a 64-bit >>> floating point vector, but it was accumulated over several iterations, 3 >>> or 4 bits at a time.
It seems though that it allows, or can allow, for different exponent
bits by 1s. SELECTED_REAL_KIND only allows counting
in units of 3.32 bits, so too coarse for this system.
And then there is unsigned.
But that does not mean a special real kind is unreachable: it would appear in the list of supported real kinds and with KIND= you can also get variables of that special kind ...
Yes, if the programmer knows the kind, he could just define the
appropriate parameter constant in a single place, and let that
definition propagate throughout the rest of the code in the usual way.
Also, there have been suggestions in the past to allow an optional
argument to selected_real_kind to specify the precision in bits rather
than decimal digits. That could be added at any time, in a backward
compatible way, once it is practically useful.
I realize in these discussions how many programmers do not appreciate
how well designed and how flexible the fortran kind system really is.
Compare to C for example, where each of these floating point kinds that
differ by one mantissa bit from each other is specified with some
obscure incantation of "short short long short long short...".
There are two modifications that might have been useful back when f90
first introduced this into the language. One is to have separate kind
values for different types, and the other would have been to have the
kind values be a type distinct from other integers. Either or both of
those things might have helped programmers eliminate coding errors. But overall, it works very well in practice even as is, with almost
unlimited ability to expand and adapt in the future if/when these kinds
of floating point types become available.
$.02 -Ron Shepard
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)