Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Achiziționare tuner TV !

Din ce este facuta terasa asta?

Cum accesez site-ul CNAS ?

Algoritm simplu de calculare al u...
 Bitdefender Total Security ș...

casa verde 2024

Intrerupator cu N - doza doar cu ...

Incalzire casa fara gaz/lemne
 Incalzire in pardoseala etapizata

Suprataxa card energie?!

Cum era nivelul de trai cam din a...

probleme cu ochelarii
 Impozite pe proprietati de anul v...

teava rezistenta panou apa calda

Acces in Curte din Drum National

Sub mobila de bucatarie si sub fr...
 

random numere

- - - - -
  • Please log in to reply
49 replies to this topic

#19
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

Africanul, on Sep 28 2005, 09:17, said:

Toti cei 3 algoritmi sunt buni, si cel mai bun este primul (ala in VB), dar este cel mai lent.

<{POST_SNAPBACK}>

:D aici iar te contrazic, algoritmul vb nu e cu nimic mai bun ca al meu. practic face acelasi lucru, ia la intamplare cate un numar din multimea de elemente si il pune in solutie.

diferenta este ca poate genera un numar aleator care exista deja in solutie si trebuie sa-l verifice. cu cat raman mai putine elemente de ales, cu atat va fi mai greu sa nimereasca unul care sa corespunda. al meu asigura ca la fiecare pas se obtine un element care nu a mai fost ales.

#20
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003
@caracatita: vezi deasupra postului tau.

#21
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003

sapho, on Sep 28 2005, 10:45, said:

:D aici iar te contrazic, algoritmul vb nu e cu nimic mai bun ca al meu. practic face acelasi lucru, ia la intamplare cate un numar din multimea de elemente si il pune in solutie.

diferenta este ca poate genera un numar aleator care exista deja in solutie si trebuie sa-l verifice. cu cat raman mai putine elemente de ales, cu atat va fi mai greu sa nimereasca unul care sa corespunda. al meu asigura ca la fiecare pas se obtine un element care nu a mai fost ales.

<{POST_SNAPBACK}>


Da si nu! Algoritmul in VB reprezinta implementarea toriei, al tau este o optimizare a celui de mai sus. Din respect pentru teorie, il declar pe primul cel mai bun. Din respect pentru resurse si viteza, il declar pe al meu cel mai bun!
Parerea mea!

#22
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

caracatita, on Sep 28 2005, 09:42, said:

Poti sa mai citesti pe acolo si eventual sa te uiti intr-o implementare de stl (asta daca stii c++)

<{POST_SNAPBACK}>


ca sa mai dau un citat:

Quote

This algorithm is described in section 3.4.2 of Knuth (D. E. Knuth, The Art of Computer Programming. Volume 2: Seminumerical Algorithms, second edition. Addison-Wesley, 1981). Knuth credits Moses and Oakford (1963) and Durstenfeld (1964). Note that there are N! ways of arranging a sequence of N elements. Random_shuffle yields uniformly distributed results; that is, the probability of any particular ordering is 1/N!. The reason this comment is important is that there are a number of algorithms that seem at first sight to implement random shuffling of a sequence, but that do not in fact produce a uniform distribution over the N! possible orderings. That is, it's easy to get random shuffle wrong.


#23
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003

sapho, on Sep 28 2005, 10:49, said:

ca sa mai dau un citat:

<{POST_SNAPBACK}>


Corect!  :coolspeak: Toti cei care au terminat 10 clase stiu, sper!, cate permutari se pot face cu o multime de "n" elemente!!!
Ma intreb: exista vreun algoritm, oricat de costisitor ar fi, care sa genereze o "permutare perfecta"? (ce cretinatate: permutare perfecta!!!)

Edited by Africanul, 28 September 2005 - 09:58.


#24
caracatita

caracatita

    Junior Member

  • Grup: Members
  • Posts: 90
  • Înscris: 22.03.2004

Africanul, on Sep 28 2005, 09:53, said:

Corect!  :coolspeak: Toti cei care au terminat 10 clase stiu, sper!, cate permutari se pot face cu o multime de "n" elemente!!!

