GC_10_237 splits as:

[CODE]prp91 factor: 1512377072986105793004196812647603257592302047201854599339358341182117713918227729923555823
prp91 factor: 7822173151770781861682077554423204567826632176976141792644026318725502158714722126226603209[/CODE]161 hrs to solve 15.35M matrix using target_density=80 -t 4 on Core-i5.

[QUOTE=RichD;369019]GC_10_237 splits as:

[CODE]prp91 factor: 1512377072986105793004196812647603257592302047201854599339358341182117713918227729923555823
prp91 factor: 7822173151770781861682077554423204567826632176976141792644026318725502158714722126226603209[/CODE]161 hrs to solve 15.35M matrix using target_density=80 -t 4 on Core-i5.[/QUOTE]Brilliant!

Paul

GW_5_339
 

Hi all, it has been a while since I have been postprocessing I would be keen to take GW_5_339. I think it will fit into 12 gig of RAM? If this is not the case could somebody please advise me. I will start to download of the .DAT file in about 16 or so hours. Monday 17th around 8:30 a.m. New Zealand daylight saving time If anybody can suggest a shorter running job I would be happy to take it instead of this one

GC_8_262
 

Just completed this composite after 130+ hours on my i7. Imagine my surprise when I go to report the results in factordb and find the number is already fully factored! Just one of those things I guess - someone helped out over the years and no one noticed. My fault too for not checking status before starting the post processing.

[code]
prp60 factor: 904076630073200973071845071612316104114727407128281752180859
prp141 factor: 606625086440938588570886913614578101130135357532683232001986727791754202704750890694263443026373641246753028278422941760796166329290826567827
[/code]


eta: I will take C176_118_93 next.

[QUOTE=swellman;369098]Just completed this composite after 130+ hours on my i7. Imagine my surprise when I go to report the results in factordb and find the number is already fully factored! Just one of those things I guess - someone helped out over the years and no one noticed. My fault too for not checking status before starting the post processing.

[code]
prp60 factor: 904076630073200973071845071612316104114727407128281752180859
prp141 factor: 606625086440938588570886913614578101130135357532683232001986727791754202704750890694263443026373641246753028278422941760796166329290826567827
[/code]
eta: I will take C176_118_93 next.[/QUOTE]
I always give credit to the first person who informs me of a factorization either directly (as in your mail earlier today) or indirectly (as when I happen across it as in your posting). No-one has informed me of the earlier discovery so, as far as I am concerned, you and NFS@Home and Rob Hooft are the discoverers. Rob has done a vast amount of ECM pre-testing, work which is still on-going, for the NFS@Home candidates and it's only fair that he gets his share of recognition.

Apologies to the earlier person(s) who completed the factorization but if you want your result to be known you need to tell the world about it in a manner which is attributable.


Paul

Taking F1893

[QUOTE=Speedy51;369069]Hi all, it has been a while since I have been postprocessing I would be keen to take GW_5_339. I think it will fit into 12 gig of RAM? If this is not the case could somebody please advise me. I will start to download of the .DAT file in about 16 or so hours. Monday 17th around 8:30 a.m. New Zealand daylight saving time If anybody can suggest a shorter running job I would be happy to take it instead of this one[/QUOTE]

Yes, that should fit fine in 12G; they're starting to be a bit of a squeeze on a well-used 8G machine (I had one run crash my desktop, which is an 8G iMac with a 2G virtual machine constantly active).

You might find that GW_3_497 is a bit quicker (I say this only because it has rather more relations, and we're on a cusp of matrix size vs relation count); remember '-nc1 target_density=112'.

[QUOTE=fivemack;369106]Yes, that should fit fine in 12G; they're starting to be a bit of a squeeze on a well-used 8G machine (I had one run crash my desktop, which is an 8G iMac with a 2G virtual machine constantly active).

You might find that GW_3_497 is a bit quicker (I say this only because it has rather more relations, and we're on a cusp of matrix size vs relation count); remember '-nc1 target_density=112'.[/QUOTE]
Thanks Five mack, can I please get GW_3_497 assigned to me and to give back GW_5_339. The reason I want to do this is because it sounds like GW_3_497 is going to run faster for me. I will start the download of GW_3_497 now

I see the problem. I did GC_8_262 as GW_8_262.

I can start the REAL GW_8_262 download tomorrow.

[QUOTE=swellman;369098]Just completed this composite after 130+ hours on my i7. Imagine my surprise when I go to report the results in factordb and find the number is already fully factored! Just one of those things I guess - someone helped out over the years and no one noticed. My fault too for not checking status before starting the post processing.

[code]
prp60 factor: 904076630073200973071845071612316104114727407128281752180859
prp141 factor: 606625086440938588570886913614578101130135357532683232001986727791754202704750890694263443026373641246753028278422941760796166329290826567827
[/code][/QUOTE]


[QUOTE=RichD;368880]GW_8_262 splits as:

[CODE]prp60 factor: 904076630073200973071845071612316104114727407128281752180859
prp141 factor: 606625086440938588570886913614578101130135357532683232001986727791754202704750890694263443026373641246753028278422941760796166329290826567827[/CODE][/QUOTE]

[QUOTE=RichD;369190]I see the problem. I did GC_8_262 as GW_8_262.

I can start the REAL GW_8_262 download tomorrow.[/QUOTE]

:max:

Wait - the mystery is solved! Happy ending.:tu:

All is well.

Another topic - seeking advice. When I start post processing C176_118_93, a 31 bit job, what target_density should I use? Typically I just use default values but maybe it's worth trying to tighten up the matrix a bit prior to LA? It's a pretty ugly poly with a terrible yield but best we could find.

Thanks in advance for any suggestions.

I tend to use target_density 112, if that doesn't work then 96, if that doesn't work then the default 70. The difference between 112 working and 70 working is often only about 5% of the total relation count.

What I don't quite understand is why I don't get a usable matrix, even with enormous over-sieving, at target densities 128 or over.