BOINC@Poland

Sprawa jasna. Wiem, co się dzieje, nie wiem dlaczego.

Bezpośrednim winowajcą jest:

mpz_set_ui(mpN,N);

które powinno zamienić 64-bitową liczbę N na GMP, a zamiast tego obcina ją do 32 bitów, czyli w pewnym sensie zachowuje się jak na 32 bitach.

Najprościej zastąpić to wersją uniwersalną, która powinna działać niezależnie od 32/64 bitów:

    mpz_set_ui(mpN,N>>32);
    mpz_mul_2exp(mpN,mpN,32);
    mpz_add_ui(mpN,mpN,N&(INT64_C(4294967295)));

To powinno załatwić sprawę konwersji N do GMP.

Jaką masz wartość GMP_LIMB_BITS ?

Można to druknąć dając gdziekolwiek w programie:
printf("GMP_LIMB_BITS: %d\n",GMP_LIMB_BITS);

Teraz nie mam wątpliwości.
validate_ap26 działa poprawnie co do zasady, ale skopane jest testowanie pierwszości wewnątrz validate_ap26.

Dzięki bugowi z f zamiast N w ogóle cokolwiek przechodzi przez validate_ap26. Gdyby nie ten bug, to najprawdopodobniej program niczego by nie drukował do pliku, a i na ekranie by się mniej pojawiało.

Pomyślę jak temu dziadostwu zajrzeć w bebechy.

EDIT:

Pierwszy test:

Zamiast

Cytat
    mpz_set_ui(mpN,f);

    if (mpz_probab_prime_p(mpN,9) == 0)
      break;

daj

Cytat
    mpz_set_ui(mpN,N);
{
char kuku[128];
int pipi;
FILE *fifi;

fifi=fopen("BUG.TXT","at");
mpz_get_str(kuku,10,mpN);

fprintf(fifi,"%"PRId64" %s\n",N,kuku);


    if ((pipi=mpz_probab_prime_p(mpN,9)) == 0)
{fprintf(fifi,"zlozona %"PRId64" %s %d\n",N,kuku,pipi);
fclose(fifi);
      break;
};
fprintf(fifi,"pierwsza %"PRId64" %s %d\n",N,kuku,pipi);
fclose(fifi);
};

i zobacz, co się pojawia w BUG.TXT

To wisi na testowaniu pierwszości GMP. Jeżeli to działa źle, jak przy AP19 u mindca, to stąd się może brać problem validate_ap26.

Jednak nadal nie rozumiem, dlaczego ten 11-elementowy kawałek AP25 został wydrukowany do pliku.

EDIT:

No dobra, teraz doczytałem, że pierwszość GMP przetestowałeś i jest OK.

To ja już nic nie rozumiem.

EDIT:

Myślę, że po prostu sprawdzanie pierwszości w programie działa trochę źle. Trochę, tzn. najczęściej daje dobre wyniki, ale nierzadko się myli w obie strony (tzn. liczby pierwsze oznacza jako złożone, a złożone jako pierwsze). Te pomyłki powodują z jednej strony, że gubi się rozwiązania, a z drugiej strony validate_ap26 nie chce przepuszczać lipy.

Żeby podważać poprawność validate_ap26 musiałbym wiedzieć, jakie rozwiązania są oznaczane jako Non-solution i się im przyjrzeć. Wtedy będę wiedział, czy są odrzucane słusznie, czy niesłusznie.

EDIT:

W/g mnie tam jest bug, zamiast

mpz_set_ui(mpN,f);

powinno być

mpz_set_ui(mpN,N);

Napisałem o tym do Geoffa. Jednak to nie ma prawa mieć związku z Twoimi problemami. Jeśli tu istotnie jest bug, to polega na tym, że weryfikator wielokrotnie sprawdza pierwszość pierwszego wyrazu. To się w żaden sposób nie powinno wiązać z tym, czego doświadczasz. Ani też nie powinno mieć znaczenia póki program działa poprawnie.