<{POST_SNAPBACK}>


Vad ca esti mandru ca stii si tu :D

#25
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003

caracatita, on Sep 28 2005, 10:57, said:

Vad ca esti mandru ca stii si tu :D

<{POST_SNAPBACK}>

Caracatita, fara mistouri aici. Daca tu ai terminat profesionala la brutarie, nu-i problema mea... Discuta civilizat, daca esti in stare, sau du-te la covrigii tai!

#26
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002
imoplemetarea din gcc:

  /**
   *  @brief Randomly shuffle the elements of a sequence.
   *  @param  first   A forward iterator.
   *  @param  last    A forward iterator.
   *  @return  Nothing.
   *
   *  Reorder the elements in the range @p [first,last) using a random
   *  distribution, so that every possible ordering of the sequence is
   *  equally likely.
  */
  template<typename _RandomAccessIterator>
    inline void
    random_shuffle(_RandomAccessIterator __first, _RandomAccessIterator __last)
    {
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
     _RandomAccessIterator>)
      __glibcxx_requires_valid_range(__first, __last);

      if (__first != __last)
	for (_RandomAccessIterator __i = __first + 1; __i != __last; ++__i)
   std::iter_swap(__i, __first + (std::rand() % ((__i - __first) + 1)));
    }

destul de ciudata dupa parerea mea. din cate inteleg, face swap numai cu elemente cu "index" mai mic sau egal cu cel curent. o sa ma mai uit pe net pt asta, dar nu acuma ca nu mai am timp.

daca ma gandesc mai bine, pare destul de buna ideea...

Edited by sapho, 28 September 2005 - 10:11.


#27
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

Africanul, on Sep 28 2005, 09:17, said:

creste complexitatea la 2*n care este in continuare mai mica decat n*n, pt. n>2

<{POST_SNAPBACK}>

inca o chestie: nici algoritmul meu nu are complexitate n*n, nu sunt (sau nu ar trebui sa fie) doua for-uri imbricate. chestia cu "for (int j = 0; j < random; ++j) ++it;" este asa numai pentru ca iteratorul pentru set nu are definit operatorul "+=". timpul mai mare de executie de acolo vine. o sa vad daca pot implementa altfel (cu ceva gen vector, numai ca asta are timp mare pt erase la un element cred).

reviu... :D

#28
caracatita

caracatita

    Junior Member

  • Grup: Members
  • Posts: 90
  • Înscris: 22.03.2004

Africanul, on Sep 28 2005, 10:01, said:

Caracatita, fara mistouri aici. Daca tu ai terminat profesionala la brutarie, nu-i problema mea... Discuta civilizat, daca esti in stare, sau du-te la covrigii tai!

<{POST_SNAPBACK}>


Ma africane eu nu am nimic cu nici o rasa (desi totusi oamenii sunt albi  :lol: ) dar tu esti al dracului de nerespectuos* :P






* eufemistic spus

#29
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003

sapho, on Sep 28 2005, 11:19, said:

inca o chestie: nici algoritmul meu nu are complexitate n*n, nu sunt (sau nu ar trebui sa fie) doua for-uri imbricate. chestia cu "for (int j = 0; j < random; ++j) ++it;" este asa numai pentru ca iteratorul pentru set nu are definit operatorul "+=". timpul mai mare de executie de acolo vine. o sa vad daca pot implementa altfel (cu ceva gen vector, numai ca asta are timp mare pt erase la un element cred).

reviu... :D

<{POST_SNAPBACK}>


Asa este. Complexitatea algoritmului tau, presupunand ca "random" este maxim, este de n+(n-1)+(n-2)+...+1 = n(n+1)/2 (suma primelor n numere naturale). Asta facand exceptie de STL! Oricum, este mare...

@caracatita: ok!

Edited by Africanul, 28 September 2005 - 10:35.


#30
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002
#include <cstdlib>
#include <iostream>
#include <vector>
#include <ctime>

using namespace std;

