Chronology | Current Month | Current Thread | Current Date |
[Year List] [Month List (current year)] | [Date Index] [Thread Index] | [Thread Prev] [Thread Next] | [Date Prev] [Date Next] |
. . . I cannot emphasize too strongly that changing addition
to subtraction is not *not* _not_ NOT !NOT! what is required
to change multiplication to division. Iterated addition
gives you A*B. Iterated subtraction gives you -A*B.
-- Neither of those is division.
-- Either of those *placed inside a feedback path*
can give you division.
... too tedious for humans, unless numbers are small.
This is another reason for asking, why bring it up?
Conceptually and pedagogically it is worse than nothing,
and as a practical algorithm it is laughable, so what's
the point? . . .
Division of positive integer numbers by positive numbers can
consecutive subtractions. But this is too tedious for humans,
unless A is not much larger than B. To divide a number A by
a number B (to find C=A/B) proceed as follows:
1) Set your counter of subtractions to zero (k=0). Also make
the initial R=A.
2) Subtract B from R (R=R-B). If the result is negative then
the answer is C=k+B/A. Go to 6 below.
3) If the result is zero then C is integer (C=k). Stop.
4) If the result is positive then increment the counter (k=k+1).
5) Go back to 2
6) What should one do with a fractional part of the answer,
such as 6/17? It depends on the desired accuracy. The easiest
case is to ignore the fraction; that is usually OK when A >> B.
But suppose one wants additional decimal digits, for example,
four of them? In that case multiply the remainder by 10000
and divide the result by B, in the same way as above. The
integer part of that second division would provide the
desirable digits (after the decimal point). . . .