
Da sa lepsie ? Overovac, generator prvocisel. Python 3.
Nikde nie su zaciatocnicke cvicenia pre python 3 programovanie. Z obavy ze vsetko zabudnem, vymyslel som si toto zadanie.
Algoritmus som zalozil na tomto:
Toto je jednoduchsi skript pre input jedneho cisla pre overenie:
345EFMC
Gro zistovanie je zabalene v meraci CPU casu. Ze kolko to cele trvalo vyratat.
Na mojom starom pc(sekundy):
14 miestne: 55555544444441 4.8984314
15 miestne: 101103107109113 6.4584414
15 miestne: 111111151111111 6.723643099999999
15 miestne: 988666444411111 19.6249258
16 miestne: 6171054912832631 50.123121299999994
Toto je zlozitejsi skript pre input hornej hranice. Program postupuje od zaciacku (cislo 2):
A
Tu je casomerac umiestneny lepsie. Mal by merat presnejsie iba vypocty:
3ZSXE0D
Ale ak zadam cislo: 999999, trva mu to 62 sekund. Dlhsie ako horsie umiestnenemu koncu casomeraca v pripade B(po list.append()):
B
05QDZEX
Takto to pri tom istom cisle trva 43 sekund. Ako je to mozne ?
Daju sa skripty napisat lepsie, aby bol kratsi cas /mensi vykon potrebny na vyratanie ?
Pre poriadok. Toto je povodny vytvor s casom 40 s, pri inpute 999999.
05QDZEX
@ Wikan:
Upravil som to podla tvojej rady nasledovne:
0946RQM
Ale cas sa vysplhal uplne inde. Po vyse 2 minutach som to zrusil.
@ pme:
Mam takyto CPU: 2 jadrovy: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz
Ale aj mne sa zda, ze to trva akosi dlho.
@ MM..:
Na stringy musim previest koncovu cislicu cisla, lebo int sa neda indexovat ani iterovat, neni subscriptable. To iste plati pri sucte cifier cisla.
Inak sa koniec casomeracu neda umiestnit, aby som sa vyhol list.append().
"Ked jedno delenie num % numb trva cas X, a vies s nim priamo overit ze ci to je prime, tak naco tam strkas pred to zbytocnu operaciu numb % 2, takto ti to trva cas 2*X t.j. 2*dlhsie. Ked chces preskakovat parne cisla tak sa to da robit rovno v cykle ze sa robi cislo+2"
- Upravil som povodny vytvor a teda toto:
som nahradil tymto:
a usetrilo sa 5 sekund :)
Tohle vypadá divně:
Nepřidává to náhodou do toho seznamu všechna čísla a ne pouze prvočísla?
Nie, je to v poriadku.
Pozeral som to tuto krok za krokom.
Chod sem: visualize.html
Pastni tam ten kod bez casomeraca: 2HA1M3M
Daj input: 100 a pekne to ide ako ma.
Zkusil jsem tohle: 07MHFHV
Chodí to docela rychle, ale pořád je místo pro optimalizace.
Nemusis nic prevadzat na string. testovanie prvocisel je jedno delenie v cykle. NIC VIAC v tom cykle nema byt. TO je najoptimalnejsie. (a cyklus ma mat krok 2).
P.S. az prestanes pouzivat integery uplne (vyssi level co sa tyka velkosti cisla) tak potom je to nieco uplne ine. Ak sa len hras ze pouzivas integery tak nerob ziadne somariny vnutri cyklu a ani nic neprevadzaj na stringy.
Mozes cely post rozpisat ako si to myslel ? Nechytam sa vobec
Vyhod vsetky prevody na string a vsetky nezmysly ktore ten string pouzivaju.
a dalej ? to riesenie som chcel precitat normalnejsie
ako vysvetlis, ze optimalnejsie riesenie Wikanove, zabera viac casu ?
upravene "tvoje" riesenie (bez vyuzivania doterajsieho zoznamu prvocisel)
neviem ci to je syntakticky spravne nepoznam python. Toto trva kolko?
ok dik len pockaj chvilu, zistil som ze to wikanove riesenie asi bude rychlejsie(prepac wikanko. aj ked asi nie o vela, lebo vypadne len par cisel), len ja som zabudol zadat limit hornej hranice.
malo to byt takto:
lenze mi vyhadzuje chybu, ked kontroluje cislo 17.
lebo odmocnina je 4 a to nie je v nasom liste prvocisel. tuto list.index(value) metodu potrebujem upravit, ze ked nenajde presne to cislo, tak nech zoberie najblizsie nizsie prvocislo. lenze, do indexu nemozem dat boolean, lebo vyjde nie cislo ale True alebo False. teraz neviem co spravit
Nedavaj tam ziadne indexy, kontroluj cely list. A vyhod tie tvoje nezmyselne extra kontroly na 2,3 a 5, ved to predsa je v tom liste to iste (kontrola na 2, 3 a 5 je hned ako prva, v zozname prvocisel, nemusis to predtym kontrolovat extra debilnymi stringami)
wikan:
nie je mozne to ohranicit indexom, lebo ciselny gap medzi prvocislami je random. neda sa to spravit.
tak som to vymyslel takto:
lenze uz pri malom inpute: 99999, to trvalo 47 sekund !
nechapem ako je to mozne, ked logicky, tymto prechadzam mensim poctom cisel ako tomu bolo tu:
uz neviem co s tym
Já ale o indexech nic nepsal. Proč jsi nepoužil to mé řešení?
A pomalé je to proto, že tam neustále počítač odmocninu, což oproti ostatním operacím trvá celou věčnost.
ved som pouzil - prechadzal som uz ulozene prvocisla ako si povedal
a prave som zistil ze to o 5 sekund rychlejsie MM.. riesenie nepocita spravne.
toto naslo ako prvocislo: 99967, ale nie je
male cisla malo spravne, myslel som si ze je to v poriadku
uz ma to prestava bavit toto programovanie..
Myslím přímo ten kód, který jsem sem dával.
Aha, nevsimol som si to.
Tak pri 999999 to trvalo 8-9 sekund, teda dost mega efektivne. Hlava mi to nebere.
Nakolko nemam rad, ked vsade lietaju variabilne zbytocne definovane, tak som ti zrusil 'maximum' a napisal som to priamo do kodu:
povodne:
prerobene:
takto prerobene to trvalo 14-15 sekund. nechapem preco
To tam neni zbytecne, ale prave proto, aby se to nepocitalo znovu pri kazdem pruchodu.
MM.. mi hore napisal, ze kazde druhe cislo overovat, ze sa da priamo v cykle. a neda sa. teraz to kukam vo vizualizeri, a vobec neberie do uvahy tuto linu:
stale berie numb a nie numb+2
preto to pocita hovadiny, ale ako je potom mozne ze aj tak to preslo o 5 sekund rychlejsie ?
prosimta, co to tam zas lepis za nezmysel? Ja som nikde nepisal ze mas delit nieco s numb+2. A dal som ti jasne priklady jak sa to robi. Nepochopil si ani slovo, uz radsej nic neprogramuj :)