ark (09/17/82)
The C Reference Manual has the following to say about integer division: "The binary / operator indicates division. When positive integers are divided truncation is toward 0, but the form of truncation is machine-dependent if either operand is negative. On all machines covered by this manual, the remainder has the same sign as the dividend. It is always true that (a/b)*b + a%b is equal to a (if b is not 0)." In other words, you get what the machine gives you, and that is usually obtained by making the remainder have the same sign as the dividend. It is consistent to have the remainder have the same sign as the dividend or as the divisor. Provided that division and remainder are consistent with each other (in other words, that (a/b)*b + a%b is equal to a) exercising the choice one way or the other has different implications. For instance, if you say the divisor should have the same sign as the remainder, you make the remainder operator behave more like the normal mathematical usage, so that (-1)%3 would be 2. This usage is actually nice for preventing surprises: if you take a%b and b is positive, this choice guarantees a non-negative result. Thus, for instance, you could use % for division hashing with the assurance that the remainder would indeed be a valid index in your hash table. However, if division is to be kept consistent, it must always truncate down in this case. This violates the sometimes useful idea that (-a)/b should always equal -(a/b), and would have (-3)/2 equal to -2, for example. The other choice is to make the remainder and dividend have the same sign. This preserves (-a)/b equal to -(a/b) but now means that (-1)%3 is -1. I suppose intuitive behavior on division is better than on remainder. The language that has my favorite treatment of this issue is APL. In APL, the remainder has the sign of the divisor, and the issue of counterintuitive division is handled by having division return a real number at all times. If you want truncating division, you must do the truncation yourself and it will truncate any way you asked.
tim@ism780c.UUCP (Tim Smith) (01/28/86)
A recent discussion on net.arch raised the problem of defining integer division for negative numbers. Most computers seem to say that -3/2 is -1, and -3%2 is -1. Many people thought this was fine, but some of us think that -3/2 should be -2, and -3%2 should be 1. Both sides agree that integer division on computers must be defined to satisfy (1) (a/b)*b + a%b = a. Everyone agreed that for positive a and b, a/b should round toward zero. The people who want -3/2 to be -1 argue that the following should hold: (2) (-a)/b = -(a/b). Those of us who want -3/2 to be -2 want the following to hold: (3) a%b for positve b has a range of [0,b-1], not [-b+1,b-1], and (4) (a+b)/b = a/b + 1. Are there any good mathematical grounds for choosing one alternative over the other here? Note that I am not asking from a hardware point of view which is better. I want to know mathematically if one is better than the other. My opinion is that (3) and (4) are more important properties than (2), but when I was a math major my major interest was number theory, where (3) and (4) are more useful than (2). [ I have been havig trouble with my mailer, so please respond to net.math ] -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
weemba@brahms.BERKELEY.EDU (Matthew P. Wiener) (01/30/86)
In article <332@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >[Which is preferred: (-a)%b == - (a%b) or (-a)%b >= 0 always?] >Are there any good mathematical grounds for choosing one alternative over >the other here? Note that I am not asking from a hardware point of view >which is better. I want to know mathematically if one is better than >the other. I have NEVER seen an instance where the first one is preferable. Not only is it not preferable, it is just incorrect. Why such a routine has been allowed to be 50% inaccurate in every existing language all these years is beyond me. But since that is what you get, I have always had to program around it, sometimes thinking of clever ways to prevent negative numbers from being fed into the remaindering. Even in non-mathematical usages, the second is preferred. For example, if you have a circular list of length N, kept in an array, i=change(i)%N is the usual way most steps through the list are done, for some integer function change(i). At one research institute I have worked at, IMOD is put in the Fortran library, to be used instead of MOD, so as to get the correct remainder. MOD was left for portability from other people's software, not for usage. [I pity the fool who says "but the first is faster".] [Whether CS people should even be *allowed* to make such mathematical decisions is another question. In C on UNIX, for example, one has log(-x) == log(x), a rather dangerous identity, not based on anything comprehensible. Thus, the implementation of general exponentiation, a**b = pow(a,b) = exp( b*log(a) ) will silently return the wrong value if a is negative. (Try taking cube roots this way!)] ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720
msb@lsuc.UUCP (Mark Brader) (01/31/86)
[Sorry about repeating 20-odd lines, but I needed the equation numbers] Tim Smith (tim@ism780c.UUCP) writes in net.math: > A recent discussion on net.arch raised the problem of defining integer > division for negative numbers. Most computers seem to say that -3/2 is > -1, and -3%2 is -1. Many people thought this was fine, but some of us > think that -3/2 should be -2, and -3%2 should be 1. Both sides agree > that integer division on computers must be defined to satisfy > > (1) (a/b)*b + a%b = a. > > Everyone agreed that for positive a and b, a/b should round toward zero. > The people who want -3/2 to be -1 argue that the following should hold: > > (2) (-a)/b = -(a/b). > > Those of us who want -3/2 to be -2 want the following to hold: > > (3) a%b for positve b has a range of [0,b-1], not [-b+1,b-1], and > (4) (a+b)/b = a/b + 1. > > Are there any good mathematical grounds for choosing one alternative over > the other here? Note that I am not asking from a hardware point of view... > > ... when I was a math major my major interest was number theory, where > (3) and (4) are more useful than (2). I'm going to answer this from a software person's point of view (and therefore I'm cross-posting back to net.arch, which I don't read). When I do an "integer division" operation, (2) is important to me. I want the operation of dividing and then truncating at the decimal point. I hardly ever want the remainder as well as the quotient, and *when I do*, the dividend is always *positive*. When I do a % operation, I may be doing one of two things. I may want the remainder that goes with the division I just did -- in which case, as I say, the dividend is, in my experience of cases of interest, always positive. Or I may want to do the mathematical operation of taking the modulus, which is expressed by (3); and in that case, the "dividend" may be negative or positive. This puts me squarely in the *third* camp. I want (2) *and* (3), and I don't give a dam~ about (1) for negative dividends. So I want -3/2, or rather (-3)/2, to be -1, and (-3)%2 to be +1. I must make one hardware-type comment: I think one argument, perhaps unconscious, in favor of (1) is that computers (the ones I know, anyway) compute quotient and remainder simultaneously. To this I say, yes, but why should they do that anyway? Few languages have DIVIDE X BY D GIVING Q REMAINDER R., and most often the second computed value is unused anyway. I see no reason that this tradition should give extra weight to (1). Mark Brader
wyatt@cfa.UUCP (Bill Wyatt) (01/31/86)
> [ .... ] In C on UNIX, for example, one has > log(-x) == log(x), a rather dangerous identity, not based on anything > comprehensible. Thus, the implementation of general exponentiation, > a**b = pow(a,b) = exp( b*log(a) ) will silently return the wrong value > if a is negative. (Try taking cube roots this way!)] > > ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720 I did the above example (uVax II, Ultrix 1.1) and got a `floating exception'. AHA, I thought , DEC cleaned up this bogosityr! Then I decided to simply print log(-4.0), and it happily printed a garbage number! It would seem that the exception was only because the exp function was delivered a large number. -- Bill UUCP: {seismo|ihnp4|cmcl2}!harvard!talcott!cfa!wyatt Wyatt ARPA: wyatt%cfa.UUCP@harvard.HARVARD.EDU
td@alice.UucP (Tom Duff) (01/31/86)
Pardon my flamage, but what sort of nonsense is this: [in reference to divide instructions that give -(a/b)=(-a)/b] >I have NEVER seen an instance where the first one is preferable. Not >only is it not preferable, it is just incorrect. Wrong! That's the definition. It can't be incorrect. It might be different from what a number theorist wants, but by no stretch of the imagination can it be called incorrect. A mathematician should be able to to handle this elementary concept. >Why such a routine >has been allowed to be 50% inaccurate in every existing language all >these years is beyond me. Well, it's that way because that's the way it's defined in the ANSI Fortran standard, and Fortran is probably a Good Thing for a computer to support -- certainly more important than niggling know-nothing number-theoretic nonsense. Why does Fortran do it that way? Probably because the IBM 701 did it that way. Why did the IBM 701 do it that way? Well, at the time people thought that a divide instruction that satisfied certain identities was more important than mod function behavior. Certainly in most of the applications for which Fortran was designed (i.e. engineering numerical calculations) the behavior of the mod function is of minimal interest. In any case, why should you be worried that some operation you want to do isn't primitive. Most programming languages don't provide arithmetic on multivariate polynomials with arbitrary precision rational coefficients either (which I want more often than I want a number-theoretic mod function.) In any case, it's fairly easy to write: a=b%c if(a<0) a+=c I can't believe that you couldn't discover this code sequence yourself. (Note that it works whether the range of b%c is [0,c) or (-c,c) -- the C language definition allows either.) >[Whether CS people should even be *allowed* to make such mathematical >decisions is another question. In C on UNIX, for example, one has >log(-x) == log(x), a rather dangerous identity, not based on anything >comprehensible. Thus, the implementation of general exponentiation, >a**b = pow(a,b) = exp( b*log(a) ) will silently return the wrong value >if a is negative. (Try taking cube roots this way!)] This sort of nonsense makes me wonder whether the writer should be allowed to make *any* sort of decision at all. No plausible definition of the log function will let you use it to take cube roots of arbitrary reals in this manner. On a higher level of discourse, this writer (Matthew P Whiner) seems to think that mathematicians enjoy some sort of moral and intellectual superiority to engineers and computer scientists. Usually, this attitude is a symptom of envy, since mathematicians are so hard to employ, can't get decent salaries when they do find work, and have a much harder time raising grant money. The smart ones embrace computer science rather than denigrating it. The dull ones just say ``Computer Science? Pfui: that's not mathematics,'' thus demonstrating their lack of understanding of the nature of mathematics and of computer science. In summary: It is better to remain silent and be thought a fool than to speak up and remove all doubt.
mouse@mcgill-vision.UUCP (der Mouse) (02/03/86)
[ Line eaters? Who ever hea
Don't you think this issue has been beaten to death already? How
about just agreeing that both sorts of behavior should be provided and
letting it go at that? We have different instructions which produce
this behavior when the divisor is a power of two (shifts and divides);
why can't we just have two sorts of divide? Some will want one and some
the other, as in all religious debates -- and it's surely not that hard
to satisfy both.
--
der Mouse
USA: {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse
philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
Hacker: One who accidentally destroys /
Wizard: One who recovers it afterwardjer@peora.UUCP (J. Eric Roskos) (02/03/86)
> Pardon my flamage, but what sort of nonsense is this: > [in reference to divide instructions that give -(a/b)=(-a)/b] > >I have NEVER seen an instance where the first one is preferable. Not > Wrong! That's the definition. It can't be incorrect. It might be > different from what a number theorist wants, but by no stretch of the > imagination can it be called incorrect. A mathematician should be able to > to handle this elementary concept. But it may not be too usable to mathematicians if your definition is different from the generally accepted one... after all, mathematicians are one of the main groups of people these machines are built for... Anyway, I thought he was talking about "%", not "/"... I would think that since 3 * -2 = -6 then -6 / 3 = -2 and -6 / -2 = 3 Could someone who is a genuine number theorist please post the way the "modulo" function is supposed to work, and also what number theorists would prefer the results of integer divisions with nonzero remainders to be (for various permutations of signs), so that people who have some say in the way instruction sets get designed can make sure it's done right in the future? Please put "I am a number theorist" at the start of your posting (include some proofs too if you want!) ... this discussion has been going around and around for weeks. Better yet, put "Number theory" in the "subject" line ... Be sure to post it to net.arch, not just net.math. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCUR.UUCP CCUR DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 xxxxx4xxx "There are other places that are also the world's end ... But this is the nearest ... here and in England." -TSE
ladkin@kestrel.ARPA (02/03/86)
In article <4917@alice.UUCP>, td@alice.UucP (Tom Duff) writes: > Pardon my flamage, but what sort of nonsense is this: > reals in this manner. > [......] > On a higher level of discourse, this writer (Matthew P Whiner) seems > to think that mathematicians enjoy some sort of moral and intellectual > superiority to engineers and computer scientists. Usually, this > attitude is a symptom of envy, since mathematicians are so hard to > employ, can't get decent salaries when they do find work, and have > a much harder time raising grant money. The smart ones embrace > computer science rather than denigrating it. The dull ones just > say ``Computer Science? Pfui: that's not mathematics,'' thus demonstrating > their lack of understanding of the nature of mathematics and of > computer science. > > In summary: > It is better to remain silent and be thought a fool than > to speak up and remove all doubt. I don't think anybody should pardon this sort of thing. Arrogance and snobbishness are best indulged in between consenting adults in private. Please let's clean up the discussion. This is an important and interesting issue, as shown by the inability of the participants to resolve it easily. Peter Ladkin
omondi@unc.UUCP (Amos Omondi) (02/04/86)
> In article <4917@alice.UUCP>, td@alice.UucP (Tom Duff) writes: > > Pardon my flamage, but what sort of nonsense is this: > > reals in this manner. > > [......] > > On a higher level of discourse, this writer (Matthew P Whiner) seems > > to think that mathematicians enjoy some sort of moral and intellectual > > superiority to engineers and computer scientists. Usually, this > > attitude is a symptom of envy, since mathematicians are so hard to > > employ, can't get decent salaries when they do find work, and have > > a much harder time raising grant money. The smart ones embrace > > computer science rather than denigrating it. The dull ones just > > say ``Computer Science? Pfui: that's not mathematics,'' thus demonstrating > > their lack of understanding of the nature of mathematics and of > > computer science. > > > > In summary: > > It is better to remain silent and be thought a fool than > > to speak up and remove all doubt. > > I don't think anybody should pardon this sort of thing. > Arrogance and snobbishness are best indulged in > between consenting adults in private. > Presumably this also applies, notwithstanding how angry the number theorists are, to articles implying that all CS types are idiots who don't have the foggiest idea of what they are doing.
hansen@mips.UUCP (Craig Hansen) (02/05/86)
I assume that everyone else is as sick and tired of seeing this dead horse beaten as I am, but I find a point still unstated. Several people have asked for mathematical reasons for choosing integer division with rounding to - infinity rather than zero. I submit the following: If you wish to compute an approximation to a/b to the NEAREST integer, when a/b is rounded to minus infinity, you can use (a+a+b)/(b+b). I can think of no expression except those that involve conditionals for which this can be done when a/b is rounded to zero. Craig Hansen MIPS Computer Systems ...decvax!decwrl!mips!hansen
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/06/86)
What I would like is for the language to provide a notation for obtaining BOTH the quotient and the remainder of an integer division in a single operation. Too often I need both and have to go through extra overhead to get them (many computers compute both parts at the same time). (I would also like to get both the sine and the cosine of an angle in a single operation with reduced overhead, but that seems much less feasible.) This % vs. Mod debate is rather silly. C's % operator is NOT repeat NOT intended to be a modulo operator, although people often use it that way for positive operands. All reasonable mathematicians agree on what the definition of a mod b is for positive b and negative a. That should not be confused with what the result of a % b should be under similar circumstances. C intentionally hedges a bit on the meaning of % in such a case (which makes that a generally inadvisable situation to allow to arise in one's C code).
ladkin@kestrel.ARPA (02/06/86)
(ladkin) > > Arrogance and snobbishness are best indulged in > > between consenting adults in private. (omondi) > Presumably this also applies, notwithstanding how angry > the number theorists are, to articles implying that all > CS types are idiots who don't have the foggiest idea of > what they are doing. Yes it does, witness the paragraph you edited out, and my previous postings. A plea: please include uucp pathnames so that we on arpa can avoid posting personal replies like this. Peter Ladkin
earl@mips.UUCP (Earl Killian) (02/07/86)
Of the languages I'm familiar with, I believe integer division is best handled in Common Lisp. There are four functions of two arguments: trunc, floor, ceil, and round. Each divides the first argument by the second and then rounds the result to an integer using round to zero, round to -infinity, round to +infinity, and round to nearest respectively. The second return value is the remainder of that division. Thus: (trunc 7 3) => 2, 1 ; 2*3 + 1 = 7 (trunc -7 3) => -2, -1 ; -2*3 + -1 = -7 (floor 7 3) => 2, 1 ; 2*3 + 1 = 7 (floor -7 3) => -3, 2 ; -3*3 + 2 = -7 (ceil 7 3) => 3, -2 ; 3*3 + -2 = 7 (ceil -7 3) => -2, -1 ; -2*3 + -1 = -7 (round 7 3) => 2, 1 ; 2*3 + 1 = 7 (round -7 3) => -2, -1 ; -2*3 + -1 = -7 The programmer picks what is appropriate. I have found floor and ceil to be the most useful, and trunc somewhat less. I have never used round. Actually these are also functions of one argument: (floor 3.5) => 3 0.5, etc.
weemba@brahms.BERKELEY.EDU (Matthew P. Wiener) (02/08/86)
In article <367@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > Don't you think this issue has been beaten to death already? yes > .... >why can't we just have two sorts of divide? How would you implement that? If you make one form get / and the other a function call, you haven't changed things very much! > Some will want one and some >the other... Is there someone out there who *wants* a/b to round towards 0 (for reasons that say that is the desired result)? I asked that before and have not seen any affirmatives. ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720
cdshaw@watrose.UUCP (Chris Shaw) (02/09/86)
In article <4589@kestrel.ARPA> ladkin@kestrel.ARPA writes: >... deleted personal argument goes here ... >A plea: please include uucp pathnames so that we on arpa can >avoid posting personal replies like this. > >Peter Ladkin I think the obvious choice is to shut one's face instead of cluttering the technical newsgroups with this kind of trash. I'm up to my chest in all the mud that got slung around on this issue, and I'm getting rather sick of it. In the future, if one has something to say, be concise, and try not to repeat what others have said. Ad Hominems and Straw Men will no longer be accepted. Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath University of Waterloo In doubt? Eat hot high-speed death -- the experts' choice in gastric vileness !
hofbauer@utcsri.UUCP (John Hofbauer) (02/10/86)
> This % vs. Mod debate is rather silly. C's % operator is > NOT repeat NOT intended to be a modulo operator, although > people often use it that way for positive operands. All > reasonable mathematicians agree on what the definition of > a mod b > is for positive b and negative a. That should not be > confused with what the result of > a % b > should be under similar circumstances. C intentionally > hedges a bit on the meaning of % To paraphrase Alice In Wonderland loosely, an operator means whatever you want it to mean, nothing more, nothing less. The remainder of a machine integer division is defined as being whatever the engineer's found convenient to implement. Any resemblance to mathematics is purely coincidental.
ken@turtlevax.UUCP (Ken Turkowski) (02/10/86)
In article <685@brl-smoke.ARPA> gwyn@brl.ARPA writes: >(I would also like to get both the sine and the cosine of >an angle in a single operation with reduced overhead, but >that seems much less feasible.) You'll be glad to know that the 68881 returns BOTH the sine and cosine with a 15% timing penalty over just sine. -- Ken Turkowski @ CIMLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.DEC.COM
jsdy@hadron.UUCP (Joseph S. D. Yao) (02/10/86)
In article <685@brl-smoke.ARPA> gwyn@brl.ARPA writes: >What I would like is for the language to provide a notation >for obtaining BOTH the quotient and the remainder of an >integer division in a single operation. C doesn't provide a notation for an op with two returns, so this might be a little hard. (How I Did It:) On a PDP-11 with no FPP and V6 (that long ago), I wrote the long div/rem functions. Since the work involved was massive, I saved the operands, the quotient, and the remainder. If subsequent calls had the same operands, I just returned the already-computed values! If a div or rem is "cheap", this loses. However, if it is done in microcode the same way, this technique is recommended to the microcoders. >This % vs. Mod debate is rather silly. C's % operator is >NOT repeat NOT intended to be a modulo operator, although >people often use it that way for positive operands. Hooray. Modulo() != Remainder() except under certain circumstances, as this branch of net.flame has shown. I was at the point of posting this myself, the discussion was getting so disgusting (not to mention ad hominem -- or ad speciem). My degrees and first job titles all said "mathematics". Subsequent job titles have included phrases like "computer scientist" and "software engineer." This may qualify me to speak. (One degree also says "CS", and > 1 decade of experience lends credence to "engineer".) I consider each occupation to be superior to the others in what they do. Period. I don't expect the M or SE to immediately see a CS point of view, nor an SE or CS the M point of view, or any of the other possible permutations. SE's and programmers have made the remainder function what it is because the specs said so -- great! CS'ers, who don't use i m p l e m e n t e d languages unless they have to, are free to use mod() or rem() as they please. Mathematicians (pure) use anything they want, as long as it's in the realm of pure thought. Mathematicians (applied) have to use the tools that are available: so it is necessary for the SE's to provide their users d o c u m e n t a t i o n that clearly says, e.g., what rem is (it isn't mod, for instance). Then it is necessary for the users to r e a d said documentation, before complaining. Or take a class and l i s t e n . (No, I'm not saying none of my students ever did -- just the ones that complained most that they didn't understand. ;-}) All >reasonable mathematicians agree on what the definition of > a mod b >is for positive b and negative a. That should not be >confused with what the result of > a % b >should be under similar circumstances. C intentionally >hedges a bit on the meaning of % in such a case (which >makes that a generally inadvisable situation to allow to >arise in one's C code). -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
bmw@aesat.UUCP (Bruce Walker) (02/11/86)
| Is there someone out there who *wants* a/b to round towards 0 (for reasons | that say that is the desired result)? I asked that before and have not seen | any affirmatives. | | ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720 Yes, *I* want a/b to round toward 0, and for a good (although selfish) reason. (I also want divide to produce *both* result *and* remainder which answers a question posed by someone else on just that point.) When I write the firmware for the disk controller boards I design, I want that code to run as fast as possible (so do you, if your machine uses my board!). When a logical block address is handed to me, I do an integer divide by the number of sectors per track which produces both a quotient and remainder. The quotient will represent the track I should seek, and the remainder represents the sector I should read. No extra work is done, and all the micros I would normally use for this kind of purpose do what I expect. The above algorithm is simplified of course, one would normally have to consider bad-block management etc., but the principle remains intact. So, if as a result of this discussion, every uP manufacturer ups and "fixes" his microcode, don't come crying to me that all your disk reads take 20 more microseconds than they used to. Bruce Walker {allegra,ihnp4,linus,decvax}!utzoo!aesat!bmw "I'd feel a lot worse if I wasn't so heavily sedated." -- Spinal Tap
jeff@gatech.CSNET (Jeff Lee) (02/12/86)
>[Whether CS people should even be *allowed* to make such mathematical >decisions is another question. I am afraid that I must rank this statement right up there with the statement that was made about a year ago that only computer scientists should be the people allowed to program. Being a computer scientist with an interest in math, I find in both statements some of the most ignorant and arrogant attitudes that I have seen just about anywhere (in a professional situation). I suppose that you also believe that only professional mechanics should work on your car, that professional drivers should drive it, that architects should be the only people allowed to design your house, or that professional cooks should be the only people allowed to cook your meals? I am afraid that I do all these things and will continue to do so. If you really believe that statement that you made, I would expect you to start giving your programming work to professional programmers who are trained in this sort of thing... -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
tim@ism780c.UUCP (Tim Smith) (02/14/86)
In article <557@aesat.UUCP> bmw@aesat.UUCP (Bruce Walker) writes: > >Yes, *I* want a/b to round toward 0, and for a good (although selfish) >reason. (I also want divide to produce *both* result *and* remainder >which answers a question posed by someone else on just that point.) > >When I write the firmware for the disk controller boards I design, I >want that code to run as fast as possible (so do you, if your machine >uses my board!). When a logical block address is handed to me, I do an >integer divide by the number of sectors per track which produces both a >quotient and remainder. The quotient will represent the track I should >seek, and the remainder represents the sector I should read. No extra >work is done, and all the micros I would normally use for this kind of >purpose do what I expect. > If your logical block numbers are >= 0, and your disks have a positive number of sectors per track, then round toward zero and round toward negative infinity are the same. If you were given a relative block number to seek to, say N blocks from the start of the current track, then N might be negative. In this case you would also want to round to negative infinity. For example, if we have 16 sectors per track, and want the logical sector -13 from the start of the current track, we want -13/16 = -1, and -13%16 = 3, so we go back one track and read sector 3. With round toward zero, we would get -13/16 = 0, -13%16 = -13, thus we try to read sector -13 of the current track. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
jimc@ucla-cs.UUCP (02/18/86)
In article <557@aesat.UUCP> bmw@aesat.UUCP (Bruce Walker) writes: >| Is there someone out there who *wants* a/b to round towards 0 (for reasons >| ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720 > >Yes, *I* want a/b to round toward 0, and for a good (although selfish) >reason. (I also want divide to produce *both* result *and* remainder >which answers a question posed by someone else on just that point.) > >...When a logical block address is handed to me, I do an >integer divide by the number of sectors per track ... "Round" is a misnomer. I think the problem is, if the logical block number is negative, should the answer be made more or less positive? In other words, in (-16)/7 do you want the answer to be -2 or -3? I don't think I have ever had a situation where it mattered -- but remaindering is closely related, and it *does* matter there. Do you want (-16)%7 to be -2 or +5? In your disc example I think you would rather be on sector +5, track -3 rather than sector -2 track -2. Similarly for circular caches, hash tables, etc.etc. One point, though: most divisions and remainderings are of known-to-be positive quantities, and we want to avoid adding useless overhead to check unsigned quantities for being negative. It would be best if the hardware would let the remainder have the sign of the divisor, whatever the dividend is. (Ask for the moon and they might give it to you.) James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU
pete@valid.UUCP (Pete Zakel) (02/28/86)
> Is there someone out there who *wants* a/b to round towards 0 (for reasons > that say that is the desired result)? I asked that before and have not seen > any affirmatives. > > ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720 I do! Mainly because I want the absolute value of (-a)/b to equal the absolute value of a/b. -- -Pete Zakel (..!{hplabs,amd,pyramid,ihnp4}!pesnta!valid!pete)