CADO NFS

[akruppa]

The GNU tar format changed in version 1.13, I put an archive in the old format at http://www.loria.fr/~kruppaal/cado-nfs-r2150.oldtar.gz

Alex

[frmky]

I put together this sequence of operations to use the CADO binaries. The parameters below came from the c59 example, and therefore are probably not appropriate for larger numbers. Starting with a polynomial in snfs.poly and a pile of relations in snfs.dat, do the following:

../bin/sieve/makefb -poly snfs.poly > snfs.roots
../bin/sieve/freerel -poly snfs.poly -fb snfs.roots > snfs.freerels
../verify snfs.dat snfs.rels
../bin/merge/duplicates -nrels "$( wc -l snfs.dat)" -out ./snfs.nodup.gz snfs.freerels snfs.rels 1> /dev/null
../bin/merge/purge -poly snfs.poly -nrels "$( zcat snfs.nodup.gz | wc -l)" -out snfs.purged snfs.nodup.gz 
../bin/merge/merge -out snfs.merge.his -mat snfs.purged -forbw 1 -keep 160 -maxlevel 15 -cwmax 200 -rwmax 200 -ratio 1.5 
../bin/merge/replay -his snfs.merge.his -index snfs.index -purged snfs.purged -out snfs.small -costmin "$( tail -n 1 snfs.merge.his | sed 's/BWCOSTMIN: //')"
../bin/linalg/bwc/bwc.pl :complete seed=1 thr=2x2 mpi=1x1 matrix=snfs.small nullspace=left mm_impl=sliced interleaving=0 interval=100 mode=u64 mn=64 splits=0,64 ys=0..64 wdir=bwc 
../bin/linalg/apply_perm --perm bwc/mat.row_perm --in bwc/W.twisted --out W.bin
xxd -c 8 -ps W.bin > snfs.W
../bin/linalg/mkbitstrings snfs.W > snfs.ker_raw 
../bin/linalg/characters -poly snfs.poly -purged snfs.purged -ker snfs.ker_raw -index snfs.index -rel snfs.nodup.gz -small snfs.small -nker 64 -skip 32 -nchar 50 -out snfs.ker 
../bin/sqrt/allsqrt snfs.nodup.gz snfs.purged snfs.index snfs.ker snfs.poly 0 10 ar snfs.dep 
../bin/sqrt/algsqrt snfs.dep.alg.000 snfs.dep.rat.000 snfs.poly 1>> snfs.fact
../bin/sqrt/algsqrt snfs.dep.alg.001 snfs.dep.rat.001 snfs.poly 1>> snfs.fact

verify is a program that eliminates free relations added by msieve and removes obviously bad relations. I'm surprised that duplicates doesn't verify the relations as it looks for duplicates and removes bad ones. That seems like something useful to add. The source for verify is attached.

The 10 in the arguments of allsqrt can be increased to prep more dependencies for algsqrt. Likewise, run as many algsqrt's as necessary to get the factors.

Having said all of this, it worked for a small example but when I tried a larger example, all of the algsqrt's failed with "condition (nab & 1) == 0 failed" or "the squares do not agree modulo n!" so there are probably one or more of the parameters that are completely inappropriate for larger numbers.

[jasonp]

Alex, if lots of people here start using the CADO tools, perhaps you shouldn't be the only one from LORIA fielding help requests :)

[thome]

Admittedly the documentation is too scarce. So I might occasionally help with the difficulties people encounter.

By the way, I've posted an updated tarball which should now be compatible with tar-1.12 as well.

E.

[R.D. Silverman]

Originally Posted by akruppa

The GNU tar format changed in version 1.13, I put an archive in the old format at http://www.loria.fr/~kruppaal/cado-nfs-r2150.oldtar.gz

Alex

When I extracted everything from the tar file, It reported that it
could not find

polyselect/aux.c
polyselect/aux.h

[xilman]

Originally Posted by R.D. Silverman

When I extracted everything from the tar file, It reported that it
could not find

polyselect/aux.c
polyselect/aux.h

A well-known problem in multi-architecture installations.

Under MS-DOG and its successors, at least as far as Vista, the files "aux" and "aux.*' are special --- they are actually devices. Various other names, such as con, and lpt, are also special. Actually, you were slightly fortunate --- I've seen applications lock solid when they attempt to access aux.*.

There are two solutions.

1) Extract the archive on a non-MS operating system, rename the files and then transfer everything to your Windoze machine.

2) Ask the CADO people very nicely whether they will consider renaming the files in subsequent releases, and then waiting until they do so.


Paul

[thome]

Originally Posted by xilman

2) Ask the CADO people very nicely whether they will consider renaming the files in subsequent releases, and then waiting until they do so.

Done, that was easy.

Although my very clear bet is that there is no chance the thing works in non-unix environments.

It's been extensively tested on linux/x86_64 (primary platform), with various compiler/linker combinations. It's regularly tested on linux/x86_32, macos/x86_64. We've also had successes on freebsd and openbsd, but that was a while ago, and not re-checked on a regular basis.

E.

[R.D. Silverman]

Originally Posted by xilman

A well-known problem in multi-architecture installations.

Under MS-DOG and its successors, at least as far as Vista, the files "aux" and "aux.*' are special --- they are actually devices. Various other names, such as con, and lpt, are also special. Actually, you were slightly fortunate --- I've seen applications lock solid when they attempt to access aux.*.

There are two solutions.

1) Extract the archive on a non-MS operating system, rename the files and then transfer everything to your Windoze machine.

2) Ask the CADO people very nicely whether they will consider renaming the files in subsequent releases, and then waiting until they do so.


Paul

Or... go into the actual tar file before extraction, and manually
extract the files with an editor......

[R.D. Silverman]

Originally Posted by thome

Done, that was easy.

Although my very clear bet is that there is no chance the thing works in non-unix environments.

It's been extensively tested on linux/x86_64 (primary platform), with various compiler/linker combinations. It's regularly tested on linux/x86_32, macos/x86_64. We've also had successes on freebsd and openbsd, but that was a while ago, and not re-checked on a regular basis.

E.

With your permission, I will *try* to get it to work under WINDOZE.

pthreads will be a problem........

[xilman]

Originally Posted by R.D. Silverman

Or... go into the actual tar file before extraction, and manually
extract the files with an editor......

Ooh! That's much deeper magic than almost all Windoze people are prepared to attempt.

You could also edit the filenames in the tarball. It's probably best to keep the lengths the same, so "sux.{h,c}" is the obvious candidate.

You'll need to fix up all the other files (Makefiles especially) accordingly. If you don't, they'll fail to find the evil twins. If you rename the aux files you're back into the original situation and, if you are lucky, the app won't lock solid when you try to access them.


Paul

[R.D. Silverman]

Originally Posted by xilman

Ooh! That's much deeper magic than almost all Windoze people are prepared to attempt.

You could also edit the filenames in the tarball. It's probably best to keep the lengths the same, so "sux.{h,c}" is the obvious candidate.

You'll need to fix up all the other files (Makefiles especially) accordingly. If you don't, they'll fail to find the evil twins. If you rename the aux files you're back into the original situation and, if you are lucky, the app won't lock solid when you try to access them.


Paul

I will not be using the make files. I will do this under VC++ and use
windoze .dsw files..........

This will take some time.. I have little enough of it.