Michael Milgram wrote:
>
> Just what does the standard have to say about mixing variables of
> different KINDS
Fortran retained compatibility, so to a first approximation what was
legal before, is legal now.
> and and can you get into trouble by doing so?
Sure, that's always been true.
>
> For example, mixing integers and double as in
>
> A=B/(1+C)
>
> implicitly converts the integer "1" into a real, but is it a single
> "real" or a double real? (A, B and C are declared double).
>
As you probably are aware, traditionally compilation systems did either.
The standard only requires "single" precision. It's problematic (viz.
always provokes a dispute) if a compilation system is in error if it
provides more precision than the Standard "intends" (for for processors
like the Intel's "traditional" x87 coprocessor family, double extended
precision is the norm for all intermediate computations ... it's a bit
expensive to ensure less precision for every operation).
> Also, what is the default definition for "E" vs "D" specifications.
> Will 0.1D-1 give the same result on a 64 bit processor as on a 32 bit
> processor (I know, the standard says nothing about processor, but
> somewhere it must define "D" vs "E").
>
If you really want to inform the processor about what you want, declare
your constants as PARAMETERs and use explicit declaration statements to
establish the kinds.
> I made up a small program (attached) to test some possibilities, and
> got some answers that don't make too much sense, including,
>
Test programs test the behavior of a given implementation, not the
Standard itself. If you test *all* implementations you may determine
important information about what's likely to work (and where) and how
different implementors view parts of the Standard. Essentially all of
your questions are really those of implementation, and not the standard
itself.
Use named constants (PARAMETER), use explicit kinds. You'll get less
confusing behavior. You may also have to disable some of the more
aggressive optimizations of some processors.
--
Keith H. Bierman [log in to unmask]
Sun Microsystems PAE | [log in to unmask]
12 Network Circle UMPK 12-325 | 650-352-4432 voice+fax
Menlo Park, California 94025 | sun internal 68207
http://blogs.sun.com/khb
<speaking for myself, not Sun*> Copyright 2005
|