mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Aliquot sequence reservations (https://www.mersenneforum.org/showthread.php?t=11588)

 fivemack 2015-10-02 07:00

Dropping 138738 (2^4 * 7^2 * 17 * 31 * ECMed C124)
Dropping 171552 (2^2 * 3^2 * 7, ECMed C128)

 fivemack 2015-10-03 07:30

Dropping 440520 (2^5*3, ECMed C142)

 Sergiosi 2015-10-05 20:40

Reserving 953172

 Gimarel 2015-10-06 12:40

Dropping 115440, 115596

Taking 103656, 171888

 fivemack 2015-10-07 23:39

Taking 637032

 fivemack 2015-10-09 19:58

Dropping 100656 (2^2*7^2, ECMed C121)
Dropping 199002 (2^5*3^2, ECMed C125)

 Happy5214 2015-10-10 03:45

Releasing 414468, 462920, 471504, 498360, 499080

 nessalc 2015-10-13 01:38

I'll take 499080.

 fivemack 2015-10-14 21:00

Dropping 138960 (2^4*31, ECMed C121)

 kirvin 2015-10-17 16:28

Releasing 132600, 483282

Reserving 312330

 fivemack 2015-10-18 09:44

Dropping 920064 (141 digits, 2^2*7, ECMed C136)

 fivemack 2015-10-18 15:21

Dropping 156688 (2^2*5*7, ECMed C129)

 fivemack 2015-10-19 07:06

Dropping 756630 (2*3*5*C146); have run 20k @ 1e6 on the C146 but it would need more ECM

 Sergiosi 2015-10-23 21:45

Reserving 800922
Dropping 953172

 kirvin 2015-10-24 04:35

Dropping 312330
Reserving 963342

 Wick 2015-10-24 07:10

Releasing 998850 (141 fully ecm-ed)

 kirvin 2015-10-25 04:27

Reserving 239520
Dropping 963342

 ChristianB 2015-10-25 09:30

Dropping 806472 (size: 144, ECMed C136 cofactor)
Dropping 828600 (size: 117, ECMed C117 cofactor)

 fivemack 2015-10-25 19:43

Dropping 807834 (2^3*3, ECMed C122)

 fivemack 2015-10-26 23:10

Dropping 156174 (2^2*7, ECMed C123)

 yoyo 2015-10-30 18:43

There is now no sequence less then a size of 122, which isn't reserved. So I start reserving sequences with size of 122 now and run them until a size of 130 (or termination).

 LaurV 2015-10-31 06:43

[QUOTE=yoyo;414332]There is now no sequence less then a size of 122, which isn't reserved. So I start reserving sequences with size of 122 now and run them until a size of 130 (or termination).[/QUOTE]
(technically this is false :razz:, 319860 is at 41 digits and not reserved, but this sequence seems it is broken in the data base at 118 digits)
([URL="http://factordb.com/sequences.php?se=1&aq=2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538&action=last20"]link to the continuation[/URL] of it)

 Sergiosi 2015-10-31 07:44

Reserving 303996

 LaurV 2015-10-31 08:03

[QUOTE=LaurV;414390]319860 is at 41 digits[/QUOTE]
121 digits :redface:
don't know how 41 got in :blush:

 yoyo 2015-10-31 08:17

[QUOTE=LaurV;414390](technically this is false :razz:, 319860 is at 41 digits and not reserved, but this sequence seems it is broken in the data base at 118 digits)
([URL="http://factordb.com/sequences.php?se=1&aq=2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538&action=last20"]link to the continuation[/URL] of it)[/QUOTE]

Ok, Ok, I'll take this also :)

 ChristianB 2015-10-31 10:16

@LaurV: you reserved the number by accident please drop it so yoyo can reserve it again

@yoyo: please reserve the number here because the reservations script can't handle broken sequences in your ali.txt.all file

 LaurV 2015-10-31 10:27

Unreserving 319860

Unreserving 2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538

:razz:

(Ha! did the script got upset by a line in my former post starting with "t"? I was afraid about that, but I thought it was fixed, and only when the full words like taking/reserving/dropping/unreserving are used, action is taken...)

 yoyo 2015-10-31 10:57

reserving 319860

reserving 2825523558447041736665230216235917892232717165769067317116537832686621082273062400083298623866666431871912457614030538

 ChristianB 2015-10-31 11:07

You were using the number and the word "reserved" in the same line and that got picked up by the script (I think).

A bit further explanation: broken sequences are shown in the table with the correct size, index, known factors and everything else as if it was not broken. Only the links behind sequence and index point to the broken sequence and not the continuation. This can be reached through the links to the continuations on the top of the table.

 fivemack 2015-11-01 18:25

Dropping 114408 (2^2*5*7, ECMed C126)

 fivemack 2015-11-02 08:00

Dropping 637032 (2^3*3, ECMed C129)

 fivemack 2015-11-02 08:04

Taking 352440 558600 889800 897930

 kirvin 2015-11-05 19:06

Reserving 71028
Releasing 239520 (2^3*3^2*5, ECMed C131)

 yoyo 2015-11-05 21:38

I have now much more user in yafu@home, so I have more then 900 Sequences reserved.
Maybe I will reserve more :)

