Aliqueit.exe discussion

[Mini-Geek]

Originally Posted by EdH

Sorry if this is somewhere I should have found it. I did look in a lot of places...

(Even sorrier if this is something I should know.)

Where can I find a list of the codes Aliqueit places in the sequence line it outputs to the console, i.e. un, ru?

I'm not sure what you're referring to...The sequence line that Aliqueit outputs to the console looks like this: (ignore the line breaks in the middle of things, too much trouble to remove)

 2518 .  c172 = 202603822958964327769028103708475085360917969673432003521748801454817413856537285884
2715809344664160119060244199212323292734231931503734729276568447959395371387900931517576 = 2^3 * 7 *
 11 * 19861 * 7572739 * 213707623 * 2266533089 * 3637046480699 * 83136865706039887106758063548386716
8226159 * 14930977716074183218202849037086987095402611116492933462800195088349992532423708467017

The format here is quite simple:

 index . cxxx = abcdef... = 2^3 * ...

The only thing that might need explaining (but I doubt you wouldn't already know it) is the cxxx is the decimal length of the full index.

There's nothing here like "un" or "ru".

[EdH]

Here's what my output looks like:

 733 .     c106 = 6428448981218514817450159347532233087079734956465411627019034926711607688465743111579329342315808354153936 = 2^4 * 137 * 151 * 35022580789758232726146307562824117349741 * 554549807182491990987952019975269580185369205393826127163263
c80: running 196 ecm curves at B1=5e4...              
sieving in progress (press Ctrl-C to pause)
46100 relations (23749 full + 22351 combined from 252464 partial), need 46037
sieving complete, commencing postprocessing
 734 .     c106 = 6200670516325916984937423484345636342611132162220012075524626015833319558325156717102922974557753176185392 = 2^4 * 41 * 701 * 655751639 * 1502160881743 * 142883804609275801710058085231012351 * 95802746312603519157352796913131189927983841
 735 .un c106 = 6123704208045157994739728086919109992088028246976706401487865469811838066974610124129118763654950762620368 = 2^4 * 15137 * 162675828503689 * 922519564994163736450819 * 168482888108329986212642069673488057372911857585092706724534919
c71: running 23 ecm curves at B1=5e4...               
sieving in progress (press Ctrl-C to pause)
13368 relations (6428 full + 6940 combined from 75139 partial), need 13284
sieving complete, commencing postprocessing
 736 .     c106 = 5741756514617164950567794919715597176270016591392331432589512667323534665335305633978488588922710841587632 = 2^4 * 11 * 2663 * 12911 * 6837151 * 31635763 * 56325179639 * 58519924882308755271931871 * 1330887132336263283325234815647843028652054117
 737 .ru c106 = 6399728591890050313267555994630461678255572614498800958064552796150899343875801944812112914681587608619088 = 2^4 * 34231 * 1724128105792531663124083807067 * 6777233603810544463009695726968032947013825642904205688350933339237209
c81: running 2 ecm curves at B1=25e4...               
sieving in progress (press Ctrl-C to pause)
50273 relations (26863 full + 23410 combined from 262071 partial), need 50096
sieving complete, commencing postprocessing
 738 .     c106 = 6000107784283933561066060246966752632918848508251829814242485432379066326042737857503254234640841195714672 = 2^4 * 41 * 17387 * 4600772288611329227 * 210916150644279560901973 * 378785150487254776566442831 * 1431189159929035941659468048101
 739 .un c106 = 5909327649269415616516053905483873174738518061374691861702163134073377021081716632186068993133341074177936 = 2^4 * 17 * 37 * 41 * 103 * 112979 * 851363 * 6733212167169152579 * 214689875033412382632849159368268385642844340914823331163291096560961
 740 .ru c106 = 6968752997001129265452079768965125080598374337863515669395094823850049804313846596653389228224495703908464 = 2^4 * 28945319447557492033 * 15047236327852086417476575150825614411353963686998514051629027413580452350327993051463
 741 .un c106 = 6533205934688558686827789109568219442002749771422639986809874271656375627144731034184443729223506789262592 = 2^8 * 229 * 419297 * 2788678373720475704074351889629 * 95308298517567271255815355129736053907188361597527127076872049941
 742 .ru c106 = 6564663961223426471016535752903381072097022979130670676332389676666577376538412012876023800251874833889808 = 2^4 * 97 * 3654903349 * 1157297156578136873619557415570556450171791487204684473484428586491800383252819615346326435421
 743 .un c106 = 6285496554017164983289129905055200140575628940846243147038869484264337075102347458093825892963066762830792 = 2^3 * 37 * 157 * 42841 * 845229688087 * 59870788573087 * 62387690388028851966849138229010979115070531927437765015002642283455209
c77: running 138 ecm curves at B1=5e4...               
sieving in progress (press Ctrl-C to pause)
35483 relations (18072 full + 17411 combined from 187006 partial), need 35214
sieving complete, commencing postprocessing
 744 .     c106 = 5895710042964688363370907022588422321548280552206474999571104632486536661832362701822844738704366962814008 = 2^3 * 37 * 8369 * 57024520147607374907203 * 68605802973923330083909885767191 * 608342763379563751860059107550867083019940079
c89: running 430 ecm curves at B1=25e4...

Notice on some of my lines there is a "un" or "ru" before the composite reference.

Possibly of note, I'm running the linux version 108...

Is this possibly telling me that the composite is swapping direction in size? It looks like maybe (except for 735)...

[RichD]

Originally Posted by EdH

Possibly of note, I'm running the linux version 108...

Is this possibly telling me that the composite is swapping direction in size? It looks like maybe...

I get the same codes with my Mac version (108).

[Mini-Geek]

Originally Posted by EdH

Here's what my output looks like:

How odd...
That's not in the source code.

        string msg1 = " " + tostring( index ) + " .\t ";
        string msg2 =  n.get_str() + " = ";
        for( size_t j = 0; j < factors.size(); ++j ) {
            if( j ) msg2 += " * ";
            msg2 += factors[j].first.get_str() + ( factors[j].second > 1 ? ( "^" + tostring( factors[j].second ) ) : "" );
        }
        save_result( seq, msg1 + msg2 + "\n" );
        cout << msg1 << ( factors.size() == 1 && factors[0].second == 1 ? "prp" : "c" ) << n.get_str().size() << " = " << msg2 << endl;

My guess is it's being left over from something, and not getting cleared out correctly when the \t (tab) is being printed. Observe the similarities here:

Originally Posted by EdH

 739 .un c106 =   5909327649269415616516053905483873174738518061374691861702163134073377021081716632186068993133341074177936   = 2^4 * 17 * 37 * 41 * 103 * 112979 * 851363 * 6733212167169152579 *   214689875033412382632849159368268385642844340914823331163291096560961
c81: running 2 ecm curves at B1=25e4...

 737 .ru c106 =  6399728591890050313267555994630461678255572614498800958064552796150899343875801944812112914681587608619088  = 2^4 * 34231 * 1724128105792531663124083807067 *  6777233603810544463009695726968032947013825642904205688350933339237209
c100: running [some stuff; I actually made this line up to show you c100+, it wasn't in your output]...

The "ru" and "un" line up. So my guess is that the "ru" and "un" are remaining portions of "running", depending on if it's 2 digits (resulting in "un") or 3 digits (resulting in "ru") in the number of digits in the composite that was last worked before the line finished.

You could test this by changing "running" in your source to something different and recognizable - like "wxyzing", recompiling, and see if the "codes" change accordingly (to "wx" and "xy", assuming I'm right).
I'm not sure just what would be done to fix this...I suppose you could change it to use a space instead of a tab, and that ought to work better with little to no negative side effects (this would, of course, have the effect of changing all of aliqueit's output to use a space instead of a tab to separate that stuff, but I think everything will still be able to read the files).

[EdH]

Originally Posted by Mini-Geek

...You could test this by changing "running" in your source to something different and recognizable - like "wxyzing", recompiling, and see if the "codes" change accordingly (to "wx" and "xy", assuming I'm right).
I'm not sure just what would be done to fix this...I suppose you could change it to use a space instead of a tab, and that ought to work better with little to no negative side effects (this would, of course, have the effect of changing all of aliqueit's output to use a space instead of a tab to separate that stuff, but I think everything will still be able to read the files).

Good deduction! I changed "running" to "wxyzing" and the "un" changed to "xy" with it. (I tried "xyzzy" but nothing happened.)

How disappointing that instead of a code, it turned out to be a "feature." I never thought to look in the source for the answer. I don't know why not. I've been looking the source over for a lot of other things.

Anyway, thanks for the detective work.

[Mini-Geek]

Glad to have helped figure it out.

[kar_bon]

The recent errors in the FactoringDB makes it needful the check those sequences in there.

I've looked about a program only to check if the factorizations in an ELF-file are correct, but found nothing.

So what about a function/parameter for aliqueit.exe (like -t) to test an input file/list of files and give a positive or negative result (without calculating further), perhaps printing the line-index to locate a possible error!?

[mklasson]

Sounds easily doable. The only problem is I was in the middle of adding threading when I last stopped working on aliqueit, so I'm not sure it's compilable right now. I'll have a look at it.

[schickel]

Originally Posted by kar_bon

The recent errors in the FactoringDB makes it needful the check those sequences in there.

I've looked about a program only to check if the factorizations in an ELF-file are correct, but found nothing.

So what about a function/parameter for aliqueit.exe (like -t) to test an input file/list of files and give a positive or negative result (without calculating further), perhaps printing the line-index to locate a possible error!?

Check Clifford's web page in the utilities section. He has a program that will check elf files for errors. I don't think he's managed to get it compiled for 64-bit Windows yet. It returns a non-zero error code on incorrect files, so it could incorporated into a script... There is also a UB program that does APRT-CL tests, but for quick checks that would be over-kill.

[kar_bon]

Originally Posted by schickel

Check Clifford's web page in the utilities section. He has a program that will check elf files for errors.

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'!

Perhaps the extension in aliqueit would be a better solution because this program is supported in the next furture!

PS: Sent a mail to Clifford about this bug.

[EdH]

I would be happy enough for now, if the current aliqueit errors were reported to the log. AliWin will already run an entire aliqueit verification on each sequence in the alinum.txt file by simply changing "last" to "all" in the wget call. I am in the process of making that happen by simply using 0 as the size to go to. it already verifies, but I can't easily get the error messages. If they were written to the log file, I could pull them out without too much trouble. Then it would be a simple matter of entering 0 ##### ##### ##### ##### ##### . . . ##### to have it verify the entire list. I could then have the output file take just about any form - possibly simply:

Number          Index         Size
---------       -------       -----
216804          4883          115
. . .           . . .         . . .

Actually, if aliqueit could add all the merge and prime messages, as well, that would be super.

Thanks for all the work on aliqueit.