Setting for double precision?

[hzy]

In Intel Visual Fortran, is there an easy way to set the program so that it interprets a constant in a statement, e.g., X=0.1,as double-precision value?

Show below is an example of wrong interpretation:

double precision X
X=0.1

After executing thesecond line, I got X=0.100000001490116.

In order to getan exact value of 0.1, I need to write X=1d-1. It is easy towritenew code in this clean way. However,for an existingbig programwhich I want to convert to double precision from single precision, it is hard to do so.

Please advise if you have any idea on this topic. Thanks.

[mecej4]

I recommend against relying on non-standard compiler options to make a Fortran program behave in a non-standard way. If, one day, someone else inherits your program or you move to a different computer/compiler combination or forget to use the non-standard compiler options, your program could fail in pernicious ways.

If, despite what I just said, you want to plunge ahead into hazardous territory, look at the /double-size: and /fpconstant options.

[TimP]

I agree for the most part with the advice from mecej4. The compiler treats 0.1 as a single precision constant, as that is what the Fortran standard requires, so it would be preferable to fix your program so that options aren't required to over-ride what the standard dictates.

I don't think double-size will accomplish what you request. real-size might, if you want all default real promoted to a wider precision.

[Andrew_Smith]

It is common among FORTRAN vendors to provide some choice for the storage size of REALS. And also common that we have a compiler option to set a default size. I for one do am not reluctant to use this feature. I rather expect to do so and would not purchase a compiler that did not support it.

It is strange that something so commonly supported is not a part of the language. Oh I forgot, FORTRAN is agnostic about the storage size of REALS. Then why the belief that we must have a default size of 4 bytes.

Andy

[TimP]

Options such as real-size become potentially confusing when applied to code with a mixture of default and specific sized reals, such as in the original post.
Are you saying that lack of standardization of command line options is strange? The standard took a small step in that direction when it required a means of diagnosing non-standard extensions, but that hasn't turned out to be a vast improvement, partly because it can't be counted on.

[Andrew_Smith]

Yes I think a standard command line option would be what I want. There could be many well used command line options that could be standardized.

Not being counted on is common to anything non-standard or from new Fortran standards because of the length of time it takes to see a standard conforming compiler these days. Still only a few F2003 conforming!

I make use of compliler comparison tables such as the PolyHedron ones when making decisions to do something non-standard or new standard stuff. But we could do with even more details in the tables for non-standard features (command line options) and F2003 features.

Andy

[TimP]

I've not been present at J3 meetings, but I doubt that they would want to standardize a command line option which not all compilers could support.
gfortran seems to have reconciled the command line options with general practice to a greater extent than other compilers, but there's still a significant gap.
ifort for Windows has adopted Microsoft-resemblant options, which aren't likely to be accepted outside Windows, yet there are inconsistencies even in this area; for example, you must set -fp:source (much more conservative than default) to match Microsoft -fp:fast (more aggressive than default). The scheme of prefixing -Q to many options, which is considired necessary in the Windows arena, is unlikely to be accepted elsewhere.

[Steven_L_Intel1]

The /Q prefix comes from Microsoft Fortran PowerStaton - at least indirectly. Intel Fortran's options come from a variety of sources:

- DEC Fortran
- Microsoft Fortran PowerStation
- Microsoft C++
- Intel Fortran prior to version 8
- g77
- gcc

This is why they seem so inconsistent in style.

The Fortran standard is indeed agnostic about what size "default real" is - there are implemenations where it is 64 bits (Cray) and there are architectures with 16-bit reals. Actually, the language doesn't insist that reals be binary - IEEE has standardized a decimal floating type and such could be supported in Fortran without any changes to the language. The only limits the standard puts on reals is:

"The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall be at
least 37. It is recommended that the decimal precision of default real be at least 6, and that its decimal exponent
range be at least 37."

I will also comment that the "kind" values are not necessarily byte sizes. While most compilers do use that convention, I know of at least one that uses kinds 1, 2 and 3.

The standard tries very hard not to get involved with architectures or compiler options (it barely acknowledges that such exist.)

[nvaneck]

Quoting Andrew Smith

It is common among FORTRAN vendors to provide some choice for the storage size of REALS. And also common that we have a compiler option to set a default size. I for one do am not reluctant to use this feature. I rather expect to do so and would not purchase a compiler that did not support it.