int main(int argc, char *argv[]) {

    const int sz = RAND_MAX;       // 32767 (numarul de elemente)
    
    int v[sz];                         // solutia
    int random;                        // nr ajutator
    int i;                             // contor
    vector<int> iv;                    // multimea elementelor de "amestecat"
    vector<int>::iterator it;          // iterator pe aceasta multime
      
    srand(clock());                    // optional :D
    i = 0;
    iv.resize(sz);                          
    for (it = iv.begin(); it != iv.end(); ++it, ++i) *it = i;          // initializare multime
    
    for (i = 0; i < sz; ++i) { 
        random = rand() % iv.size();                     // nr aleator,  < nr de elemente ramase
        it = iv.begin();                                 // iterator catre primul element ramas
        it += random;                                    // iteratorul se muta la un element ales random
        v[i] = *it;                                      // punem elementul in solutie
        iv.erase(it);                                    // elementul este scos din multime
    }
    
    for (i = 0; i < sz; ++i) {                       // afisare
        cout << v[i] << "\t";     
        if ((i+1) %10 == 0) cout << endl;                // de-o maniera ordonata :D
    }
    
    system("PAUSE");
    return EXIT_SUCCESS;
}

asta e implementarea cu std::vector<> , muuult mai rapida decat orice std::set sau std::list: afisare "aproape instant" pe un P4 2.6. oricum ramane mai lent decat implemetarea lui Africanul, dar e mai sigura.

diferenta care ramane cred ca se trage de la functia erase() (care la vector oricum e ceva mai lenta decat la ceilalti containeri), si de la folosirea vector-ului in loc de array.

Quote

Ma intreb: exista vreun algoritm, oricat de costisitor ar fi, care sa genereze o "permutare perfecta"? (ce cretinatate: permutare perfecta!!!)

nu degeaba am dat citatul ala cu Random_shuffle yields uniformly distributed results; that is, the probability of any particular ordering is 1/N!. bineinteles, toate implementarile depind de calitatea generatorului de numere random (rand()), dar banuiesc ca totusi il putem considera "reliable". daca nu, exista si alte metode de generare numere aleatorii.

m-am uitat in Knuth - the Art of Computer Programming, vol2 - si (stupoare!) implementarea din gcc este gresita! algoritmul descris de Knuth este cam asa (pentru n numere):

int v[n];                 // deci indecsi de la 0 la n-1     
for (i = n-1; i > 0; --i) 
    swap (v[i], v[rand() % (i + 1)])   // inclusiv el insusi

ceea ce, luat de la cap la coada, ar veni cam asa:

for (i = 0; i < n-1; ++i) 
    swap ( v[i] , v[i + (rand() % (n - i))] )   // inclusiv el insusi

ceea ce inseamna ca interschimbarea se face cu elemente cu index mai mare sau egal cu cel curent, si nu mai mic sau egal, ca in implementarea gcc. cineva ar trebui sa le transmita ca exista o greseala in STL. :D

un alt algoritm despre care am citit ar fi ceva de genul: pentru o secventa finita de elemente, se asociaza fiecarui element o valoare generata random. elementele se sorteaza apoi in functie de aceste valori. ideea e sa ai o plaja cat mai mare de numere din care sa alegi valorile astea random, pentru ca valorile generate sa nu se repete (ca sa le poti sorta dupa aia). oricum, banuiesc ca in caz ca se itampla sa se repete, poti vedea asta in rutina de sortare si reiei toata procedura. ideea e sa se intample cat mai rar chestia asta.

si pe final, ca si un sfat pentru Africanul: incearca sa citesti/asculti mai atent ceea ce au de zis si ceilalti participanti la o discutie. nimeni nu are tot timpul dreptate, toti mai avem cate ceva de invatat chiar daca ni se pare ca le stim pe toate :D. asta pentru ca am observat anumite "probleme de comunicare" (cu mai multe ocazii). si, evident, nu se intampla nimic daca mai si recunoastem cand gresim :D. dar, ma rog, e numai un sfat.

Edited by sapho, 29 September 2005 - 00:17.


#31
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002
acu imi dau seama ca implementarea facuta de mine este de fapt o varianta a algoritmului lui Knuth (mai costisitoare, ce-i drept :D).

de ce zic asta? ce face Knuth:

