Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Patrulek

Strony: [1] 2 3
1
Warsztat Summer of Code 2017 / Odp: Warsztat Summer of Code 2017
« dnia: Sierpień 14, 2017, 11:37:25 »
Mam nadzieję, że też coś uda mi się napisać. Póki co, tworzy się pomysł.

2
Cytuj
Ogólnie jak zapisywałem tą "kaskadę" jako dwie serie bajtów: opers and orders to nie miałem za bardzo pomysłu jak zdefiniowac operację crossoveru tak aby było sensownie. Opers to tablica operatorów (z wartościami od 0 do 10), Orders natomiast to tablica która poprzez swoje wartości sugeruje odpowiednie przemieszanie elementów, jakby permutację, zmianę kolejności na odpowiadającej kaskadzie. Crossover więc zdefiniowałem jak typowy crossover na bajtach poprostu i wziąłem go mało a w pewnych iteracjach rozwiązywania problemu w ogóle dałem go na zero procent.

Nie bardzo rozumiem co masz na myśli mówiąc o permutacji elementów. Kaskada o której piszesz jest tak jakby drzewem. Operację krzyżowania możesz zdefiniować dzieląc to drzewo na dwie części (niekoniecznie równe) i tworzyć potomków biorąc lewą część z pierwszego rodzica i prawą część z drugiego, i na odwrót. Przy czym robisz to tylko z operatorami. Mógłbyś próbować też dzielić liczbę wejściową, ale wtedy musiałbyś "naprawiać dzieci", tj. usuwać powtarzające się bity i dodawać brakujące. Myślę, że lepiej jakby tym zajął się operator mutacji. Poglądowy rysunek:



Operator mutacji z kolei, zamienia miejscami poddrzewa w drzewie lub kolejność bitów liczby wejściowej. Odległość Hamminga wydaje się sensowną funkcją dopasowania.


Cytuj
Próbowałem pójśc za radą Dab'a, ale nie umiem dobrac odpowiedniej liczby warstw ukrytych, i odpowiedniej funkcji aktywacji (wybierałem sigmoidy i z dużą alfą i z małą i z bardzo małą i nic). Cały czas error rate nie schodzi w dół tylko raz spadnie raz wzrośnie. Próbowałem tego z niskimi i wysokimi learning rate i nic.

Tutaj jest nieduże narzędzie, które być może mogłoby Ci pomóc w doborze topologii sieci. Nie używałem, nie wiem jak to w praktyce wychodzi, ale wygląda ciekawie.
Tutaj z kolei masz slajdy ze Stanfordu odnośnie deep learningu. Nawet jeśli byś nie chciał budować głębokich sieci to jest tam trochę informacji/pojęć, które mogą być przydatne + jest kilka architektur wykorzystanych w konkursie ImageNet.
Ogółem co do doboru parametrów to nie ma dobrej metody na każdy problem. Można na początku się trochę pobawić samemu jeśli masz jakieś przypuszczenia odnośnie tego, co może się sprawdzić, ale najlepiej chyba po prostu puścić automat, który znajdzie odpowiednie parametry.

3
Odnośnie programowania genetycznego: próbowałeś może zmienić parametry algorytmu? 95% mutacji brzmi jakby algorytm miał problemy ze stabilizacją populacji przez co ostatecznie mógł wyznaczyć wynik bliski randomowemu wybieraniu. Proporcje mutacji/crossingu powinny być raczej odwrotne. Chyba że pomyliłeś się tylko podczas pisania postu. W dodatku przyjmując, że funkcja składa się z 2^9 operatorów, gdzie każdy z nich jest jednym z, mniej więcej, dziesięciu zdefiniowanych, to masz do wyboru jedną funkcję spośród 10^(2^9). Próbowałeś zmniejszyć zakres liczby wejściowej, liczby zdefiniowanych operatorów lub głębokości drzewa np. pozwalając na większą ilość bitów niż 1 jako operand i zobaczyć jak sobie algorytm wtedy poradzi?

