If n is a default integer and radix(n) /= 2 or n<0 then F2023 16.3.1 says that the result of bit_size(n) is processor-dependent. In all the compilers I have access to, radix(n) == 2. Does any Fortran compiler implement bit_size(n) with radix(n) not 2 ? If so, what does it do with bit_size(n) ?
(I ask because I’m trying to improve my program giving details of all the real and integer kinds, and its current version assumes radix 2.)
Those of us of a certain age might recall the IBM 1401 computer with its decimal storage. The Fortran standard tries hard not to bake in any architecture specifics. While I don’t know of any current systems that use a radix other than 2, such might appear in the future.
In the case you specify, it would be up to the implementation to decide what to return for bit_size(). The intrinsic returns a value according to the “integer model” in the standard, which might not be the model implemented. (For example, the real model in the standard is not IEEE float.)
1 Like
I think radix was introduced in Fortran 90. According to Wikipedia, IBM 1401 was introduced in 1959, and was used into 1970s or even 1980s in some places. @sblionel do you know if any Fortran 90 compiler could compile for IBM 1401 (in other words if there is a chance that somebody could have used radix on IBM 1401)? The wikipedia page says the computer could run Fortran II and Fortran IV.
Fortran is one of the few languages that tries hard to be truly platform independent. I think that’s the right approach. Consequently compilers should try to run it on any hardware and squeeze high performance out of it.
Thank you @sblionel and @certik. I also use bit_size, which like radix first appeared in f90. Contrary to a statement in “Fortran 95/2003 explained” by Metcalf, Reid and Cohen (2004), p.169, it was not in MIL-STD 1753 though of course it is very useful for people wanting to use the procedures that were.
Various IBM machines, 360, 370 etc., implemented Fortran 77 and used hexadecimal floating point but I don’t know if radix(1.0) would have been 2 or 16, even though I used IBM 370 and 4341 at different times.
1 Like
I am not aware of any FORTRAN 77 compilers for the IBM 1401, not to mention Fortran 90.
The IBM “hex normalization” floating point would have no impact on RADIX or bit_size, both of which deal with the integer model/
1 Like
I have read about the possibility of a ternary computer where each bit can store the values (-1,0,+1) or (0,1,2) for decades, but as far as I know, a practical one has never been built. I’d guess that there has been some experimentation with the circuits, but I don’t know of anything beyond that. Magnetic core memory can do this (there are two magnetized states and one unmagnetized state), atoms in a P state can do this (Lz quantum numbers of -1, 0, and +1), and triplet molecular states can do this (Sz quantum numbers of -1, 0, and +1).
I have never quite understood why a photon, with total spin of S=1, has only two polarizations (left and right, or vertical and horizontal) rather than the expected three for an S=1 object.
@sblionel has dealt with RADIX(X) if X is of integer type, but it is also valid in Fortran 90 and later if X is of real type. That is why I am still curious about what RADIX(1.0) would be in IBM “hex normalization” floating point.
I think it would be 16, but that does not mean that each bit encodes 15 values, rather that 4 bits at a time are used to encode those values, and, also important for floating point, the base of the exponent values is 16.
1 Like
I seem to remember that discussions about radix at X3J3 meetings in the 1980s centered around this possibility.
Mike