Aliqueit.exe discussion

[Mini-Geek]

Originally Posted by Greebley

Ya, I think I understand the concept. The more curves run and fail, the greater the chances are that the factors are quite large and ecm is unlikely to work.

Well, technically, any particular number's factorization is already absolutely determined and has been from before the beginning of time, and any particular sigma value (the randomized value) on an ECM curve, as I understand it, either will or won't find the factors, so really the chances are either 0 or 1, but...well that's just being pedantic. I know what you mean, and it's right.

Originally Posted by Greebley

That is why I used the term "any benefit" - to clarify what I wanted to know. In this case I have a c120 so too few (and not finding one that I could) is worse than too many I am thinking.

Yeah, I definitely know the feeling, (even though I've never dealt with numbers quite that huge) but it's still best in the long run to only run the optimal number of curves. But that doesn't mean you have to take what aliqueit.exe suggests since it could very well be underestimating the optimal and causing you to run unnecessary GGNFSs, meaning you ought to run extra curves...or it could be overestimating it and causing you to waste time running unneeded curves, meaning you should skip straight to GGNFS while it still wants to ECM. The question is: which is it doing? I haven't the slightest clue, sorry!

Originally Posted by Greebley

The number 232800 is being very annoying. Its around size 123 with no driver, and it is looking like I need to run the second c120 through ggnfs after doing a ggnfs run: c120 = c19 x c102 only 4 iterations ago (and a c110 in between).

Are you saying you ran a GGNFS on 232800 index 809? I can factor it with ECM in 5 seconds at http://www.alpertron.com.ar/ECM.HTM, and 1.2 seconds of that was verifying the primality of the p102. By the way "cxx", like c102, means a composite with xx digits. "pxx", like p102, means a prime with xx digits. Assuming the number I linked earlier is the right one, it should be "c121 = p19 * p102". If you really missed a p19 factor in doing the ECM that aliqueit.exe would run on a number that large, (and you didn't somehow skip the ECM) you have insanely bad luck, if that's even possible at all.

To mklasson, two feature requests:
1. It'd be nice if the B2 values used in ECM/P-1/P+1 were recorded, even if only by another option in aliqueit.ini. That way you'd know what B2 values to put in to Syd's DB when reporting work. And,
2. An automated way to report factoring attempts to Syd's DB would be a nice complement to the new -s option. If it could be added automatically as part of the -s option, great, otherwise a separate option would do. I'm guessing that -s reads from the alq_xxx.elf file and not the .log file with the factoring records, so it might not really be feasible to make this part of the -s option.

[mklasson]

Originally Posted by Mini-Geek

To mklasson, two feature requests:
1. It'd be nice if the B2 values used in ECM/P-1/P+1 were recorded, even if only by another option in aliqueit.ini. That way you'd know what B2 values to put in to Syd's DB when reporting work. And,

The problem is that I don't know the B2 before ecm runs. But maybe you just meant you'd like to see it in the log file? I guess I could parse the B2 values while checking the ecm tempfile for factors. Perhaps I could change the log output to:

[Jun 16 2009, 03:25:10] c126: running 904 ecm curves at B1=1e6...
[Jun 16 2009, xx:xx:xx] c126: ran 904 ecm curves at B1=1e6 B2=xxxxxx

That would help conjure automatic partial ecm work continuation into existence as well.

Originally Posted by Mini-Geek

2. An automated way to report factoring attempts to Syd's DB would be a nice complement to the new -s option. If it could be added automatically as part of the -s option, great, otherwise a separate option would do. I'm guessing that -s reads from the alq_xxx.elf file and not the .log file with the factoring records, so it might not really be feasible to make that part of it.

Is this something people would find useful? For the team crunching, I imagine? I could probably take care of that in some way.

[Mini-Geek]

Originally Posted by mklasson

The problem is that I don't know the B2 before ecm runs. But maybe you just meant you'd like to see it in the log file? I guess I could parse the B2 values while checking the ecm tempfile for factors. Perhaps I could change the log output to:

[Jun 16 2009, 03:25:10] c126: running 904 ecm curves at B1=1e6...
[Jun 16 2009, xx:xx:xx] c126: ran 904 ecm curves at B1=1e6 B2=xxxxxx

That would help conjure automatic partial ecm work continuation into existence as well.

Sounds fine to me. I was imagining it being on the same line as the "running" line, but that works too. Besides, if you really want the B2 from an in-progress ECM run, you can look in the aliqueit_ecm_temp.log file.

Originally Posted by mklasson

Is this something people would find useful? For the team crunching, I imagine? I could probably take care of that in some way.

I'm not sure how useful it would be to most people, it just seemed to me like something that ought to exist to me. Feel free to not put it in if you think it'd be too much work for the use it would have, I wouldn't mind very much.

[Greebley]

Originally Posted by Mini-Geek

Are you saying you ran a GGNFS on 232800 index 809? I can factor it with ECM in 5 seconds at http://www.alpertron.com.ar/ECM.HTM, and 1.2 seconds of that was verifying the primality of the p102. By the way "cxx", like c102, means a composite with xx digits. "pxx", like p102, means a prime with xx digits. Assuming the number I linked earlier is the right one, it should be "c121 = p19 * p102". If you really missed a p19 factor in doing the ECM that aliqueit.exe would run on a number that large, (and you didn't somehow skip the ECM) you have insanely bad luck, if that's even possible at all.

It is more likely that I am mistaken about which one was hard and it was further back than I thought. In fact the when I look at it 2^6 seems wrong - there was a 2^5 factor, so I am not sure which it was.

- I found it 788 - a c56 x c65 which makes a lot more sense and I got farther than I had thought.

Edit: Oh and I wasn't commenting on whether aliqueit.exe's estimate was accurate - it is more a case of an aborted ecm at 650/1221, should I then skip ecm or not - so the choice is 650 or 1871. Stopping near 1221 would require I be there when it was reached which is not the case.

[henryzz]

i have noticed a bug in 64-bit linux(probably all linux)
aliqueit tries to using the command "del" to delete the gnfs folders
"del" doesnt exist on my 64-bit linux instalation
i think it is a windows thing

[10metreh]

Look in aliqueit.ini, spot the hashed alternative with "rm"

[kar_bon]

i think, it would be helpful to see, which number of the curves an ECM run produced/found a factor, so the log-file should contain something like this:

c85: running 214 ecm curves at B1=5e4...
factor found in curve 23/214
Using B1=50000, B2=12746592, polynomial x^2, sigma=2218727820
Step 1 took 297ms
Step 2 took 312ms
********** Factor found in step 2: xxxxxxxx

some minds?

[mklasson]

Originally Posted by kar_bon

i think, it would be helpful to see, which number of the curves an ECM run produced/found a factor, so the log-file should contain something like this:

I agree. It already would if gmp-ecm started printing "Run x out of y:" on the first curve instead of the second. I'll try to fix it anyhow.

[10metreh]

Originally Posted by kar_bon

i think, it would be helpful to see, which number of the curves an ECM run produced/found a factor, so the log-file should contain something like this:

c85: running 214 ecm curves at B1=5e4...
factor found in curve 23/214
Using B1=50000, B2=12746592, polynomial x^2, sigma=2218727820
Step 1 took 297ms
Step 2 took 312ms
********** Factor found in step 2: xxxxxxxx

some minds?

Same, I thought of that too. I have no idea why I never mentioned it. (Actually, I often don't mention improvements I think of for both aliqueit and the database... I'll probably get around to posting them soon.)

[Greebley]

Another possible item for your list of enhancements:

I had a case where ggnfs ran into an issue and didn't return the final factor (aborted early). Running ggnfs again however gave the correct answer.

It occurred to me that it would be nice to have an option where rather than running ecm forever, you could repeat the ggnfs attempt instead.

Note that this option should default to false because the most usual error is that ggnfs is not set up right and so calling it again won't do anything. But once I know ggnfs is set up correctly, I would like to be able to switch to retrying ggnfs because it is likely to succeed the second time.

[10metreh]

Originally Posted by Greebley

I had a case where ggnfs ran into an issue and didn't return the final factor (aborted early). Running ggnfs again however gave the correct answer.

How did ggnfs manage to abort early? Was it that "matrix must have more columns than rows" error?