It is strange that something so commonly supported is not a part of the language. Oh I forgot, FORTRAN is agnostic about the storage size of REALS. Then why the belief that we must have a default size of 4 bytes.

Andy

Writing the suffix for all constants is very annoying and makes reading the code unnecessarily messy and it's easy to forget and omit it sometimes. Clean numbers much easier to read in complicated expressions. I found it a godsend when I discoverd the way to default them all since I use REAL(8) precicisoneverywhere. As far as I'm concerned REAL(4) should be obsoleted.

[mecej4]

> As far as I'm concerned REAL(4) should be obsoleted
> I use REAL(8) (sic) precicisoneverywhere

With the constraint "as far as I'm concerned" removed, that would be a fundamentalist viewpoint which I, for one, abhor. If many Fortran users insisted on having features of the language that they do not use declared obsolete, it is conceivable that there would not be much left in the language.

There are many applications in which 4-byte reals are perfectly adequate (think graphics, for example), and other applications where 8-byte reals are not enough. I can even think of a few situations where less precision than that of 4-byte reals would be very useful.

[nvaneck]

Quoting mecej4

> As far as I'm concerned REAL(4) should be obsoleted
> I use REAL(8) (sic) precicisoneverywhere

With the constraint "as far as I'm concerned" removed, that would be a fundamentalist viewpoint which I, for one, abhor. If many Fortran users insisted on having features of the language that they do not use declared obsolete, it is conceivable that there would not be much left in the language.

There are many applications in which 4-byte reals are perfectly adequate (think graphics, for example), and other applications where 8-byte reals are not enough. I can even think of a few situations where less precision than that of 4-byte reals would be very useful.

Well, that's pretty generalized,, harsh, way over the top and insultingI think. I only referred to the REAL(4) and not just because I don't use it, but because todays processors are so fast with higher precisions. Can't see any advantage to or need for lessor precision nowadays. In the 60's we used single precision and iterative procedures to gain better results and save space, but higher precision with newer processors obsoleted that.

I don't know anything about graphics processors, but if they are all using real(4) for the games, great, but I suspect higher precisions are desireable there as well.

In fact there are several obsoleted thing in f2003 that I miss, so perhaps the shoe is on the otrher foot.

[mecej4]

> In fact there are several obsoleted things in f2003 that I miss.

Would EQUIVALENCE be one of them? I ask because I have run into several excellent programs from the 1970-s and 1980-s where that feature was used. Unfortunately, the EQUIVALENCEd variables are not of the same type, not even compatible as prescribed in the 2003 standard, so replacement of EQUIVALENCE by TRANSFER is not feasible. As a result, those programs are impossible to convert to Fortran 90 with reasonable effort, and one has to keep an old F77 compiler on standby just for the sake of such programs.

[jarvusluntatintel]

I'm probably an unusual case, but single precision is preferable for much of what I do because of the huge number of large arrays. Single precision takes up less space with input files, output files, and even in memory.

But I have to agree that the nomenclature for writting double precision leaves a lot to be desired.

When x is written

X = 0.1

It is only using one significant figure. Is it really that hard or undersirable to assume that all of the digits to the right of the .1 are zeros when it gets used in a double precision computation? (Such as setting X equal to it.)

[mecej4]

When x is written

X = 0.1

It is only using one significant figure.

True. But, this is a number which cannot be represented in binary exactly. In single precision, the internal representation is 3DCCCCCD. Note the last nybble: 'D', signifying that the infinite sequence of 'C's was rounded. The same number, in double precision, is 3FB999999999999A. Again, the last bit has been obtained by rounding.

I agree that it would have been nice to be able to issue a declaration such as CONSTANT REAL*4 at the beginning of a subprogram and have the declaration cover all constants in that scope with no explicitly stated precision. It is quite likely that there are reasons to oppose this suggestion.

Intel Fortran has options to modify how constants are treated, but precautions are necessary to ensure that the options are indeed used where needed and that they are not used otherwise.

[Steven_L_Intel1]

Quoting mecej4

As a result, those programs are impossible to convert to Fortran 90 with reasonable effort, and one has to keep an old F77 compiler on standby just for the sake of such programs.

Say what? All commercial (and most non-commercial) Fortran compilers support EQUIVALENCE and all the rest of the deprecated/deleted features. EQUIVALENCE still works in today's Intel Fortran, and we are not going to remove support for any of the "deleted" features.

