Aliqueit.exe discussion

[EdH]

Originally Posted by RichD

What about printing 8 spaces to the screen with a <CR> right before the log entry. Anything left on the line is overwritten by the composite.

printf("        \r");

I just came up with basically the same thing as you, but (I think) it needs 10 spaces to cover indices in the 1xxxx:

Change line 1327 in the GitHub version from:

        cout << msg1 << (factors.size() == 1 && factors[0].second == 1 ? "prp" : "c") << n.get_str().size() << " = " << msg2 << msg3 << endl;

to:

        cout << "          \r" << msg1 << (factors.size() == 1 && factors[0].second == 1 ? "prp" : "c") << n.get_str().size() << " = " << msg2 << msg3 << endl;

What do you guys think?

Edit 2: As an additional note, line 904's comment is incorrect. It should be changed from:

//output a result line to screen and elf file

to:

//output a result line to elf file

It does not do anything with screen output.

[EdH]

@Chris: I have stumbled onto a problem with the GitHub version. I turned off the merge detection to let a sequence run down to a prime and it broke on 81 (3^4). Here's an example using 33391084425, with "detect_merge = false"

$ ./aliqueit -i 0 33391084425 33391084425
Reading config file...
Precalcing primes for trial factoring...
Preloading mersenne primes for trial factoring...
seq = 33391084425
index = 0
value = 33391084425 (11 digits)
0 .t dri c11 = 33391084425 = 3 * 5^2 * 397 * 1121447 : No driver
1 .t dri c11 = 21954617271 = 3^3 * 23 * 499 * 70849 : Decreased!
2 .t dri c11 = 12053382729 = 3 * 4017794243 : Decreased!
. . .
21 . dri c3 = 231 = 3 * 7 * 11 : Decreased!
22 . dri c3 = 153 = 3^2 * 17 : Decreased!
23 . dri c2 = 81 = 1 * 3^4 : Decreased!

ERROR: factor not prime: 1

Here's the resulting .elf:

0 .     33391084425 = 3 * 5^2 * 397 * 1121447
1 .     21954617271 = 3^3 * 23 * 499 * 70849
2 .     12053382729 = 3 * 4017794243
. . .
21 .     231 = 3 * 7 * 11
22 .     153 = 3^2 * 17
23 .     81 = 1 * 3^4

Here's what the .elf should be:

0 .   33391084425 = 3 * 5^2 * 397 * 1121447
1 .   21954617271 = 3^3 * 23 * 499 * 70849
2 .   12053382729 = 3 * 4017794243
. . .
21 .   231 = 3 * 7 * 11
22 .   153 = 3^2 * 17
23 .   81 = 3^4
24 .   40 = 2^3 * 5
25 .   50 = 2 * 5^2
26 .   43 = 43

If run 81 as the sequence, it breaks later:

$ ./aliqueit -i 0 81 81
Reading config file...
Precalcing primes for trial factoring...
Preloading mersenne primes for trial factoring...
seq = 81
index = 0
value = 81 (2 digits)
0 .t dri c2 = 81 = 3^4 : No driver
1 .t dri c2 = 40 = 2^3 * 5 : Decreased!
2 .t dri c2 = 50 = 1 * 2 * 5^2 : Downdriver!

ERROR: factor not prime: 1

Note: This is from a clean d/l from GitHub. I made no edits to this source, which is why you can see the "t dri" extraneous characters.

[Happy5214]

Originally Posted by EdH

There is one thing I'd like to address at some point, unless you already know: If I'm using -y to let YAFU perform all the external factoring, I can't get Aliqueit to stop once it's under way. If I use CTRL-C, YAFU interrupts, but Aliqueit just steps into another iteration. If I force the terminal to close, Aliqueit/YAFU just keeps going in the background. Even if I close YAFU via pkill or by kill PID, it gets started right back up with a new PID. I've been having to reboot the computer to kill everything. Any ideas?

Try killing aliqueit first (using kill PID), and then killing yafu. That should prevent yafu from re-spawning.

[EdH]

