Jajcenty

Testowałem taką możliwość również. zakładałem tablice małych liczb pierwszych i względem nich sprawdzałem. To dało zejście z 48 do 27 sekund czyli całkiem sporo. Próbowałem tablice małych pierwszych o rozmiarach od 1024 do 65355. O dziwo, rozmiar nie ma znaczenia. Powyżej 32768 miał miejsce lekki spadek wydajności. Ostatecznie używałem tablica[8192] pierwszych pierwszych, ale po wprowadzeniu dzielenia prze 6i+1 przestały działać. Obecnie cały zysk na szybkości to ten fragment: ulong MAX = (ulong)Math.Sqrt(Number); ulong dvd = 12; //divide by 6i-1 and 6i+1 while (dvd <= MAX) { dvd -= 1; if (Number % dvd == 0) return false; dvd += 2; if (Number % dvd == 0) return false; dvd += 5; } return true;

Aktualizacja. ulong 264 bitów, zszedłem do 16,7 sek/pierwszą ; przerabiam 2,48 liczby/sek. Użyłem chwytu od Xitami: dzielę przez liczby 6i-1 i 6i+1. Dużo więcej z tego nie wyduszę. Algorytm startował od 54 sek. Zeszliśmy wspólnymi siłami do 17, zatem trzykrotny wzrost szybkości. Punkt honoru został ustalony na 10 razy, więc jeszcze trochę. Niniejszym uznaję swoje ostatnie miejsce w konkursie jednowątkowym, i poszukam szczęścia w wielu wątkach, tak by dobić do 5 sekund per liczba pierwsza. Na pocieszenie mam, że w przeciwieństwie do mnie, primesieve.org nie potrafi pełnego ulonga. Pisownia oryginalna: Please use positive integers < 2^64 - 2^32*10

To akurat cecha giełdy, Każdy analityk ma doskonałe wyjaśnienie dlaczego mylił się wczoraj. W konkursach gry na giełdzie dobrze sobie radzą małe dziewczynki i małpy (losowe inwestycje). Stanley już poruszył kwestię: jeśli ze zbioru usuniemy podzbiory wybierane według reguł czyli nielosowe, to pierwotny biały szum przestaje być biały. Ja jednak uważam, że staje się jedynie "bledszy".

dla long: 29 sek na pierwszą; 1,45 liczby/sek dla long akurat na początku są jakieś duże przerwy między pierwszymi 00:00:21.1394624 9223372036854775783 00:00:44.2416246 9223372036854775643 * 00:00:47.4166287 9223372036854775549 * 00:00:49.0677030 9223372036854775507 * 00:00:44.9756219 9223372036854775433 * 00:00:21.1411755 9223372036854775421 jeśli odrzucić odstające wyniki to mamy jakieś 21sekund na pierwszą.

Bo nie o to chodzi by złapać króliczka lecz by gonić go. Tak formalnie to Astro podał rozwiązanie. http://primesieve.org/ Tylko brać i generować, ale gdzie tu zabawa? Update: Niechętnie dodałem dodałem do Erastotenesa pregenerowaną small prime table[4096]. Ta tablica jest pierwsza do sprawdzania podzielności. Co ciekawe jej rozmiar wydaje się nie mieć dużego wpływu. jedna liczba pierwsza kosztuje teraz średnio 26 sekund (było 47) / 2.6 sekundy per 64 bitowy integer. Wynik (timespan, prime) 00:00:26.4980836 18446744073709551557 00:00:24.9163866 18446744073709551533 00:00:24.9338560 18446744073709551521 00:01:12.1850855 18446744073709551437 !!! dziura na 84 liczby 00:00:24.6580624 18446744073709551427 00:00:36.9004336 18446744073709551359 00:00:24.6210776 18446744073709551337 00:00:50.9192274 18446744073709551293 00:00:24.5627875 18446744073709551263 00:00:24.8693882 18446744073709551253

Dla mnie bomba. Widać że nie ma większych trudności z uzyskaniem 10e8 liczb pierwszych rzędu 10e18. A oni zatrzymali się na 1oe7 liczb rzędu 10e12. Teraz powinieneś im je posłać. Ja ciągle płacę 47 sekund za prime'a, ale się nie poddaję Prze weekend coś wymyślę. Tak, spirala Ulama miała być naocznym dowodem na nielosowości pierszych, ale tłumaczono mi że to tylko przypadek. Dla mnie wskazówką podejrzanego zachowania pierwszych jest twierdzenie Gaussa o liczbie Podejrzana sprawa

Podaj proszę jaką największą liczbę znalazłeś? Czasy jakie podałeś u mnie osiągam dla ulong.MaxValue/10. Coś mi tu nie gra.

I tak będą nieporównywalne bo mamy różne maszyny. A jednowątkowo to się nawet nie zbliżymy do jakiś rozsądnych czasów. Tak się zastanawiam. Skoro w publikacji chodzi o korelację między ostatnimi cyframi, to może nie trzeba pamiętać wszystkiego, a wystarczy tablica 10x10 do zapamiętania częstości par. Tak, zajarzyłem w końcu. Przyczyną jest funkcja. Kompilator słusznie nie chciał uronić ni jednego efektu ubocznego. Dobry krzemiak. EDYCJA: Po ostatnich zmianach 48 minut / 100 największych. Urwaliśmy 6 minut z 54. Astro urwał 4. Brawo Astro!

No nie wiem. Nie widzę jak zmienna Number miałaby się zmienić w ramach pętli for. Ale OK, nie pierwszy raz mamy kontrowersję z kompilatorem. Skoro tak uważasz - nie ma sprawy.Specjalnie dla Ciebie będę sufiksował, nigdy prefiksował.

Muszę zobaczyć cudzy gotowy kod używający tej własności. Wtedy będę wiedział. Na razie odsuwam to koniec listy. I dobrze. Masz rację. Cymbał kompilator liczy to za każdym razem. Duży plus dla Ciebie, a ja się czuje zrobiony w bambuko - jestem prawie pewien, że powinien to zoptymalizować do stałej. A tu nie wiem o co chodzi - skomentowałem przeca edycję? Nie zmiąchałem też, za dużo?. Ot 1 zmieniła się na 2 .

Tak oczywiście mogę ustawić flagę, wykonać break i sprawdzenie flagi żeby zobaczyć jak wyszło z wewnętrznej pętli. Walczymy o każdy cyk zegara, więc goto i posprzątane, Ponieważ wykrycie że dvd == 15 albo ogólnie sprawdzenie (dvd > 5 && dvd%5==0) jest kosztowniejsze. Obracamy się w rejestrach procesora i 500/24 jest tak samo kosztowne jak 5555555/2358. Gdybym użył biblioteki do obliczeń z dużą liczbą cyfr, wtedy byłoby się o co bić. Good point. Sprawdzę to, ale jestem pewien że kompilator liczy to raz przy konstruowaniu pętli - sprawdza warunki pirewrszego wejścia. Będizie sporo tych bloków zanim dojedziemy do 2^63. Jakieś 2^31.

Pozwoli, pozwoli. W końcu będzie ich z 50 razy więcej do analizy i będą z ciągłego podzbioru N. Oczywiście mogę ci wygenerować wszystkie, ale Ty dajesz dyski Niestety inline urwało tylko 2 minuty z 54 na 52 minuty. Nie tędy droga. Wreszcie! Po latach! Użyłem! GOTO! I jest to pełnoprawne użycie wyklętej przez teoretyków, ale jak widać niezbędnej instrukcji. do { if (Number % 2 == 0) continue; if (Number % 3 == 0) continue; if (Number % 5 == 0) continue; if (Number % 7 == 0) continue; if (Number % 9 == 0) continue; for (ulong dvd = 11; dvd < Math.Sqrt(Number) + 2; dvd += 2) { if (Number % dvd == 0) goto NotPrime; } file.WriteLine(Number.ToString()); howMuch--; NotPrime: continue; } while (--Number > 0 && howMuch > 0); edit: poprawiłem błąd z powodu upodobania do ostrych nierówności;

Nie wiem, czy o to chodzi: szukamy podzielników N w zakresie 2 do sqrt(N) +1 . Bo wystarcza nam jeden, jakikolwiek podzielnik. Z tym jest trochę problem. Masz zamiar zapamiętać wszystkie pierwsze mniejsze od 263? To całkiem sporo bajtów Rzędu 1017 Pozostaje je tylko policzyć. [ myślę że od tego miejsca należałoby to wydzielić jako offtop ] Historia: zbadano kilkanaście milionów liczb pierwszych rzędu 1012 i stwierdzono pewne regularności sugerujące nielosowość liczb pierwszych. Oprotestowałem to, twierdząc że ja i mój wierny laptop potrafimy lepiej. Po wstępnym zmierzeniu się z problemem muszę trochę odpuścić z pierwotnych założeń. Ponieważ część z nas nie ma dostępu do 64 bitowych liczb bez znaku, możemy sformułować następujące wyzwanie: Wygenerować i zapamiętać 108 największych 63 bitowych liczb pierwszych. W ten sposób uzyskamy 100 milionów liczb pierwszych (oni tylko kilkanaście milionów) rzędu 1017. Ci najbardziej zaciekli powtórzą i zweryfikują obliczenia z artykułu. Ale to już fakultatywnie

Właśnie Piersze co zrobię to isPrime() jako inline. Potem wątki. ulong Number = ulong.MaxValue; ulong howMuch = 100; do { if (isPrime(Number)) { file.WriteLine(Number.ToString()); howMuch--; } } while (--Number > 0 && howMuch > 0); tak, wiem, formalnie powinno być howMany, ale mu tu wszyscy kochamy dźwięk "hałmać".

Och, tak. Ale dopóki trzymamy się poniżej 19 cyfr znaczących to sprawdzanie podzielników na podzielność przez 5 dokłada roboty. Chyba że umiemy z 2n+1 wywalić te podzielne przez 5 nie używając modulo? Nic to nie zmieniło, ale rzecz jest do dalszego śledztwa - mimo nastaw x64 kompilator z uporem produkuje win32. Włoski strajk? W każdym razie mój naiwny, jednowątkowy algorytm dostarczył 100 liczb pierwszych w 54 minuty, na dobę jakieś 2500. Obciążenie procesora mniejsze od 25% Czyli kicha, słabo i nędza z mułem. Postawiłem sobie za punkt honoru, że w wolnym czasie wyduszę z niego 10 razy więcej. Oto największy 64 bitowy prime: 18446744073709551557 To chyba nadaje się jako osobny wątek do dyskusji bo w ferworze walki nam to umknęło. Widziałem jedną alternatywną teorię orbitali atomowych, ale jej twórca nie zyskał sobie uznania.

Tak. uint to 4 bajty; System jest 64. Język jak język. Wiele bajerów wspierających, listy, słowniki zdejmują ze mnie 3/4 roboty. Sprawdzenie 2^31 dzieleń to około 20 sekund. Spróbuję się zoptymalizować i puścić to na nieco szybszym procesorze. Zobaczymy ile pierwszych znajdę w rozsądnym czasie (tydzień) odliczając w dół od 2^64. Tu nie czuję - dlaczego bez 5? To może też wykrywać wielokrotności 5 i nie dzielić?

Też tak myślę, ale u mnie uint32 jest jakby dwa razy szybszy od uint64; 5160 do 9887 ms @Afoancja sqrt(2^64) = 2^32; tylko nieparzyste 2^31 i +1 za dzielenie przez 2 uint CNT = 1000 * 1000 * 1000; uint i = 0; ulong l = 0; System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch(); sw.Start(); do { i++; uint tmp = i % 3; } while (i < CNT); sw.Stop(); long avgi = sw.ElapsedMilliseconds; sw.Reset(); sw.Start(); do { l++; ulong tmp = l % 3; } while (l < CNT); sw.Stop(); long avgl = sw.ElapsedMilliseconds;

Nie ma problemu. Jak mi dasz trochę czasu to sobie sam napiszę cały potrzebny mi soft. Po prostu ucieszyłem się że kompilator daje wsparcie. Co do reszty to prawdopodobnie ucieszyłem się zbyt wcześnie. Ale i tak mam zamiar sprawdzić ile zajmuje 231 +1 dzieleń, bo jeśli się nie mylę to tyle w najgorszym razie dzieleń potrzebuję by rozebrać 264 Long jest dla mnie egzotyczny. Nawet w bazach trzymam klucz główny w czterobajtowym int.

No fizyk nazwałby to silnym potwierdzeniem - obie hipotezy wzajemnie się wspierają. Niestety o ile pamiętam, matematycy mają głęboką niechęć do dowodów numerycznych. W tym przypadku może się okazać, że efekt braku losowości zmienia się co każde 10100 by efekcie być całkowicie losowym jeśli tylko przedział jest szerszy niż 10200 Te kilkanaście biliardów czyli 1015 to coś dziwnego. Mój laptop bez łaski obsługuje liczby całkowite do 9x1018. Mogli przebadać przedział znacznie szerszy. Zaraz się z Afordancją za to weźmiemy edit: nawet nie wiedziałem: mam tu ulong! Moge se turlać numerki do 1,8x1019. Ha! ulong.MaxValue = 18 446 744 073 709 551 615

Ja mam zęby przystosowane do cedzenia. Planktonem się nie pożywię ale herbacie dam radę

Ale bez cukru, witamin B6 i B12, a najważniejsze bez L-teaniny. Więc nie tak znowu drogo Muszę znaleźć bogate źródło tego cudownego aminokwasu. Czy ktoś tutejszy zna dobry sposób ekstrakcji l-teaniny z tych pociętych patyków uchodzących u nas za zieloną herbatę?

Amator. Załatwiłeś sobie dożywotni obowiązek wsparcia*. Dojdzie kolumna, albo zmieni się wersja eksela i klops. Mam jedynie nadzieję, że zmieniłeś pracę, a ten pasztet zostawiłeś komu innemu. Przyjmij radę: dawaj userowi wędkę. Co prawda uczenie makr jest dłuższe i szkody mogą być zdecydowanie większe, ale w dłuższym czasie to się bardziej opłaca. *Może nie będzie tak źle, a przyjemność obcowania z użytkownikiem wynagradza koszty;)

Właściwie maszyna może być lepsza od człowieka w te klocki. Może posługiwać się podczerwienią, ultradźwiękami i dostać trójwymiarowy obraz żył, do jakiego człowiek nie ma dostępu. Ponadto może monitorować położenie igły podczas wkłuwania. Ale taniej by było skonstruować jakieś gogle tego typu i dać to człowiekowi. HI mamy za darmo

Jak na Byt Bez Reguł to sporo ich tam masz na początek. Pierwsze prawo: nie ma żadnych praw, po drugie: zmienia się (samoorganizacja i ewolucja), po trzecie są oddziaływania i mają wypadkowe. Dodałbym jeszcze czwartą fundamentalną: różnica wywołuje ruch - najczęściej w celu zlikwidowania różnic - ale nie wiem czy takie natężenie teleologii jest do zaakceptowania. Jestem pewien że nie ma sporu między nami, tylko zła komunikacja - twierdzę Rzeczywistość istnieje niezależnie od jej badaczy i ich modeli. No wiesz, w tym chodzi o nasze lenistwo. Skonstruujemy sobie inteligencję i ona będzie za nas myśleć. Niezmordowanie, nieustannie, a my tylko będziemy konstruować ich więcej i więcej, aż będziemy wiedzieć Wszystko. Automatyczne leczenie to tylko efekt uboczny. Ale do tego jeszcze trochę.

Nie wiem na czym to polega, więc nie wiem czy jest możliwe zbudowanie takiej maszyny. Znam jednak dwa przykłady robotów medycznych które radzą sobie lepiej niż chirurdzy. Wybacz laicki opis: zabezpieczenie do wiertarki by nie "wpadała" do środka po przewierceniu jakiejś kostki w uchu. Frezarka do kolan - przygotowanie pod implanty - Maszyna właściwie sama mogłaby wyfrezować odpowiednie kształty wcześniej zaprojektowane z pomocą komputera, ale brak zaufania do maszyny nie pozwolił na to. Zamiast tego chirurg prowadzi frez, a maszyna pilnuje by nie wyjechał poza projekt. Czujesz paradoks? Maszyna nadzoruje chirurga