I'll take [B]1900421426047_19_minus1[/B] and [B]GW_9_257[/B] next (when they complete sieving).

[QUOTE=xilman;408676]Bob: here is a challenge for you. Create a file containing the requisite data and I'll happily cut and paste it into the NFS@Home management page for you.

To get you started, you should be able to work out the format of the data required from this portion of what I put in the queue recently.

[code]245.84 GW_4_404 C234

n: 182663290085714596372021721458859683719140136581935284808903062213888627336770619920223260688617050448274127075762175128041513974064310499694053658089367491687543401766045426285765895242734291894712743140114971423517933893391959045459
m: 43556142965880123323311949751266331066368
c6: 101
c0: -1
skew: 0.463389765542633
type: snfs
rlim: 134217727
alim: 134217727
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6

247.65 GW_9_257 C179

n: 14978168706446814773960602413293886719582246766318673163022584571105025810085697492025404992929933355006878238320348636403237469028987526117998884954980764760575821006409605467021
m: 35917545547686059365808220080151141317043
c6: 20817
c0: -1
skew: 0.190661779880819
type: snfs
rlim: 134217727
alim: 134217727
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6
[/code]

Yes, I could easily do it myself but that's not the point. If you have any question about the information above there are a number of people who will be willing to help you.[/QUOTE]

I merely need a definition for the inputs.

[QUOTE=Dubslow;408645]I lurk here, though don't follow very closely. Is there an extra need for LA workers?

I can pitch in with a i7-2600K, though the smaller the better since it's my everyday desktop. What are the priority numbers/sievers, and where do I download the work?[/QUOTE]

Not sure if you got an answer to this, but you can view the status of the NFS@Home project [url=http://escatter11.fullerton.edu/nfs/]here[/url]. Stick with the 14e siever queue for now.

Contact Greg (frmky) for download credentials.

[QUOTE=R.D. Silverman;408679]I merely need a definition for the inputs.[/QUOTE]I'm disappointed. I thought you were capable of taking a reasoned estimation of what might be required, then to make your best attempt at satisfiying the requirements, then subsequently posting the result. As I wrote, there are a number of people here who are willing to provide guidance.

Once more: treat it as a challenge. You may find the result helpful, in more ways than one.

[QUOTE=xilman;408690]I'm disappointed. I thought you were capable of taking a reasoned estimation of what might be required, then to make your best attempt at satisfiying the requirements, then subsequently posting the result. As I wrote, there are a number of people here who are willing to provide guidance.

Once more: treat it as a challenge. You may find the result helpful, in more ways than one.[/QUOTE]

Yes, I know quite a few of them. However, just to cite one ambiguity, skew can be either c_0/c_max or c_max/c_0.
lambda could be a tolerance limit (as an exponent) for the size of the cofactor, (i.e. accept max_prime^lambda)
lpbr is clear, but mpbr is not.

[QUOTE=R.D. Silverman;408702]Yes, I know quite a few of them. However, just to cite one ambiguity, skew can be either c_0/c_max or c_max/c_0.
[QUOTE]

This can be inferred because the given values are < 1.

However, since all coefficients are part of the inputs, skew can be computed by the code. Why does it need to be an input?

ggnfs-lasieve4I1?e wants the skew inside the poly file, otherwise it errors out quickly. It does not attempt to compute it, AFAICT from that externally visible behaviour.
Forgetting to add the skew was the cause of at least one faulty batch of WUs I entered into RSALS and/or NFS@Home.

[QUOTE=swellman;408608]I'll reserve C216_119_108 for post-processing once sieving is complete.

Batalov - I will try your suggestion once a machine frees up during the next few days. Do you think my problems with remdups were just a one off?[/QUOTE]
Yes, I suspect there may have been some weird one-off circumstance that throws the program off. Because you already have the dataset on which it fails it is best to test in situ. ((in other words:) I am too lazy to fetch the same set to my computer too. :rolleyes:)

In the context of a DC project, if someone's computer sent a nonsensical file (e.g. gzipped twice, or even worse totally random file without linebreaks or a file which is \000 for the full length and then gzipped) and then this "random" file was concatenated with all other results, then you might have a buffer overflow or some other unexpected behavior at an essentially random point. If a very long line will be found then we can have a look how to bullet-proof remdupss some more (replace naked fgets with more sanity checks). Also, it would be good to know which remdups was used.

Please reserve [B]132^101+101^132[/B] and [B]GW_404[/B] for me if possible.
Thanks.

11159_61_minus1 factored
 

134 hrs (est. - power outage) to solve a 13.5M matrix on Core-i5 -t 4 with TD=112 (116 failed).
[CODE]prp97 factor: 1381818572242852792505948402006473117141054337356583454126722384661316916804380823814907072419131
prp147 factor: 521320196063707031803547109157978246715438560964046195646536177959722251432888727849295645492230346113761942953534588653809599258113056246109539971[/CODE]

9311_61_minus1 factored
 

64 hours (est. - power outage) to solve a 9.2M matrix on Core-i5 -t 4 with TD=120.
[CODE]prp62 factor: 15562034025195626664427142318328097228297893759036861965176097
prp177 factor: 886665650187557617382648552682178463453642130398093481279870288278263526398909389213754213904944807710056365875569913684169251433674959511236206124659572741320462587025699089313[/CODE]