Originally Posted by Happy5214

Try killing aliqueit first (using kill PID), and then killing yafu. That should prevent yafu from re-spawning.

Thanks. On the instances in question, I had forced the terminal to close. top showed no instance of Aliqueit to kill, but did show YAFU. When I killed YAFU, it reappeared with another PID, continuously.

[ChristianB]

@Ed:

I fixed both issues. I don't add spaces like you but instead replace the tab with the correct amount of spaces (diff 4c1bfb26 on github). This also turned out to be faster (albeit not much, considering that this functions is not called very often) and invlolved more math (although I had to correct it [diff 28b4de02 on github] because my own math was weak).

The other issue with the surplus 1 in the factor list is fixed by diff eca1a97d on github. The cause was some code I added to test the factors of the previous index before trial factoring.

You can download the current code with this link: https://github.com/ChristianBeer/ali...ive/master.zip.

[ChristianB]

Let's break those issues down.

Originally Posted by EdH

ecm.py must take care of the b2scale issue now. When I first encountered it it was crashing due to GMP-ECM having removed b2scale quite some time ago.

The B2scale option was removed with gmp-ecm 7.0. I'm still using the 6.4.4 so I never encountered this. There are two ways to resolve this. Add an ecm_version option to the ini file to accommodate users that for some reason use the older version or remove the B2scale options completely. The latter option seems to be the better one since the option is generally not required to run a 6.4.4 gmp-ecm. If there are no objections I'm going forward with this.

Originally Posted by EdH

I'm using ecmpi (called by a bash script) instead of ecm.py and have run into an issue. ecmpi does not recognize "-one," so it continues past the first factor to try to complete the factoring if possible. But, Aliqueit only finds one factor no matter how many are returned. I'm not sure if this is trouble with my conversion or if Aliqueit is only looking for one factor, since it sent "-one" out.

Could you send me a sample logfile produced by ecmpi so I can tune the factor retrieval?

Originally Posted by EdH

As mentioned earlier in this thread, Aliqueit duplicates ECM work if any factors are returned, but they don't complete the factorization for that line. I'm not sure if addressing the previous item will minimize that.

I believe there is already an open issue for a similiar case from user Happy5214. When I started using aliqueit I couldn't use the -y switch to always use yafu and later didn't use it because it didn't use all the cores for some step (can't remember now). I'll have to delve into that part of the code again.

[EdH]

As far as I can tell, ecmpi only writes to stdout. Here is a sample of its normal output for a successful run:

# 000: N = 3090600480571341440695629848053409503575850194735086870320378383071
# 000: B1 = 11000
# 000: #curves = 69
# 002: N = 3090600480571341440695629848053409503575850194735086870320378383071
# 002: B1 = 11000
# 002: #curves = 69
# 006: N = 3090600480571341440695629848053409503575850194735086870320378383071
# 006: B1 = 11000
# 006: #curves = 69
. . .
# 096: N = 3090600480571341440695629848053409503575850194735086870320378383071
# 096: B1 = 11000
# 096: #curves = 69
# 103: B1 = 11000
# 103: #curves = 69
# 046: curve 0 found factor 83229881248601348477 using sigma 1:3897721773
# 069: curve 0 found factor 83229881248601348477 using sigma -1:2104735613
# 112 curves done (162.3%)
Results: 3090600480571341440695629848053409503575850194735086870320378383071 = 37133303979371927709681795987519828996261725323 * 83229881248601348477

And, here is a sample of its normal output for an unsuccessful run:

. . .
# 068: N = 411676773140232256051084769693456454376283873543984860467009008264837448990912018251228188229503895262379101626680194478551024664844928705462803579339
# 068: B1 = 11000000
# 068: #curves = 4166
# 112 curves done (2.7%)
# 224 curves done (5.4%)
. . .
# 4144 curves done (99.5%)
# 4256 curves done (102.2%)
Results: 411676773140232256051084769693456454376283873543984860467009008264837448990912018251228188229503895262379101626680194478551024664844928705462803579339 = 411676773140232256051084769693456454376283873543984860467009008264837448990912018251228188229503895262379101626680194478551024664844928705462803579339