Teraz widzę, że same błędy testowania pierwszości tego nie wyjaśniają. W tej chwili nie rozumiem, co się dzieje.

Po przeanalizowaniu wyników jest dla mnie w miarę oczywiste, co się dzieje.

Otóż szwankuje procedura testowania pierwszości liczb.

Ja rozumiem to tak: Geoff zastąpił testowanie pierwszości GMP swoją procedurą zyskując 5% prędkości pod linuxem. Użył do tego jakiegoś typu long double, który ma pod linuxem 64 bity precyzji, a w kompilatorach Windowsowych na ogół mniej i stąd problemy. Jeśli się nie uda zmusić Windowsów do takiej precyzji (chyba o tym coś było w tym wątku PrimeGrida), to jednym z najprostszych rozwiązań jest powrót do GMP.

Ja nie wiem na ile Geoff wtopił swoją procedurę w kod, ale w zasadzie problem sprowadza się do podstawienia innej definicji procedury PrimeQ.

Oryginalna procedura używająca GMP jest w PrimeQ64.h w katalogu
http://www.math.uni.wroc.pl/~jwr/AP26
plik AP26.ZIP - to mój program, który był modyfikowany przez Geoffa.

W ostateczności, gdyby PrimeQ64.h szwankowała, można wziąć procedurę z PrimeQ.zip w http://www.math.uni.wroc.pl/~jwr/BaP

Cytat: sesef w 16 Styczeń 2009, 18:26
Przepraszam bardzo, jakie muszą być parametry startowe dla AP26, udało mi się skompilować na x64 appa z PrimeGrida jednak nie wiem czy coś mi nie działa czy podaje złe parametry startowe.

Kompilowane na Windowsowym porcie oryginalnego GMP. AP19 mi działa więc od biedy AP26 również powinno.

---

Edit.

Najlepiej przydałby się jakiś krótki przedział który na pewno mi zwróci jakiś wynik.

Rozumiem, że kompilowałeś kod z katalogu
http://www.geocities.com/g_w_reynolds/AP26/
plik AP26-boinc-src.zip

Ściągnij także plik AP26-boinc-bin.zip z tego samego katalogu.
Plik z parametrami to AP26-ini.txt - powinien się on znajdować w katalogu, w którym uruchamiany jest program (uwaga: plik z parametrami może zostać zmieniony, przy kolejnej próbie uruchomienia programu trzeba przywrócić wersje początkową).

Jeśli wszystko jest OK, to powinien powstać plik SOL-AP26.txt identyczny z TEST-366384.txt

Przy okazji widzę, że myliłem się co do postępów PrimeGrida - w AP26-boinc-bin.zip jest skompilowany program do Win64, ale on nie jest przystosowany do BOINC i chyba nie był porządnie przetestowany. Można go porównać z własną kompilacją. Ja tego nie robiłem, bo nie mam Win64 (nawet na oczy w życiu nie widziałem komputera z Win64). Ja wiem tylko tyle co zrozumiałem z
http://www.primegrid.com/forum_thread.php?id=1179
a techniczne szczegóły dotyczące kompilacji są dla mnie niezbyt zrozumiałe, więc wiem, że jest problem z kompilacją, ale nie wiem dokładnie, gdzie on leży.

Oto wskazówki dla szukających AP20 o minimalnym początku.

Po pierwsze, skompilować program z Ap20.zip z http://www.math.uni.wroc.pl/~jwr/BaP/ i postępować zgodnie ze wskazówkami w pliku Opis.txt. W razie problemów można zamiast PrimeQ64.h wczytać procedurę z PrimeQ.zip z tegoż katalogu.

Sugeruję, aby na początek brać kolejne s=1,2,...,46 i dla każdego s liczyć K do 10M.

Jeśli ktoś pisze "Biorę s=7", to znaczy, że uruchomi
./ap20 7 1 10000000

***************************

Statystyki oraz ranking (s -> liczby AP20 do AP15, kto)

