[HP35s] Program for prime number (Wheel Sieve and Miller-Rabin)
|
02-17-2019, 05:22 AM
Post: #41
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
(02-16-2019 07:57 PM)Albert Chan Wrote:(02-16-2019 07:09 PM)Gerald H Wrote: "Set at random Although the programme may check for 999999 as a factor it does not check for all factors upto 999999. |
|||
02-17-2019, 05:46 AM
Post: #42
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
(02-17-2019 04:15 AM)Thomas Klemm Wrote: Meanwhile I extended the search a bit: Thank you for the very interesting statistics, Thomas, you have done more work on that than I have for such small numbers. Indeed, as the number tested becomes smaller a single test becomes less reliable. On the 35s my interest is for numbers of the form (5 or 6 digit prime)*(5 or 6 digit prime) & for such the programme as is has been satisfactory. It would be very nice of you if you could produce statistics for numbers in that range. The programme at http://www.hpmuseum.org/forum/thread-4236.html contains some useful calculations & sadly no users, if indeed there are any, have suggested improvements - perhaps you could assist? |
|||
02-17-2019, 04:33 PM
(This post was last modified: 02-17-2019 04:37 PM by Gerald H.)
Post: #43
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
"Although the programme may check for
999999 as a factor it does not check for all factors upto 999999." Not correct, sorry - To some degree the programme does check for all factors up to 999999. eg If you enter 55021677489 the programme very quickly finds its largest factor & returns 0 |
|||
02-17-2019, 10:58 PM
(This post was last modified: 02-17-2019 11:47 PM by Albert Chan.)
Post: #44
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
Trivia: searching backwards, found a particular bad composite, with many SPRP non-witnesses.
N = 999999 512881 = 881917 * 1133893 = A*B For PRP test: Total PRP non-witnesses = gcd(A-1,N-1) gcd(B-1,N-1) = 125988 * 125988 = 15872 976144 Percent of hitting PRP non-witness = (125988² - 2) / (N-3) ≈ 1.59% For SPRP test: Tried first 10 million bases, SPRP non-witnesses = 59708 Percent of hitting SPRP non-witness ≈ 59708/1e7 ≈ 0.60% Note: 0.60% assumed statstical trend continued all the way to N-2 |
|||
02-18-2019, 06:09 AM
Post: #45
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
(02-17-2019 10:58 PM)Albert Chan Wrote: Trivia: searching backwards, found a particular bad composite, with many SPRP non-witnesses. A very nice example of a difficult case - But the chance of testing this number, or any other constructed to be difficult cases, when feeding the programme a random number is very small. Similarly the likelihood of finding a number as in posting #43 is very small. |
|||
04-09-2019, 03:52 PM
(This post was last modified: 04-10-2019 07:31 AM by fred_76.)
Post: #46
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
Hi !
After a long period without programming I was finally able to complete the Miller-Rabin primality test on the HP35s. It runs very fast, even if the code is not optimized, but from 9 digits numbers and above. For numbers less than 9 digits, the optimized brut force is faster. For numbers above 11 digits, I still have problems to calculate the exponentiation without overflow therefore I can't conclude. Compared to the "brut force V3" : Quote:Run time |
|||
04-09-2019, 05:22 PM
Post: #47
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
One can cast out small numbers (perhaps by "wheels" rather than trial division; wheels do several divisions at once) then switch to SQUFOF or Pollard's Rho or Pollard's P-1 method.
However, I digress as I only read part of an answer. The above is for factoring. Prime testing is also interesting. There is a polynomial-time algorithm but it runs in m^6 power or so where m is the length of the candidate. There are several good tests. The Selfridge-Pomerance-Wagstaff test is rather nice (I'll try it later this year sometime). The Wiki has good article on prime testing. |
|||
04-10-2019, 07:26 AM
(This post was last modified: 04-10-2019 07:32 AM by fred_76.)
Post: #48
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
TTW, the "optimized brut force" methods is a wheel (2 3 5 7), optimized to be as fast as possible on the HP35s. It will factorise the number when you repeat the program.
The last version is a Miller-Rabin method I tested last week end. The problem is the calculation of the power A^B mod N which fails on the HP35s when the prime number to test is slightly bigger than 500 000 000 000. I'm using the right-to-left algorithm. |
|||
04-10-2019, 03:56 PM
(This post was last modified: 04-10-2019 06:07 PM by fred_76.)
Post: #49
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
Miller Rabin optimized on my HP35s gives the following results. In brackets the speed compared to the brut force v3).
Code: 6 digits (999 983) in 0' 37" slower than brut force Note that the HP48GX does 999,999,999,989 in ~ 31 seconds... it is 5x faster than the HP35S. I use the Miller Rabin algorithm already detailed in some page before. I test only a small set of bases as it was proven that such small set is enough : * if n < 2,047, it is enough to test a = 2; * if n < 9,080,191, it is enough to test a = 31 and 73; * if n < 4,759,123,141, it is enough to test a = 2, 7, and 61; * if n < 1,122,004,669,633, it is enough to test a = 2, 13, 23, and 1662803; The MR test is however to be used for numbers greater than about 90 000 000 as the brut force is faster for smaller number. Well, that's quite fast for such a calculator... |
|||
04-10-2019, 09:24 PM
Post: #50
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
One of the nice things about SQUFOF is that the intermediate results are of the order of SQRT(N) rather than N. It helps; one only needs really long stuff N itself.
|
|||
04-11-2019, 02:52 AM
(This post was last modified: 04-13-2019 01:54 AM by Albert Chan.)
Post: #51
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
(04-10-2019 03:56 PM)fred_76 Wrote: I use the Miller Rabin algorithm already detailed in some page before. I test only a small set of bases as it was proven that such small set is enough : Or, you can pick the bases from the records: http://miller-rabin.appspot.com Assuming 12 digits range: if n < 132,239, test a = 814494960528 if n < 360,018,361, test a = 1143370 and 2350307676 if n < 154,639,673,381, test a = 15 and 176006322 and 4221622697 if n < 47,636,622,961,201, test a = 2 and 2570940 and 211991001 and 3749873356 Do a = a (mod n). If a = 0 or 1 or n-1, skip the test and return as probable prime. Edit: with little effort, you can use the bigger base for bigger range. Example if n < 341,531, test a = 9,345,883,071,009,581,737 → reduced a = ((9345883e12 % n) + 71009581737) % n |
|||
04-11-2019, 07:42 AM
Post: #52
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
Amusing divisibility tricks. Nearly all divisibility tests are the same. I haven't checked to see if a similar test would work for divisibility by various composites (which would allow quick trial divisibility test as part of a primality test or a factoring program.)[/align]
https://arxiv.org/pdf/1903.04903.pdf |
|||
04-11-2019, 03:18 PM
(This post was last modified: 04-11-2019 05:25 PM by fred_76.)
Post: #53
|
|||
|
|||
RE: [HP35s] Program for prime number (brut force)
Here is the code of the MR primality check.
I've been inspired by the post of Thomas Klemm. I haven't used the Gerald H arithmetic library (far too complex to me to understand with all the imbricated XEQs... sorry Gerald). That leaves place for further optimisation. Modular addition Here we reduce first A to A≡N and B to B≡N then calculate A-N+B (which can't overflow) ≡ N we could save a calculation of A-N if A+B does not overflow, but the test takes longer than the substraction A-N. Code: Line Code Comment Exemple of use : RCL A RCL B RCL N XEQ A returns (A+B)≡N in X and N in Last X (y z t contain rubbish) Modular multiplication Based on the fact that if you write : A = xk+y B = uk+u where k is a base number, I took k = (999 999 999 999)^0.5 = 1 000 000 Then A*B = (xk+y)*(uk+v) = xuk²+xvk+yuk+yv or better = k(xuk+xv+yu)+yv A*A = x²k²+xyk+xyk+y² = k(x²k+xy+xy)+y² Note that you can't use directly 2xyk as it sometimes overflows. The code is slightly more complex as it treats differently the case (AxB)≡N and (AxA)≡N for speed. Code: Line Code Comment Exemple of use : RCL A RCL B RCL N XEQ B returns (A*B)≡N in X and N in Last X (y z t contain rubbish) Modular exponentiation This one is the regular "right-to-left" modular exponentiation. Code: Line Code Comment Exemple of use : RCL A RCL B RCL N XEQ C returns (A^B)≡N in X (yzt and last x contain rubbish) Check if composite As explained here. Code: Line Code Comment Prime routine I used the bases shown here (thank you Albert Chan). Code: Line Code Comment Exemple of use : RCL N XEQ E shows P= N if N is Prime shows C= N if N is Composite the flags 1-2-3-4 show the status of the calculations (4 bases max) so you see where it is the flag 0 is used by the modular multiplication, it blinks so that you know it did not freeze :-) One could go slightly faster by storing the constants that are used several times in variables (like 1000000, 1 and 2). Adding brut force to find factors of for "small numbers" 1) I have also merged the "brut force" with the "MR" so that numbers smaller than 20 359 000 will be analysed by brut force, and greater by MR, because MR is slower than brut force for numbers smaller than 20 359 000. 2) When a number is found to be composite, it goes to brut force to find factors. When a factor is found, the quotient is sent back to MR to check if it is composite or prime, and so on. Brut force is however very slow to find factors if they are big. For example it takes only 34s for MR to say 999 999 998 479 is composite, but 2h30 for Brut Force to find its factors... Fred |
|||
04-13-2019, 06:24 PM
(This post was last modified: 10-09-2019 11:08 PM by Albert Chan.)
Post: #54
|
|||
|
|||
RE: [HP35s] Program for prime number (Wheel Sieve and Miller-Rabin)
(04-11-2019 03:18 PM)fred_76 Wrote: Modular multiplication MOD function is computational expensive. You can rearrange the formula to reduce MOD count per multiply from 4 to 3 A*B = (xk + y)*(uk − v) = (xk uk) − (y v) + (y uk − v xk) Base number must be powers of 10, otherwise MOD won't work. Similarly, IEEE double must pick 2^26 as base, sqrt(2^53-1) ~ 94906266 won't work. Since (2^26)^2 < 2^53-1, some adjustment is needed for huge IEEE double. This is my mulmod(a, b, n) Lua code: PHP Code: local function mulmod(a, b, n) -- a*b (mod n) Quote:Prime routine To cover *full* 53 bits IEEE double range, I use above link with 5 best bases. However, that does not quite reach 53 bits. One simple check pushed it over 53 bits Snippet from my isprime(n) PHP Code: -- Below good for full 53 bits (2^53-1 = 9007199254740991). Note that the huge numbers are represented *exactly* in binary. Also, adjustment (-4,-3,-291) must be negative, to avoid 53-bits overflow. lua> p = require 'nextprime' lua> x = 2^53-1 lua> for i=1,10 do x=p.prevprime(x); print(x) end 9007199254740881 9007199254740847 9007199254740761 9007199254740727 9007199254740677 9007199254740653 9007199254740649 9007199254740623 9007199254740613 9007199254740571 Edit: nextprime.lua in https://github.com/achan001/PrimePi |
|||
04-15-2019, 03:55 PM
(This post was last modified: 04-19-2019 05:46 PM by Albert Chan.)
Post: #55
|
|||
|
|||
RE: [HP35s] Program for prime number (Wheel Sieve and Miller-Rabin)
(04-11-2019 03:18 PM)fred_76 Wrote: Adding brut force to find factors of for "small numbers" If you have built "MR", there is no point doing "brute force". For example, I just created factor.lua, using Pollard's rho Algorithm. My code do 3 deltas for efficiency, but only 1 is really needed. Example, this is from my 7 years old laptop. lua> p = require 'factor' lua> n = 999999998479 lua> n, '=', table.concat(p.factor(n), ' * ') -- Lua 5.4 time ~ 1.8 msec 999999998479 = 999961 * 1000039 lua> n = 2^53-1 lua> n, '=', table.concat(p.factor(n), ' * ') -- Lua 5.4 time ~ 0.6 msec 9007199254740991 = 6361 * 69431 * 20394401 Edit: updated factor.lua by replacing MOD n for the delta, and use ABS instead. Speed up ~ 5% Note: Luajit does not work properly with this code. It uses the naive a % b = a - floor(b/a) * a This is my Floor-Mod patch for Luajit 1.18: https://github.com/LuaJIT/LuaJIT/issues/493 |
|||
08-22-2022, 10:25 AM
Post: #56
|
|||
|
|||
RE: [HP35s] Program for prime number (Wheel Sieve and Miller-Rabin)
My assertion in post #35 is false.
The largest small factor tested for is 199, plus all squares up to 999999^2, so the first input requiring a Rabin test is 211*223, ie 47,053 |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 6 Guest(s)