1. ia multimea intreaga {k1...kn}, alege un element random din ea (ki), il muta pe primul loc, iar primul element trece in locul lui. ce ramane in restul secventei de elemente? evident, restul multimii ( {k1...kn} \ {ki} ), din care iar alege un element la intamplare samd.

este exact ceea ce faceam si eu in implementarea mea, numai ca nu mi-a dat prin cap sa folosesc acelasi container pentru a tine si solutia, si elementele de randomizat. in schimb eu le iau dintr-un loc si le duc in altul. dar in principiu, e aceeasi chestie :D damn, i'm good!

un alt algoritm, la care m-am gandit acuma, si care seamana cu ceea ce au facut cei de la gcc (dar nu e la fel, de unde raman la concluzia mea ca ei au gresit):

2. practic se pleaca de la o multime cu un singur element (k1). elementul k2 se aseaza, aleator, la stanga sau la dreapta lui k1, si obtin (sa zicem) (k1, k2). apoi, k3 il aseazam (aleator) pe una din cele 3 pozitii posibile (inaintea lui k1, intre k1 si k2, dupa k2). si tot asa...

3. cei de la gcc in schimb, in loc sa insereze elementul curent, schimba locul lui cu alt element care era deja pus intr-o ordine aleatoare. ce se poate intampla? de ex:

sa zicem ca la pasul al doilea se ajunge de la (k2, k1) la (k2, k3, k1) (ultimul inserat fiind, evident, k3), si vrem sa inseram undeva elem k4. daca procedam ca la pct 2 si rand() zice "pune-l pe pozitia 2" obtinem: (k2, k4, k3, k1). daca facem ca cei de la gcc,  il mutam pe k3 in poz 4, si pe k4 in poz 2 si obtinem : (k2, k4, k1, k3).
daca il lasam un pic deoparte pe k4, ramane (k2, k1, k3) ceea ce inseamna ca pe k3 puteam numai sa-l adaugam la coada sirului (k2, k1), fara sa ne chinuim sa-l mai amestecam cu celelalte, ca tot aia era.

exista deci o probabilitate (de 1/(i+1) la pasul i in implementarea gcc) sa aducem un element la locul de unde a plecat, ceea ce nu e bine.

sper ca am fost destul de clar pt ora asta :D (e doua si ceva noaptea).

Edited by sapho, 29 September 2005 - 01:25.


#32
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003

sapho, on Sep 29 2005, 01:06, said:

m-am uitat in Knuth - the Art of Computer Programming, vol2 - si (stupoare!) implementarea din gcc este gresita! algoritmul descris de Knuth este cam asa (pentru n numere):

ceea ce, luat de la cap la coada, ar veni cam asa:

for (i = 0; i < n-1; ++i) 
    swap ( v[i] , v[i + (rand() % (n - i))] )   // inclusiv el insusi

<{POST_SNAPBACK}>



@sapho: scrie algoritmul tau in C (ala batranesc, cum l-am scris eu, cum este asta din gcc), fara sa folosesti STL, atunci vei vedea cu adevarat cat de stufos este... Evident ca-i mai lent, doar folosesti STL (iar daca il vei scrie in C pe acelasi "schelet", tot trebuie sa faci ceva asemanator cu STL-ul, deci va fi in continuare lent...).
Pana acum cei mai rapizi sunt: asta din gcc (care l-ai postat tu), si al meu (care, aproximativ, tot aia face): dintr-o singura parcurgere amesteca elementele unui vector dand o solutie multumitoare.

Nu trebuie sa ne batem cu pumnul in piept al cui este mai bun: ambele dau rezultate satisfacatoare (pentru ultima data: vorbim de numere aleatoare!). Se pot scrie o infinitate de astfel de algoritmi...
Presupunem ca se face un joc de carti (Poker, Solitaire, chiar sunt) pe telefoane mobile lente, si cu memorie putina (nu iti permiti sa mai tii in memorie nu stiu ce flaguri, pozitii, etc). Ce algoritm crezi ca se va folosi pentru "amestecarea" cartilor? Unul gen VB (care dureaza enorm pe un P4 pana da rezultatul) sau unul foarte simplu si suficient de bun (ca al meu)?