[mecej4]

Perhaps I was too terse. The troubles come when one tries to modify the program or convert to Fortran 9X, runs into problems, and turns on compiler options to check for undefined variables, array overruns, etc.

Many of the EQUIVALENCE statements involve overlaying variables of numeric types and character types, which is not allowed in Fortran 9X. The volume of error messages arising from the use of EQUIVALENCE becomes overwhelming and these drown out the useful messages that one is trying to obtain.

[Arjen_Markus]

IIRC, EQUIVALENCE'ing characters and numeric types was not allowed in FORTRAN 77 either. It worked
only because most compilers allowed it as an extension.

Regards,

Arjen

[nvaneck]

I still need EQUIVALENCE in one major part of my code, where data values need to be returned in charcter-numeric, INTEGER or floating-point (or a mixture)according to the command requesting data input. If it ever got obsoleted instead of deprecated it would cause great difficulties. I still do use REAL(4), but only to allow users to import data of that type before converting for internal use, but I could get around that if necessary. I wouldn't really want to obsolete it.

In lots of places, to force as close as possible to the standard, I made use of the TRANSFER statement, but it was an awkward change and more confusing and harder to grasp visuallythan the assignment statement that used to be allowed for certain movements. In some cases I've had to make use of mini-functions toobtainrequired results, but in other cases derived types have helped.The TRANSFER statement seems inefficient as well, but probably isn't and isn't significantly so if it is, in the places I need it.

[dboggs]

Ive been following this discussion with interest, and at the risk of going off on a very slight tangent, I would like advice on converting old code to higher precision.

My code (~20,000 lines) was developed using MS Fortran 5.0 for DOS (!) and was a 16-bit application. I will now be adapting (if not rewriting!) it for IVF on Win XP (32 bit) or Win 7 (32 and/or 64 bit). The program performs lots of manipulations of 32-bit reals (which were actually converted from 16-bit integer analog/digital conversions), including FFT transforms.

Should I consider changing all of the REAL*4 declarations to REAL*8? Will it affect the run speed? I have already concluded that all of the old INTEGER*2 should now be INTEGER*4, so both of the conversions should not be terribly difficult to do. I don't THINK the increased precision is very important; I am more concerned about maintenance and future compatibility.

The new program will also use QwickWin graphics to display real-time results. I notice that the QW library routines use REAL(*)!

Daryl

[dboggs]

I have been following this discussion with great interest, and at the risk of going off on a slight tangent I would like adive regarding upgrading a very old code.

My code was originally developed using MS Fortran 5.0 for DOS (16-bit application)! I am now upgrading (if not rewriting) it for Win XP (32-bit) or Wind 7 (32- and/or 64-bit). The program manipulates large amounts of REAL*4 data using lots of real math ops, including FFT transforms. It will also use QwickWin to display real-time graphs.

Should I consider converting all REAL*4 values to REAL*8? I don't THINK the extra precision is terribly important; I am more concerned about maintenance and future compatibility. I have already begun a trend of converting all INTEGER*2 to INTEGER*4, so I don't think converting the real's would be terribly difficult--but of course some serious effort.

I also note that the QwickWin library uses REAL*8 for all calls!

Daryl

[IanH]

Regardless of what you do in terms of kinds, note that INTEGER*4, REAL*8 etc are not part of the standard language - the syntax is INTEGER(4), etc. Also, regardless of what kind you settle on, consider parameterising it - for example, in a module, perhaps called Kinds or similar:

INTEGER, PARAMETER :: rk_data = your_chosen_kind_value

then in your code...

REAL(rk_data) :: some_literal_value

your_chosen_value can use the SELECTED_REAL_KIND intrinsic and similar to avoid hardwiring the kind.

This way, if you move to a different processor then you avoid potential syntax errors (some of the compilers I use don't accept the type*kind form) and a syntax error or inappropriate representation being selected by using kind 4 or 8 (I also use a compiler where kind 4 is not a four-byte real or single precision).

Hard-wired real constants then need the kind suffix, but I'd also suggest that hard-wired real constants don't appear in executable code - they should also be parameterised out. This benefits code clarity and lessens the need to litter your code with the kind suffix (I make an exception for real constants with small integral values though).

Similar comments apply to integer variable delcarations, integer literal constants I'm less worried about as they are precisely represented if they are in range.