Czy jest jakaś szansa na rozbudowanie możliwości jakie dają skrypty w zakładce inteligencji? Byłoby super gdyby pojawiła się możliwość dodawania warunków. Wtedy gra nie sprowadziłaby się tylko statów, ale też i odrobiny pomyślunku Chociaż zdaje sobie sprawę z tego że dosyć mocno obciążyło by to serwer.
Chociaż zdaje sobie sprawę z tego że dosyć mocno obciążyło by to serwer.
Co wy macie z tym obciążeniem serwera? o.O Niby w jaki sposób miałoby go to obciążyć?
Widzę że nie masz pojęcia (a przynajmniej niezbyt duże) o tym na jakiej zasadzie działają skrypty. Skrypty w MFO są bardzo proste i w praktyce wystarczy kilka instrukcji żeby je zrealizować. W momencie gdyby administracja rozszerzyła te opcję to automatycznie rośnie złożoność algorytmu je analizującego i co za tym idzie czas jego wykonania.
Super by było gdyby pojawił się jakiś prosty język skryptowy, ale jest to raczej nie realizowalne ze względu na nakład pracy jak byłby potrzebny stworzenia jakiegoś parsera (coś co analizuję skrypt i go wykonuje) jak i zasobo-żerność.
Generlanie wystarczyłby IF'y np.
Kod:
IF moje życie <= 1000 AND życie przeciwnika <= 1000
atakuj
ELSE
IF moje życie <= 1000 AND życie przeciwnika > 1000
lecz się
ENDIF
ENDIF
Widzę że nie masz pojęcia (a przynajmniej niezbyt duże) o tym na jakiej zasadzie działają skrypty.
Jeśli możesz, wytłumacz mi tą zasadę.
crk napisał/a:
Skrypty w MFO są bardzo proste i w praktyce wystarczy kilka instrukcji żeby je zrealizować. W momencie gdyby administracja rozszerzyła te opcję to automatycznie rośnie złożoność algorytmu je analizującego i co za tym idzie czas jego wykonania.
1. Złożoność algorytmu wcale nie musi mieć wpływu na czas jego wykonywania. W przypadku skryptu tego typu wątpię, żeby czas wykonywania wzrósł w stopniu, który ktokolwiek byłby w stanie odczuć.
2. Dodanie nowych warunków wpływa na złożoność obliczeniową programu w tak minimalnym stopniu, że można ją w ogóle pominąć. Nie ma mowy o "dość mocnym" obciążeniu serwera.
crk napisał/a:
Super by było gdyby pojawił się jakiś prosty język skryptowy
Heh, marzenia... Też kiedyś o tym myślałem, ale stwierdziłem, że i tak nigdy nie wejdzie, to nie ma nawet sensu proponować. Ale jakby co masz moje poparcie
Widzę że nie masz pojęcia (a przynajmniej niezbyt duże) o tym na jakiej zasadzie działają skrypty.
Jeśli możesz, wytłumacz mi tą zasadę.
Zrobiłem to mniej więcej w poprzednim poście, ale może ujmę to inaczej. Dodanie nowych opcji w skryptach spowoduje konieczność rozszerzenia kodu, które je analizuje, więc musi być bardziej skomplikowany (a już zwłaszcza gdy dodaje się nowy rodzaj komendy, która wprowadza zagnieżdżenia jaką jest IF). Przy jednorazowym uruchomieniu kodu faktycznie różnica jest znikoma, ale nie przy takiej ilości uruchomień skryptu jaka ma miejsce w grze. Wystarczy przemnożyć ilość graczy przez średnią ilość kroków jakie mają i średnią liczbę rund w czasie walki i wychodzi ładna sumka, a przecież są jeszcze pojedynki i ataki na mapie. A przecież to tylko skrypty, a serwer ma jeszcze kupę innych zadań do realizowania.
Mam nadzieję że się wyraziłem zrozumiale
Pitazboras napisał/a:
crk napisał/a:
Super by było gdyby pojawił się jakiś prosty język skryptowy
Heh, marzenia... Też kiedyś o tym myślałem, ale stwierdziłem, że i tak nigdy nie wejdzie, to nie ma nawet sensu proponować. Ale jakby co masz moje poparcie
Dodanie nowych opcji w skryptach spowoduje konieczność rozszerzenia kodu
Owszem.
crk napisał/a:
więc musi być bardziej skomplikowany
Nie musi.
crk napisał/a:
(a już zwłaszcza gdy dodaje się nowy rodzaj komendy, która wprowadza zagnieżdżenia jaką jest IF)
Właśnie dlatego, że if wprowadza zagnieżdżenie, program nie będzie bardziej skomplikowany z punktu widzenia interpretera, który go będzie wykonywał.
crk napisał/a:
Przy jednorazowym uruchomieniu kodu faktycznie różnica jest znikoma
Przy jednorazowym uruchomieniu cały skrypt wykonuje się w ciągu setnych tysięcznych sekundy, więc w ogóle nie ma sensu się tym zajmować.
crk napisał/a:
Wystarczy przemnożyć ilość graczy przez średnią ilość kroków jakie mają i średnią liczbę rund w czasie walki i wychodzi ładna sumka, a przecież są jeszcze pojedynki i ataki na mapie.
Średnia liczba kroków nie ma tu najmniejszego znaczenia, bo nie są one wykorzystywane w jednym czasie. Liczy się ile kroków wykonuje gracz w ciągu sekundy, a to nie jest duża wartość.
crk napisał/a:
Mam nadzieję że się wyraziłem zrozumiale
Nie wyjaśniłeś zasadniczej kwestii - dlaczego uważasz, że dodanie większej liczby warunków znacząco wpłynie na złożoność obliczeniową skryptu odpowiedzialnego za walkę... Rozumiem, że kod przez to staje się dłuższy - ale jak się to ma do czasu potrzebnego na wykonanie skryptu?
Dodanie nowych opcji w skryptach spowoduje konieczność rozszerzenia kodu
Owszem.
Super, chociaż tu się zgadzamy
Pitazboras napisał/a:
crk napisał/a:
więc musi być bardziej skomplikowany
Nie musi.
Trochę mało konstruktywna ta retoryka
Pitazboras napisał/a:
crk napisał/a:
(a już zwłaszcza gdy dodaje się nowy rodzaj komendy, która wprowadza zagnieżdżenia jaką jest IF)
Właśnie dlatego, że if wprowadza zagnieżdżenie, program nie będzie bardziej skomplikowany z punktu widzenia interpretera, który go będzie wykonywał.
Może zadam Ci takie pytanie. Od ilu lat programujesz i jakie masz doświadczenie zawodowe w tej kwestii? Ja się tym zajmuję już od kilkunastu lat. Co do pytania z zagnieżdżeniami, czy zdarzyło Ci się pisać własny interpreter? Ja pisałem, więc mam o tym pewne pojęcie. Każdy kolejny leksem to już dłuższy czas wykonania, nie wspominając o bardziej złożonej analizie syntaktycznej i akcjach semantycznych (ale mądrze to zabrzmiało )
Pitazboras napisał/a:
crk napisał/a:
Przy jednorazowym uruchomieniu kodu faktycznie różnica jest znikoma
Przy jednorazowym uruchomieniu cały skrypt wykonuje się w ciągu setnych tysięcznych sekundy, więc w ogóle nie ma sensu się tym zajmować.
crk napisał/a:
Wystarczy przemnożyć ilość graczy przez średnią ilość kroków jakie mają i średnią liczbę rund w czasie walki i wychodzi ładna sumka, a przecież są jeszcze pojedynki i ataki na mapie.
Średnia liczba kroków nie ma tu najmniejszego znaczenia, bo nie są one wykorzystywane w jednym czasie. Liczy się ile kroków wykonuje gracz w ciągu sekundy, a to nie jest duża wartość.
Nieprawda. Liczy się ilość wykonań skryptu, a to zależy od tego jak długo trwa walka - im trwa dłużej tym więcej razy zostanie uruchomiony skrypt (za każdym razem gdy akcję ma wykonać postać gracza w czasie walki). Cała walka jest wykonywana od razu, a przecież w danej chwili walk toczy się wiele. O krokach wspomniałem dlatego, że obciążenie procesora nie jest stałe, a serwer musi wykonywać wiele akcji oprócz odpalania skryptów, więc uważam że ma to wpływ.
Pitazboras napisał/a:
crk napisał/a:
Mam nadzieję że się wyraziłem zrozumiale
Nie wyjaśniłeś zasadniczej kwestii - dlaczego uważasz, że dodanie większej liczby warunków znacząco wpłynie na złożoność obliczeniową skryptu odpowiedzialnego za walkę... Rozumiem, że kod przez to staje się dłuższy - ale jak się to ma do czasu potrzebnego na wykonanie skryptu?
Nigdzie nie pisałem o złożoności obliczeniowej algorytmu tylko o tym jak bardzo skomplikowany jest kod, a to dwie różne sprawy (chociaż możliwe że jedno i drugie rośnie). Każde rozszerzenie kodu o kolejne instrukcje (choćby to było zwykłe przypisanie wartości) to zwiększenie jego rozmiaru.
Nie wiem jak ci to inaczej pisać. Dla mnie jest jasne, że jedna instrukcja jest dłużej wykonywana niż dwie. Zjedzenie dwóch ciastek trwa dłużej niż zjedzenie jednego. Poderwanie dwóch dziewczyn też trwa dłużej niż poderwanie jednej. Naprawdę kończą mi się już pomysły jak inaczej Ci to uzmysłowić.
To nie jest retoryka. Po prostu nie ma bezpośredniej korelacji między długością kodu, a jego skomplikowaniem. Równie dobrze kod może być krótki i skomplikowany, co długi i prosty jak konstrukcja cepa.
crk napisał/a:
Może zadam Ci takie pytanie. Od ilu lat programujesz i jakie masz doświadczenie zawodowe w tej kwestii?
Oho, argumenty się kończą, to przechodzimy do tego kto się bardziej zna na rzeczy? Nie sądzę, żeby doświadczenie zawodowe miało jakieś znaczenie w merytorycznej dyskusji, bo nie jest w niej argumentem. Ale skoro już pytasz - nie pamiętam, być może około 10 lat.
crk napisał/a:
Co do pytania z zagnieżdżeniami, czy zdarzyło Ci się pisać własny interpreter?
Owszem, zdarzyło mi się.
crk napisał/a:
Każdy kolejny leksem to już dłuższy czas wykonania, nie wspominając o bardziej złożonej analizie syntaktycznej i akcjach semantycznych (ale mądrze to zabrzmiało )
Zabrzmiało mądrze, tylko zapominasz o prostym fakcie, mianowicie w sytuacji, w której twórca interpretera sam ustala do niego składnię, analiza zarówno syntaktyczna, jak i semantyczna jest bardzo mocno uproszczona. Nie musisz sprawdzać znaczenia każdego kolejnego słowa, bo tak układasz składnię, żeby nie mieć z tym problemu.
crk napisał/a:
Nieprawda. Liczy się ilość wykonań skryptu
Ależ bzdura... Liczba wykonań skryptu nie ma najmniejszego znaczenia, liczy się częstotliwość jego wykonań. Serwer wykonujący 100 akcji w ciągu godziny będzie obciążony mniej, niż serwer muszący przetworzyć 50 akcji, ale w ciągu sekundy, przez resztę godziny się obijając.
crk napisał/a:
O krokach wspomniałem dlatego, że obciążenie procesora nie jest stałe, a serwer musi wykonywać wiele akcji oprócz odpalania skryptów, więc uważam że ma to wpływ.
Na co wpływ? Uważasz, że jeśli gracze nie mieliby ograniczenia ruchów (mieli ich nieskończoną liczbę), to obciążenie serwera byłoby nieskończone? Obciążenie wzrosłoby wyłącznie dlatego, że gracze częściej by te ruchy wykorzystywali, a nie dlatego, że mieliby ich więcej.
crk napisał/a:
Nigdzie nie pisałem o złożoności obliczeniowej algorytmu tylko o tym jak bardzo skomplikowany jest kod, a to dwie różne sprawy (chociaż możliwe że jedno i drugie rośnie).
Pisałeś o obciążeniu serwera, a na to nie ma wpływu sposób skomplikowania kodu (jeśli uważasz, że ma, to napisz w jaki sposób).
crk napisał/a:
Każde rozszerzenie kodu o kolejne instrukcje (choćby to było zwykłe przypisanie wartości) to zwiększenie jego rozmiaru.
Oczywiście, tylko że rozmiar kodu nie ma wpływu na obciążenie serwera go wykonującego. Mogę Ci podać przykład bardzo krótkiego kodu znacząco obciążającego serwer, jak i kodu długiego, wykonywanego w mgnieniu oka.
crk napisał/a:
Dla mnie jest jasne, że jedna instrukcja jest dłużej wykonywana niż dwie.
Mylisz się w tej kwestii i to w dwóch sprawach:
1. Jedna instrukcja może wykonywać się o wiele dłużej niż dwie, choćby jedna instrukcja wejścia/wyjścia jest o wiele bardziej czasochłonna niż dwie czy nawet 10 instrukcji przypisania.
2. Sprawa bardziej kluczowa, sprawiasz wrażenie jakbyś myślał, że w programie wykonuje się cały kod, i to na dodatek dokładnie raz. Nie jest to prawdą w żadnym wypadku - jedna linijka kodu może się wykonywać miliony razy albo (i tak jest w tym wypadku) linijka wykonać się w ogóle nie musi. W każdej rundzie wykonywana będzie znikoma część kodu - ta odpowiedzialna za bieżącą akcję. Jedyny dodatkowy nakład to zwiększona liczba instrukcji warunkowych, które będą miały za zadanie określić typ bieżącej akcji. Do większości nowo dodanego kodu interpreter w ogóle nie będzie zaglądał. I to jest główny powód, dla którego sprzeciwiam się stwierdzeniu, że długość kodu wpływa na czas jego wykonania.
Powiem wam (Pit,crk) tyle,ze nie znam sie tak jak wy na programowaniu,ale wydaje mi sie,ze to Pit ma racje
przeciez to nie dlugosc kodu a liczba funkcji wplywa na to,w jakim czasie to sie wykona...
moga byc linijki,ktore nie beda wykorzystywane (np warunkowe-jesli gracz ma 0 ruchow,nie moze sie ruszyc,i wyskakuje komunikat,ale jesli ma <=1,to juz nie bierze pod uwage tej czesci kodu,bo po co mu to?)
_________________
pyry nie som strofe
Pisze nie poprawnie po polskiemu.
To nie jest retoryka. Po prostu nie ma bezpośredniej korelacji między długością kodu, a jego skomplikowaniem. Równie dobrze kod może być krótki i skomplikowany, co długi i prosty jak konstrukcja cepa.
Chyba inaczej podchodzimy do tego samego wyrazu i z tąd nieporozumienie Ty mówisz że im bardziej zamieszany kod tym bardziej skomplikowany. Ja na to patrzę z punktu widzenia jego długości w sensie ilości wykonanych instrukcji (punkt widzenia.... procesora?). Chyba faktycznie użyłem złego słowa. Mae culpa
Pitazboras napisał/a:
crk napisał/a:
Może zadam Ci takie pytanie. Od ilu lat programujesz i jakie masz doświadczenie zawodowe w tej kwestii?
Oho, argumenty się kończą, to przechodzimy do tego kto się bardziej zna na rzeczy? Nie sądzę, żeby doświadczenie zawodowe miało jakieś znaczenie w merytorycznej dyskusji, bo nie jest w niej argumentem. Ale skoro już pytasz - nie pamiętam, być może około 10 lat.
Ależ skąd, poprostu staram się rozeznać z kim rozmawiam (i z tego co widzę to podobne:) )
Pitazboras napisał/a:
crk napisał/a:
Co do pytania z zagnieżdżeniami, czy zdarzyło Ci się pisać własny interpreter?
Owszem, zdarzyło mi się.
Pitazboras napisał/a:
crk napisał/a:
Każdy kolejny leksem to już dłuższy czas wykonania, nie wspominając o bardziej złożonej analizie syntaktycznej i akcjach semantycznych (ale mądrze to zabrzmiało )
Zabrzmiało mądrze, tylko zapominasz o prostym fakcie, mianowicie w sytuacji, w której twórca interpretera sam ustala do niego składnię, analiza zarówno syntaktyczna, jak i semantyczna jest bardzo mocno uproszczona. Nie musisz sprawdzać znaczenia każdego kolejnego słowa, bo tak układasz składnię, żeby nie mieć z tym problemu.
Skoro pisałeś to powinieneś wiedzieć, że to w jaki sposób (w sumie ciężko mi tu coś wymyśleć, kolejność?) co zdefiniujesz gramatykę i leksemy nie ma żadnego wpływu na sam proces wykonywania skryptu. No chyba że robisz jakieś elementarne błędy przy definicji.
Pitazboras napisał/a:
crk napisał/a:
Nieprawda. Liczy się ilość wykonań skryptu
Ależ bzdura... Liczba wykonań skryptu nie ma najmniejszego znaczenia, liczy się częstotliwość jego wykonań. Serwer wykonujący 100 akcji w ciągu godziny będzie obciążony mniej, niż serwer muszący przetworzyć 50 akcji, ale w ciągu sekundy, przez resztę godziny się obijając.
No a o czym ja niby piszę jak nie o tym? Dlatego ci napisałem o walkach, których poszczególne rundy nie wykonują się w momencie naciśnięcia jakiegoś przycisku, ale za jednym zamachem.
Pitazboras napisał/a:
crk napisał/a:
O krokach wspomniałem dlatego, że obciążenie procesora nie jest stałe, a serwer musi wykonywać wiele akcji oprócz odpalania skryptów, więc uważam że ma to wpływ.
Na co wpływ? Uważasz, że jeśli gracze nie mieliby ograniczenia ruchów (mieli ich nieskończoną liczbę), to obciążenie serwera byłoby nieskończone? Obciążenie wzrosłoby wyłącznie dlatego, że gracze częściej by te ruchy wykorzystywali, a nie dlatego, że mieliby ich więcej.
Masło, maślane, a dlaczego częściej wykożystywaliby te ruchy, bo mieliby ich nieograniczoną ilość.
Nieskończone? Nie bardzo wiem skąd to wziąłeś.
Pitazboras napisał/a:
crk napisał/a:
Każde rozszerzenie kodu o kolejne instrukcje (choćby to było zwykłe przypisanie wartości) to zwiększenie jego rozmiaru.
Oczywiście, tylko że rozmiar kodu nie ma wpływu na obciążenie serwera go wykonującego. Mogę Ci podać przykład bardzo krótkiego kodu znacząco obciążającego serwer, jak i kodu długiego, wykonywanego w mgnieniu oka.
Pitazboras napisał/a:
crk napisał/a:
Dla mnie jest jasne, że jedna instrukcja jest dłużej wykonywana niż dwie.
Mylisz się w tej kwestii i to w dwóch sprawach:
1. Jedna instrukcja może wykonywać się o wiele dłużej niż dwie, choćby jedna instrukcja wejścia/wyjścia jest o wiele bardziej czasochłonna niż dwie czy nawet 10 instrukcji przypisania.
2. Sprawa bardziej kluczowa, sprawiasz wrażenie jakbyś myślał, że w programie wykonuje się cały kod, i to na dodatek dokładnie raz. Nie jest to prawdą w żadnym wypadku - jedna linijka kodu może się wykonywać miliony razy albo (i tak jest w tym wypadku) linijka wykonać się w ogóle nie musi. W każdej rundzie wykonywana będzie znikoma część kodu - ta odpowiedzialna za bieżącą akcję. Jedyny dodatkowy nakład to zwiększona liczba instrukcji warunkowych, które będą miały za zadanie określić typ bieżącej akcji. Do większości nowo dodanego kodu interpreter w ogóle nie będzie zaglądał. I to jest główny powód, dla którego sprzeciwiam się stwierdzeniu, że długość kodu wpływa na czas jego wykonania.
ad 1. Podejrzewałem że możesz podjąć taki argument, tyle że zapominasz że poruszamy się w troszeczkę innych płaszczyznach. To nie jest C, ani asembler. Serwer chodzi zapewne w jakimś PHP, Javie, Pythonie, albo czymś jeszcze innym i nie masz tutaj przełożenia 1 do 1 pomiędzy tym co masz w kodzie i tym co się wykona. Równie dobrze można by podjąć argument że procesory są superskalarne, ale właśnie ze wspomnianego powodu nie będzie to miało żadnego wpływu.
ad 2. Oczywiście że nie wykonuje się cały kod, tak samo jak nie wykonuje się on obecnie. Jasne jest, że jeżeli nikt nie skorzystał by z nowych opcji to prawdopodobnie obciążenie by nie wzrosło, ale chyba nie taki byłby sens jego wprowadzania.
P.S
Nie ma co, fajny offtop się zrobił. Zaraz dostanie nam się po warn'ie
Chyba inaczej podchodzimy do tego samego wyrazu i z tąd nieporozumienie Ty mówisz że im bardziej zamieszany kod tym bardziej skomplikowany. Ja na to patrzę z punktu widzenia jego długości w sensie ilości wykonanych instrukcji (punkt widzenia.... procesora?). Chyba faktycznie użyłem złego słowa. Mae culpa
W świetle powyższego, oraz
crk napisał/a:
Nigdzie nie pisałem o złożoności obliczeniowej algorytmu tylko o tym jak bardzo skomplikowany jest kod, a to dwie różne sprawy
dochodzę do wniosku, że jednak utożsamiasz złożoność obliczeniową ze skomplikowaniem, bo "długość w sensie ilości wykonanych instrukcji" to właśnie złożoność obliczeniowa.
crk napisał/a:
Skoro pisałeś to powinieneś wiedzieć, że to w jaki sposób (w sumie ciężko mi tu coś wymyśleć, kolejność?) co zdefiniujesz gramatykę i leksemy nie ma żadnego wpływu na sam proces wykonywania skryptu.
Ależ ma, inaczej zdefiniowana gramatyka (gramatyka? na dobrą sprawę do takiego skryptu nie trzeba żadnej gramatyki) wymaga innego interpretera. Im prostsza gramatyka, tym prostszy interpreter ją analizujący.
Cytat:
Masło, maślane, a dlaczego częściej wykożystywaliby te ruchy, bo mieliby ich nieograniczoną ilość.
Tak, ale nie ma bezpośredniej zależności między liczbą posiadanych ruchów, a liczbą wykonań skryptu. Jest natomiast pomiędzy liczbą wykorzystanych ruchów, a liczbą wykonań skryptu.
crk napisał/a:
Nieskończone? Nie bardzo wiem skąd to wziąłeś.
To był przykład mający Ci uświadomić nieistnienie powyższej zależności.
crk napisał/a:
To nie jest C, ani asembler. Serwer chodzi zapewne w jakimś PHP, Javie, Pythonie, albo czymś jeszcze innym i nie masz tutaj przełożenia 1 do 1 pomiędzy tym co masz w kodzie i tym co się wykona.
W C również nie ma przełożenia 1 do 1 (proste i++ to co najmniej 3 instrukcje dla procesora), zresztą dokładnie o tym pisałem - jedna instrukcja w kodzie nie jest równa jednej instrukcji procesora, zresztą nawet jedna instrukcja procesora nie musi być wykonywana w takim samym czasie (patrz przykład, który podałem wcześniej).
crk napisał/a:
ad 2. Oczywiście że nie wykonuje się cały kod, tak samo jak nie wykonuje się on obecnie. Jasne jest, że jeżeli nikt nie skorzystał by z nowych opcji to prawdopodobnie obciążenie by nie wzrosło, ale chyba nie taki byłby sens jego wprowadzania.
Cały czas pomijasz fakt, że w jednej rundzie gracz wykonuje tylko jedno polecenie z inteligencji, więc niezależnie od tego, czy ktoś będzie korzystał z nowych opcji, czy nie, i tak nigdy nie będzie się wykonywał cały kod programu, a tylko niewielka jego część.
crk napisał/a:
Nie ma co, fajny offtop się zrobił. Zaraz dostanie nam się po warn'ie
Jaki offtop? Cały czas dyskutujemy na temat. W razie czego mogę to wydzielić gdzie indziej...
Chyba inaczej podchodzimy do tego samego wyrazu i z tąd nieporozumienie Ty mówisz że im bardziej zamieszany kod tym bardziej skomplikowany. Ja na to patrzę z punktu widzenia jego długości w sensie ilości wykonanych instrukcji (punkt widzenia.... procesora?). Chyba faktycznie użyłem złego słowa. Mae culpa
W świetle powyższego, oraz
crk napisał/a:
Nigdzie nie pisałem o złożoności obliczeniowej algorytmu tylko o tym jak bardzo skomplikowany jest kod, a to dwie różne sprawy
dochodzę do wniosku, że jednak utożsamiasz złożoność obliczeniową ze skomplikowaniem, bo "długość w sensie ilości wykonanych instrukcji" to właśnie złożoność obliczeniowa.
No to tutaj walnąłeś byka. Złożoność obliczeniowa jest związana z tym jak się zmienia ilość wykonanych instrukcji w zależności od ilości danych wejściowych. Nie ma to nic wspólnego z ilością wykonanych operacji (a przynajmniej nie strikte bezpośrednio). Dlatego w prawdziwe jest wyrażenie.
O(n) + 1000 = O(n)
Wynika z niego że jeżeli masz jakiś ekstra nakład obliczeniowy, który jest wykonywany do inicjalizowania czegoś (zmienne, tablice, cholera wie co) to nie ma on wpływu na złożoność, mimo że będzie miał wpływ na czas działania i co za tym idzie na obciążenie serwera. Możesz napisać sortowanie które będzie miało,
złożoność O(n), ale będzie tyle dodatkowych akcji wykonywało w czasie sortowania, że będzie chodziło cały dzień.
Pitazboras napisał/a:
crk napisał/a:
Skoro pisałeś to powinieneś wiedzieć, że to w jaki sposób (w sumie ciężko mi tu coś wymyśleć, kolejność?) co zdefiniujesz gramatykę i leksemy nie ma żadnego wpływu na sam proces wykonywania skryptu.
Ależ ma, inaczej zdefiniowana gramatyka (gramatyka? na dobrą sprawę do takiego skryptu nie trzeba żadnej gramatyki) wymaga innego interpretera. Im prostsza gramatyka, tym prostszy interpreter ją analizujący.
Jasne że nie jest potrzebna. Mówiłem o bardziej ogólnym przypadku. Tak czy owak Ty teraz zaczynasz pisać o optymalizowaniu kodu, a dyskusja wyszła od czegoś innego. Ja mówię że dodanie kolejnych warunków czy tam elementów gramatyki wydłuży działanie algorytmu, z czym ty się nie zgadzasz.
Pitazboras napisał/a:
Cytat:
Masło, maślane, a dlaczego częściej wykożystywaliby te ruchy, bo mieliby ich nieograniczoną ilość.
Tak, ale nie ma bezpośredniej zależności między liczbą posiadanych ruchów, a liczbą wykonań skryptu. Jest natomiast pomiędzy liczbą wykorzystanych ruchów, a liczbą wykonań skryptu.
Tak ale wychodzi na to co powiedziałem, że ilość dostępnych ruchów wpłynie (w sposób pośredni) na ilość wykonanych kroków. Nie wiem czy admini prowadzą jakieś statystyki w tej kwestii, ale na czymś musiałem oprzeć moje założenia, więc podałem kroki zakładając że jeżeli ktoś je ma to je wykorzystuje.
Pitazboras napisał/a:
crk napisał/a:
To nie jest C, ani asembler. Serwer chodzi zapewne w jakimś PHP, Javie, Pythonie, albo czymś jeszcze innym i nie masz tutaj przełożenia 1 do 1 pomiędzy tym co masz w kodzie i tym co się wykona.
W C również nie ma przełożenia 1 do 1 (proste i++ to co najmniej 3 instrukcje dla procesora), zresztą dokładnie o tym pisałem - jedna instrukcja w kodzie nie jest równa jednej instrukcji procesora, zresztą nawet jedna instrukcja procesora nie musi być wykonywana w takim samym czasie (patrz przykład, który podałem wcześniej).
Ok, ale to nie od tego wyszła wyskusja. Mam wrażenie raz po raz co raz bardziej odchodzimy od głównego wątku Meriutum moich wypowiedzi jest takie że więcej instrukcji wydłuży działanie kodu (jeżeli tak nie jest to znaczy że dodany kod jest zbędny, bo nie jest wykonywany) a nie to czy jedne wykonują się dłużej a inne krócej.
Pitazboras napisał/a:
crk napisał/a:
ad 2. Oczywiście że nie wykonuje się cały kod, tak samo jak nie wykonuje się on obecnie. Jasne jest, że jeżeli nikt nie skorzystał by z nowych opcji to prawdopodobnie obciążenie by nie wzrosło, ale chyba nie taki byłby sens jego wprowadzania.
Cały czas pomijasz fakt, że w jednej rundzie gracz wykonuje tylko jedno polecenie z inteligencji, więc niezależnie od tego, czy ktoś będzie korzystał z nowych opcji, czy nie, i tak nigdy nie będzie się wykonywał cały kod programu, a tylko niewielka jego część.
Tak ale zanim to polecenie się wykona to algorytm musi do tego dojść. Gdy ktoś walnie coś na stylu
Kod:
IF życie < 10
lecz się
ELSE.
atakuj
ENDIF.
To faktycznie albo ktoś się uleczy, albo zaatakuje, ale zanim do tego dojdzie musi przejść przez nową funkcjonalność. Jak zaznaczyłem wcześniej zakładam że jeżeli taka funkcjonalność istnieje to jest ona wykorzystywana (inaczej nie ma sensu jej wprowadzać), a w przypadku zaproponowanych przeze mnie warunków IF, nie będzie to coś marginalnego, ale wręcz przeciwnie.
Pitazboras napisał/a:
crk napisał/a:
Nie ma co, fajny offtop się zrobił. Zaraz dostanie nam się po warn'ie
Jaki offtop? Cały czas dyskutujemy na temat. W razie czego mogę to wydzielić gdzie indziej...
No tak, nie zwróciłem uwagi na to że dyskutuję z moderatorem
No to tutaj walnąłeś byka. Złożoność obliczeniowa jest związana z tym jak się zmienia ilość wykonanych instrukcji w zależności od ilości danych wejściowych. Nie ma to nic wspólnego z ilością wykonanych operacji (a przynajmniej nie strikte bezpośrednio). Dlatego w prawdziwe jest wyrażenie.
O(n) + 1000 = O(n)
To, o czym piszesz, to asymptotyczne oszacowanie złożoności obliczeniowej. Złożoność obliczeniowa to ilość zasobów potrzebnych do wykonania programu, czyli dokładnie to, o czym obaj piszemy.
crk napisał/a:
Jasne że nie jest potrzebna. Mówiłem o bardziej ogólnym przypadku.
A ja pisałem o przypadku, który jest omawiany w tym temacie, czyli inteligencja gracza. Nie widzę sensu rozważania ogólniejszych przypadków, przynajmniej tutaj.
crk napisał/a:
Meriutum moich wypowiedzi jest takie że więcej instrukcji wydłuży działanie kodu (jeżeli tak nie jest to znaczy że dodany kod jest zbędny, bo nie jest wykonywany) a nie to czy jedne wykonują się dłużej a inne krócej.
1. Więcej instrukcji nie musi wydłużyć działania kodu, po prostu niektóre nie będą wykonywane przy danym obrocie pętli...
2. ... ale będą wykonywane przy następnym, więc dodany kod wcale nie jest zbędny.
Prosty przykład, bo chyba cały czas nie rozumiesz...
Kod:
for i = 1 to 100 do
if i < 50 then
blok instrukcji 1
else
blok instrukcji 2
Kod:
for i = 1 to 100 do
if i < 50 then
blok instrukcji 1
else if i < 75 then
blok instrukcji 2
else
blok instrukcji 3
Kod 2. jest dłuższy, natomiast jeśli bloki 2 i 3 są tak samo "skomplikowane" (cokolwiek by to miało oznaczać), to program będzie działał tak samo długo (ok, będzie jedno porównanie "if i < 75" więcej, ale jest to nakład marginalny), mimo że żaden fragment kodu w drugim przykładzie nie jest nadmiarowy.
crk napisał/a:
To faktycznie albo ktoś się uleczy, albo zaatakuje, ale zanim do tego dojdzie musi przejść przez nową funkcjonalność.
Ale przecież tej nowej funkcjonalności nie wykonuje. Przyznam, że nie wiem, w jaki sposób PHP przechodzi do else z niespełnionego ifa (wspomniana przez Ciebie Java radzi sobie z tym doskonale, instrukcjami skoku, jak w C czy assemblerze), ale nawet jeśli czyta cały kod wewnątrz bloku if, to samo czytanie kodu, bez wykonywania go, nie powinno zwiększyć nakładu czasowego. Zwłaszcza, że problem można bardzo prosto rozwiązać, tworząc odwołania do funkcji.
Level: 194
Wiek: 33 Dołączył: 18 Maj 2007 Skąd: Częstochowa
Wysłany: 23-12-2008, 15:13
Przepraszam, że się tak wtrącam, ale co byście chcieli dodać, czego jeszcze nie ma? Co jest jeszcze takiego, że niezbędnym jest, żeby stworzyć język skryptowy? Teraz w inteligencji możemy ustawić i leczenie i atakowanie przeciwnika, w sumie innej możliwości podczas walki nie ma (oświećcie mnie jeśli jest inaczej)... Poza tym gracze musieliby opanować składnię takiego języka, co dla niektórych byłoby ciężkie. Nawet najprostszy język może być dla kogoś trudny (biorąc pod uwagę to, że teraz niektórzy nie mogą sobie poradzić z wybieraniem poleceń...)
Chcecie, żeby zamiast tego co mamy teraz wstawiać można było robić zagnieżdżone warunki. A teraz nie można? Kwestia dodania nowego polecenia w inteligencji. Patrzcie (wybaczcie, że nie ma miniaturki, polecenie 2 potraktujmy jakby wcale nie istniało):
Polecenia 1 i 3 to w pewnym sensie zagnieżdżony warunek:
Kod:
IF hp <= hp*0.4
IF wrog.hp >= wrog.hp*0.3
lecz się miksturą hp lvl 5
ELSE
atakuj
IF mp <= 32
lecz się eliksirem
Jedyny problem jaki jest teraz to ograniczona ilość poleceń w inteligencji, który taki język mógłby wyeliminować.
Poza tym, jeśliby całkowicie zastąpić to co mamy teraz jakimś językiem, to nie wydaje mi się, żeby jakoś strasznie wzrosła złożoność (czy spadła szybkość, wszystko jedno) interpretera tych skryptów - przecież do tego co jest teraz też musi być jakiś interpreter, prawda? Zdaje mi się, że języka nie ma i nie będzie z np. tego względu, że gracze mogliby tam powypisywać bzdury i zaczęliby się żalić dlaczego im nie działa lub co gorsza wykrzaczał by się parser, albo nie wiedzieliby co powpisywać przy ifach (hp, mp, wrog.hp itp).
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach
Regulamin Forum
Chociaż zdaje sobie sprawę z tego że dosyć mocno obciążyło by to serwer.
)
Ty mówisz że im bardziej zamieszany kod tym bardziej skomplikowany. Ja na to patrzę z punktu widzenia jego długości w sensie ilości wykonanych instrukcji (punkt widzenia.... procesora?). Chyba faktycznie użyłem złego słowa. Mae culpa