yoyo

 Gimarel 2015-11-06 07:51

Taking 628656

 fivemack 2015-11-06 08:36

Dropping 638766 (2^6*127, ECMed C139)

 unconnected 2015-11-06 14:13

Dropping 135294.
Dropping 960132 (2401 lines were added).

 kirvin 2015-11-08 03:00

Dropping 71028 (2^7*3, ECMed C121)
Taking 306390

 Sergiosi 2015-11-08 12:11

Taking 263424

 kirvin 2015-11-12 05:08

Taking 68880

 fivemack 2015-11-13 00:00

Dropping 127896 (2 * 3^2 * 167; C143, has survived 20k@1e6 ECM)

 Dubslow 2015-11-13 00:04

[QUOTE=yoyo;415068]I have now much more user in yafu@home, so I have more then 900 Sequences reserved.
Maybe I will reserve more :)

yoyo[/QUOTE]

I can tell no one with the right privileges has tried running the script recently. I just got this error while testing:

[code]18:00:53 Wrote 2063 seqs
18:00:53 Error: 704 seqs couldn't fit into the posts
[/code]

We need another ~3 posts to fit all your reservations!

 LaurV 2015-11-13 02:27

[QUOTE=Dubslow;415981]We need another ~3 posts to fit all your reservations!
Disclaimer: this is not a complaint! [/QUOTE]
Fixed that for you :razz:

 Dubslow 2015-11-13 06:59

[QUOTE=LaurV;415989]Fixed that for you :razz:[/QUOTE]

:smile:

 kirvin 2015-11-14 23:15

Dropping 306390 (2^3*3*5^3, ECMed C116)
Taking 862728

 Happy5214 2015-11-17 11:45

Reserving 243102 542040 292788 688266 727596 841170 527694

 kirvin 2015-11-17 21:57

Dropping 68880
Reserving 964700

 henryzz 2015-11-18 23:03

yoyo@home just reserved over 1000 sequences. To fit them in I had to add 3 more posts. Anything that reads the first few posts will need to be updated. The new post ids are (165249, 397318, 397319, 397320, 397912,416583,416585,416586).

 Gimarel 2015-11-20 05:10

Dropping 295398
Taking 620826

 Happy5214 2015-11-20 08:36

Releasing 243102 542040

 yoyo 2015-11-20 21:14

[QUOTE=henryzz;416587]yoyo@home just reserved over 1000 sequences.[/QUOTE]

There were many hosts requesting new work :D.

 henryzz 2015-11-20 22:20

[QUOTE=yoyo;416739]There were many hosts requesting new work :D.[/QUOTE]

Warning if you think we will go beyond the size of the posts would be useful.

 henryzz 2015-11-20 23:31

[QUOTE=henryzz;416587]yoyo@home just reserved over 1000 sequences. To fit them in I had to add 3 more posts. Anything that reads the first few posts will need to be updated. The new post ids are (165249, 397318, 397319, 397320, 397912,416583,416585,416586).[/QUOTE]

Whoops confused the script with this one.

 Dubslow 2015-11-21 04:23

[QUOTE=henryzz;416749]Warning if you think we will go beyond the size of the posts would be useful.[/QUOTE]

I think he did warn us (post 1191!) :razz: but no one was updating the head post back then...

[QUOTE=henryzz;416754]Whoops confused the script with this one.[/QUOTE]

How do you mean? Something I need to fix?

 henryzz 2015-11-21 07:16

[QUOTE=Dubslow;416761]I think he did warn us (post 1191!) :razz: but no one was updating the head post back then...

How do you mean? Something I need to fix?[/QUOTE]

Just me adding sequences that don't exist. It didn't actually add them although they made it into the reason for editing.

 unconnected 2015-11-23 08:37

Taking 665142.

 kirvin 2015-11-23 22:59

Dropping 964700
Taking 559176

 Happy5214 2015-11-25 12:21

Releasing 292788 688266 841170

 unconnected 2015-11-27 00:41

Taking 226092.

 Happy5214 2015-11-27 08:53

Releasing 527694 727596

 Dubslow 2015-11-29 14:49

Reserving 434760!

 henryzz 2015-11-30 07:29

[QUOTE=Dubslow;417625]Here's an idea for a new subproject: the "standard" D5 is $2^5\cdot3\cdot7$ with class 0, but in fact $\sigma(2^6-1) = 3^2 \cdot 7$, so if a sequence mutates to $2^5 \cdot 3^2 \cdot 7$, then the $3^2$ is guaranteed to stay, so that the guide has class 2. We could target these for the subproject.[/QUOTE]
As far as I can tell there are 7 of them.
reserving one of them 696582

 Dubslow 2015-12-02 06:14

Dropping 434760

 henryzz 2015-12-02 19:30

[QUOTE=henryzz;417736]As far as I can tell there are 7 of them.
reserving one of them 696582[/QUOTE]
Strike 1
After rising 8 digits it is now on 2^7*3^2*5.
It is now stuck on a c128 with a full t40
releasing 696582

Looking at it now I wonder where I got the number 7 from there are many more.

reserving 888144

 Gimarel 2015-12-03 13:12

Dropping 213486 628656

 unconnected 2015-12-03 13:34

Dropping 665142 and 226092.

 Alfred 2015-12-03 14:41

1 Attachment(s)
Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.

PS: The siever was gnfs-lasieve4i15e

Alfred

 LaurV 2015-12-04 03:09

