- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If we use as default kind 16 bit integer and multiply 2 16 bit integer and assigning a 32 bit integer as result we should get a proper result. But it seems that due that the default kind is a 16 bit Integer we will have an overflow:
INTEGER*4 i4
INTEGER*2 i2a,i2b
i2a= 32000
i2b= 32000
i4 = i2a*i2b -> Will have an overflow.
Is there an option for setting that behavior correctly?
Regards,
Andreas
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With your declarations, the expression i2a * i2b is of type INTEGER*2.
If, however, you use a suitable intrinsic function to make the expression take on type INTEGER*24 (thanks, David), the assignment to i4 will occur without overflow causing problems.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If, however, you use a suitable intrinsic function to make the expression take on type INTEGER*4, the assignment to i4 will occur without overflow causing problems.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I4=int4(i2a)*int4(i2b)
This forces the internal calcualtions to use 4 byte integers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It should be smart enough to know what the range of the
output could be, especially when it won't TELL you that there was an overflow.
Other Fortrans I worked with in the distant past didn't have that problem.
Maybe that could be a compiler option, to automatically check for that possibility,
or to make all integer internal evaluations integer(8) by default.
That still doens't solve the problem of multiplying two integer(8) quantities.
I'm wondering if there is a special routine for that? You would have to store
the result in a integer(8) array of size 2.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are packages that implement multiple integer precision, to be used when needed, but they are slow.
That still doens't solve the problem of multiplying two integer(8) quantities.
I'm wondering if there is a special routine for that? You would have to store
the result in a integer(8) array of size 2.
Such facilities are provided by "performance primitive" libraries.
There are reasons why such facilities are impractical to provide in Fortran. One such reason is the daunting task of providing hundreds of copies of intrinsic functions, one for every combination of argument types. Secondly, once a function is provided to return an integer*16 result for the product of two integer*8 numbers, a request for the integer*32 product of two integer*16 numbers will soon follow.
On the other hand, for every processor there is a limited number of integer sizes that have hardware support. Providing complicated multi-precision integer arithmetic to cater to a few users is not as important as providing fast integer operations for most users. Generations of programmers have learned to live with these limitations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"That's one of my big gripes with this Fortran."
The Fortran standard is that the result of an operation is the same type as the operands. It is not to do with the compiler. This is the case whether you are working with integers, reals or double precision.
One consequence of this, often not recognized by novice programmers is that 1/2 is 0 not 0.5, as it is an integer operation with an integer result.
The result of multiplying two 16-bit integers will be a 16-bit integer. Any compiler which returns a 32 bit result is not complying with the Fortran Standard.
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have used the Digital Fortran 6.6 Compiler before and it worked fine.
Therefore I am searching for a compiler option, due that problems relates to several hundredthousands of code lines. These sources exist for15-20 years and nobody wants to touch that anymore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve could address the Digital FORTRAN 6.6 Compiler since I think he worked on it.
This said, did your platform change as well?
Some processors had register limitations on what could be used for arithmetic.
IOW the int16 was always converted to intSomethingLarger prior to the +-*/... then truncated back for storage if necessary. This was left as an implementation issue, still is.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jim,
Thank you.
Doyou know whoI can contactfor adding a compiler optionforthe upcoming releases?
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
is by converting all the integer types to the highest precision (integer*8 for example), then just using ONE library routine to do the actual computations.
This involves a small sacrifice in performance. But if the end result can't be stuffed into the output, it's easy to check for that, and generate a trap or warning message.
Actually, using the int8() intrinsic does the same thing, but it really clutters up the code.
This is a very important consideration when writing code to do decryption or encryption, since it involves using very large numbers of integer type. For example, the RSA algorithm involves taking taking a large integer of some very large power modulo some other integer, and the numbers involved can be hundreds of digits long.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![](/skins/images/872293744008A34B36F8ABF94A46CC66/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page