## Re: Arbitrary precision modulo operation

From: "Dann Corbit" "Paul Tillotson" , Re: Arbitrary precision modulo operation 2004-04-27 00:46:23 D90A5A6C612A39408103E6ECDD77B829408D6A@voyager.corporate.connx.com (view raw or whole thread) 2004-04-27 00:46:23 from "Dann Corbit" pgsql-general
> -----Original Message-----
> From: Paul Tillotson [mailto:pntil(at)shentel(dot)net]
> Sent: Monday, April 26, 2004 4:41 PM
> To: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Arbitrary precision modulo operation
>
>
> I see there are a few misconceptions about numeric and
> modulus on here:
>
> (1) A modulus operation on a numeric type should NOT have
> rounding errors.  The whole point of numeric is that it is an
> arbitrary precision BASE 10 representation of your number.

This is true

> The modulus returns the (whole
> number) remainder as a result of a division.

This is true if the numeric values are integers.

When the values are not integral, some non-integral results can be
returned.

2.50 % 2.50 is 0
But 13.89 modulo 3.50 is 3.39
If you work it out on paper, you will see that 3.39 is the correct
remainder.

> (2) the modulus operator/function is, AFAIK, supposed to
> return the modulus with the SAME SIGN as the divisor, so I
> think this is a bug. That's what every other modulus operator
> that I have ever seen does. Would you mind doing

I would agree that a positive modulus is preferable.  However, the
negative result is also mathematically correct.

> foodb=> SELECT version();
>
> (3) MySQL just rounds large numbers to the highest value that
> the type will support, and apparently, no arbitrary precision