I search for the asterisk in the last line to signal success and harvest the factors, which I place in "aliqueit_ecm_temp.log" via a script.

I also use a script to catch Aliqueit's "ecm.py" call and change it to what ecmpi expects. The scripts I use are fully explained in this post in my "How I..." thread for Aliqueit.

In actuality, it might not be worth the effort to make Aliqueit ecmpi friendly, though. If I can get something like ECMnet working, that would be preferred by me, mainly because Ubuntu 18.04 broke openmpi and unless 20.04 has it working again, I will stop using it altogether with my next upgrade, but also because mpi clusters work best with all similar nodes, whereas my farm is anything but similar across the nodes, resulting in the slowest machine setting the pace for the whole cluster.

And, besides, if I'm the only one using it, or there is a tiny following I/we can quite effectively use scripts to convert the calls/results.

[EdH]

Originally Posted by ChristianB

@Ed:

I fixed both issues. I don't add spaces like you but instead replace the tab with the correct amount of spaces (diff 4c1bfb26 on github). This also turned out to be faster (albeit not much, considering that this functions is not called very often) and invlolved more math (although I had to correct it [diff 28b4de02 on github] because my own math was weak).

The other issue with the surplus 1 in the factor list is fixed by diff eca1a97d on github. The cause was some code I added to test the factors of the previous index before trial factoring.

You can download the current code with this link: https://github.com/ChristianBeer/ali...ive/master.zip.

Thanks for all the work, Chris. I'll change my "How I ..." thread to reflect the current revision sometime soon. I see the link is still the same. That's great.

[ChristianB]

If I unterstand your ecmpi scripts correctly you would output multiple lines of the form

********** Factor found in step 2: $factor
Found prime factor of ${#factor} digitis: $factor

into "aliqueit_ecm_temp.log". So I just need to adjust the factor gatherer part to look for more line of this format and gather all the factors. Even if -one was specified.

Edit upon further review of the aliqueit code: this should already be the case. Could you send me an "aliqueit_ecm_temp.log" that was created by your "aliECM.sh" script?

The current code checks every line of "aliqueit_ecm_temp.log" and looks for "Found factor" it then looks for ": " and extracts the number after that. It does so with every line and collects multiple factors.

[EdH]

My ecmpi script is not harvesting correctly. If possible, you should work with actual ecmpi output. However, you probably shouldn't spend too much time on this particular item, since I may be the only user and that might be short-lived if Ubuntu doesn't fix openmpi in version 20.04 LTS. If Aliqueit is harvesting all the factors returned from GME-ECM and ecm.py, that should be sufficient. ecmpi output would be a bonus, but my script shouldn't be considered any kind of valid format, since it was just an intermediary step.

My script merely grabs the factor string and sticks it on a manufactured line and appends it to the temp file. This was from a recent success:

GMP-ECM 7.0.4 [configured with GMP 6.1.2, --enable-asm-redc] [P+1]
Input number is 199846925325212778936524636255908932994729050497908854338781889672773772151749842241106868914659381665057376759667160384756876084264093979 (138 digits)
Using B1=55000, B2=19411780, polynomial x^1, x0=683685786
Step 1 took 32ms
Step 2 took 40ms
Run 2 out of 3:
Using B1=55000, B2=19411780, polynomial x^1, x0=1704320829
Step 1 took 24ms
Step 2 took 32ms
Run 3 out of 3:
Using B1=55000, B2=19411780, polynomial x^1, x0=1137676472
Step 1 took 28ms
Step 2 took 36ms
********** Factor found in step 2: 7232220600701 * 29530212079756657
Found prime factor of 33 digitis: 7232220600701 * 29530212079756657

Thanks for all your work. I still need to update my page.

[EdH]

Originally Posted by EdH

. . .
I still need to update my page.

I've done the updating. I also noticed that Aliqueit now compiles with GMP-6.2.0.

Thanks for all the work, Chris!
[/code]