Próbowałeś może sprawdzić statystycznie, czy są jakieś bity które mają znaczący wpływ na wynik? Czy dana sekwencja bitów, niezależnie od położenia, generuje taki sam wynik? A może generuje go według jakiegoś prostego schematu? Różnica w liczbie zer/jedynek? Możliwości jest zbyt dużo, żeby dało się to jakoś sensownie rozwiązać, ale może istnieje jakaś bardzo prosta zależność, którą jesteś w stanie wymyślić i przetestować niewielkim nakładem czasowym?

Ogółem poszedłbym za radą Dab'a i skorzystał z sieci neuronowych, ale poszedłbym raczej w głębokie uczenie. Możesz np. spróbować przyjąć, że cała liczba jest dwukanałowym obrazem 16x16 i spróbować uczyć sieć, tak jak robi się to dla obrazów. Jeśli masz dostęp do mocnych kart graficznych, to może być to jakaś metoda.

Podejście do problemu z innej strony: reverse engineering (o ile masz dostęp do programu).

4
Szkółka / Odp: [C++] Nazewnictwo zmiennych
« dnia: Czerwiec 15, 2017, 16:19:30 »
Kiedyś używałem camelCase'a do zmiennych i nazw funkcji, ale później wypracowałem sobie styl, żeby zmienne pisać underscorem. Najważniejsze to  trzymać się jednej konwencji w projekcie. Póki piszesz coś samemu, to po prostu przez doświadczenie wypracujesz sobie własny styl, w którym będzie Ci się później dobrze czytać kod, w grupowym projekcie i tak będziesz musiał prawdopodobnie z niego zrezygnować na rzecz całego teamu. Nazewnictwo jakie ja stosuję:

Zmienne:
- lokalne / pola klasy - underscore (np. is_alive), jeżeli dodatkowo piszę w edytorze/IDE bez wsparcia odnośnie typów lub w językach z typowaniem dynamicznym dodaję przed nazwą zmiennej jej typ podstawowy (np. b_is_alive)
- parametry funkcji - underscore z poprzedzonym podkreślnikiem (np. _is_alive); ten trick wykorzystuję dlatego, że nie podobało mi się pisanie w Javie słówka 'this' żeby przypisać zmienną o tej samej nazwie i tak mi już zostało

Stałe / makra:
- underscore, gdzie cała nazwa pisana jest wielkimi literami (np. DAY_TO_SECONDS)

Funkcje:
- camelcase, od razu widać co jest zmienną a co metodą (np. doSomething())  (w pracy z kolei używamy też underscore'a żeby nazewnictwo było jednakowe ze standardowymi pakietami - to akurat w PLSQL - jednak żeby odróżnić nieco od nazw zmiennych zaczynamy każdy wyraz wielką literą, np. Do_Something())
- niektóre języki pozwalają na zapisanie wywołania metody bezparametrowej w taki sposób, że wygląda jak zmienna (bez użycia () za nazwą), mimo wszystko polecam stosować nawiasy (to tak poza C++)

Typy:
- PascalCase (np. SomeClass)

Najważniejsze to stosować nazwy, które jednoznacznie określają co dana zmienna/metoda/klasa oznacza. Czasem jest trudno, podasz jakąś nazwę, żeby za 5 min ją zmienić i to jest ok, o ile poprawi to czytelność kodu.

Co do długich nazw nie są one problemem dopóki:
- korzystasz z edytora, który ma podpowiadanie kodu
- jest bardzo mało takich nazw w module
- zmienne te nie posiadają wspólnego członu (odpowiednio długiego) na początku nazwy

A propo poszukiwania własnego stylu, możesz albo wypracowywać go samemu, albo popatrzeć w jakieś otwarte projekty i z nich czerpać inspiracje, jeśli uznasz że jakiś projekt dobrze Ci się czyta, to być może warto przetestować te praktyki nazewnictwa u siebie.

5
Szkółka / Odp: poruszenie sprita z punktu A do B
« dnia: Grudzień 18, 2016, 13:01:04 »
Cytuj
Ta, bo jak ktoś zaczyna naukę, to pierwsze co robi, to zaczyna od pętli czasu rzeczywistego, liczenia fps'ów i ich ograniczania. Ludzie, trzymajcie mnie.

OP napisał, że ma już poruszanie za pomocą strzałek, jakąś pętlę musi mieć do sprawdzania wystąpienia eventów klawiszy. Mam się domyślić, czy ogranicza jakoś czas? Przyjąłem takie założenie, a nie inne, jeśli się okaże, że autor nie ma takiej pętli to po prostu się uzupełni wypowiedź, ludzie trzymajcie go.

Co do kodu, widzę błąd, zaraz poprawię. Obliczeniowo jest poprawnie, ale złe nazewnictwo się wkradło. Pewnie godzina zrobiła swoje i trochę przekombinowałem.

6
Szkółka / Odp: poruszenie sprita z punktu A do B
« dnia: Grudzień 18, 2016, 01:58:26 »
Podejrzewam, że posiadasz pętlę czasu rzeczywistego, która ogranicza Ci jakoś prędkość programu do np. 60 klatek na sekundę?

SDL_Event event;

if( SDL_PollEvent(&event) ) {
  if( event.type == SDL_MOUSEBUTTONDOWN ) {
    Vec2D delta = target_pos - player_pos; // Na początek obliczasz wektor pomiędzy celem, a obiektem

    float obj_target_dist = delta.magnitude(); // Math.sqrt(delta.x * delta.x + delta.y * delta.y) ... obliczasz odległość obiektu od celu, aby przechować później tę wartość w obiekcie
   
    delta.normalize(); // delta /= delta.magnitude() ... normalizujesz wektor delta, będziesz wiedział ile musisz się przemieścić na osi x, oraz na osi y aby przemieścić się o 1 jednostkę

    Vec2D velocity = delta * player.speed * Time.deltaTime ; // wektor prędkości obiektu

    player.velocity = velocity; // nadajesz prędkość graczowi
    player.player_target_dist = obj_target_dist; // nadajesz odległość jaką musi pokonać; można by to obliczać co klatkę, ale w sumie po co ;)
  }
}

void player::move() {
  player_target_dist -= velocity.magnitude();

  if( player_target_dist > 0 )  { // jeszcze nie doszliśmy do celu
    pos += velocity;
  } else { // przeszliśmy za daleko
    float ratio = (velocity.magnitude() + player_target_dist) / velocity.magnitude(); // musimy obliczyć przez jaki ułamek przemnożyć prędkość aby nie przejść za daleko celu
    pos += velocity * ratio;

    velocity = Vec2D.ZERO; // zerujemy wektor prędkości, doszliśmy do celu
    player_target_dist = 0;
  }
}

@edit
Jason mnie ubiegł, aczkolwiek dałem trochę bardziej szczegółowe wyjaśnienia ;)

@edit2
Poprawiono.

7
Też kiedyś się zastanawiałem jak to dokładnie działa, ale nigdy samemu nie próbowałem czegoś takiego napisać. Przede wszystkim pomyślałbym najpierw jak będą wyglądać mapy. Jeśli nie będzie map, które będą miały przejścia np. węższe niż 3 jednostki to bym prawdopodobnie próbował rozwiązywać kolizje dopiero w momencie kiedy nastąpią. Czyli:

1) znajdź ścieżkę do celu:
* jeśli cel nieosiągalny to jednostka zaczyna narzekać i się nie rusza
* jeśli osiągalny (jako obszar) ale samo pole jest zajęte to szukałbym pola najbliżej położonego, a jak będziemy się zbliżać do celu to raz jeszcze sprawdzić, czy pole faktycznie jest zajęte
* jeśli pole wolne to ścieżka bezpośrednio do tego pola
2) po znalezieniu ścieżki przesuwamy się po gridzie i badamy czy następne pole do którego chcemy iść nie będzie zajęte:
* jeśli nie to idziemy
* jeśli zajęte to jednostki między sobą muszą rozwiązać tę kolizję; przydałyby się jakieś reguły postępowania w różnych sytuacjach i według tych reguł rozwiązać kolizje np. poprzez dodanie jakiejś sekwencji ruchów do pola/pól obok, po jakimś czasie można odwrócić sekwencję i kontynuować drogę albo obliczyć nową ścieżkę od pola na którym skończyliśmy kolizję;
3) powtarzaj do momentu aż nie dojdziesz do wyznaczonego celu

