Project Goals (Octoproth and Dodecaproth)

[Greenbank]

OK, I'm still working on the website (I underestimated the time it would take to get it up and running, and overestimated my free time available to work on it!).

Here's what I think we should be going for at the moment...

For n<=55 (maybe even 56)
Complete list of Octoproths for these n values (done to n=54)

For n<=60 (due to limitations in the program)
Complete list of Dodecaproths for these n values (almost there)

For n>60
The lowest Octoproth
The lowest Dodecaproth

[R. Gerbicz]

Originally Posted by Greenbank

For n<=60 (due to limitations in the program)
Complete list of Dodecaproths for these n values (almost there)

I think it isn't impossible to rewrite the programs. Just use almost everywhere mpz_t integers in GMP instead of long long variables, I'll think about it, if I can do it then there won't be limitations in the program ( it won't be slower!) and probably we can find a Hexaproth also by a very-very large computation. I' ve estimated that it is possible that the smallest hexaproth's n value is n=71 but k is about 2^70>kmax limit=2^60 in the program.

[Greenbank]

Originally Posted by R. Gerbicz

I think it isn't impossible to rewrite the programs. Just use almost everywhere mpz_t integers in GMP instead of long long variables, I'll think about it, if I can do it then there won't be limitations in the program ( it won't be slower!) and probably we can find a Hexaproth also by a very-very large computation. I' ve estimated that it is possible that the smallest hexaproth's n value is n=71 but k is about 2^70>kmax limit=2^60 in the program.

I had a quick go as part of my work on the network client.

I'm trying to combined both programs (octo and dodeca) and also move the long long vars to mpz_t.

When I get a bit closer I'll send you my modified source, with the hooks in it needed for the network client that will be ifdef'd out by default.

I was also waiting for the programs to settle down (octo 5.0 and dodeca 2.0) as I don't want to pushing out new clients every other day :-)

[R. Gerbicz]

Originally Posted by Greenbank

I was also waiting for the programs to settle down (octo 5.0 and dodeca 2.0) as I don't want to pushing out new clients every other day :-)

I think that the sieving part now very-very well optimized in c.
Probably in the prp part I can write better than gmp's prp program.

[Greenbank]

Other enhancements to the program:-

1) Status update line to calculate estimated time left ((100-percentage_so_far) * time_taken_so_far / percentage_so_far ).

i.e. currently it outputs:-

Status: 47.7 percentage of the project is complete. Time thusfar: 2408 sec.

It would be nice if it did:-

Status: 47.7% so far. Time thusfar: 2408 sec. Est time remaining: 2640 sec.

where 2408*(100-47.7)/47.7 = 2640 sec.

2) Trigger a status update line to be written out after every possible octoproth/dodecaproth is output.

When checking complete ranges like n=55 the octoproths are output so frequently that it is hard to see the status lines. If a status line is written out aften every octoproth/dodecaproth then the current status will always be visible.

[R. Gerbicz]

Originally Posted by Greenbank

When checking complete ranges like n=55 the octoproths are output so frequently that it is hard to see the status lines. If a status line is written out aften every octoproth/dodecaproth then the current status will always be visible.

OK, this will be in a future version.
Your G5 is so fast

[Greenbank]

Originally Posted by R. Gerbicz

OK, this will be in a future version.
Your G5 is so fast

Having liquid cooled dual-core dual-cpus helps. http://homepage.mac.com/thunderaudio/PhotoAlbum11.html

The main reason GMP is so fast is thanks to Phil McLaughlin and Rogue for writing some G5 specific assembly code optimisations that allow GMP to be compiled natively 64-bit.

The 64-bit x86 optimisations for GMP should be even faster but they haven't been released yet. (GMP 4.2 or GMP 5.0, whichever comes out next, will fly!)

[Kosmaj]

I'd like to suggest that posts in Octo/Dodeca-Proth reservation threads are not removed any more. These are forum threads, not web pages. Telling about one's search experience like this one is interesting and entertaining both to old and potentially new users. Furthermore, it's easy to mistakenly remove reports about found primes. Currently, for example, smh's report about found OctoProths for n=197 is missing.

It will be good to hear what the others think about this and other project related issues.

[Greenbank]

Originally Posted by Kosmaj

I'd like to suggest that posts in Octo/Dodeca-Proth reservation threads are not removed any more. These are forum threads, not web pages. Telling about one's search experience like this one is interesting and entertaining both to old and potentially new users. Furthermore, it's easy to mistakenly remove reports about found primes. Currently, for example, smh's report about found OctoProths for n=197 is missing.

It will be good to hear what the others think about this and other project related issues.

OK, you raise some good points and I hope everyone realises that I'm not trying to run this thing as some kind of evil dictator. You'll notice both robert44444uk and Dougy are both moderators for this forum too.

The reason for keeping that thread clean is that it makes it much easier for people to see which n's are not reserved. I can't be around 24 hours a day to keep the reservation post up to date so the alternative is to wade through some 30 posts to see if the specific n has been reserved by someone else or even results posted for it without a reservation.

For Dodecaproths this isn't too bad as there are much fewer dodecaproths than octoproths for a specific n, but for the Octoproth thread it will quickly become unreadable.

How about this for a compromise. I will create another 2 threads to hold the posts that were 'deleted' from the reservation threads (both octo and dodeca). Inside these will be all of the results posted, plus the reservations and the general history amongst us searchers.

The posts that I have already deleted are not really deleted, they are just hidden from view to non-moderators. I can easily resurrect them and move them to these new threads. Indeed, if it was a case of permanently deleting them I would probably have gone with this method anyway, I don't like deleting information.

I had intended the website to be up and running by now, all of the Octoproths found would be entered into the underlying database and available for all to search and download.

Due to the sheer number of some we have found (n=55 is almost complete and the count stands at 583061 already) listing them all on a website is not viable.

Later on today I'll post some ideas on how I want to present the information on the website, and how this would link in to picking ranges to reserve. I'll do this in a separate thread to make it easier to follow the conversation.

While I'm on the subject please, everyone, feel free to create new threads if you have a new idea, a new direction, a new this or that. Don't feel you have to keep posting in one of the current threads, we have loads of space!

Thoughts everyone?

[Greenbank]

Well if no-one objects I'll implement this tomorrow then.

[Kosmaj]

The reason for keeping that thread clean is that it makes it much easier for people to see which n's are not reserved. I can't be around 24 hours a day to keep the reservation post up to date so the alternative is to wade through some 30 posts to see if the specific n has been reserved by someone else or even results posted for it without a reservation.

What I'm saying is that you just leave those posts in place while keep on updating the summary in post #1.

I also wonder whether Dougy and other OctoProth old-timers know that the thread was moved here. The project was created at once with almost no anouncement in the original thread in the Math forum. I'll mail Dougy to see.