Aliqueit.exe discussion

[Greebley]

I didn't exactly pull it from thin air, I based it approximately on the work that those who know more than me chose as the right value for the c150 for 4788 (though I did round off to an even 47).

[10metreh]

Behind all this is the problem that, for example, half t50 does not mean exactly t47.5. It is lower (and not too easy to work out; I am not an expert on ECM). If we used 10-digit increments, then half t50 would seem to mean t45.

[Greebley]

I wasn't really worried about being super-accurate, rather work with what we do have which is a linear function based on the digits and making aliqueit match more closely what is chosen when it is done manually.

[Greebley]

I thought this interesting: The factors listed by aliqueit were strange for this one (232956:1890). The 73159784497 is the product of the following two factors (128873*567689). I wonder why it found that one before it found the much smaller 43541? In any case aliqueit handled it fine so not a bug - just unusual.

using previously found factor 2
using previously found factor 2
using previously found factor 2
using previously found factor 2
using previously found factor 3
using previously found factor 31
using previously found factor 47
using previously found factor 47
using previously found factor 73159784497
using previously found factor 128873
using previously found factor 567689
using previously found factor 43541

Edit: though it did get two
WARNING: factor doesn't divide n
WARNING: factor doesn't divide n
These seem common - I am not sure what causes them.

[mklasson]

Originally Posted by Greebley

I thought this interesting: The factors listed by aliqueit were strange for this one (232956:1890). The 73159784497 is the product of the following two factors (128873*567689). I wonder why it found that one before it found the much smaller 43541? In any case aliqueit handled it fine so not a bug - just unusual.

I suppose it's not too improbable if your trial cutoff is < 43541.

Originally Posted by Greebley

using previously found factor 73159784497
using previously found factor 128873
using previously found factor 567689

Edit: though it did get two
WARNING: factor doesn't divide n
WARNING: factor doesn't divide n
These seem common - I am not sure what causes them.

After it's divided n by 73159784497 the two smaller factors no longer divide n and the warning appears. Another common reason for that warning is that you've started (and aborted) factoring a line several times. Multiple occurrences of the same factor are then parsed from the log and a scenario similar to the above unfolds. Not super neat, but no big deal either imho.

Cheers!

[Batalov]

Now that yafu is multithreaded, for some reason -threads 2 (2 is for example here) parameter doesn't work with "siqs(num)" in the command-line, but stdin works, so I recommend a patch to aliqueit.cc:

        //system( ( cfg.yafu_cmd + " \"siqs(" + input_number + ")\"" + hide_output ).c_str() );
        system( ( "echo \"siqs(" + input_number + ")\" | " + cfg.yafu_cmd + hide_output ).c_str() );

and add
yafu_cmd = yafu -threads 2
to aliqueit.ini (2 is for example).

[Andi47]

Originally Posted by Batalov

Now that yafu is multithreaded, for some reason -threads 2 (2 is for example here) parameter doesn't work with "siqs(num)" in the command-line, but stdin works, so I recommend a patch to aliqueit.cc:

        //system( ( cfg.yafu_cmd + " \"siqs(" + input_number + ")\"" + hide_output ).c_str() );
        system( ( "echo \"siqs(" + input_number + ")\" | " + cfg.yafu_cmd + hide_output ).c_str() );

and add
yafu_cmd = yafu -threads 2
to aliqueit.ini (2 is for example).

Hmmm... For me, it seemed to work yesterday, when I had specified to use 2 threads in yafu.ini. (at least, yafu sayed something like "sieving in progress (2 threads); I didn't check the task manager, if both threads had actually been used.)

P.S.: -threads 2 would make even more sense for aliqueit, if it would be able to run 2 (or more) threads of ECM - otherwise the second (in this example) thread would be idle while ECM is running.

[mklasson]

Originally Posted by Andi47

Hmmm... For me, it seemed to work yesterday, when I had specified to use 2 threads in yafu.ini. (at least, yafu sayed something like "sieving in progress (2 threads); I didn't check the task manager, if both threads had actually been used.)

I think the problem is that yafu is very picky about the order of arguments. Putting "-threads 2" _last_ on the cmdline seems to work. Thank you for the workaround, Batalov.

Originally Posted by Andi47

P.S.: -threads 2 would make even more sense for aliqueit, if it would be able to run 2 (or more) threads of ECM - otherwise the second (in this example) thread would be idle while ECM is running.

Yeah, I was right in the middle of adding that when I suddenly got busy some months ago. I'll try to get to it...

[Mini-Geek]

Just use yafu.ini. That's why he put it in.

[bsquared]

Originally Posted by mklasson

I think the problem is that yafu is very picky about the order of arguments. Putting "-threads 2" _last_ on the cmdline seems to work. Thank you for the workaround, Batalov.
...

It expects to see the expression first, i.e. yafu "siqs(num)"... followed by any number of arguments in any order.

Or...

Originally Posted by Mini-Geek

Just use yafu.ini. That's why he put it in.

[zarabatana]

Sorry for this novice question, but, is possible make aliquot use only yafu with this argument: yafu factor (num)
yafu is faster than aliqueit using ecm.
If siqs can't be used with yafu use, use msieve.
Here isn't the right place, but, why yafu use msieve 1.38 and not 1.43?

==== post processing stage (msive-1.338) ====
begin with 482799 relations
reduce to 110713 relations in 9 passes
attempting to read 110713 relations
failed to read relation 37820
recovered 110712 relations
recovered 87774 polynomials
attempting to build 55306 cycles
found 55306 cycles in 4 passes
distribution of cycle lengths:

Thank you for your time, and sorry for my bad english.