Jeśli mapy będą zawierać jakieś wąskie przejścia, wąwozy, mosty, cokolwiek to:
1) można spróbować postępować jak wyżej przy czym należałoby dodać odpowiednie reguły przy przechodzeniu przez takie przejścia (np. tak, żeby zminimalizować czas przejścia wszystkich jednostek na drugą stronę); np. ustalić która strona ma pierwszeństwo i oszacować czas jak długo będą zajmowały przejście; po tym czasie jednostki z drugiej grupy skorzystałyby z szansy że przejście jest wolne, jeśli rzeczywiście jest
2) można by oznaczyć w edytorze takie wąskie przejścia i już przy liczeniu ścieżki brać pod uwagę, że będziemy przez nie przechodzić; wtedy jeśli akurat się zdarzy sytuacja że przejście będzie zajęte to podzielić ścieżkę na dwie części, idziemy do punktu przed przejściem, czekamy odpowiednią ilość czasu i kontynuujemy drogę drugą ścieżką / ewentualnie jeśli nie jest to jedyne przejście, a droga będzie wystarczająco długo zablokowana możemy szukać innej drogi; kolizje które by występowały w miejscach innych niż wąwozy rozwiązywać dopiero w momencie wystąpienia
3) podzielić mapę na obszary (logiczne) lub wyznaczyć pewien obszar dookoła jednostek; przy każdej zmianie liczby jednostek w obszarze sprawdzić czy wystąpi kolizja; jeśli tak to ją rozwiązać zanim wystąpi

8
Matematyka i fizyka / Odp: Najlepszy ruch obiektu
« dnia: Listopad 08, 2016, 19:09:37 »
Nie wiem, czy to w ogóle można traktować jako rzut poziomy. W rzucie poziomym prędkość na osi y w czasie t0 nie powinna wynosić 0?

Można to wyliczyć np. za pomocą wzoru s = v0t + gt^2 / 2
Wychodzi równanie kwadratowe z którego obliczamy t, znając t obliczamy przesunięcie na osi x w tym czasie i mamy wynik, który dla g = 4 wychodzi też 172.

9
Matematyka i fizyka / Odp: Najlepszy ruch obiektu
« dnia: Listopad 08, 2016, 15:36:23 »
Dla mnie to wygląda jak wałek w zadaniu. Zastanawia mnie grawitacja, wydaje mi się dziwnie mała. Wynik wychodzi 172 (w przybliżeniu), ale podstawiając pod grawitację wartość 4.

Kod

10
Matematyka i fizyka / Odp: Najlepszy ruch obiektu
« dnia: Listopad 05, 2016, 16:53:16 »
Cytuj
W skrócie pisząc jak obliczyć w którym miejscu x upadnie piłka?

Oblicz czas jaki potrzebuje piłka aby pokonać różnicę wysokości między nią, a obiektem, a później odległość jaką pokona w tym czasie na osi x.

11
Projektowanie kodu / Odp: Projektowanie kodu - robicie? Jak?
« dnia: Wrzesień 01, 2016, 13:43:23 »
A ja z kolei polecam projektować nawet jeśli nie jest to nic dużego i można to skończyć relatywnie szybko. Nie musi to być bardzo szczegółowe projektowanie z różnymi diagramami klas/sekwencji itd, nawet zwykłe use case'y w punktach często dużo dają. Oprócz tego, że się nieco podszkolisz to może Ci to zaoszczędzić później trochę pracy plus nic tak nie motywuje jak odhaczanie zrobionych zadań. Bo rozumiem, że teraz robisz coś na zasadzie: "potrzebuję takiej funkcjonalności, to sobie ją teraz napiszę"? Ok, wtedy też można śledzić swój progres, ale według mnie, to nie to samo.

