Re: Arbitrary precision modulo operation

Bruno, perhaps round is an issue. Thank you. Here is an example that
should involve no rounding and indeed it works:

Multiply the ten largest integer scale prime numbers:

# select 2147483477::numeric * 2147483489::numeric * 2147483497::numeric
* 2147483543::numeric * 2147483549::numeric * 2147483563::numeric *
2147483579::numeric * 2147483587::numeric * 2147483629::numeric *
2147483647::numeric;
?column?
------------------------------------------------------------------------------------------------
2085923946138988916149190605561960475118165298582929035878182900998428077414994652962618167119
(1 row)

Now, modulo this by any of the factors correctly returns 0:

# select
'2085923946138988916149190605561960475118165298582929035878182900998428077414994652962618167119'::numeric%
2147483563;
?column?
----------
0
(1 row)

Also, diviing out all of the factors correctly returns 1:

# select
2085923946138988916149190605561960475118165298582929035878182900998428077414994652962618167119
/ 2147483477 / 2147483489 / 2147483497 / 2147483543 / 2147483549 /
2147483563 / 2147483579 / 2147483587 / 2147483629 / 2147483647;
?column?
------------------------
1.00000000000000000000
(1 row)

This provides the solution to my problem: I merely needed to cast all
of the numbers to numberic for product and modulo operations.

Thank you,
Chadwick.

Bruno Wolff III wrote:

>On Mon, Apr 26, 2004 at 10:18:52 -0400,
> Chadwick Boggs <chadwickboggs(at)yahoo(dot)com> wrote:
>
>
>>I need to perform modulo operations on extremely large numbers. The %
>>operator is giving me number out of range errors and the mod(x, y)
>>function simply seems to return the wrong results. Also, my numerator
>>is in the format of a quoted string, which the mod function can't take.
>>
>>
>
>I tried some large values and seem to be getting reasonable results.
>I did get some negative remainders, but I didn't find anything in the
>mod documentation on whether or not these were allowed. For small values
>I always got positive remainders so it isn't consistantly return the
>remainder closest to zero. My guess is that it has to do rounding when
>dividing numerics.
>
>
>