Large integer modulo division is not very convincing
Look at these:
>>>from mpmath import mp
>>> 20988936657440586486151264256610222593863921 % 2623617082180073274358906876623916797788160
291280009243618888211558641
>>> 20988936657440586486151264256610222593863921 % 5247234164360146548717813753247833595576320
291280009243618888211558641 <<<HOW CAN THIS BE THE SAME ANSWER AS ABOVE?
>>> mp.fdiv(20988936657440586486151264256610222593863921, 5247234164360146548717813753247833595576320)
mpf('4.00000000000000005551115123125782779)
>>> mp.fdiv(20988936657440586486151264256610222593863921, 2623617082180073274358906876623916797788160)
mpf('8.00000000000000011102230246251565558)
I am trying to write a program that returns true if a large number is prime.
As you probably already know, python has its limits. Not just with floating point numbers but also with large numbers above a decillion. If my Python 3.7 (64-bit) can support large integers up to:
import sys
int(sys.float_info.max)
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368
...then why can I not do a simple modulo on the numbers above and not get inconsistencies? Can anyone refer me to some other tool to help me or is there something I'm just missing?
python integer modulo
|
show 5 more comments
Look at these:
>>>from mpmath import mp
>>> 20988936657440586486151264256610222593863921 % 2623617082180073274358906876623916797788160
291280009243618888211558641
>>> 20988936657440586486151264256610222593863921 % 5247234164360146548717813753247833595576320
291280009243618888211558641 <<<HOW CAN THIS BE THE SAME ANSWER AS ABOVE?
>>> mp.fdiv(20988936657440586486151264256610222593863921, 5247234164360146548717813753247833595576320)
mpf('4.00000000000000005551115123125782779)
>>> mp.fdiv(20988936657440586486151264256610222593863921, 2623617082180073274358906876623916797788160)
mpf('8.00000000000000011102230246251565558)
I am trying to write a program that returns true if a large number is prime.
As you probably already know, python has its limits. Not just with floating point numbers but also with large numbers above a decillion. If my Python 3.7 (64-bit) can support large integers up to:
import sys
int(sys.float_info.max)
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368
...then why can I not do a simple modulo on the numbers above and not get inconsistencies? Can anyone refer me to some other tool to help me or is there something I'm just missing?
python integer modulo
1
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38
|
show 5 more comments
Look at these:
>>>from mpmath import mp
>>> 20988936657440586486151264256610222593863921 % 2623617082180073274358906876623916797788160
291280009243618888211558641
>>> 20988936657440586486151264256610222593863921 % 5247234164360146548717813753247833595576320
291280009243618888211558641 <<<HOW CAN THIS BE THE SAME ANSWER AS ABOVE?
>>> mp.fdiv(20988936657440586486151264256610222593863921, 5247234164360146548717813753247833595576320)
mpf('4.00000000000000005551115123125782779)
>>> mp.fdiv(20988936657440586486151264256610222593863921, 2623617082180073274358906876623916797788160)
mpf('8.00000000000000011102230246251565558)
I am trying to write a program that returns true if a large number is prime.
As you probably already know, python has its limits. Not just with floating point numbers but also with large numbers above a decillion. If my Python 3.7 (64-bit) can support large integers up to:
import sys
int(sys.float_info.max)
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368
...then why can I not do a simple modulo on the numbers above and not get inconsistencies? Can anyone refer me to some other tool to help me or is there something I'm just missing?
python integer modulo
Look at these:
>>>from mpmath import mp
>>> 20988936657440586486151264256610222593863921 % 2623617082180073274358906876623916797788160
291280009243618888211558641
>>> 20988936657440586486151264256610222593863921 % 5247234164360146548717813753247833595576320
291280009243618888211558641 <<<HOW CAN THIS BE THE SAME ANSWER AS ABOVE?
>>> mp.fdiv(20988936657440586486151264256610222593863921, 5247234164360146548717813753247833595576320)
mpf('4.00000000000000005551115123125782779)
>>> mp.fdiv(20988936657440586486151264256610222593863921, 2623617082180073274358906876623916797788160)
mpf('8.00000000000000011102230246251565558)
I am trying to write a program that returns true if a large number is prime.
As you probably already know, python has its limits. Not just with floating point numbers but also with large numbers above a decillion. If my Python 3.7 (64-bit) can support large integers up to:
import sys
int(sys.float_info.max)
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368
...then why can I not do a simple modulo on the numbers above and not get inconsistencies? Can anyone refer me to some other tool to help me or is there something I'm just missing?
python integer modulo
python integer modulo
edited Nov 15 '18 at 5:49
Gunasekar
5221518
5221518
asked Nov 15 '18 at 3:15
Infinity LoopInfinity Loop
3019
3019
1
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38
|
show 5 more comments
1
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38
1
1
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38
|
show 5 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311884%2flarge-integer-modulo-division-is-not-very-convincing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311884%2flarge-integer-modulo-division-is-not-very-convincing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I'm getting the exact same results in Clojure using BigIntegers. I'm too tired to consider the maths, but the results you're getting seem legitimate. The first two do in fact result in the same answer.
– Carcigenicate
Nov 15 '18 at 3:22
right...but look at the mpmath divisions.... They are 4.00000000000000then5551115123125782779 I guess it rounds it to a 4 or what? If it does, then the modulo actually gives a wrong answer.
– Infinity Loop
Nov 15 '18 at 3:25
Python appears to be correct here. What makes you think it isn't?
– jwodder
Nov 15 '18 at 3:32
The two mp.fdiv() show different floating point answers. Since the floating point decimal answers are different, the remainder of the modulo on the two shouldn't be the same. I'm guessing Python is rounding it because the zeros go above 15-16 places from the decimal point.
– Infinity Loop
Nov 15 '18 at 3:33
Again, I'm way too tired to consider math in any depth right now, but I can replicate your results exactly in my Clojure REPL. If there is something wrong here, it's also wrong in the JVM/Clojure number module.
– Carcigenicate
Nov 15 '18 at 3:38