Dividing two floats not giving the quotient I need

Im using the remquo function in the cmath library as follows:

int quotient;
double a = remquo (10.3, 4.5, &quotient);

This gives the correct remainder (a = 1.3) and quotient (quotient = 2).

Infact about 50% of the answers are right when I play around, however, trying something like:

int quotient;
double a = remquo (2.25, 1.5, &quotient);

yields an incorrect quotient of 2 and remainder of 0.

I do think this has something to do with float arithmetic. I recall tinkering with the float number 0.500 and that the CPU actually saves it as 0.50000000000000231. However if my suspicion of float arithmetic as the suspect is correct, I do not understand why a tenth decimal would make such a drastic difference as changing the quotient result.

Please advise.

Lol it's because you're storing a double as an int.

Edit : Or is this just how the library you're using works? What is it storing as an int? Because the variable name quotient makes me think it's the actual evaluation and not the remainder or integer representation.

Quote:

---

Originally Posted by MutantJohn

Lol it's because you're storing a double as an int.

Edit : Or is this just how the library you're using works? What is it storing as an int? Because the variable name quotient makes me think it's the actual evaluation and not the remainder or integer representation.

---

The function takes the following parameters:

Code:

---

double remquo  (double numer    , double denom    , int* quot);

---

Quote:

---

Originally Posted by Vespasian

I recall tinkering with the float number 0.500 and that the CPU actually saves it as 0.50000000000000231.

---

it's incredibly unlikely that the system would show it that way, because IEEE floating point values can exactly represent any value, within the range of the data type, that can be described by m * 2ⁿ, where m and n are integers. in the case of 0.5, it's 1 * 2^-1, so it can be represented perfectly by a floating point value. if it's displaying it with the extra digits at the end, it's likely because the function that converts the floating point value to a string representation lacks the precision to do it correctly when you ask for too many digits after the decimal point.

I started looking through the documentation and I'm surprised it doesn't work.

Alright, I just tried your code, doing this :

Code:

---

        int quo;
        double a = remquo(2.25, 1.5, &quo);
        std::cout << a << std::endl;
        std::cout << quo << std::endl;

---

And my output was :

Code:

---

-0.75
2

---

I guess what the function does it, rewrites the division to quo*1.5 + a = 2.25 so we have 2*1.5 + -.75 = 3 - .75 = 2.25.

Things that are binary fractions (1/2, 1/4, etc) would store exactly (assuming they fit) so there's no floating-point inaccuracies here. Are you sure you didn't get your 2.25/1.5 and your 2.5/1.25 backwards? (Since that is exactly 2 remainder 0.)

Code:

---

tabstop@ubuntu:~/helping$ cat divide.c
#include <stdio.h>
#include <math.h>

int main(void) {
    int quotient;
    double a;
    a = remquo(2.25, 1.5, &quotient);
    printf("Quotient is %d with remainder %g.\n", quotient, a);
    a = remquo(2.5, 1.25, &quotient);
    printf("Quotient is %d with remainder %g.\n", quotient, a);
    return 0;
}

tabstop@ubuntu:~/helping$ ./divide
Quotient is 2 with remainder -0.75.
Quotient is 2 with remainder 0.

---

Hi guys,

I kept it as 2.25/1.5 and still got 2 and 0. But I realized that the widget box (Im using a GUI and not console) only displays positive numbers and hence did not display a remainder of -0.75 as it was below 0 and therefore showed a remainder of 0.

This brings me to the next question. I have never in all my life of engineering, maths and science heard of a negative remainder. Looking at it now, I get the logic in that 2 r -0.75 is the same as 1 r 0.75, but what benefit to humanity does a negative version of the same answer bring??

How can I make this thing output normally as 1 r 0.75?

Use something other than remquo, since remquo rounds the quotient to the nearest number. I don't know exactly whose idea this was, but Re: [OT] remquo suggests it was designed to reduce things mod pi for trig functions (and other similar pursuits) so the quotient was pretty irrelevant, and for trig [-pi/2,pi/2] is a lot neater than [0,pi] where applicable.

Anyway if you want "normal" division, that's fmod.

Yes it is a maths thing. It's the difference between modulus and remainder I believe.

https://www.google.com/#q=modulus+vs+remainder

Quote:

---

Originally Posted by Vespasian

I have never in all my life of engineering, maths and science heard of a negative remainder.

---

That probably means you've only ever worked with positive operands.

Quote:

---

Originally Posted by Vespasian

double a = remquo (2.25, 1.5, &quotient);
yields an incorrect quotient of 2 and remainder of 0.

---

My guess is if the quotient ends up between two integers (x.5), then remquot rounds towards the nearest even integer, so 1.5 and 2.5 both round to 2.0, 3.5 and 4.5 round to 4.0, ... , which is the default rounding mode used in IEEE 754 computing functions and operators. Wiki article / section:

Rounding - Wikipedia, the free encyclopedia

Quote:

---

Originally Posted by Vespasian

negative remainder.

---

This is a side effect of rounding to nearest even integer. It's also occurs in C / C++ in signed integer division, the quotient is rounded towards zero, and the remainder can be negative if the dividend is negative and the remainder is not zero. In a few other languages, such as APL, integer division is rounded towards -∞, so the remainder can be negative if the divisor is negative (this is more mathematically "correct").