0-10M 1 -> {0, 0, 1, 5, 4, 13} emik
0-10M 2 -> {0, 1, 1, 1, 4, 14} emik
0-10M 3 -> {0, 0, 0, 6, 4, 17} emik
0-10M 4 -> {0, 0, 1, 3, 7, 8} sesef
0-10M 5 -> {0, 1, 1, 0, 5, 18} sesef
0-10M 6 -> {0, 0, 1, 2, 7, 20} sesef
0-10M 7 -> {0, 0, 1, 4, 5, 18} Szopler
0-10M 8 -> {0, 0, 1, 1, 7, 21} emik
0-10M 9 -> {0, 0, 0, 1, 5, 19} emik
0-10M 10 -> {0, 0, 0, 2, 2, 16} sesef
0-10M 11 -> {0, 0, 0, 4, 5, 24} sesef
0-10M 12 -> {0, 0, 0, 3, 3, 13} sesef
0-10M 13 -> {0, 0, 2, 5, 9, 16} sesef
0-10M 14 -> {0, 0, 3, 3, 4, 12} emik
0-10M 15 -> {0, 0, 3, 1, 2, 22} sesef
0-10M 16 -> {1, 0, 0, 2, 7, 20} sesef
10M-20M 1 -> {0, 0, 1, 0, 2, 13} sesef
10M-20M 2 ->  emik
10M-20M 3 -> {0, 0, 0, 1, 1, 10} sesef
10M-20M 4 -> {0, 0, 0, 1, 4, 9} sesef
10M-20M 5 ->  sesef

Razem: {1, 2, 16, 45, 87, 303}

1. sesef {1, 1, 9, 24, 54, 189}
2. emik {0, 1, 6, 17, 28, 96}
3. Szopler {0, 0, 1, 4, 5, 18}

Cytat: Szopler w 16 Styczeń 2009, 18:29
Ciekawie jest... 1 AP19 na tyle liczenia :). Jakie jest prawdopodobieństwo, że przed 1 000 kk będzie następna ;)?

Trudno to dokładnie oszacować, ale myślę, że mniejsze od 50%. Czym dalej, tym bardziej szanse maleją, bo wchodzimy w coraz to większe liczby. Niestety, nie każde poszukiwania kończą się sukcesem. Czasami trzeba w którymś momencie zdecydować o przerwaniu poszukiwań i przerzuceniu się na inny cel. Trzeba też pamiętać, że najlepsze wyniki często są uzyskane przez poszukiwania, które wydają się bez szans, ale szukający miał kupę szczęścia.

Sądzę, że w chwili obecnej AP20 daje większe szanse na znalezienie rozwiązania. Być może ze względów psychologicznych warto zawiesić AP19 i przenieść się na AP20. Albo trzymać oba fronty otwarte i każdy sobie wybierze, co woli.

Zaraz otworzę wątek AP20 z sugestiami jak szukać, gdyby ktoś chciał. Nieważne, czy ktoś chce w to wchodzić już teraz, czy to sobie trochę poczeka.

Cytat: mindc w 16 Styczeń 2009, 11:26

Cytat: Jarek Wróblewski w 12 Styczeń 2009, 16:50
(...) Z tym, że nam był potrzebny program na własny użytek, więc można było zrobić jakąś łatankę na kolanie - mindc miał jakieś syfiate GMP, które co prawda pierwszości porządnie testować nie umiało, ale z którego dało się wybrać coś, co działa poprawnie, i jakoś to ruszyło.

używałem intelowskiej biblioteki GMP  :ph34r:

Jednakowoż trzy fakty są bezsporne:

1. Twoje GMP nie radziło sobie z testowaniem pierwszości liczb 64-bitowych.

2. Dało się to obejść.

3. Z kompilacją zaszedłeś dalej niż jest obecnie PrimeGrid.

Jak rozumiem, problemem jest to, że na razie nikt tam nie umie sensownie skompilować wersji Win64. Co prawda kompilacja się udała, ale za cenę 2.5-krotnego spowolnienia programu, co jest nie do przyjęcia.