Edited by Africanul, 29 September 2005 - 08:52.


#33
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

Africanul, on Sep 29 2005, 08:50, said:

Pana acum cei mai rapizi sunt: asta din gcc (care l-ai postat tu), si al meu (care, aproximativ, tot aia face): dintr-o singura parcurgere amesteca elementele unui vector dand o solutie multumitoare.

<{POST_SNAPBACK}>

iar n-ai citit exact ce am scris eu mai sus: cel din gcc este gresit! cel pe care l-ai/l-am citat este din Knuth. Algoritmul lui Knuth obtine in n pasi o solutie "perfecta" cum ii spui tu, ceea ce al tau nu stiu daca obtine vreodata (pentru ca nu poti sti sigur cat de mare sa fie numarul ala de amestecari ca sa iasa ceva corect). evident (am recunoscut) ca al meu este mai stufos si se misca mult mai greu, dar respecta algoritmul lui Knuth. al tau, sorry, da' nu respecta.
implementarea algoritmului lui Knuth se face foarte usor (in plain C), dar eu am ales o cale mai complicata, cu STL and stuff ...

Africanul, on Sep 29 2005, 08:50, said:

Se pot scrie o infinitate de astfel de algoritmi...

<{POST_SNAPBACK}>

nu cred ca e asa de simplu.

Africanul, on Sep 29 2005, 08:50, said:

Unul gen VB (care dureaza enorm pe un P4 pana da rezultatul) sau unul foarte simplu si suficient de bun (ca al meu)?

<{POST_SNAPBACK}>

nici unul, nici altul, ci se alege cel foarte simplu (si corect) dat de Knuth :D.

Edited by sapho, 29 September 2005 - 09:22.


#34
Africanul

Africanul

    Active Member

  • Grup: Members
  • Posts: 1,739
  • Înscris: 24.10.2003
0) Probabil n-am citit cu atentie... Sorry!
1) Nu exista "solutie perfecta" intr-o permutare a unei multimi! Cu ce este permutarea {1, 3, 2} mai buna decat {3, 1, 2}, sau chiar {1, 2, 3}?
2) Se pot scrie, intr-adevar, o infinitate de algoritmi de genul asta, care toti vor face acelasi lucru.
3) Algoritmul dat de Knuth este unul din cei "o infinitate", doar ca Knuth este un nume. Si al tau si al meu si ala din VB sunt din cei o infinitate.
4) Si totusi, algoritmul meu a fost folosit intr-o aplicatie care s-a vandut (si se vinde in continuare) si toata lumea este multumita!

Dau in continuare 20 de generari de numere de la 0 la 9, cu NR_MAX=MAX_SWAP
1 0 3 9 8 2 4 6 5 7
0 7 6 5 2 8 1 4 3 9
8 7 2 9 5 0 6 1 3 4
0 1 6 8 7 3 4 9 5 2
7 1 9 2 4 8 5 3 6 0
1 4 8 6 5 9 7 0 2 3
3 7 1 6 0 2 5 9 8 4
4 0 7 3 1 6 2 5 9 8
6 0 8 7 4 2 5 3 1 9
9 5 1 3 4 6 7 2 0 8
6 9 5 0 2 3 1 8 7 4
1 9 0 3 8 6 2 7 4 5
1 3 9 5 0 4 6 8 7 2
0 5 6 3 9 4 1 7 2 8
2 3 4 8 1 6 5 7 0 9
4 2 7 9 3 5 8 6 0 1
1 2 8 7 4 9 5 3 0 6
7 3 4 2 0 1 6 9 5 8
9 6 1 0 3 5 7 2 8 4
6 4 3 7 2 8 0 1 5 9
Ce-i in neregula cu asta?
Nu scrie nicaieri ca I(k) (elementul de pe pozitia k din multimea initiala) trebuie sa fie diferit de P(j, k) (elementul de pe pozitia k din permutarea j a multimii initiale)!
Matematica ne spune ca "o multime cu n elemente poate fi permutata in n! ori", corect? Deci inclusiv multimea initiala este o permutare a multimii initiale, inclusiv "permutarile imperfecte" sunt permutari ale multimii initiale. Matematica!

