mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Aliqueit.exe discussion (https://www.mersenneforum.org/showthread.php?t=11618)

mklasson 2010-05-22 20:18

[QUOTE=EdH;215681]Actually, if aliqueit could add all the merge and prime messages, as well, that would be super.

Thanks for all the work on aliqueit.[/QUOTE]

Thanks, glad you enjoy it.

I think I've taken care of the log requests now, as well as added the verify-only mode. Give it a spin and let me know if it doesn't work like you wanted it to.

aliqueit v1.09 available at [url]http://mklasson.com/aliquot.php[/url].

v1.09 22 May 2010
+ "-t" quits aliqueit after verifying the elf file. Returns 1 if any error (not warning) is detected, otherwise 0.
+ logs error and warning msgs during elf verification.
+ logs any encountered wrong factors.
+ logs cycle, merge and termination msgs.
+ logs the ecm curve # that found the factor. Thanks kar_bon.

cheers,
Mikael

kar_bon 2010-05-22 21:14

Now that was a fast change!

I think I can now change my script to verify a range of sequences from the FactorDB.
I will give some results here when ready.

Thanks a lot!

EdH 2010-05-23 02:44

Excellent! Thank you very much.

I have modified AliWin so it now gives at least some explanation as to why aliqueit ends early due to an elf error and I modified the verification routine to include the messages for those sequences that fail verification.

Thanks again for a great program and the quick response with modifications.

kar_bon 2010-05-26 11:16

[QUOTE=kar_bon;215661]The program 'chk.exe' has a bug: If I put an error in the last full line of an ELF-file it reports 'no errors found'!

PS: Sent a mail to Clifford about this bug.[/QUOTE]

Clifford Stern has de-bugged and updated his 'chk.exe' on [url=http://www.lafn.org/~ax810/aliquot.htm]his page[/url].

It works fine now in checking for errors in ELF-files.

Andi47 2010-05-30 18:21

GNFS: aliqueit hits bug in FactMsieve.pl for c115+
 
I am just adding another few lines to sequence 10212 (not re-reserving it unless the 57-bug is fixed in the DB), and It seems that aliqueit.exe has hit a bug in factmsieve.pl when attempting to GNFS a c129:

The polynomial file which is created by aliqueit.exe does [I]not[/I] contain the line "type: gnfs". Thus, when GNFSing a composite >c115, a bug described [URL="http://www.mersenneforum.org/showpost.php?p=216706&postcount=505"]in this posting[/URL] is hit - and makes FactMsieve.pl think that it factors a c160 or bigger and thus the parameters file (def-params.txt) is ignored. (for me it chose 28 bit large primes for a c129 factorization :yucky: )

This bug (in FactMsieve.pl) could be circumvented if aliqueit.exe would add the line

[CODE]type: gnfs[/CODE]

to the polynomial file.

Note: It is not important where in the polynomial file this line is placed - it just has to be there.

Edit: forget about this - it seems that aliqueit adds the line, but factmsieve.pl does not take it over to the subfiles when creating poly files for multiple threads...

mklasson 2010-08-24 23:18

Evening,

Greebley has added some functionality to aliqueit and I've compiled a v1.10 zip with his changes. So, aliqueit v1.10 at [url]http://mklasson.com/aliquot.php[/url].

v1.10 25 Aug 2010
+ "-d <max_digits>" quits after sequence reaches <max_digits> digits.
+ "-c <max_cofactor>" quits after sequence passes ecm with a cofactor of <max_cofactor> or more digits.
+ "-b" with -c and -d quits after a number meets both limits.
+ "-m <max_ecm_level>" ecm will only run to level <max_ecm_level> where '1'=20-digit factor, '2'=25, etc.
All updates in this version were done by Greebley.

cheers,
Mikael

EdH 2010-08-25 14:45

These sound great! Thanks Greebley & Mikael!

Now, I need to rewrite AliWin to keep up with your new additions. This will make things much simpler. Bummer though - I can't spend a lot of time with AliWin right now. . .

@Mini-Geek: I think this means we can get rid of the extra scripts for AliPerl. Could you check into this?

Actually, thinking about this a little bit more, if a queue was developed for aliqueit and an auto-send routine, I think we could get rid of AliWin and AliPerl altogether. . .

Writing as I'm thinking. . . I believe a batch (or script file) could now be used to do the above, rather simply and easily.

Maybe it's already time to retire AliWin and AliPerl.

Thoughts?

Greebley 2010-08-25 16:01

I haven't yet had a chance to try aliwin so I don't know quite what it does. Writing a batch file each time is certainly doable, however it is more cumbersome. I think typing in or importing a list of sequences and setting the max digits and max cofactor (with a check box for the -b option) is more elegant.

Getting and sending the results makes the script much more cumbersome and I need to use emacs macros for such scripts. For this a GUI is definitely a win.

So in all I think there is use for a GUI to do this despite the fact one can use scripts as well. I even started my own GUI once but didn't like having to abort aliqueit which eventually led me to adding the switches to aliqueit. In a sense, the new functionality is designed to work with a GUI that doesn't need to ever abort aliqueit.

EdH 2010-08-25 16:18

The new changes can definitely streamline a lot of what Aliwin does in a non-delicate manner. I also think it might even be simple enough now, that I could write a GTK version to work in linux.

But, my thoughts on the script/batch file, would be one that would take in a text file similar to alinum.txt, but with all the switch info as the first line and the numbers and size for the rest. Then only an edit of the text file would be in order for each run.

In any event, I will explore the remake of the GUI and whether I can now create a linux version and see if they are indeed valuable.

I suppose I could really make it complicated, if I wanted to, now - set up AliWin to be able to set all the switches uniquely for each entered number. . .:smile:

Thanks again for all the work.

Andi47 2011-06-18 09:48

Is it possible to use yafu's new nfs() functionality for aliqueit's GNFS jobs? The command line would be:

yafu "nfs(number)" -v -threads <number of threads>

yafu uses msieve for poly search and postprocessing and GGNFS for sieving; the advantage over factmsieve.pl would be that yafu is capable of doing multiple-threaded poly search. (at least as long as Jasonp doesn't add a native msieve -np -t <number of threads> functionality to msieve.)

bsquared 2011-06-24 14:01

[QUOTE=Andi47;264057]Is it possible to use yafu's new nfs() functionality for aliqueit's GNFS jobs? The command line would be:

yafu "nfs(number)" -v -threads <number of threads>

yafu uses msieve for poly search and postprocessing and GGNFS for sieving; the advantage over factmsieve.pl would be that yafu is capable of doing multiple-threaded poly search. (at least as long as Jasonp doesn't add a native msieve -np -t <number of threads> functionality to msieve.)[/QUOTE]

Is there still interest in this? Other advantages is that it does multi-threaded ECM (on linux) and better balancing of ecm vs. siqs/nfs (IMO). I've modified my local copy of aliqueit (version 1.08) to use yafu after doing aliqueit's internal rho, so you would no longer need external msieve, ecm, and factmsieve.xx tools as well. However mklasson's [URL="http://mklasson.com/aliquot.php"]site [/URL]has been down the last couple days and so I haven't been able to modify the latest version of aliqueit.

If there's still interest and if someone can provide the latest version of the code, I can try to modify it to use yafu for everything other than rho...

[edit]
It could be set up as an option, as well, so that folks could continue to use external ecm/msieve/factmsieve.xx tools if they wanted.


All times are UTC. The time now is 22:40.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.