Best way for integer division
sumesh.pt
really cannot change the type of variables to real and hence forced to
use integer variables. Right now I am using dble()/dble() to avoid any
errors associated with integer division. But it looks so time
consuming. Is there a smarter way of doing it that some one has come
across in fortran?
Thanks,
sumesh
Richard Maine
Well, for a start, the "errors" you are talking about aren't errors.
They are the correct results from the definition of integer division.
They might not be what your application needs, but that doesn't make
them "errors" except insomuch as it is an error to use them if they
aren't what you need.
Assuming that what you need is the result of dble()/dble(), then there
isn't any special magic trick involved. That's the reasonably obvious
way to express it. As with many expressions, using the simple obvious
forms is also likely to be efficient. That's not always the case, but
it's a good first guess in most cases because it is the most efficient
in many, including this one. You are unlikely to find a more efficient
general way. In some special cases, you might be able to do a hair
better, but odds are high that you would slow it down instead of
speeding it up.
The only improvement I could suggest would be to use the f90+ form of
the real intrinsic with a kind parameter instead of the f77-style dble.
But that's not going to affect the speed. It is more of a style matter.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
mecej4
There are no errors associated with integer division; they may arise
with schoolchildren, perhaps, but not on computers.
On the contrary, as is well known, it is division of reals that is error
prone. There are some people who explain this on the basis of only
integers being the product of divine creation...
Consider this example:
program igood
real x,y
integer i,j
x=100000005
y=3
write(*,*)nint(x/y)
i=100000005
j=3
write(*,*)i/j
end
All the variables fit into 4-byte words. Which division is exact? Can
you explain the results?
HTH
-- mecej4
Dieter Britz
If by "time consuming" you mean the typing in, you could make do
with dble()/n, saving one dble(). The integer n's value would get
converted to real. But as Richard Maine has written, dble is out of
date if you are using f95, which lets you define what you mean by
double precision and you can then write real(n,dbl), having set dbl
to the appropriate KIND.
--
Dieter Britz (dieterbritz<at>yahoo.com)
David Jones
The OP was not particularly clear about context, but the above suggestion can be extended to cover some important cases. In particular, if one of quantities in dble()/dble() is fixed and a power of two, then typical modern compilers can take advantage of this for speed purposes, provided that the code allows them to see that this is the case by using explicit constant values rather than variables.
David Jones
robin
news:e088fdd1-b6a9-49b3...@x1g2000prb.googlegroups.com...
|I have a code where I need to do integer divisions several times. I
| really cannot change the type of variables to real and hence forced to
| use integer variables. Right now I am using dble()/dble() to avoid any
| errors associated with integer division.
How are you using the result? What does the statement look like?
(also - Why are you usng double precision? Why not REAL?)
Phred Phungus
> sumesh.pt <sume...@gmail.com> wrote:
>
>> I have a code where I need to do integer divisions several times. I
>> really cannot change the type of variables to real and hence forced to
>> use integer variables. Right now I am using dble()/dble() to avoid any
>> errors associated with integer division. But it looks so time
>> consuming. Is there a smarter way of doing it that some one has come
>> across in fortran?
>
> Well, for a start, the "errors" you are talking about aren't errors.
> They are the correct results from the definition of integer division.
> They might not be what your application needs, but that doesn't make
> them "errors" except insomuch as it is an error to use them if they
> aren't what you need.
I have no idea what motivates fortran's integer division. I'm sure it's
stuff that happened 40 years ago, give or take a decade.
One would think that 56 / 7 == 8
, likewise 57 / 7 == 8
From symmetry of the additive ring about zero then:
-56 / 7 == -8
, and analogously, 57 / -7 == -8
So integer division, with this model, would round toward the origin.
Is that right?
--
fred
Richard Maine
> I have no idea what motivates fortran's integer division. I'm sure it's
> stuff that happened 40 years ago, give or take a decade.
>
> One would think that 56 / 7 == 8
> , likewise 57 / 7 == 8
>
> From symmetry of the additive ring about zero then:
>
> -56 / 7 == -8
> , and analogously, 57 / -7 == -8
>
> So integer division, with this model, would round toward the origin.
>
> Is that right?
I will not try to debate what should be or what "would" be based on some
model you posit. Nor will I try to speculate about what motivations for
the rules might have been, though I personally doubt that "symmetry of
the additive ring" would likely have been a phrase to even have been
mentioned.
I will, however, answer the much simpler question about what the rules
are and what answers result from them. The rules do in fact round toward
the origin and give the answers you suggest for all of the above cases.
I'm a little puzzled that you say you don't understand what motivates
Fortran's integer division, but then you appear to say that you would
instead expect rules that.... appear to be exactly the Fortran ones.
This makes me half suspect that you might not know what the Fortran
rules are. The other half of my suspicion is that I misunderstood what
you were saying.
Ron Shepard
Phred Phungus <Ph...@example.invalid> wrote:
> I have no idea what motivates fortran's integer division. I'm sure it's
> stuff that happened 40 years ago, give or take a decade.
I think they simply chose the most useful definition.
> One would think that 56 / 7 == 8
Yes.
> , likewise 57 / 7 == 8
Yes, with a remainder of 1, which can be obtained with the MOD()
function. This is the way we all learned division in grade school,
even before we learned about decimals, right?
> From symmetry of the additive ring about zero then:
>
> -56 / 7 == -8
> , and analogously, 57 / -7 == -8
>
> So integer division, with this model, would round toward the origin.
>
> Is that right?
Yes. Note that some lesser languages (including C and C++) do not
define integer division when one or both operands are negative.
Fortran does.
$.02 -Ron Shepard
glen herrmannsfeldt
> In article <80aurr...@mid.individual.net>,
> Phred Phungus <Ph...@example.invalid> wrote:
>> I have no idea what motivates fortran's integer division.
>> I'm sure it's stuff that happened 40 years ago, give or take
>> a decade.
Fortran is now more than 50 years old. It was developed originally
on a machine with binary sign-magnitude for integer representation.
Sign-magnitude tends to round in a sign independent manner, which
may have been the reason for the Fortran standard for division.
> I think they simply chose the most useful definition.
(snip)
>> From symmetry of the additive ring about zero then:
>> -56 / 7 == -8
>> , and analogously, 57 / -7 == -8
>> So integer division, with this model, would round toward the origin.
>> Is that right?
(see below)
Note that many, especially those using the C % (mod) operator
have complained about this. One result of this division method
is that a consistent mod operation gives a negative result in
some cases. That is, as you say, 57/(-7) == -8 with a remainder
of 1, but note also that -57/7 = -8 with a remainder of -1.
That is, MOD(-57,7) is -1.
> Yes. Note that some lesser languages (including C and C++) do not
> define integer division when one or both operands are negative.
> Fortran does.
I believe that was changed in C99. Previously, C allowed for
integer division with negative values to round either way, allowing
for hardware differences. C always required the % (mod) operator
to be consistent with the / (divide) operator.
Interestingly, when looking up the properties of Fortran divide,
I find Note 7.22, allowing I>J to be computed as (J-I)<0.
While those should be the same, the results in case of overflow
may be different, or even undefined. While some may disagree
with them, the results of C integer operations, other than
the noted negative divide, are fairly strictly defined.
Otherwise, in 7.2.1.1 Fortran specifies:
"The result of such an operation is the integer closest to the
mathematical quotient and between zero and the mathematical
quotient inclusively."
As hardware tends to do the same, if no other reason than to be
consistent with Fortran, it tends to do the same for C.
-- glen
robin
|
| I have no idea what motivates fortran's integer division. I'm sure it's
| stuff that happened 40 years ago, give or take a decade.
The most basic of the early computers provided at least integer arithmetic.
Later or as well, some also provided floating-point arithmetic.
Integer arithmetic is needed for subscript manipulations
and the like. Some problems are best solved using integers,
or provde a facility for truncating flosting-point to integer form.
Many commercial programs require integers or scaled fixed point,
where arithmetic produces exact results.