Practica: Se da multimea initiala {1, 2, 3} - are 3 elemente, deci poate fi permutata in 3!=6 ori. Sa dam permutarile:
1) {1, 2, 3} - hopa! chiar multimea initiala! Si este "total imperfecta"!!!
2) {1, 3, 2} - permutare imperfecta!
3) {2, 1, 3} - permutare imperfecta!
4) {2, 3, 1}
5) {3, 1, 2}
6) {3, 2, 1} - permutare imperfecta!

Corect? Algebra!

Dupa tine, permutarile "bune" ale multimii {1, 2, 3} sunt doar... 2: {2, 3, 1} si {3, 1, 2}... Si marmota invelea ciocolata in staniol!

Edited by Africanul, 29 September 2005 - 10:17.


#35
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

Africanul, on Sep 29 2005, 09:28, said:

1) Nu exista "solutie perfecta" intr-o permutare a unei multimi! Cu ce este permutarea {1, 3, 2} mai buna decat {3, 1, 2}, sau chiar {1, 2, 3}?

<{POST_SNAPBACK}>

Quote

Random_shuffle yields uniformly distributed results; that is, the probability of any particular ordering is 1/N!
asta este cerinta de baza pentru a obtine o permutare "perfecta" (pornind de la alta permutare). practic asta trebuie indeplinita ca sa obtii un algoritm care face bine o amestecare. in momentul in care stii aproape sigur ca, aplicand un anumit algoritm, in ultimele 20 de numere din 10.000 tot timpul vei avea cateva care nici nu s-au miscat din loc, inseamna ca nu e indeplinita aceasta conditie.

#36
sapho

sapho

    Active Member

  • Grup: Members
  • Posts: 1,578
  • Înscris: 22.09.2002

Africanul, on Sep 29 2005, 09:28, said:

1 0 3 9 8 2 4 6 5 7
0 7 6 5 2 8 1 4 3 9
8 7 2 9 5 0 6 1 3 4
0 1 6 8 7 3 4 9 5 2
7 1 9 2 4 8 5 3 6 0
1 4 8 6 5 9 7 0 2 3
3 7 1 6 0 2 5 9 8 4
4 0 7 3 1 6 2 5 9 8
6 0 8 7 4 2 5 3 1 9
9 5 1 3 4 6 7 2 0 8
6 9 5 0 2 3 1 8 7 4
1 9 0 3 8 6 2 7 4 5
1 3 9 5 0 4 6 8 7 2
0 5 6 3 9 4 1 7 2 8
2 3 4 8 1 6 5 7 0 9
4 2 7 9 3 5 8 6 0 1
1 2 8 7 4 9 5 3 0 6
7 3 4 2 0 1 6 9 5 8
9 6 1 0 3 5 7 2 8 4
6 4 3 7 2 8 0 1 5 9

Ce-i in neregula cu asta?
Nu scrie nicaieri ca I(k) (elementul de pe pozitia k din multimea initiala) trebuie sa fie diferit de P(j, k) (elementul de pe pozitia k din permutarea j a multimii initiale)!

<{POST_SNAPBACK}>

nu scrie, dar nu e cam ciudat ca in (aproape) fiecare permutare obtinuta, exista cel puti unul care ramane pe loc?? compara cu un output generat de algoritmul lui Knuth si vei vedea diferenta.

Edited by sapho, 29 September 2005 - 09:46.


Anunturi

Chirurgia cranio-cerebrală minim invazivă Chirurgia cranio-cerebrală minim invazivă

Tehnicile minim invazive impun utilizarea unei tehnologii ultramoderne.

Endoscoapele operatorii de diverse tipuri, microscopul operator dedicat, neuronavigația, neuroelectrofiziologia, tehnicile avansate de anestezie, chirurgia cu pacientul treaz reprezintă armamentarium fără de care neurochirurgia prin "gaura cheii" nu ar fi posibilă. Folosind tehnicile de mai sus, tratăm un spectru larg de patologii cranio-cerebrale.

www.neurohope.ro

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate