HP Forum Archive 14

[ Return to Index | Top of Index ]

33s Rmdr Bug? Message #1 Posted by Shaun Greaney on 6 Mar 2004, 4:54 p.m. Am I looking at the correctly? The "Rmdr" function is supposed to return the remainder from an integer division. If x and y are both positive integers the function behaves as I would expect: 25 4 -> Rmdr 1 25 5 -> Rmdr 0 25 6 -> Rmdr 1 So far, so good. If I start to use negative numbers though, the results are a bit surprising: 25 -4 -> Rmdr -3 25 -5 -> Rmdr 0 25 -6 -> Rmdr -5 -25 4 -> Rmdr 3 -25 5 -> Rmdr 0 -25 6 -> Rmdr 5 -25 -4 -> Rmdr -1 -25 -5 -> Rmdr 0 -25 -6 -> Rmdr -1 The "INT/" (left shift on the same key) works as I would expect and does not make sense in conjuction with the "Rmdr" key for negative calculations: 25 4: <- INT/ 6, -> Rmdr 1 25 -4: <- INT/ -6, -> Rmdr -3 ??? Any other proud 33s owners out there? In general I like the 33s. The keypad is not as bad as I thought it would be and it is still nicer to use then TI or Casio, IMHO. Just need to identify the buggy functions to avoid. Thanks and sorry for the long post, Shaun

Re: 33s Rmdr Bug? Message #2 Posted by Shaun Greaney on 6 Mar 2004, 5:01 p.m., in response to message #1 by Shaun Greaney Sorry about the format, my line breaks disappeared. Supposed to look like: 25 4 -> Rmdr 1 25 5 -> Rmdr 0 25 6 -> Rmdr 1 25 -4 -> Rmdr -3 25 -5 -> Rmdr 0 25 -6 -> Rmdr -5 etc.

Re: 33s Rmdr Bug? Message #3 Posted by Ben Salinas on 6 Mar 2004, 8:18 p.m., in response to message #1 by Shaun Greaney There is an error there, though it is not too large. Technically, the only time it produces a wrong answer is when you use two negative numbers. According to modular aritmetic (more info http://www.geocities.com/piguy31415926/indep_study.html) if you are finding the remainder when dividing by 5, then -4 is the same as 1. So, the calculator is right in that case, though it gives the less obvious answer (but you sometimes need to use a negative to simplify your equation... if you are dividing by 60 and you get a result of 59, it is much easier to call it -1 instead of 59... there is an example of this in the modular arithmetic document on the page above) -Ben Salinas

Re: 33s Rmdr Bug? Message #4 Posted by Michael F. Coyle on 6 Mar 2004, 9:21 p.m., in response to message #1 by Shaun Greaney Hi Shaun, I don't like what I'm seeing. Ben is probably right about the 33S not strictly following the rules of modular arithmetic; I haven't checked this. That wouldn't bother me so much, except that the 33S seems to violate a more permissive rule wrt integer division and remaindering: In the C programming language, if "/" means integer division and "%" means remainder, then (a/b)*b + a%b = a (assuming b non-zero) For negative operands, the C standard does not specify the exact result, only that the above relationship must always be true. That lets compiler writers use the underlying hardware behavior, whatever it is, to give the most efficient (but not necessarily portable) implementation. Using 25 and -4, and the integer division and remainder results given above, (25/-4)*-4 + 25%-4 = 25 (-6)*-4 + -3 = 25 24 + -3 = 25 21 = 25 which is clearly not right. Anyone writing programs which do integer division with negative operands may be (very!) surprized at the results. To me, this constitutes a genuine bug. I don't have a 33S so I can't go any further. Perhaps someone could investigate this a little more, with a variety of operands of both signs. - Michael

Re: 33s Rmdr Bug? Message #5 Posted by Shaun Greaney on 7 Mar 2004, 2:51 a.m., in response to message #4 by Michael F. Coyle Hi Ben and Michael, Thanks for your replies. I had noticed the modular aspect, but since the "integer divide" and the "remainder" functions are located on the same key ("%"), I expected them to work as Michael described. Guess I'll try contacting HP next week and see how they respond. Thanks, Shaun

