ARGH. Who wrote intrinsic_set_exponent.f90?

[Richard E Maine]

On Aug 28, 2006, at 1:30 PM, Jack Howarth wrote:

>     This may be a stupid question but what is the utility
> of having equivalence between different type variables
> if one becomes undefined every time the other is assigned?

Two uses:

> The only reason I can imagine is to allow the same memory
> to be reused for two different data types. However that
> doesn't seem quite as useful these days with large amounts
> of ram being typical.

Yep. That's one. Whether it is useful in new codes "these days" is  
sort of irrelevant. If you want to know why it was put in the  
language, ask what it was useful for in those days rather than in  
these ones. It has been in Fortran since days when it was useful for  
saving memory. It is still extremely useful "these days" because  
zillions of still-useful existing codes use it. I might add that some  
of the common uses are in memory allocation schemes (pre-f90), and  
thus it sometimes get used on arrays that are quite large.

2. A point often neglected in many places, including in this thread.  
Just because the standard says something is nonstandard, that does  
*NOT* mean it isn't useful and won't in fact work on most compilers.  
being nonstandard can mean many things. In this case, it basically is  
the standard's way of warning you that the practice is inherently non- 
portable. You can equivalence different types like this and it will  
work fine with almost every compiler out there. I say "almost every",  
but I'm not actually sure there is a single exception. Of course,  
you'll get different results for machines with different physical  
representations - that's why it is labeled as non-standard. But  
assuming that you know the relevant representations, it will pretty  
much invariably work. Innumerable old codes assumed this and they  
work - particularly for the case where all you are doing is using the  
"wrong" type just to store the bits without ever manipulating them.

People keep suggesting TRANSFER as a "solution", but it doesn't have  
much difference in practice. The standard says that the result of  
such a TRANSFER is processor-dependent. That's not a whole lot  
different from being undefined. About the only difference is that  
with undefined, the processor can, in theory, do things other than  
give you a bogus value. It might, for example, abort. There are some  
compilers that try to track undefinition status, but I'm not at all  
sure they could catch this case - at least one implementation that I  
know of doesn't seem like it should be able to.

As an illustration that nonstandard is not the same thing as useless:  
Referencing a vendor-specific intrinsic makes a program non-standard.  
Yes, that is so even when using that vendor's compiler. This doesn't  
mean that useful programs never do that. The standard even explicitly  
allows vendors to add their own intrinsics - practically encourages it.

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain