hello mindenki! 
egy olyan kodra lenne szükségem, ami kilistazza az adott 
halozaton letezo osszes gep ip cimet. egy jatekhoz kellene, 
hogy a kliens meg tudja keresni a szervert. 
köszi!

OJ>  >> szal a proci sebessege nem sokat jelent ?????
OJ> szerintem ez a tipikus spekulativ gondolkozas esete, ahol egy
OJ> konkluzióra probalunk körmönfont (és tök hibás) elméletet
OJ> ráhúzni, hogy ne kelljen a programot végiggondolni...

Sztem programozasnal elsosorban az a fontos, hogy a program
vegiggondolt elmeletre epuljon. Akkor nem kell 5x ujrairni. De vegig
kell gondolni a programot, csak az nem mindegy, hogy milyen
alapelkepzelessel tesszuk. Most az en elmeletem volt a hibas? Lehet...


OJ> ebből látszik, hogy
OJ> - inkább a rekord ide-oda másolása dominál az
OJ> időszükségletben, tehát célszerű csupán pointereket rendezni!

Tehat akkor megsem mondtam akkora marhasagot?! Mert en is majdnem
ugyanezt irtam

OJ> - a median-of-three javítással kiegészített quicksort majdnem
OJ> kétszer olyan gyors rendezett adathalmazra, mint
OJ> rendezetlenre, tehát nem kell félni a legrosszabb esettől,
OJ> sőt így ez már a legjobb esetté válik!!!

Most lehet, hogy hulyeseget irok, mivel nem tudom mi az a
median-of-three quicksort, de az elobbi kijelentesed alapjan nem
kepzelheto el, hogy csak azert gyorsabb, mert nem masolgatja a
rekordokat ide-oda???... Ja es a masii, hogy mennyi idovel kesobb
eresztetted ra? Mert kicsit nehez win alatt ilyen mereseket csinalni,
mert o is cache-el (bar lehet, hogy rosszul ertelmezem a dolgokat a
winnel kapcsolatban, ez esetben valaki felvilagosithatna, hogy is
mukodik ez, mert erdekelne).

OJ> értem, te se tudod pontosan, (különösebb értelme sincs, nyilván "balra"
OJ> is rendezhető), de azért alkalom egy kis villogásra...

Nyilvan rendezheto balra is, en csak segiteni probaltam, bocs ha ezt
villogasnak vetted...

OJ> Ha pontosan azt írtad volna, hogy kvázi rendezett adatbázis esetén
OJ> igen mély lehet a rekurzió, akkor rögtön értettem volna...

Igy is megertetted, az mar mas kerdes, hogy nem rogton. Szinten bocs,
de nem vagyok tanar.

OJ> Szerintem néha érdemes megfogadni is a tanácsokat, nem csak kérni...

Nem en kertem a tanacsot.

-- 
Wildhemp

>>
>> HC> - rendezett adatbazis eseten rovidebb jobb oldal marad, stb...
>>
>> Ezt ugy szoktak megoldani, hogy megkeverik az adatokat, mielott
>> elkezdenek rendezni. Probalkozz esetleg ezzel.

HC> Megkeverni a szepen rendezett adatokat?
HC> Jaj. Lehet h valamirol lemaradtam, de illet meg nem hallottam.

Hat ha jobban belegondolsz, elvileg logikus. Ha a qsort legroszabb
esete az, ha rendezett adatokon fut, akkor elotte megoldjuk, hogy ne
legyen rendezett..

HC> Rendezett adatok eseten csupan annyi a dolgod, hogy megkeresed
HC> azt a poziciot, ahova az adatnak kerulnie kell, tehat az elso elemet
HC> amelynél
HC> a beszurando adat kisebb (vagy nagyobb a rendezes iranyatol fuggoen)
HC> es ettol a ponttol kezdve eltolod a tomb elemeit 1-el feljebb, majd az igy
HC> meguresedett helyre beteszed az uj adatot.
HC> Ha vki ennel gyorsabb algoritmust mond, +hivom 1 sorre.

Valoban ez a leggyorsabb, plane ha lancolt listaban csinalod. Akkor
nem kell tologatni sem...

Ugyse szeretem a sort :((

-- 
Wildhemp

Hello!

A kovetkezo osszeget kell kiszamitani, ebbol megvan a poligon terulete es a
koruljarasi iranya is:

 //n: poligon csucspontjainak szama
 //a poligon zart, utolso es elso koordinata megegyezik (tehat pl egy 4szog
az 5 koordinatabol all)
 for(i=0;i<n-1;i++){
  pr1=coords[i  ].x * coords[i+1].y;
  pr2=coords[i+1].x * coords[i  ].y;
  sum+=(pr1-pr2);//ennek az osszegnek a fele lesz a poligon terulete
      //plusz informacio: ha sum pozitiv, akkor a poligon pozitiv
koruljarasi iranyu (pontjai az oramutato jarasaval ellenkezo iranyban
vannak)
      //ha negativ, akkor az irany negativ
 }

 polyArea=fabs(sum)/2;


hello:

Cs.


> wrote in message
news:...
> szia coderek
>
> van egy tetszöleges sokszög, amelynek a pontjainak tudom a koordinatait.
> keresem azt az algoritmust, amellyel ki tudom szamitani a sokszög
területet.
>
> segitseget elöre is köszönöm
>
> hello barna
>

Szia Barna

>szia coderek

>van egy tetszöleges sokszög, amelynek a pontjainak tudom a koordinatait.
>keresem azt az algoritmust, amellyel ki tudom szamitani a sokszög
területet.

>segitseget elöre is köszönöm

>hello barna

Adottak egy  sokszog (jelen estetben 5) pontjai:

1. 2,2
2. 7,2
3. 11,2
4. 7,8
5. 2,8
es ujra az elso
1. 2,2

Majd sorban haladva, a koordinata parosokbol felirhato 2x2-es matrixok
determinansait osszeadogatod, a vegen osztod kettovel.

Azaz az elso matrix,es a determinans:

2 2
7 2

det1=4-14=-10

Kovetkezo:

 7 2
11 2

det2=14-22=-8

det3=88-14=74

det4=40

Az utolso det.:

2 8
2 2

det5=4-16=-12

determinansok osszege 84.

Terulet=84/2=42

Mar csak kodolni kell. :)

Üdv:
Peter

wildhemp=freemail.hu, 7/17/2002:
>HC> 300, sőt 300 ezer rekord sem szabad hogy probléma legyen a mai gépek
>HC> mellett, úgyhogy valami igen komoly gáz van nálad. Ötletek:
>Hat ez igy nem egeszen igaz. Azert mert egy ciklusban csinalod a
>dolgokat, es olyankor a sebesseg elvesz, plane rekurzional, mert
>olyankor stackbe irni, stackbol olvasni, valtozok letrehozasa stb.
>Igazabol nem a proci dolgozik, hanem csak memoria irras, olvasas van,
>igy ez foleg a memoria sebessegetol fugg. Ciklusnal is hasonlo a
>helyzet, szal a proci sebessege nem sokat jelent...

 >> szal a proci sebessege nem sokat jelent ?????
szerintem ez a tipikus spekulativ gondolkozas esete, ahol egy
konkluzióra probalunk körmönfont (és tök hibás) elméletet
ráhúzni, hogy ne kelljen a programot végiggondolni...

Teszt eredmények C-ben (1 db integer összehasonlítás a rendező feltétel,
Athlon XP 1600+, disk swap nélkül, Borland C++ Builder 6).
oszlopok: rekordméret (byte), sorok: rekordszám

1) rendezetlen adathalmazra
         4       8       16      32      64      128
300     0       0.01    0       0       0       0.01
3000    0       0       0.01    0.02    0.03    0.05
30000   0.08    0.1     0.13    0.21    0.401   0.701
300000  0.891   1.131   1.542   2.524   4.426   8.222
1000000 2.864   3.816   5.238   8.482   15.252  28.801

2) rendezett adathalmazra (még 1x ráeresztjük ugyanazt a
rendezést)
         4       8       16      32      64      128
300     0       0       0       0       0.01    0
3000    0       0       0.01    0       0.01    0.01
30000   0.05    0.05    0.07    0.09    0.16    0.23
300000  0.611   0.65    0.802   1.172   1.812   3.325
1000000 1.913   2.203   2.744   4.076   6.76    11.467

ebből látszik, hogy
- inkább a rekord ide-oda másolása dominál az
időszükségletben, tehát célszerű csupán pointereket rendezni!
- a median-of-three javítással kiegészített quicksort majdnem
kétszer olyan gyors rendezett adathalmazra, mint
rendezetlenre, tehát nem kell félni a legrosszabb esettől,
sőt így ez már a legjobb esetté válik!!!

HC> 5. mi az a rovidebb jobb oldal?
>Nezz utana a quicksort legroszabb esetenek, amikor az elemek
>rendezettek. Ott jon elo az, hogy a jobboldal egyelemu vagy ures,mar
>nem tom pontosan

értem, te se tudod pontosan, (különösebb értelme sincs, nyilván "balra"
is rendezhető), de azért alkalom egy kis villogásra...
Ha pontosan azt írtad volna, hogy kvázi rendezett adatbázis esetén
igen mély lehet a rekurzió, akkor rögtön értettem volna...

Szerintem néha érdemes megfogadni is a tanácsokat, nem csak kérni...

Józsi

Hello!

> Felado :  [Hungary]
> Temakor: Re: rendezes ( 28 sor )
> Idopont: Mon Jul 15 10:03:34 CEST 2002 CODER #1573
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
...
> Semmifele qsort, vagy buborek nem kell.
Ha ugyanazt az adathalmazt hasznalod, es nem a progid kezdte el feltolteni,
akkor eccer azert le kell rendezni, de allandoan tenyleg folosleges!

> Rendezett adatok eseten csupan annyi a dolgod, hogy megkeresed
> azt a poziciot, ahova az adatnak kerulnie kell, tehat az elso elemet
> amelynél a beszurando adat kisebb (vagy nagyobb a rendezes
> iranyatol fuggoen) es ettol a ponttol kezdve eltolod a tomb elemeit 1-
> el feljebb, majd az igy meguresedett helyre beteszed az uj adatot.
> Ha vki ennel gyorsabb algoritmust mond, +hivom 1 sorre.
Tomb helyett (rendezett) dinamikus listat hasznalsz. Ha a tombod tul nagy =>
pazarlas, ha tul kicsi => nem fersz bele egy ido utan (ha jol emlekszem
Pascalban nincs dinamikus tomb, csak Delphiben).
Igaz, hogy rendezett tombben gyorsabban keresel pl. binaris keresessel,
listaban meg linearisan keresel, de ha megvan az elem, listaban csak
beszurod es kesz, tombben meg az utana kovetkezo elemeket meg toligalnod
kell! Foleg, ha az elemek eloszlasarol van nemi fogalmad, akkor egy
ketiranyu listaban a kereses iranyat egy elozetes vizsgalat utan
megvalasztva meg gyorsabb lesz.
Na, meger egy sort? :-)

Ja, es megvalami: erdemes indexelni, mert a kulcsmezok kisebb helyet
foglalnak a memoriaban, mint a teljes rekord.

Jo codolast!
Sipi