Re: 33s Rmdr Bug? Possible explanation Message #6 Posted by Andrés C. Rodríguez (Argentina) on 7 Mar 2004, 2:03 p.m., in response to message #1 by Shaun Greaney The behavior observed by you seems consistent with an algorithm related to repetitive substraction instead of division. This may or not be correct, I think that it should be a clear definition of "reminder"... When you use negative numbers, and check for a value to be "less" than other, the lesser number is the one with greater absolute value. It seems that, for positive cases (both positive or both negative numbers), the 33s calculates the following: + 25 4: 4*6=24, the reminder is 25-24=1, because 24 is the closest multiple of 4 that is less or equal than 25 + 25 5: 5*5=25, the reminder is 25-25=0, because 25 is the closest multiple of 5 that is less or equal than 25 + 25 6: 6*4=24, the reminder is 25-24=1, because 24 is the closest multiple of 6 that is less or equal than 25 Now, for negative cases (one positive and one negative number), the 33s calculates the following: - 25 4: 4*(-7)=-28, the reminder is -28-(-25)=-3, because -28 is the closest multiple of 4 that is less or equal than -25 - 25 5: 5*(-5)=-25, the reminder is -25-(-25)=0, because -25 is the closest multiple of 5 that is less or equal than -25 - 25 6: 6*(-5)=-30, the reminder is -30-(-25)=-5, because -30 is the closest multiple of 6 that is less or equal than -25 It is not very clear, but it seems consistent... Edited: 7 Mar 2004, 2:28 p.m.

Re: 33s Rmdr Bug? -- MOD vs. RMD Message #7 Posted by Karl Schneider on 7 Mar 2004, 5:23 p.m., in response to message #6 by Andrés C. Rodríguez (Argentina) Shaun -- Andres just might have it right, but I'd like to point out that there's a difference between the remainder ("RMD") function and modulo division ("MOD" function). The 41C*, 42S and RPL calc's (28/48/49) have "MOD" built in. The 16C has "RMD" built in. Arguments MOD RMD 25, -6 -5 1 25, -4 -3 1 -25, 4 3 -1 -25, -4 -1 -1 25, 4 1 1 Obviously, there's a difference in the definitions: "RMD" is defined only for integer input arguments; its results are consistent with RMD (y, x) = x * frac (y / x) using floating-point calculations. "MOD" can also be used with floating-point inputs. Apparently, MOD is equivalent to repeated subtraction or addition (as appropriate) of the divisor until the remainder is either zero or, lesser in magnitude and of the same sign of the divisor. It looks as though the 33S is really doing modulo division ("MOD"), and HP ought to label and define it as such.

Re: 33s Rmdr Bug? -- MOD vs. RMD Message #8 Posted by Andrés C. Rodríguez (Argentina) on 7 Mar 2004, 7:08 p.m., in response to message #7 by Karl Schneider Your explanation is very good and plausible. Perhaps the omnipresent marketing strategies dictated that "reminder" was a concept most people has (at least, after learning how to divide in primary school), while "modulo" was only known by more mathematically knowledgeable people (=> less market share). One can imagine a scene in which some VIP asked "What is this "modulo" thing? and somebody else, just trying to ease the moment answered "Well, it is kind of "reminder", you know..."

Re: 33s Rmdr Bug? -- MOD vs. RMD Message #9 Posted by Shaun Greaney on 8 Mar 2004, 7:16 p.m., in response to message #8 by Andrés C. Rodríguez (Argentina) Thanks for all the thoughts and all the input. I've got one more wrinkle for you: MathCAD defines the "Modulo" function, mod(x,y) as the remainder on dividing x by y with the result having the same sign as x. As expected, it tests out to have the same results as Karl Schneider's RMD function. MatLab, however, defines it as: MOD(x,y) is x - y.*floor(x./y) Which matches the MOD and Rmdr functions. I just wish HP would have kept the Integer Divide and "Remainder" functions consistent since they share the same key. Choosing the "MOD" function, calling it "Rmdr", and placing is side-by-side with the Integer Divide function is just irritating.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall