Chirurgia endoscopică a hipofizei
"Standardul de aur" în chirurgia hipofizară îl reprezintă endoscopia transnazală transsfenoidală. Echipa NeuroHope este antrenată în unul din cele mai mari centre de chirurgie a hipofizei din Europa, Spitalul Foch din Paris, centrul în care a fost introdus pentru prima dată endoscopul în chirurgia transnazală a hipofizei, de către neurochirurgul francez Guiot. Pe lângă tumorile cu origine hipofizară, prin tehnicile endoscopice transnazale pot fi abordate numeroase alte patologii neurochirurgicale. www.neurohope.ro |
BigOperation - operatii numere mari
Ultima postare: iun 20 2020 12:59, Inițiat de
MihaiProg
, apr 03 2020 13:53
·
0
#19
Publicat: 05 aprilie 2020 - 11:12
Adunarea in implementarea aceea este de 12 ori mai rapida ca implementarea mea,
la inmultire diferentele nu sunt asa da mari, banuiesc ca din cauza faptului ca utilizeaza karatsubaMultiply. Metoda karatsuba este eficienta doar pentru numere colosale daca imi aduc bine aminte. |
#21
Publicat: 05 aprilie 2020 - 11:45
IvanMihai, on 05 aprilie 2020 - 11:12, said:
Adunarea in implementarea aceea este de 12 ori mai rapida ca implementarea mea, Pe sistemul meu, dupa masuratori precise, e doar de 2.1x mai rapida decat naive_add al tau. Printre cauze:
Editat de dani.user, 05 aprilie 2020 - 12:05. |
#22
Publicat: 05 aprilie 2020 - 14:19
dani.user, on 05 aprilie 2020 - 11:45, said:
Pe sistemul meu, dupa masuratori precise, e doar de 2.1x mai rapida decat naive_add al tau. aici sunt diferente mari. Ca valori bigints am utilizat ce ai postat tu intr-un post anterior. Daca ignori convetirea string_to_vector, de fapt nu este mai rapida ca implementarea mea. "dupa masuratori precise" - ce intelegi prin masuratori precise??? Ce-i drept eu am utilizat doar: clock_t time_req; time_req = clock(); // first_store_add(one, two); time_req = clock() - time_req; printf("Orig took %f seconds\r\n",(float)time_req/CLOCKS_PER_SEC); Quote Te plimbi prin tot vectorul in GetSign/SetSign De ce contine zerouri la inceput: din moment ce dimesiunea vectorului rezultat este aproximata. GetSign/SetSign este utilizat doar de cateva ori deci nu ar trebui sa fie diferente mari. Quote
Ajungi sa efectuezi impartiri pentru naive_add (in cadrul finalize) Quote cand faci adunare x + y cu returnarea unui z ma astept sa nu modifici x si y, sa ramane constante. La sfarsit seteaza semnul inapoi. Daca ar fi sa ignor partea cu convertirea din string a biginteger, implementarea pare ok. |
#23
Publicat: 05 aprilie 2020 - 14:51
Da, am masurat doar adunarea. Urmeaza sa masor si conversia.
Masuratori precise:
Cel mai mult te costa impartirea, o operatie foarte costisitoare. Iar, pentru adunare cel putin, poti scapa foarte usor de ea. Conversia e cam de 1.4x mai rapida in cazul bigint decat string_to_vector:
Editat de dani.user, 05 aprilie 2020 - 14:59. |
#24
Publicat: 05 aprilie 2020 - 19:40
Am rezolvat problema cu viteza convertirii din string in big integer, mai ramane problema cu viteza adunarii (din moment ce am utilizat aceasi metoda ca la inmutire), si problema cu impartirea (ceva nu este bine cu implementarea mea a impartirii).
@dani.user: Din moment ce metoda pe care ai utilizat-o pentru masurare este diferita si nu o pot reproduce, vreau sa te rog sa compari scaderea (-) intre implementarea mea si implemetarea gasita pe NET. |
#27
Publicat: 07 aprilie 2020 - 17:05
Buna. O noua versiune (v2) a acestui program atasata.
Acelasi mod de utilizare ca originalul, doar implementarea s-a schimbat. Totusi adunarea nu este dacat cu putin mai rapida decat cea din clasa luata de pe NET, am rezolvat si acum nu mai inmulteste pentru carry (metoda finalize) la adunare, Scaderea pe de alta parte este de aproximativ doua ori mai rapida decat cea din clasa luata de pe NET, inca nu inteleg de ce exista asa de mare diferente intre adunare si scadere. Pe de alta parte inmutirea este mult mult mai lenta ca adunarea/scaderea, si nu stiu daca o voi putea imbunatatii: de exemplu renuntarea la "/" si "%" in impartire - nu stiu daca este chiar si posibil. GetSign/SetSign este tot acolo, motivul pe care poate fi lent este ca vectorul contine 0 la inceput ceea cred ca poate fi evitat cumva. (nu este facut in versiunea curenta). Sper ca de data asta cel putin nu mai produce rezultate eronate. Cateva teste valori si teste viteza nu ar strica. Fișiere atașate |
#29
Publicat: 07 aprilie 2020 - 18:38
dani.user, on 07 aprilie 2020 - 17:40, said:
Baza putere de 2 si transforma compilatorul / si % in operatii pe biti. este neglijabil. Operatia de inmultire insasi este cea care ia mult timp, ceea ce este logic din moment ce face asta: vector<long long> res(2 * len); // result takes twice size for (int i = 0; i < len; ++i) { for (int j = 0; j < len; ++j) { res[i + j] += x[i] * y[j]; } } |
#30
Publicat: 07 aprilie 2020 - 18:40
IvanMihai, on 07 aprilie 2020 - 17:05, said:
Scaderea pe de alta parte este de aproximativ doua ori mai rapida decat cea din clasa luata de pe NET, Tot clasa de pe net e mai rapida pentru scadere. Cam de 1.3x. GetSign/SetSign tot afecteaza (nu inteleg de ce tii cu dintii de ele). Nici greater_or_equal nu e optim. |
#32
Publicat: 07 aprilie 2020 - 19:08
dani.user, on 07 aprilie 2020 - 18:40, said:
Tot clasa de pe net e mai rapida pentru scadere. Cam de 1.3x. Este ceva in neregula cu ce am facut eu ???: clock_t time_req; time_req = clock(); for (int i=0;i<2768;i++) { bigint div = bigint("30194693..."); bigint divby = bigint("280000..."); bigint res = (div)+(divby); } //std::cout << res; time_req = clock() - time_req; printf("\r\nNew took %f seconds\r\n",(float)time_req/CLOCKS_PER_SEC);Am incercat si cu QueryPerformanceCounter - aproximativ acelasi rezultat! |
#36
Publicat: 08 aprilie 2020 - 10:44
for (int i=0;i<332768;i++)
.... add de pe NET: 10.53, 10.73 secunde add de mine: 12.43, 12.27 secunde sub de mine: 12.95, 12.79 secunde Am setat GetSign cu "return 1" si SetSign cu "return;" si timpul este de 12 secunde, 1 secunda ia faptul ca am "vector<long long>" in loc de "vector<int>" |
Anunturi
▶ Utilizatori activi: 1
0 membri, 1 vizitatori, 0 utilizatori anonimi