FactorDB is moving to another server this night -> some downtime

[science_man_88]

Originally Posted by Syd

Maybe. I just grabbed an old backup with the ecm data, lets see if it can be imported ..



Good idea. This might lower the load average a bit.



Forgot to upload this file. Should work now.



Fixed this one.

Btw: I´m exporting the last line of every aliquot sequence to a seperate file now. It wont update, its just whats in the db now. If anyone has a use for it:

http://factordb.com/endings

The file is still growing.

isn't that kinda what Allseq.zip does it shows a list of last know ends for open sequences that aren't reserved ? edit: but I do see a use for this in the aliquot genealogy project.

[kar_bon]

Originally Posted by science_man_88

isn't that kinda what Allseq.zip does it shows a list of last know ends for open sequences that aren't reserved ? edit: but I do see a use for this in the aliquot genealogy project.

1. It shows for every seq the last term not only for open seqs.
2. That's the reason I asked about such file.

[science_man_88]

Originally Posted by kar_bon

1. It shows for every seq the last term not only for open seqs.
2. That's the reason I asked about such file.

the fact that it shows finished sequences is why I think it could be used for the aliquot genealogy project because it gives ending primes that are actually used not necessarily all primes. the problem is getting the pathways in between unless we just group them by end prime.

[henryzz]

Originally Posted by Syd

Btw: I´m exporting the last line of every aliquot sequence to a seperate file now. It wont update, its just whats in the db now. If anyone has a use for it:

http://factordb.com/endings

The file is still growing.

Would it be possible to add iteration numbers to the file? If enough info is in this file(I think just iteration numbers are needed. We can generate drivers etc.) then we won't ever have to pull all the sequences the slow way again reducing server load.

[EdH]

Originally Posted by Syd

...
Btw: I´m exporting the last line of every aliquot sequence to a seperate file now. It wont update, its just whats in the db now. If anyone has a use for it:

http://factordb.com/endings

The file is still growing.

Excellent! This is what I was looking for when I initiated the Genealogy thread. But, as already mentioned, the iteration would help, too.

Thanks for all the great work, Syd.

[Syd]

Originally Posted by EdH

Excellent! This is what I was looking for when I initiated the Genealogy thread. But, as already mentioned, the iteration would help, too.

I also added the iteration (@n=...), but needed to restart the process.

There are some more issues:
- just 200 secs cpu time if not logged in (fixed now, it should have been 2000 secs)
- large numbers (~>200kbit) take forever to load. Seems to be an issue with my modified php version.

[EdH]

Originally Posted by Syd

I also added the iteration (@n=...), but needed to restart the process.

There are some more issues:
- just 200 secs cpu time if not logged in (fixed now, it should have been 2000 secs)
- large numbers (~>200kbit) take forever to load. Seems to be an issue with my modified php version.

Again, excellent! (although, I would have probably used @i=). But, this is great as it is!

Thank you for all the work.

[kar_bon]

Originally Posted by EdH

(although, I would have probably used @i=)

A job for textprocessing awk after this is finished or FIND-REPLACE with a good text editor.

[EdH]

Originally Posted by kar_bon

A job for textprocessing awk after this is finished or FIND-REPLACE with a good text editor.

Hence, the "But, this is great as it is!" Yes, indeed the "n" is arbitrary, but n seems to signify the number at forefront in statements and equations, while the lines in sequences are referred to as (l)ines, (i)terations, (i)ndices, etc. That was my thought for "i."

On to something else: I have noticed a new button on the status page to show a list of certificate contributors. Neat! However, now I have another page to check from time to time. I've certainly supplied a lot more under my name than I realized, though.

Thanks, Syd.

[Syd]

Maybe i would have been a better choice. But now its n ..

There is still a problem with huge numbers >60k digits. Some of them take forever to load.

I tracked it down to the call to mpz_perfect_power_p i use on each number - which takes very long. Must be an issue with my gmp installation.

[science_man_88]

Originally Posted by Syd

Maybe i would have been a better choice. But now its n ..

There is still a problem with huge numbers >60k digits. Some of them take forever to load.

I tracked it down to the call to mpz_perfect_power_p i use on each number - which takes very long. Must be an issue with my gmp installation.

yeah I looked at it a few times timing one minute in between refreshing and I got about 8-9 more hours to reach a 1000000. that was a within the last few hours.