Dodatkowo projektowanie ma jak dla mnie ważną cechę: jeśli projekt zaczyna zbaczać z toru (w końcu wszystkiego od razu nie przewidzimy) to być może powinniśmy się znów zastanowić w jakim kierunku powinno to wszystko dalej pójść i pomyśleć o refactoringu zanim utkniemy w bagnie.

Ale o tym co wyżej pewnie też gdzieś już wyczytałeś, a jak ja to robię? Zaznaczam, że też się z tym borykam jeszcze, ale tutaj mogę potwierdzić słowa Rega i MrKaktusa.
Wpadłem na pomysł na pewną aplikację, pierwsze co zrobiłem to rozpisałem sobie w punktach, co powinna ona robić (interakcja z użytkownikiem ogranicza się do minimum, ale sama w sobie wykonuje trochę czynności). Przy czym tutaj starałem się raczej przechodzić od ogółu do szczegółu, tj. mam jakąś funkcjonalność i idę w głąb problemu szukając jego podproblemów i zależności od innych problemów. Przykładowo potrzebowałem monitorować aktywne okno w systemie, zadałem sobie pytania: "jak?", "w jaki sposób?". Timer, i tu schodzimy głębiej, "jaki interwał?", "w jaki sposób zaimplementować?" itd.  Później szukałem zależności, aplikacja powinna coś tylko jeśli aktywne jest konkretne okno. W taki sposób starałem się rozpracować jak największą liczbę funkcjonalności.
Następnie starałem się je dopasować w logiczne moduły z podmodułami: parser XML, komunikacja z systemem itd. Kolejno stworzyłem sobie diagram z zależnościami między modułami. I ok, dzięki temu udało mi się stworzyć podstawową wersję aplikacji. W międzyczasie wpadłem na kilka dodatkowych pomysłów, których wcześniej nie zaprojektowałem. Więc stworzyłem sobie proste gui dla kolejnej wersji i zacząłem kodzić. Złapałem się na tym, że po dodaniu nowej funkcjonalności potrzebna jest mi jednak dalsza analiza i refactor.

Ze swojej strony mogę jeszcze polecić stronkę draw.io na której sobię tworzę diagramy i gui. Powyższe może nie odnosi się w pełni do gier, ale nie samymi grami człowiek żyje :P

12
Warsztat Summer of Code 2016 / Odp: Warsztat Summer of Code 2016
« dnia: Sierpień 02, 2016, 23:53:03 »
W tym roku także spróbuję swoich sił. Mam w planach dwie proste gierki, mam nadzieję, że wrzesień wystarczy na ukończenie chociaż jednej z nich.

13
Warsztat Summer of Code 2015 / Odp: Warsztat Summer of Code 2015
« dnia: Październik 17, 2015, 03:07:40 »
Wow, całkowicie nie spodziewałem się podium, a do tego jeszcze 4x 2 miejsca w kategoriach specjalnych... taki wynik cieszy i mobilizuje do dokończenia i dopracowania projektu.
Wcale natomiast nie dziwi mnie fakt, że CaveStrider i AncientTower zajęły tak dobre miejsca, które są zdecydowanie zasłużone.
Gratki dla wszystkich, którym udało się skończyć projekt przed czasem.

14
Warsztat Summer of Code 2015 / Odp: Warsztat Summer of Code 2015
« dnia: Październik 11, 2015, 21:33:28 »
Tam gdzie się nie odpalało to nie wiem czy był ten redist (możliwe, że nie, chociaż żaden komunikat o braku jakichś bibliotek nie wyskakiwał, po prostu nic się nie działo), ale nawet jeśli nie było, to nie miałem administratora, żeby zainstalować. Na lapku za to pomogła zmiana rozdzielczości na niższą, także przetestuję i zaktualizuję opis.

15
Warsztat Summer of Code 2015 / Odp: Warsztat Summer of Code 2015
« dnia: Październik 11, 2015, 16:18:35 »
Może źle to napisałem :) Z powrotem do miasta udało mi się wejść, ale nie widziałem nigdzie drogi dalej, po obu stronach lasu kłody przez które nie dało się dalej przejść, a w lesie tylko kilka mobów i jakaś chatka.

Strony: [1] 2 3