[QUOTE=Alfred;418116]Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.
[/QUOTE]
a. It is normal to "take a while", for a C163.
b. you can not "optimize the parameters" of a poly you already have (I didn't look into the files, but it seems to be a poly, from the extension of the file names). However, you may find a better poly, if you search longer.
c. you can request a poly (better or not than the one you already have, depends on your luck, you may have hit a very good poly already) in the "request polys" thread, here around. Some people have "dedicated" hardware and are able to get very good polys very fast. You just specify the number, and where it is coming from (like "C163 from aliquot xxxxx") and someone may take up the challenge to find the best poly. The "where it comes from" is necessary because we don't try to factor encryption keys for gaming sites, etc.

 Dubslow 2015-12-04 06:39

[QUOTE=LaurV;418162]
b. you can not "optimize the parameters" of a poly you already have (I didn't look into the files, but it seems to be a poly, from the extension of the file names). However, you may find a better poly, if you search longer.[/QUOTE]

:huh:

...uh, yeah you can. The siever, factor base bounds, large prime sizes, large prime counts, whatever those lambda things are... there's a whole bunch of things to tweak with a given polynomial.

 VBCurtis 2015-12-04 08:26

[QUOTE=Alfred;418116]Since sieving at the c163 of 30450:808 took a while, I would like to get some help on optimizing the parameters.

PS: The siever was gnfs-lasieve4i15e

Alfred[/QUOTE]
Alfred-
The .poly file does not list the E-score for a polynomial by default, but your msieve log file will list the score. If you could post that, I can help you determine how much of your "took a while" was due to an insufficient poly-search phase, and how much was due to parameters being suboptimal.

I've been posting recently about how a number this size is likely faster with lpbr and lpba at 32 rather than 31 when running with the 14e siever. Going up a siever rather than up a large-prime-bound (lpb) also results in improved yield, at the cost of higher time per relation (sec/rel). 15e/30 isn't that weird, but I think 15e/31 or 14e/32 are faster by something like 10-20% of project length.

I would have run this with 14e siever, lpbr/lpba at 32, mfbr/mfba at the usual 2*lbpr/lbpa (64, in my case, though 31 and 62 would be roughly equal in project-length, I think), and alim = rlim = something around 45 or 50M. I would sieve from q = 10M to something like 60/65M, and expect a matrix to build with the filtering flag of target_density=90 (or 84 or 96 or 100, but not 70 because the matrix is too big and takes too long to solve). Given use of 15e siever, 31/62 bounds is probly faster than 32/64.

I don't think the lambdas need be messed with for individual-sized projects; I use 2.6 also, though for a C166 I may try 3.6 for alambda to see what happens.

My current C165 has a poly score of 6.67e-13, and Gimarel posted a poly for my next C166 at 6.46e-13. Scores drop 12-15% per digit usually, so I think a C163 should have a score above 8.0e-13. If your poly has a score down in the 6e-13 range, your factorization had the difficulty of a C165/166 with a good poly, 20-40% tougher than it should have been.

How many raw relations did it take to build a matrix? (at what target-density did you have it build?) I've never run a 30-bit project for a number this big, curious how relations scales.

 VBCurtis 2015-12-04 08:38

[QUOTE=Dubslow;418177]:huh:

...uh, yeah you can. The siever, factor base bounds, large prime sizes, large prime counts, whatever those lambda things are... there's a whole bunch of things to tweak with a given polynomial.[/QUOTE]

This. GNFS just works without worrying much about parameters for projects in the 130-140 digit length, while parameter choice can start to save useful time in the 140-150 digit length. I took to heart Jason's advice to "turn the knobs" on a handful of ~140 digit factorizations before trying something in the 150s, and then did 3 in the 150s before my current dabble in the 160s. An iffy parameter choice at 140 digits might take 35 hrs instead of 25, but it stinks when a C163 takes 6 quad-core-weeks instead of 4!

That really low alim Alfred has might be what caused it to "take a while." Skew is higher than I'd like, but I don't have a good idea of how that influences yield; I don't do poly searches with a1 under 10,000 to reduce the chance of a wonky poly that looks good on a quick test-sieve but yields lower than desired.

Alfred, can you also post what your yield was at a couple of different q's? Specifically, the number of relations found for a block of 10k or larger q, such as "at q = 10M, a 100k block of q yielded 240,000 relations."

 Alfred 2015-12-04 12:05

[CODE]c. you can request a poly (better or not than the one you already have, depends on your luck, you may have hit a very good poly already) in the "request polys" thread, here around. Some people have "dedicated" hardware and are able to get very good polys very fast. You just specify the number, and where it is coming from (like "C163 from aliquot xxxxx") and someone may take up the challenge to find the best poly. The "where it comes from" is necessary because we don't try to factor encryption keys for gaming sites, etc.[/CODE]

@LaurV

This is a very time saving offering. Thank you.
My knowledge (in order to find good polynomials is poor) my hardware is very poor.

Alfred

 Alfred 2015-12-04 13:04

2 Attachment(s)
@ VBCurtis

[QUOTE]The .poly file does not list the E-score for a polynomial by default, but your msieve log file will list the score. If you could post that, I can help you determine how much of your "took a while" was due to an insufficient poly-search phase, and how much was due to parameters being suboptimal.[/QUOTE]

Two log files are attached.
None of these files is the complete log file - I've lost it.
But I think that I needed ~ 88 M relations (with duplicates).

[QUOTE]I've been posting recently about how a number this size is likely faster with lpbr and lpba at 32 rather than 31 when running with the 14e siever. Going up a siever rather than up a large-prime-bound (lpb) also results in improved yield, at the cost of higher time per relation (sec/rel). 15e/30 isn't that weird, but I think 15e/31 or 14e/32 are faster by something like 10-20% of project length.[/QUOTE]

I sieved a short q-range with the 14e and the same poly-file as for the 15e - not optimally.
Due to your advice the next time I can use better parameters.

[QUOTE]How many raw relations did it take to build a matrix? (at what target-density did you have it build?) I've never run a 30-bit project for a number this big, curious how relations scales.[/QUOTE]

I needed nearly 88 M raw relations to build a matrix with target-density 70.

 Alfred 2015-12-04 14:07

[QUOTE]Originally posted by VBCurtis

Alfred, can you also post what your yield was at a couple of different q's? Specifically, the number of relations found for a block of 10k or larger q, such as "at q = 10M, a 100k block of q yielded 240,000 relations."[/QUOTE]

I changed the parameters to values you suggested:

rlim: staying 41500000
alim: from 21049999 to 41500000
lpbr: from 30 to 31
lpba: from 30 to 31
mfbr: from 30 to 62
mfba: from 30 to 62
rlambda: staying 2.6
alambda: staying 2.6

Testing these parameters with the 15e siever

with "gnfs-lasieve4i15e -R -v -f 30000000 -c 10000 -o 30450.out -a 30450.poly"

I get ~ 0.0543 sec/rel, yielding more than 56k rel.

The next time I'll ask before starting the sieve job.

 VBCurtis 2015-12-04 17:31

Alfred-
No, it's not a doubling of the project time, because the number of relations needed to build a matrix jumps by approximately 75% for each step of lpba/lpbr you go up. You needed 88M raw relations (raw = including duplicates) for 30LP; I believe you would need 150 to 155M for 31LP, but the relations come twice as quickly. So the time savings for my suggested parameters might save you 13-15% of time (1.75x as many relations, divided by 2x speed = 0.87ish). I put a range, because we don't know precisely how many relations will be required to build a matrix.

The score I requested is the "combined" number at the end of the poly in the log. 9.4e-13 is not a bad poly.

The siever does not process q less than alim, so you'll see a message "reducing alim to 29999999" for the test-sieve line you wrote with q = 30m, This is not a permanent change; as q rises, the siever's treatment of alim also rises (though it resets only each time it is called, so if you sieved say a 5M block of q for a week, alim remains fixed during that time).

Your yield with my params is 5.6 (56000 rels divided by -c of 10000), which is pretty high. That suggests it was 2.6 to 2.8 with your parameters, which is well within "reasonable" range. I don't think your choices were very bad, a C163 just takes a while ("a" in LaurV's response). Yields under 2.0 generally mean you should change parameters and start over, but 2.7 does *not* tell you that.
If your test-sieve is representative of the whole region, I think my parameter suggestions would lead to a q-range of (155M / 5.6) = 27M or 28M; say,q from 25M to 53M. If I'm estimating correctly, you needed (88M/2.7) = 32M or 33M range of special q. Again, not a huge difference, nor one to suggest you should regret your choices.

 Alfred 2015-12-04 18:48

@VBCurtis

My sieving range was q=21M to 56M.

I've learned a lot.

 VBCurtis 2015-12-04 21:01

You're welcome, sir. I see threads like this as a chance for me to put into words what I think I've learned from 2 years of knob-turning (tinkering with parameters and the factmsieve.py script). I enjoy doing so, not least because quite often one of the true experts corrects my beliefs, and everyone gains.

One more idea for you: I found better results by starting the sieve region at alim/3 rather than alim/2 (the default in the script). This change reduces the frequency of going up into q's where yield (and sec/rel) fall off badly. On some factorizations it makes no difference, but on poor-yielding polys where the sieve has to go well above alim, the range from alim/3 to alim/2 is usually more fertile than the range from (for instance) 1.3*alim to 1.5*alim. In your case, supposing alim = rlim = 42M, I would aim for 14M to 49M rather than 21M to 56M. I think 14M to 21M is more efficient than 49M to 56M, but this varies *a lot* from job to job.

 Happy5214 2015-12-06 16:01

Releasing 236840 856530 933564 570996 93000

 Happy5214 2015-12-08 14:45

Releasing 761516 832314

 Dubslow 2015-12-10 04:39

Taking 541458

 kirvin 2015-12-10 17:16

Taking 721386
Releasing 862728

 kirvin 2015-12-11 07:32

Taking 59430
Releasing 559176

 Happy5214 2015-12-11 10:22

Releasing 701784 693120 913920 282168 27570

 Sergiosi 2015-12-11 15:50

Taking 621036
Releasing 800922 303996

 Dubslow 2015-12-11 19:24

Dropping 541458

Taking 524814

 Dubslow 2015-12-13 08:53

Dropping 524814

Taking 81192

 Happy5214 2015-12-19 17:38

Releasing 416250 803598

 Happy5214 2015-12-19 18:09

Releasing 727596

 Sergiosi 2015-12-21 09:53

Releasing 263424
Taking 956840

 Gimarel 2015-12-21 12:01

Dropping 246648 465750

 Happy5214 2015-12-22 20:55

Releasing 822432 897960

 unconnected 2015-12-23 06:43

Reserving 329490.

 Drdmitry 2015-12-23 18:43

Reserving 70884

 Dubslow 2015-12-24 07:56

Dropping 81192

Taking 790308 920976 518628 435420 337860 977160 127848 456372 362880 379272 136500 246708 958704 898752 211812 417726 to 130 digits

 yoyo 2015-12-24 09:09

[QUOTE=Dubslow;420057]Dropping 81192

Taking 790308 920976 518628 435420 337860 977160 127848 456372 362880 379272 136500 246708 958704 898752 211812 417726 to 130 digits[/QUOTE]

According to our frequently updated reservation page: [url]https://www.rechenkraft.net/aliquot/AllSeq.html[/url]

[QUOTE]
Warning: seq 920976 is owned by yoyo@home but is trying to be reserved by Dubslow!
Warning: seq 337860 is owned by Happy5214 but is trying to be reserved by Dubslow!
Warning: seq 211812 is owned by yoyo@home but is trying to be reserved by Dubslow![/QUOTE]

 Dubslow 2015-12-24 11:08

[QUOTE=yoyo;420064]According to our frequently updated reservation page: [url]https://www.rechenkraft.net/aliquot/AllSeq.html[/url][/QUOTE]

Whoops! I used the same tools to scrape the [URL="http://mersenneforum.org/showpost.php?p=417625&postcount=1219"]sequences of interest[/URL], and completely forgot to check for reservations :smile: I'll not step on your toes.

 henryzz 2015-12-26 17:55

dropping 888144
[URL="http://factordb.com/sequences.php?se=1&aq=888144&action=last20&fr=0&to=100"]888144[/URL] currently 2^5*3^2*7*13 which seems very stable. I have ecmed the c144 to around t44.
I would love to see this one picked up and continued as I would love to see it lose this guide. It is rising quickly if anyone wants to set a PB for largest sequence. This is the largest I have taken a sequence.

reserving 672834 to replace it

All times are UTC. The time now is 21:37.