Prev: Vector, Point, Homogeneous Coordinates Point Implementation
Next: inquire size of a file
From: robin on 16 Mar 2010 20:45
"sumesh.pt" <sumesh.pt(a)gmail.com> wrote in message
news:e088fdd1-b6a9-49b3-b03f-ee0caf9eec8e(a)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?)

| But it looks so time
| consuming. Is there a smarter way of doing it that some one has come
| across in fortran?
| Thanks,
| sumesh


From: Phred Phungus on 16 Mar 2010 22:59
Richard Maine wrote:
> sumesh.pt <sumesh.pt(a)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
From: Richard Maine on 17 Mar 2010 00:14
Phred Phungus <Phred(a)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.
>
> 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.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Ron Shepard on 17 Mar 2010 02:27
In article <80aurrFaofU1(a)mid.individual.net>,
Phred Phungus <Phred(a)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
From: glen herrmannsfeldt on 17 Mar 2010 05:07
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
> In article <80aurrFaofU1(a)mid.individual.net>,
> Phred Phungus <Phred(a)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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Vector, Point, Homogeneous Coordinates Point Implementation
Next: inquire size of a file