AiDec i mindc:
Wygląda na to, że blah i  Skligmund są na razie poza Waszym zasięgiem, natomiast
4.  [B@H] Clooney 3,008
od długiego czasu nie ruszył się z miejsca, więc macie szansę go wyprzedzić za kilka dni i zrobić trójkę Polaków w pierwszej piątce.

Będę Wam kibicował.

ksysju: Gratuluję 20,000 WU i trzymam kciuki za pięćdziesiątkę w styczniu.

Statystyki przedziału 1-100mln (w nawiasie 25M-50M, 50M-100M), EDIT: 100-200mln:

AP15 - 243 (62, 84), 130
AP16 - 64 (16, 16), 35
AP17 - 26 (7, 7), 14
AP18 - 5 (4, 0), 2
AP19 - 1 (0, 0), 0

Morał z tego jest z grubsza taki, że jedno AP19 w tym przedziale jest w sam raz - trudno mówić o szczęściu lub pechu.

Czym dalej, tym rozwiązania będą pojawiać się rzadziej. Jak będzie pokryty cały przedział 100M-200M, trzeba będzie przeliczyć, ile tam jest rozwiązań.

To na pewno nie jest ten problem, o którym pisałem. To już jest nowsza generacja próbek, np. ...27
się nazywa:
ap26_168602_168605_0_0
tu są 4 kolejne K, bo 168603 odpada jako podzielne przez 43.
Zresztą jak widać ktoś to potem przeliczył.
Czyli to nie wina próbek, tylko coś u Ciebie zaszwankowało, ale nie podejmuję się zgadywać co. Może to losowe i jednorazowe.

A jeśli chodzi o uruchamianie Windy, to wygląda na to, że PrimeGrid walczy ze skompilowaniem tego pod Win64.
Geoff Reynolds jest raczej specem od kompilowania pod linuxem, a inni jak dotąd dostają różnego rodzaju błędy.

To są chyba problemy w tym duchu, co my mieliśmy z kompilacją AP19 - w jednym systemie chodzi, a w drugim coś się zacina. Z tym, że nam był potrzebny program na własny użytek, więc można było zrobić jakąś łatankę na kolanie - mindc miał jakieś syfiate GMP, które co prawda pierwszości porządnie testować nie umiało, ale z którego dało się wybrać coś, co działa poprawnie, i jakoś to ruszyło.

No ale oni to chcą mieć porządnie skompilowane, więc to trwa...

Wysiłki kompilacyjne można śledzić tutaj:
http://www.primegrid.com/forum_thread.php?id=1179

Cytat: TJM w 12 Styczeń 2009, 14:25
Tak, mi się wysypywały zaraz na początku, zajrzyj na stronę w te WU - pewnie u wszystkich się sypnęły, tak właśnie było w moim przypadku.

Na początku oni bezmyślnie robili próbki z trzech kolejnych K.
K podzielne przez liczbę pierwszą z zakresu 29-59 są pomijane przez program.
Próbki, które zawierały 3 takie K nie miały nic do roboty i zwracały błąd, a potem gdzieś tam wisiały i krążyły między użytkownikami.

Zdaje się, że teraz próbki zawierają tyle kolejnych K, żeby dokładnie 3 były niepodzielne przez 29-59.

Cytat: ksysju w 12 Styczeń 2009, 14:16
Witam

Czy komuś "wysypywały" się próbki?

Ostatnio na dwóch kompach miałem tak po kilkanascie sztuk wu  z errorem po sekundzie, dwóch.
Na obu w tym samym czasie (sobota-niedziela). Może przypadek, może coś więcej.

--
ksysju

Czy jesteś w stanie podać namiary na te próbki?

Tutaj
http://www.primegrid.com/forum_thread.php?id=1179
toczy się dyskusja nad instalacją Windy. Ja z tego rozumiem, że to jest kwestia odpowiedniego skompilowania i przetestowania programu, więc nie można wykluczyć, że Windę uruchomią lada chwila. No ale mogą się też pojawić jakieś problemy i się trochę pociągnie.

Jak Winda ruszy, to ogłoszenie może się ukazać gdzieś w dziale
http://www.primegrid.com/forum_forum.php?id=38

Na stronie
http://www.primegrid.com/forum_thread.php?id=1182
publikowane są szczegółowe dane dotyczące znalezionych AP23 i dłuższych.

Na razie znaleziono 2 AP24 (w tym jeden ksysju) oraz 3 AP23 (w tym jeden AiDec).

EDIT: AKTUALIZACJA:

Znaleziono 2 AP24 (w tym jeden ksysju) oraz 4 AP23 (w tym dwa AiDec).

Ładnie ciągniesz, AiDec, może dziesiątkę dogonisz. Trzymam kciuki.

Chętnie poznam w realu liczydłowych z mojej okolicy, ale w tej chwili jestem nadziębiony i nie myślę o żadnych spotkaniach. Będziemy w kontakcie.

Cytat: AMT-1 w 04 Styczeń 2009, 13:43
@ksysju
Widze niezłe stadko tam masz i to karmione 64 bitami ;D Tylko pozazdrościć :arrr:

Cosik mi się widzi, że to stadko się rozrasta  XD

Liczby WU w/g PrimeStat:

W dniu 8 stycznia 2009
całe AP26 - 5,387
BOINC@Poland - 3,144 = 58,36 %
ksysju - 2,832 = 52,57 %

Razem do 8 stycznia 2009
całe AP26 - 37,434
BOINC@Poland - 10,958 = 29,27 %
ksysju - 7,939 = 21,21 %

No i jeszcze, nie wolno tego przemilczeć, to prowadzenie drużyny w AP26 to główna zasługa ksysju, który dostarcza większość punktów i prowadzi w kategorii indywidualnej.

Cytat: Troll81 w 09 Styczeń 2009, 08:03
Odpowiedni news już napisany.

Świetnie.

Pomyśl też, czy nie warto się pochwalić także tym:

BOINC@Poland zajmuje pierwsze miejsce w podprojekcie AP26 Search projektu PrimeGrid mając ponad dwa razy tyle punktów, co następna drużyna.

Nie wiem jakie tu panują obyczaje, tzn. czy reklama na stronie głównej w stylu "64-bitowi linuxowcy mogą pomóc utrzymać to I miejsce" jest stosowna, czy też jednak strona główna zachowuje neutralność i nie reklamuje poszczególnych projektów.

Cytat: KrzychuP w 09 Styczeń 2009, 07:33
Pewnie znasz Jarku Agnieszkę Kazun  ;)

Tak.

 :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack:
:attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack:
:attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack: :attack:

Machloj znalazł AP19 o najmniejszym znanym początku (nowy rekord świata w tej kategorii), dzięki czemu BOINC@Poland (z linkiem) jest wymieniony na stronie rekordowych postępów arytmetycznych liczb pierwszych:
http://hjem.get2net.dk/jka/math/aprecords.htm
Jest to pierwszy rekord z roku 2009.

BOINC@Poland pojawia się 3 razy:
News
Credited programs and projects
Smallest AP-k with minimal start

Zgodnie z obyczajem, przy rekordzie wymienia się kolejno:
Odkrywcę  - Machloj zdecydował wystąpić pod swoim nickiem - wolna wola odkrywcy
Projekt, który organizował poszukiwania - BOINC@Poland
Autora użytego programu - to ja

Również gratuluję, tym razem publicznie. Ogłoszenie wyniku jest w:

http://tech.groups.yahoo.com/group/primenumbers/message/19789

Ponieważ Machloj nie chciał się ujawnić, zgłosiłem znalazcę jako anonimowego. Po wysłaniu przeze mnie ogłoszenia, Machloj zdecydował się na ujawnienie nicku. To już doślę w prywatnym liście do administratora strony

http://hjem.get2net.dk/jka/math/aprecords.htm

On zazwyczaj aktualizuje stronę w tym samym dniu, ale późno. A póki co, szukajcie dalej.

No i ksysju doliczył się do pierwszego AP24.
Co prawda to już było znane, ale próba generalna przed prawdziwymi odkryciami zaliczona  :attack:

Cytat: Mchl w 07 Styczeń 2009, 09:40
Jakby tak jeszcze ktoś od nas znalazł pierwszy AP26 to w ogóle byłoby fajnie :)

Na razie nie ma znalezionych żadnych AP24 ani AP25. Jednak myślę, że AP24 się wkrótce pojawi w statystykach, bo najmniejszy znany AP24 jest na drodze programu, a WU, który ma go znaleźć, został już przydzielony użytkownikowi o nazwie ksysju. No chyba, że ksysju nałykał się tyle WU do buforka, że będzie to liczył przez tydzień, albo, za przeproszeniem, zwróci.

EDIT:

http://www.primestats.net/primegrid/teams.php?project=AP26

1     BOINC@Poland     106,343     7,814
2    BOINCstats    65,774    4,833
3    BOINC@Heidelberg    60,384    4,437
4    PrimeSearchTeam    45,119    3,316
5    BOINC Confederation    21,027    1,545    

http://www.primestats.net/primegrid/users.php?project=AP26

1     ksysju     69,504     5,107
2    blah    50,464    3,708
3    [B@H] Clooney    40,937    3,008
4    Skligmund    36,174    2,658
5    Lumiukko    23,926    1,758

Może warto namówić więcej linixowców 64-bitowych, żeby pomogli utrzymać to prowadzenie.

Może warto się tym gdzieś na stronie głównej pochwalić. A nuż ktoś rzuci jakiś superpunktujący projekt i przerzuci swoje moce na ten front.

Cytat: emik w 07 Styczeń 2009, 19:49
Panie Jarku - rozumiem, że możemy dopiero chwalić się w tym wątku jak utworzy nam plik SOL-AP19.TXT

Tak. Jeśli ktoś dostanie plik SOL-AP19.TXT to niech się pochwali.

Jednak nie kasujcie pliku ze śmieciami SOL-AP15.TXT - jeśli nie znajdzie się rozwiązanie, to może będę chciał je kiedyś przeanalizować.

Myślę, że "Jarku" w zupełności wystarczy, nie ma potrzeby utrzymywać sztucznego dystansu, zwracanie się na "Ty" lub po imieniu jest w/g mnie odpowiedniejsze.

Cytat: Szopler w 07 Styczeń 2009, 17:32
Jak dzielimy zakresy?

Moja sugestia. Piszcie tu po kolei posty:
Biorę od ... do ...

Cytat: Szopler w 07 Styczeń 2009, 17:32
tylko jeszcze z nazwą pliku trzeba by coś zrobić bo ap19 tworzy wynik ap15 ;).

To jest celowe. W pliku SOL-AP15.TXT są zapisywane wszystkie AP15 i dłuższe. Z punktu widzenia poszukiwań są to śmieci, ale takie śmieci dobrze jest zapisywać, żeby wiedzieć co się dzieje - ile jakich rozwiązań znajduje program, np. ile 18-tek, 17-tek.

Jeśli będzie AP19, to będzie zapisane w SOL-AP15.TXT oraz w SOL-AP19.TXT (dwa razy).

Cytat: RAD-Poland w 05 Styczeń 2009, 18:54
nie dowierzałem, że taki wynik osiągnął nasz ksysju :parrrty:

zrobiłem na szybko pełną statystykę stan na 05-01-09 20:15
łączna liczba przeliczonych wu podprojektu AP26Search = 23898

ksysju zrobił swoje, a ja mam podejrzenie, że reszta dopchnęła BOINC@Poland na I miejsce w AP26. Czy ktoś jest w stanie to sprawdzić?

Dogrzebałem się ręcznie do:
BOINC@Poland 4,604
[B@H] Clooney ->  BOINC@Heidelberg  4,403
blah -> niezrzeszony
Skligmund ->  BOINCstats 3,145

dalej nie miałem cierpliwości przeglądać...

Może to w końcu zadziała
http://www.math.uni.wroc.pl/~jwr/BaP/
plik PrimeQ.zip

@bartsob5: Tak, pracuję na Uniwersytecie Wrocławskim. O żadnych łatwo dostępnych superkomputerach mi nic nie wiadomo.

@mindc: No to chyba teraz wiadomo tyle, że to Twoje GMP jest jakieś lewe, przynajmniej test pierwszości daje wyniki do bani powyżej 2^32.

Zaraz pomyślę nad następnym testem, może da się to obejść...

EDIT

Spawa jest banalna. Robisz program

Cytat
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <gmp.h>
int main(int argc, char *argv[])
{
int i;
char c[64];
char d[64];
mpz_t n;
mpz_t m;
mpz_t dwa;
mpz_init(n);
mpz_init(m);
mpz_init(dwa);
mpz_set_str(n,"15000000019",10);
mpz_set_str(dwa,"2",10);
for(i=1;i<=12;i++){
mpz_add_ui(n,n,2000000000);
mpz_powm(m,dwa,n,n);
mpz_get_str(c,10,n);
mpz_get_str(d,10,m);
printf("%s %s\n",c,d);
};
mpz_clear(n);
system("PAUSE");
return 0;
}

Jeśli dostajesz dokładnie to

Cytat
17000000019 1855924640
19000000019 18764911666
21000000019 2
23000000019 8
25000000019 14662086300
27000000019 2
29000000019 25672840505
31000000019 3693428967
33000000019 8068775031
35000000019 134217728
37000000019 16095345138
39000000019 38213931463

to jestem w stanie prosto napisać procedurę testującą pierwszość.

Jeśli dostajesz cokolwiek innego, to przynajmniej wiadomo, co można zrobić z Twoim GMP - ale tego już nie napiszę na forum ;)

Co do wersji na Win64, to jak mnie poinformowali administratorzy, może to być kwestia rzędu miesiąca. Czyli raczej nie należy oczekiwać w najbliższych dniach. Wiadomo też, że oni mają kupę innej roboty i takie rzeczy często się opóźniają. Np. samo przygotowanie projektu AP26 trwało pól roku. No więc Windowcy 64 bitowi muszą uzbroić się w cierpliwość, albo zrobić przesiadkę.

A ksysju ma wynik imponujący. Gratulacje! Tak trzymać!

Zapytałem administratorów PrimeGrida o orientacyjny termin wersji Win64, jak mi coś konkretnego odpowiedzą, to się wieściami podzielę.

Jeśli dobrze interpretuję te liczby WU, to mi wychodzi, że ksysju wyrabia jakieś 10% przerobu całego AP26. To by wymuszało miejsce w pierwszej dziesiątce. Czy takie statystyki są już gdzieś dostępne?

Można powiedzieć, że poszukiwanie AP to sztuka dla sztuki. Chociaż nigdy nie wiadomo, kiedy taka sztuka dla sztuki znajdzie zastosowanie, bo przy okazji rozwija się różne algorytmy. Ale przede wszystkim to zabawa dla ludzi zafascynowanych tymi rzeczami. Przy okazji weryfikująca pewne teorie, wyobrażenia o występowaniu i rozmieszczeniu liczb pierwszych.

Poszukiwania dużych liczb pierwszych, takie jak to robi np. PrimeGrid, czy też publiczne poszukiwania jakichkolwiek liczb pierwszych, w kryptografii zastosowania nie mają absolutnie żadnego. Po pierwsze, nikt przy zdrowych zmysłach nie użyje w kryptografii liczb pierwszych ogólnie znanych, bo istotą zastosowania liczb pierwszych w kryptografii jest ich tajność, a więc m.in. w żadnym wypadku nie mogą mieć one żadnej szczególnej postaci. Po drugie, te liczby nie mogą być zbyt duże, bo zakodowanie krótkiej wiadomości nie może trwać paru tygodni, a tak by było, gdyby użyć liczb o milionach cyfr.

Uczciwie mówiąc, z kryptografią wiąże się bardziej umiejętność rozkładania liczb na czynniki pierwsze, bo to pozwala łamać szyfry. Liczby pierwsze używane w kryptografii mają po kilkaset cyfr, ich znajdowanie dla potrzeb kryptografii nie jest żadnym problemem, znajduje się je w ułamku sekundy. Kryptografia używająca liczb pierwszych też wyrosła z takiej sztuki dla sztuki, jednak w obecnym czasie znajdowanie liczb pierwszych dla potrzeb kryptografii nie jest wyzwaniem obliczeniowym. Teoria matematyczna zrobiła swoje i już.

Cytat: mindc w 04 Styczeń 2009, 18:18
a może chodzi o to, że podczas kompilacji sypie mi warningami o
konwersji '__int64' na 'unisgned int',  po modyfikcjach pliku PrimeQ64.h
lub konwersji '__int64'  na 'int' w pliku AP19.h
może dlatego gubimy liczby powyżej 2^32 z powodu właśnie niezamierzonej konwersji typów

W AP19.h sobie może sypać warningami, bo nie mapowałem wyraźnie typów, to powinno być OK. Coś jest skopane w definicji PrimeQ i teraz już nie wiem co.

***********

Sprawdzenie procedury PrimeQ:

Robimy plik PrimeQ.h:

Cytat
int PrimeQ(long long value)
{
   int out;
   char c[64];//usunac jak bedzie OK
       mpz_t  n;
       mpz_init(n);

mpz_set_ui(n,(unsigned int)(value>>32));
mpz_mul_ui(n,n,1<<16);
mpz_mul_ui(n,n,1<<16);
mpz_add_ui(n,n,(unsigned int)(value&((1LL<<32)-1)));

       out=mpz_probab_prime_p (n,1);

mpz_get_str(c,10,n);//usunac jak bedzie OK
printf("%s %d\n",c,out);//usunac jak bedzie OK

       mpz_clear(n);
       
       return out;

}

oraz Test.c:

Cytat
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <gmp.h>

#include "PrimeQ.h"
int main(int argc, char *argv[])
{

int i;

long long n;

n=1000000019;

for(i=1;i<=13;i++)
{
n+=2000000000;
PrimeQ(n);
};

system("PAUSE");

  return 0;
}

Po skompilowaniu i odpaleniu Test.c powinien dać na 32 lub 64 bitach:

Cytat
3000000019 1
5000000019 0
7000000019 0
9000000019 0
11000000019 0
13000000019 0
15000000019 0
17000000019 0
19000000019 0
21000000019 1
23000000019 0
25000000019 0
27000000019 1

EDIT:

@mindc: Jak będę wiedział, jakie wyniki drukuje u Ciebie powyższy test, to dopiero wtedy możemy coś dalej kombinować. To się powinno zachowywać jak wyżej, niezależnie od liczby bitów.

Cytat: TJM w 04 Styczeń 2009, 16:32
No chyba, że mamy jakąś pewność, że byłoby co liczyć przez co najmniej parę  miesięcy - wtedy można coś w tym temacie pomyśleć.

Zagadnień do liczenia na dowolnie długi czas mogę spokojnie dostarczyć. Na razie jest chyba trochę przedwcześnie, aby mówić o szczegółach BOINC-ów czy serwerków. Myślę, że najpierw parę w miarę krótkich zagadnień trzeba rozwiązać dzieląc zakresy ręcznie. To pokaże nam wszystkim, na czym polega ta zabawa i jakie się mogą pojawiać problemy. Na dłuższą metę rozdział zadań musi być automatyczny, więc jakiś serwerek to chyba absolutne minimum, jeśli mamy zamiar myśleć o czymś poważnym.

Pusto, bo głupotę napisałem. Zamiast

mpz_add_ui(n,n,(unsigned int)(value^((1LL<<32)-1)));

powinno być

mpz_add_ui(n,n,(unsigned int)(value&((1LL<<32)-1)));