[QUOTE=RichD;451624]Another one apparently missed is this [URL=http://www.mersenneforum.org/showthread.php?t=20024&page=784"]post[/URL]. Plus, one of the "n" numbers is wrong.[/QUOTE]

I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.

[QUOTE=swellman;451627]I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.[/QUOTE]

The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.

[QUOTE=RichD;451628]The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.[/QUOTE]

Indeed, the n is the old incorrect value in the poly and ini files for C187_141_61 on 15e. It should be

[code]
5084489050566775179592003313348801937179533477099429174053297255387060223505309107949313623243535576335735180641443792678300621272851343104861268721864517835102764733898119986107069118573
[/code]

The matter was discussed [url=http://www.mersenneforum.org/showpost.php?p=450489&postcount=853]here[/url]. The correction was never implemented when it was enqueued.

Can a gatekeeper please make the correction for C187_141_61? Thanks.

This OPN is ready and comes from the [URL=http://www.lirmm.fr/~ochem/opn/t490.txt]t490[/URL] file.

63601^47-1 (C190) SNFS-231

C150
 

If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:
[CODE]n: 186268686335827877320004854432051878822128838126242537957264027670795037255662305248760790177888122105986774051056721859678174962268961805642675348313
c5: 4296600
c4: -2917007031510
c3: -4790076774663310507
c2: 1670064884437700063934274
c1: 554651519036985580252614263896
c0: 35031679686473547988714210631764400
Y1: 481307053823461
Y0: -33682396687270334451539720481
skew: 542112.99
rlim: 20800000
alim: 10399999
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
[/CODE]

Everything after skew was set automatically based on the factmsieve.py choices.

better E score for c150
 

@wombatman
After CADO optimization:
[code]
Y0: -33682396661918448005496559228
Y1: 481307053823461
c0: 24457818467628788035786542630926349
c1: 386035412486131568983076678246
c2: 870862274534921302685050
c3: -5285460019326801427
c4: -1785432972510
c5: 4296600
skew: 484727.35042
# alpha -6.66, 5 real roots
# MurphyE=5.80851238e-12
[/code]

[QUOTE=wombatman;451760]If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:
[/QUOTE]

My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?

A C150 is in the vicinity of 60 Ghz-days, under a week for a quad-core. If I had a vote, I'd set 158 as the bottom for GNFS.

[QUOTE=jyb;451903]My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?[/QUOTE]

No worries. I figured I would ask and see what the bottom limit was. I'll go ahead and start it on personal hardware! Thanks for the consideration :smile:

C197_148_45 looks like a good 14e candidate and it has seen a full t55, but it's yield is not great unless 32-bit LP is used in sieving (or 31-bit and lots of patience). Otherwise it's an easy 15e/31 job. I'm not a fan of 14e/32 jobs but they are doable. I'll sign up to postprocess it regardless of siever used.

Otherwise the next unequivocal 14e candidate for the xyyx project is 2-3 weeks away.

The old "feed the grid or use it most efficiently" quandry.

(I'll have post the poly tomorrow. I don't have access to my files tonight.)

I have a few OPNs to keep the grid going. These are not as significant as others because they all come from the t800 file. Perhaps keep these on the back shelf and when one is needed, queue it right before the grid runs dry. Feel free to add other numbers before these when applicable. These are about SNFS-235 +/-.

P40.15461_7M.C186
1546180993982253931724756630608282852337^7-1
P40.12838_7M.C181
1283810768507270931382867729773882314783^7-1
P39.83661_7M.C179
836611965227956085219418549834729037351^7-1