Reserved 769_79_minus1 for you, and cleaned up the C158. Thanks :smile:

[QUOTE=Dubslow;301251]Thanks guys. I have my own plans for remdups4, if I ever get CUDALucas debugged :yucky:[/QUOTE]

[OT]
:smile:

Finished my plans and debugged CUDALucas literally in the same 30 seconds. The solution to the last bug of my modifications to remdups4.c presented itself literally 10 seconds before I read kjaget's delightful post over in the CUDALucas thread. What a wonderful morning it has been :smile:

[code]/* remdups4.c
By Greg Childers
This is a standalone one-pass duplicate relations remover;
only syntax (a,b:<csv-of-factors>:<csv-of-factors>) is checked and incomplete lines are discarded;
validity of relations is not tested (nor is polynomial needed).
Hashing of (a,b) values was changed to accomodate for gnfs projects with huge skews (S. Batalov).
Verbose mode was added (Lionel Debroux)
Made remdups4() a standalone, like Msieve; main() can also now accept a filename as an arg (Bill Winslow)

This version is a filter (stdin, stdout):
you may redirect stdout to /dev/null and/or
you may use many input relation files (or pipe from zcat, bzcat).
However, this needs porting for Windows (use remdups.c instead or get CygWin).

Alternately, you may now pass an optional 'filename' as an argument:
In such case, this will move the 'filename' to '.filename.tmp' and filter the
unique rels back to 'filename' (and the tmp will be deleted). DIM is optional
with a filename; if not provided, this will count the lines (assumed to be
roughly the number of rels) in 'filename' and choose a near-optimal DIM.
(Still needs porting to Windows, especially the line counting function.)

No makefile needed:
cc -O3 -o remdups4 remdups4.c

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 3
of the License, or (at your option) any later version.

You should have received a copy of the GNU General Public License along
with this program; see the file COPYING. If not, write to the Free
Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
*/

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

static int strccnt(const char *s, int c)
{
const unsigned char *us = (const unsigned char *) s;
const unsigned char uc = c;
int n = 0;
if (!uc) return 1;
while (*us) if (*us++ == uc) n++;
return n;
}

int remdups4(int DIM, FILE* in_stream, FILE* out_stream, FILE* badfile, int verbose) {[/code]

View full code [url=http://dubslow.tk/random/remdups4.c.txt]here[/url].
[/OT]

debrouxl, do you want me to continue to throw the larger numbers from my sequence at RSALS? The lines are currently at sz 167, although they're almost at the threshold of 166.

[QUOTE=Dubslow;301251]
M. Debroux, if you don't mind, I think I'd like to attempt a 30-bit LA job, 769^79-1. [/QUOTE]

Piece of cake. The mem usage was about the same as the GNFS158 (1.5GB) and took less around two days to finish.

[code]PRP106 = 3894423628520048539514782988734170351471819418391430202426078611425004941707892301430112800316090416267201
PRP78 = 371666121786353422200164642350909673584726802611512620011623749482444648771729[/code]Submitted to FDB.



debrouxl, do you want me to continue to throw the larger composites from my sequence at RSALS?

Thanks for the post-processing help :smile:

[quote]debrouxl, do you want me to continue to throw the larger composites from my sequence at RSALS?[/quote]
Oops, forgot to reply...
Yeah, sure, provided (as usual) that the number has received sufficient ECM treatment, and a decent polynomial has been found :smile:

Reserving 797_73_minus1

I would like to reserve 22223_224

[QUOTE=jrk;301562]Reserving 797_73_minus1[/QUOTE]
Done. Factors are in the gratuitous OPN factors thread.

[QUOTE=Mathew;301780]I would like to reserve 22223_224[/QUOTE]

Complete
[CODE]prp57 factor: 331002594598132649474533055207122930615109963303568003781
prp160 factor: 3054082779120619915895872815908901627863574297361398667184559561582134492905196565775771303474198133736770160808730853622202404234958531689390097196324475734187[/CODE]

@Mathew: I updated the page and reported the factorization yesterday :smile:

As I cannot easily post-process 30-bit and 31-bit LPs tasks, and 29-bit LPs tasks are almost being sieved faster than I can cope with them, unprocessed relations tend to be stockpiling. We'd need even more people to lend a hand clearing the queue, thanks in advance :smile:

Has there been a surge in clients attached to the project?

What's the memory requirement for the 30 bit large prime jobs?

[QUOTE=debrouxl;302154]@Mathew: I updated the page and reported the factorization yesterday :smile:

As I cannot easily post-process 30-bit and 31-bit LPs tasks, and 29-bit LPs tasks are almost being sieved faster than I can cope with them, unprocessed relations tend to be stockpiling. We'd need even more people to lend a hand clearing the queue, thanks in advance :smile:[/QUOTE]

The 31-bit jobs all seem to be spoken for; shall I take 1871,73- ?