William,

I know about the paper and the algorithm that could be used to recognize algebraic factors, but I dont understand it at a level to be able to implement it. Any help is appreciated here! Currently its implemented in php and uses the internal data structure I also use to parse the terms. If you are interested I'll send the code over

- Syd

[QUOTE=Syd;270186]I know about the paper and the algorithm that could be used to recognize algebraic factors, but I dont understand it at a level to be able to implement it. Any help is appreciated here! Currently its implemented in php and uses the internal data structure I also use to parse the terms. If you are interested I'll send the code over[/QUOTE]

Hmm. there is a paper and algorithm? I was thinking in terms recognizing the strings a^b+1 and a^b-1, and finding the prime factors of b. Maybe you better send the paper (link or reference) first.

Its Computing Aurifeuillian factors from R. P. Brent

[QUOTE=Syd;270196]Its Computing Aurifeuillian factors from R. P. Brent[/QUOTE]

Ahh. Before we tackle that, there is a lot of improvement yet in the cyclotomic factors. Especially on the "plus" numbers. For a^n+1 where n has many prime divisors, factordb misses many of the divisors. I've had some fun adding these algebraic factorization to finish primality proofs, but I'm thinking it is time to fix this in the core.

William

Hello,

based on my tests and experience with my Perl script above, I set up a small Boinc server which fetches composites with unknown factors from factordb and runs YAFU on them.
[url]http://yafu.dyndns.org/yafu[/url]
Currently C88 and C89 are handled.

yoyo

[QUOTE=yoyo;270712]a small Boinc server[/QUOTE]

:tu: :bow:

Looking at the [URL="http://factorization.ath.cx/stat_1.php"]distribution of composites[/URL] this afternoon, I see that there are no 89 nor 90 digit composites left, and that 88 and 91 digit ones are dropping rapidly.

At this size the savings from SNFS treatment are not worth the hassle of detecting and treating them, but at this rate we can already see the end of that regime. Does anyone have a plan or suggestion for automation of SNFS detection?

Long Query Time
 

I attempted an inquiry for Aliquot sequence 1840896 and it took several seconds. I was using all the default values. The footnote shows:[quote]factordb.com - 71,277 queries to generate this page (47.71 seconds)[/quote]which is an extremely long time. Is there an index that is not in order?

[QUOTE=RichD;270857]I attempted an inquiry for Aliquot sequence 1840896 and it took several seconds. I was using all the default values. The footnote shows:which is an extremely long time. Is there an index that is not in order?[/QUOTE]Not sure about the index issue, but since the start value is >1M, it may have spent the time calculating the sequence to a higher value than it was (checking just now: [B][I]factordb.com - 1,971 queries to generate this page (0.38 seconds)[/I][/B]).

axn has calculated sequences >1M up to 71 digits.....1840896 is at 84 digits right now.

[QUOTE=schickel;270858]it may have spent the time calculating the sequence to a higher value than it was[/QUOTE]

So are you saying by simply inquiring on a sequence the data base will extend it a predetermined amount?

Some neighboring sequences I have not "touched" include:

1840470
1840566
1840608
1840650
1840662
1840830
...
1840968
1841136
1841160
1841168
1841172
1841394
1841520

[QUOTE=RichD;270859]So are you saying by simply inquiring on a sequence the data base will extend it a predetermined amount?[/QUOTE]Syd would know exact details, but it seems to extend a "fresh" sequence until it hits a composite that won't trial factor....try it with a random 8-10 digit number and you can see what it does.

I think that after it stalls it doesn't calculate any further, but any leftover composite goes into the unfactored composite queue and will be factored by someone (local worker or distributed worker) thereby extending the sequence the next time you query it after the factors are reported....