A tak serio to ciągle tego używam (różnych modeli) i rozumiem dlaczego zastąpiło juniorów, oraz dlaczego nie zastąpi seniorów w tej architekturze jaka jest. To jest dosłownie tak bezmyślne jak junior. Taki sam poziom ogarnięcia z matmy i rozumienia co się dzieje liczbom, że źle oraz wywnioskowanie co w kodzie jest z dupy bo syntax.
Jak palcem nie pokażesz i nie przypier… z dokumentacji to w zaparte idzie, że coś ma działać, kiedy nie działa. A jak dokumentacja jest wadliwa to leży i kwiczy.
W trybie Agent działa istotnie lepiej, bo samo siebie opiernicza. Ale działa tylko na dobrze zdefiniowanym boisku (tzn musi umieć tez robić buildy, testy i czytać wyniki). Więc każdy duży system legacy jest nie do przejścia, bo tam stary kod to najmniejszy problem. Pamiętam z czasów pracy w Motorolii w Krakowie. Oni mieli jakiś kompletnie poroniony system buildów dla C++, co miał 4 różne warstwy i działał tylko na dyskach sieciowych Novella w IBMowskim ClearCase.
Tak, ale listując “szto duma” to włącza się za dużo pętli zabezpieczenia przed
infinite loops jeśli ma się odnieść do funkcji. Ponieważ korzysta z czegoś co od biedy przypomina zmutowanego llm do liczb to nie robi tego dość oszczędnie i ma trudność w śledzeniu losów argumentu.
Na przykład w glsl es regularnie wykłada się, bo gdzieś w danych treningowych ma normalize(vecN) gdzie sama konstrukcja gpu poza pewnymi atrybutami, które muszą być (a i tak niestosujesiędlaporządku) nie pozwala na funkcję wewnętrznie zwracającą do argumentu, musi być vecN = normalize(vecN), średnik, basta. No i takiego babola nie wyłowi, ale sam zaleci (losowo - raz tak, raz siak, jak gdyby dane treningowe były równoważne).
Jak wylistowałem debug z shadera i się popatrzyłem, że coś nie gra na wyjściu to wrzuciłem do zmielenia. Zaczął mi pierdolić że trzeba bitangent i takie tam duperele (kiedy po prostu obracałem normalne o losowe wartości, żeby trochę noisu zadać). Normalnie, po bożemu mat[3x3]. Jak mi wypisało równanie to go wyłączyłem i poszedłem pomyśleć. Bo błąd występował tylko w jednym wypadku (y+ ca 1. przestawiało się na -1. plus minus parę groszy).
Pomyślałem sobie tak dzień, włączyłem debug i zacząłem sobie spisywać wyniki na kartce. Okazało się, że jedna linijka mnożenia za zakresu 0-1 mul 0-1 pozwalało uzyskać >1 bo błędy numeryczne; no i normalizacja była spaprana w sposób powyższy.
Wrzuciłem działające rozwiązanie i kazałem porównać z tym jego bitangentem pod kątem pożerania mocy.
No i się przypomina men o przejeździe przez tunel ze spuszczaniem powietrza w kołach.
Gość znalazł naprawdę fajne publikacje, projekty i korespondencje z lat '60 i to byli naprawdę łebscy ludzie Sutherland Sketchpad - Wikipedia , A.Key i C.A.R Hoare (przez zbieg okolicznosci udało mi się dawno temu zdobyć od niego autograf).
PS Wnioskuje do adminów o wyodrębnienie z tego osobnego wątku, bo chciałbym wrzucic troche rzeczy w temacie
~7.5 przelewu na sekundę w OOP php_fpm pod nginx z obiektami serializowanymi i przechowywanymi w bazie danych jako bloby kontra 215 przelewów na sekundę kiedy przelew jest zaimplementowany jako stored procedure w marii.
kod OOP aplikacji w php_fpm nie był mój, kod sql w stored procedure jest.
Ale to nie może być powód różnicy na wydajności bo przelewy w OOP php pisali zawodowi programiści a ja jestem amatorem.
OOP na poważnie rozkręciło się gdzieś po 94 bo wtedy każdy mógł kupić mniej więcej podobne x86 liczydło. Wcześniej to była dżungla i dla prostoty oraz ograniczeń zasobów się tego nie używało ponad demonstrator.
A na tym forum są prawie same dinozaury, więc najpewniej uzyskasz odpowiedź deprecjonującą użytkowników OOP tak jak kogoś kto używa prądu nie umiejąc złożyć generatora.
@Koncereyra wysłuchałem no i to jest średnio słabe?
A co do tego omawianego gdzie indziej/kiedy indziej wewnętrznego narratora to słuchanie podcastu nie przeszkadza mi w klepaniu kodu
Po prostu jesteś za słabym nerdem jeśli chodzi o języki programowania. Moim kolegom się podobało:)
Tzn rozumiem, że jak ktoś nie jest zafascynowanym tym jak do tego doszło że programowanie wygląda jak wygląda, a w zasadzie już od lat '60 nie jest to tylko kwestia optymalności/“inaczej nie działa” a kombinacji tego oraz inercji procesów propagacji paradygmantów wśród ludzi i arbitralnych/losowych momentów. Jakby Bjarne Stroustrup najpierw zaimplementował template’y a potem funkcje wirtualne to pewnie taka Java i C# by dziś wyglądały zupełnie inaczej:)
Owszem, ale samo OOP nie rozwiązywało “wszystkich” problemów. Jak się patrzy na ówczesny kod, to właśnie gdyby C++ zaczeło od templateów a potem dodało dziedziczenie to byśmy “pisali od prawej do lewej”.
Nigdy nie lubiłem OOP, bo poza tworzeniem UI to ono nigdy nie rozwiązywało moich problemów. Templaty owszem rozwiązywały.
W sensie bez OOP byłoby więcej? Przecież jak się patrzy na JavaScript, Python czy PHP to ludzie de facto twardo robią tam programowanie imperatywno-proceduralne, nawet jak język do tego zniechęca, albo ma inne lepsze opcje.
Jak mówię, poza UI - mój pierwszy kontakt z OOP to TurboVision w TurboPascalu - to nie jestem pewien czy OOP gdziekolwiek było mi potrzebne. Nawet w moim dużym korpo z OOP C++ to zostały tylko template’y i klasy robiące de facto za interfejsy/prototypy(JS)
no ale to jest trochę paraolimpiada, tzn PHP ssie niezależnie od przyjętego paradygmatu.
Ja się mocno obawiam że jeśli chodzi o pierwsze 10kb kodu źródłowego w życiu to mogę być w top5 tych forumowych dinozaurów
Za mało treści, za dużo ekscytacji.
Znam tę historię trochę inaczej, kiedy ci ludzie wzmiankowali o frustracji kolejnych problemów do rozwiązania.
Widzę to trochę inaczej, nie od strony języka, ale hardware. Dla mnie kodoklepstwo to tylko skomplikowany sposób opisania maszynie jak ma zmieniać zworki na wejściu prąda w cyklach.
Gdybym miał to ogarnąć od papieru w dziurki to nie widzę przeszkód.
Antropomorfizujesz.
To tylko przełączniki światła, nadbudowujesz nad tym abstrakty wyjaśniające jak efektywnie zarządzać oświetleniem.
Ważne co się sprzedało i przyjęło.
To że mamy gpu na trójkątach wynika z rynku akceleratorów voodoo. Akceleratory do cada operowały zupełnie inaczej (bliżej voxeli).
A i tak na końcu okazuje się, że po wprowadzeniu nanite odkopujemy rozwój tamtych akceleratorów i trzeba będzie rozbudować tę cześć gpu. Które jest rozbudową regionu pamięci zrzucanego cyklicznie na konwerter to telezorka.
W zasadzie nie rozwiązywało żadnych. Wiele tworzyło. Ale było zrozumiałe dla hopsztyliona ludzi.
Dla mnie to zbędny poziom abstrakcji, nigdy mi się nie przyjęło. Za wcześnie zacząłem i nie potrzebowałem protezy.
Dla mnie inherity są średnio użyteczne. Tak samo strong data type - no niech sobie będzie, przecież i tak argument sprawdzę, bo inaczej nie działa.
No dobra… use case istnieje.
A template… sam sobie coś podobnego zrobiłem. Bo potrzebowałem. Później się dowiedziałem że istnieje^^
Nazywam się 3r3 i w klubie anonimowych użytkowników AI muszę przyznać, że po raz pierwszy, wczoraj udało mi się wyzyskać ejaja (Grokusia w wersji darmowej) do czegoś użytecznego, czego nie musiałem tłumaczyć, poprawiać i poganiać kijem.
Wrzuciłem bydlęciu customowy kod glsl es w wersji 2.0 (czyli teoretycznie pójdzie na debilkach z droidem) i wyniki testów, gdzie z serii warstw coś chodzi, ale jak się redukuje liczbę to nie chodzi. Czyli gdzieś w stosunkach decode f32/(f24 w rzeczywistości) > vec3, które tam lecą hurtem, a później sortowaniu wykonania (tak, można robić pętle kolejności wykonania przydzielonej dynamicznie w potoku bez uprzedniej wiedzy o tym) coś było nie halo, ale na tyle, że mi się po 14h klepania klawiatury numerki przed oczyma zajączkowały.
Udało się tosterowi przeanalizować co kod robi, gdzie są iteracje, po wuj tam są, gdzie są pętle, znalazł jedno przypisanie zakresu iteracji “za krótkie” do float_array oraz trzy literówki (że autor miał na bezmyśli co innego niż skopipaścił jako referencję z bloku wyżej). Wypisał linijki z podpadziochami oraz co zapewne było na bezmyśli, i to zadziałało. Czyli jakieś pińcet linijek dał radę.
Wcześniej gubił się już przy czterdziestej (czyli poziom simnumeric sprzed 30 lat).
