-
IT café
Új hozzászólás Aktív témák
-
proci985
MODERÁTOR
válasz
husztiimi #20810 üzenetére
Ezért mondtam, hogy én ránéznék az authorlistákra. Nekem is volt, hogy egy PhD thesisből vagy egy régi repoból kellett visszafejteni mit csináltak, de még mindig egyszerűbb, mint ilyen szinten belemászni az optimizációba.
Egyébként adott esetben megpróbálni felvenni a kapcsolatot az authorokkal is működhet.
-
proci985
MODERÁTOR
válasz
husztiimi #20805 üzenetére
(nem mozgok HPC területen)
leírás alapján tippre lehet bele kéne nyúlni a pipelinebe, hogy nyerjetek is valamit.
GPUn mátrix transzformációnak gyorsabbnak kéne lennie, de a kérdés, hogy mennyi idő megy el az adatmozgatással.
ha kutatási terület, én ránéznék a környezeti publikációkra, hogy ki futtat hasonló HPC környezetben. cikkeknél nem mindig írják le, hogy mit hogy oldottak meg tartalmi okok miatt, de pl egy master vagy phd thesis esetén van esély, hogy lesz egy github repo és egy rendes leírás is.
-
proci985
MODERÁTOR
válasz
hiperFizikus #20784 üzenetére
ChatGPT nem ért a területhez, bár egész szürreálisan kezdett összehaluzni mindent egy ponton.
Másik topikot zártam, ezt pedig itt engedjük el, mert ez egy szakmai topik.
-
proci985
MODERÁTOR
-
proci985
MODERÁTOR
válasz
AndrewTdi #20756 üzenetére
Végiggondolva:
[link] VROOM pl erre néznék rá, ahogy nézem a constraintek jórészét amit leírtál tudja. Van pár algoritmusa és valószínűleg ugyan nem kapsz optimális eredményt, ugyanakkor nem fog elmenni egy (fél) nap a beosztás összerakásával.
JoinR meglátása egyébként stimmel, ez nem az a probléma, amire gyorsan össze lehet egy egyszerű megoldást dobni, ha automatizálni akarod.
-
-
proci985
MODERÁTOR
Egészen, részben mert emberi nyelv, részben meg mesterséges nyelveknél nem szokás kivételeket csinálni hacsak nem nagyon muszáj, mert szívás.
Természetes nyelveknél viszont az interakciók és a használat során változások történnek. A magyarban meg azért bőven van (nehezen formalizálható) kivétel.
-
proci985
MODERÁTOR
válasz
hiperFizikus #20710 üzenetére
Ha ennyire bele akarod ásni magad a témába, én ránéznék a formális nyelvek területére. Kb a Chomsky-Turing ami összeköti a (gyakorlati) Turing gépet a nem-mesterséges nyelvekkel, amely utóbbi halmazba a magyar is beletartozik.
Magyarul talán a Bach féle "Formális nyelvek" volt ami egész jól végigment a témán, de egyrészt nagyon száraz, másrészt pedig elég elméleti, harmadrészt pedig a gyakorlatban sem egy kezdő könyv. A lényeg mondjuk a Recursively enumerable (Type-0) grammars, ami a Wikin gyönyörűen egy paragrafusban össze van foglalva.
-
proci985
MODERÁTOR
válasz
VikMorroHun #20705 üzenetére
Nyelv és IDEfüggő. VS és Eclipse alatt IDE listázza az összes odatartozó változót. Innentől redundáns és ha változtatni kéne a változót, akkor mehet a refaktor (ami továbbra is szívás). Persze ettől még pattern szinten prefixek vannak használatban, C#nál az I prefixnek van értelme, Javanál redundáns.
Pl Minix kernel használja (Linuxban nem vagyok biztos) és ott tényleg van értelme arra, amire eredetileg ki lett találva, de C# vagy Java esetén felesleges. Viszont, jellemzően első-másodéves BScn nem ez a fő probléma.
dabadab: Így, ezzel a pontosítással.
-
proci985
MODERÁTOR
Ahol én végeztem ott első éves OO kurzuson pár kritérium erősen ezen alapul. Pl elvárták az értelmes változóneveket, az értelmes kommentárokat, a rendesen felosztott rendszert.
Értsd, az
int värde = 5 // sätter värde till 5
szintű dolgokat izomból irtották, mert olvashatatlan. 10+ éve is és ahogy hallom, most is. -
proci985
MODERÁTOR
kb BSc masodev vegi szinten egy jo konyv, jo otletekkel.
amiket felhozol problemaknak azzal jellemzoen a konyv is explicit modon tisztaban van. avagy ha szorol szora betartod, valoszinuleg hasznalhatatlan lesz a kod. de ezt emlekeim szerint tenyleg, tobbszor emliti es emlekezteti az olvasot.
ettol fuggetlenul kezdeni valahol el kell kezdeni, hogy mondjuk ne hasznaljon magyar valtozoneveket, se hungarian notationt, se ekezeteket. meg olyan dolgok, mint az egyseges nevezektan, a (komponens szinten) egyseges scope azert modellezes szempontbol nem az ordogtol valo. ez nem a te szinted, es nem is egy senior szintje (sot jobb esetben, nem is egy juniore mert ezekkel erdemes lenne tisztaban lenni).
plusz az is stimmel, hogy foleg OO teruletre jo.
"there is no silver bullet"
-
proci985
MODERÁTOR
válasz
hiperFizikus #20626 üzenetére
Semmi szükség egy újabb párhuzamos Programozás topikra.
-
proci985
MODERÁTOR
Magyar felsőoktatási szabályokkal teljesen nem vagyok teljesen tisztában, de az EUs szabályozással valamennyire igen. A kurzus adatlap jogi dokumentum, szóval valós tudást mutatni ami nem teljesül, az jogsértés és a fórum alapelveibe ütközik. Emiatt a threadet töröltem.
Félrevezetni beadásnál csalás. ChatGPT generált kód jellemzően 85-95%ban stimmel nyelvtől függően, de egyébként megbízthatatlan, StackOverflow viszonylatban is. Plusz megvan a veszélye, hogy ész nélkül használva az LLMek (beleértve a Copilotot) első ránézésre oké kódot generálnak. Amit egy senior tényleg összepofoz 5 perc alatt, viszont egy elsőéves sok év fejelsztői tapasztalat nélkül nem fog, tetejében nem tanul semmit ami hosszabb távon ez további problémákat generál.
Ha elkap az oktató, akkor pedig meghúzáson kívül fegyelmi eljárás is lehet a vége. Namost, említett esetekben ChatGPT generált kódnál általában domainfüggően látszik, hogy az, mivel nagyon fura és eléggé egyedi hibákat generál*. Ugyanígy, az "explain this piece of code" promptra se vennék mérget.
*pl C kódot teledobálja
exit(0)
okkal teljesen váratlan helyeken vagy úgy elszúrja a pointer aritmetikát, hogy senior devként is lassítja a munkafolyamatot egy sima keresőhöz képest. -
proci985
MODERÁTOR
válasz
hiperFizikus #20606 üzenetére
[link] pl igy
a hogyan tovabb az az, hogy gyakorlatban alacsonyszinten ugy van minden megvalositva, ahogy te magas szinten akarnad.
-
proci985
MODERÁTOR
válasz
hiperFizikus #20604 üzenetére
Én a ciklusok és az elágazások összeolvasztására tettem kísérletet
jumprol hallottal low-level nyelveknel? -
proci985
MODERÁTOR
válasz
hiperFizikus #20602 üzenetére
-
proci985
MODERÁTOR
ja igen, el is felejtettem, hogy a beepitett RPC (Java RMI) mekkora dolog volt anno.
marmint, hogy ez igy ennyi, 10 sor es van egy mukodo C/S megoldasod, ami ameddig standardizalva van az interface, addig kb megold mindent. ennel mar csak az android volt szurrealisabb kb 2014-2015 korul, avagy oke, hogy thread pool, de konkretan nyelvi szinten kenyszeritette a parhuzamositast es az event-based modellt.
-
proci985
MODERÁTOR
válasz
petyus_ #20513 üzenetére
semmi, kb svedeknel fullstack mostanaban .net + azure. meg par ceg ami javazik.
coco2: java reszben a (z eredeti) licenszmodell, reszben a compiler, reszben az extenziv language featureok miatt: avagy volt beepitett minden is amit a JVM megoldott, es meglepo modon mukodott egy csomo felhasznalasra, pl valosidore es embedded feladatokra is. tetejeben 2005 korul a Netbeans IDE kb hiperurugras volt pl egy Borland Choz / Turbo Pascalhoz kepest (most itt a szenne moddolt vim / emacsot egy pillanatra felejtsuk el). VSnek kellett par ev, mire elkapta az Eclipset.
plusz nyelvi elemek es OO design a kezdetektol. 90es evek vegen az se volt egyertelmu, hogy a compiler tamogat e 8 karakternel hosszabb valtozoneveket, vagy hogy megis mekkora szamot tamogat az int.
vagy az automatikus memoriaallokacio. vagy mondjuk Java5el a java.lang.concurrent, mikozben a winAPInel meg mindig ott tartottunk, hogy egy koteg parametert kellett manualisan null ertekre allitani, mert nem volt valos polimorfizmus.
nagyon hosszu utat jartunk be azert.
-
proci985
MODERÁTOR
válasz
kovisoft #20448 üzenetére
egyebkent szenne lehet mindent is makrozni
duckynal voltak erre megoldasok 10 eve is, egyebkent meg ott a vim, plusz munkatars kb egy szenne makrozott emacsot hasznal a problemat megoldani.
plusz van meg par megoldas, pl pedallal.
programozasnal mondjuk szvsz kodtol fuggoen nem a gepirasi sebesseg lesz a szuk keresztmetszet altalaban.
-
proci985
MODERÁTOR
válasz
btraven #20432 üzenetére
ez a ketto ugyanaz, csak tukrozve ha megnezed
btw, ha jatekosan akarsz tanulni, az elso typing of the dead gyakorlatilag megtanit ra. elvileg az uj is oke, de nem emlekszem, hogy abban benne volt e az elso jatek kb fullos tutorialja, ami kb egy teljes "tanulj meg vakon gepelni" kurzus volt.
-
proci985
MODERÁTOR
válasz
hiperFizikus #20427 üzenetére
ami csak bonyolitana az egesz problemat, szoval egy kezdonek ezt ajanlani nem jo otlet. marmint, koncepcio szinten elhibazott az otlet.
-
proci985
MODERÁTOR
válasz
dabadab #20424 üzenetére
ja, ez igy siman ijeszto, mintha egy prolog programozo kodjat olvasnam aki frissen nyergelt at javascriptre.
#20423hiperFizikus: nem tudom, hogy egy karakterkeszlet behozasa hogyan segit matematikai analizisnel. leginkabb sehogy. marmint ugye ez most nem szintiszta trollkodas volt?
-
proci985
MODERÁTOR
válasz
cog777 #20408 üzenetére
jatekfeljesztes atment C++rol C#ra, szoval explicit pointer aritmetika nem annyira erdekes mar. gyakorlatban egy (nagyon sok) extra hibaforras. foleg, ha nincs massziv architekturalis / low-level hattered is.
elore ne optimizalj, inkabb fokuszalj arra, mit es hogyan tarolj es mi felelos miert. profilerrel lehet utana optimizalni, elore tokfelesleges.
stackoverflowval meg ovatosan, hogy mit es mit nem tekintenek annak aminek. ACMnek voltak anno eleg jo konferenciai amik jatekfejlesztesnel a technikai reszre is relevansak, tippre ACM siggraph es sigsoft eseten lehet talalnal hasznalhatot.
tovabbra is azt mondom, hogy maradj eloszor square tablan, a hexaval feleslegesen szivatod magad. es ha a grafos tarolas uj, akkor szerintem nem igazan latod be, hogy mennyivel bonyolultabb ez a megoldas. persze ha szivatni akarod magad, arra tokeletes, csak eppen kb feature creepnek hangzik, amit irsz.
-
proci985
MODERÁTOR
válasz
dabadab #20390 üzenetére
plusz jatekoknal jellemzoen OO helyett DOD megy utobbi evekben, ami a leirasoddal jobb lesz (meg kb azzal is mukodik jol).
cog777: igen, ezert irtam, hogy hex helyett kezdj negyzetekkel, mert sokkal egyszerubb. nincs plusz egy konverzios layer.
hexat mar nem biztos, hogy arrayben tarolnam pl.
egyebkent kezdj modellezessel: kene UML, kene par use-case (legalabb a jatekos -> interface (view) -> controller (logika) -> controller (data layer) szinten. mockupolni oke, igazabol azt gondold vegig, hogy milyen informacio kell, milyen manipulacio kell, hol tarolod, hogy mukodnek az interakciok.
ha csak egyszer akarod lekodolni (spoiler: tobbszor fogod), rendesen vegiggondolt desing modellszinten altalaban segit.
nem kell felfedezni a spanyolviaszt. a data layert amit leirtal kb eppen barokkosan tulbonyolitod eppen. maskepp: bugos lesz, es a hajad fogod tepni a harmadik strukturalis overhaul kozepen, foleg, ha a component interfaceidre is feluton jossz ra, hogy nem mukodnek.
-
proci985
MODERÁTOR
-
proci985
MODERÁTOR
-
proci985
MODERÁTOR
válasz
nyunyu #20330 üzenetére
nekunk BASIC volt, de sokminden nem maradt meg.
ECDLt leraktam brahibol 16 evesen esti kurzuson.
mondjuk Excel nem volt rossz, kesobb meloban meglepoen sokat hasznaltuk ad-hoc adatanalizisre. Python jobb, de 10 eve boven nem volt meg a jelenlegi Anaconda szintu integracio, Tableau meg szinten meg sehol nem volt ha jol emlekszem.
40-50 programnyelv es par ev tapasztalat utan az, hogy mit tanult az ember mar kevesbe szamit. tavasszal kb 12 ora alatt tanultam meg regresszios analizist csinalni vizualizacioval Rben.
-
proci985
MODERÁTOR
válasz
pmonitor #20295 üzenetére
(na akkor kiadom magambol, ha mar csinaltam rajta code reviewet megnezni, hogy mi a baj)
ok raneztem bovebben a kodra, szoval ez egy
ami el lett nevezveList
MyHashSet<T>
nek, majd hogy ugy tunjon, hogy ket parametert hasznal, kreal egyPoint
classt. szoval ez szep meg jo, csak koze nincs a Sethez.mondjuk vannak szepsegek, ez a sor
if (list.Count != Count) list = new List<T>(this);
sor miatt semmit nem csinal, es ha nem lenne korabban a list inicializalva, akkor ennek hibat kene dobnia (hacsak C#nal nincs auto init listre mostanaban. Javaban ez a megoldas NullPointerExceptiont dob mert nem mukodik rendesen a vedelem, bar lehet compilation errort dobna, mert egyertelmuen elerhetetlen a kod, mivel a list. Count es a Count valtozo egy es ugyanaz ebben a kontextusban, Javaban meg erre par eve van automatikus check).reg lattam ennyire olvashatatlan kodot egyebkent. minden valtozo public / auto scope, hasonlo naming conventionert meg ahol en vegeztem az elso eves OO kurzuson mar automatikus fail jart (akkor is, ha a program egyebkent mukodott): nem azt csinalja a class mint amit a neve alapjan elvarnank, C style iterator inicializacio (nem hibas, de balesetveszelyes), magyar valtozonev (torl), roviditett valtozonev (torl), inkonzekvens valtozonev (myPt egy listanak?), inkonzekvens class scope valtozonevek (X, Y).
egyebkent minel tovabb nezem, annal szornyubb.
-
proci985
MODERÁTOR
válasz
dabadab #10398 üzenetére
"Ezt egészen addig fogod gondolni, amíg össze nem kerülsz olyan kóddal, aminek az írója azt gondolta, hogy semmi gond azzal, ha szlovákul (görögül, kínaiul stb) vannak a kommentek meg a változónevek."
És mindenki ugyanazon az OS platformon van. Avagy amikor a spec karakter win-*NIX valtas kozott krikszkrakszá változik, aztán van ennek a hardcore variánsa, amikor a filenév is spec karakteres aztán az egész cucc átnevezés nélkül nem is használható.
Szintén tapasztalatból, megtörtént esetek alapján.
-
proci985
MODERÁTOR
Eclipse Modelling Frameworknek van valami alternatívája, illetve létezik hasonló másik framework?
-
proci985
MODERÁTOR
válasz
bambano #7095 üzenetére
vannak SoC megoldások a célra.
aquaero 5 LT
aquaero 5 Pro
Corsair Link -> ez lehet csak ambientet tud
mCubed tBalancer miniNG
mCubed Tbalanced classic
mCubed Tbalancer BigNGa miniNG olyan 10k, a többi jellemzően 20-25 körül mozog. de ez itt ebben a topikban nagyon off.
-
proci985
MODERÁTOR
válasz
freelanced #7079 üzenetére
mindenképp. mindkettő aktívan használt, hasznos és relatíve egyszerű.
igazából bármelyikkel is kezded, utánna a másik egyszerűbb lesz (elég sok hasonlóság van), ha pedig kedved lenne a C/C++ pároshoz, akkor azok is menni fognak, mert elég sok hasonlóság van.
Eclipse Juno EMF / M2M, úgy néz ki ideális futáshoz x86 alatt ki kell lőni a multithreadelést, valamiért lassabb úgy az ATL.
-
proci985
MODERÁTOR
válasz
freelanced #7077 üzenetére
nem feltétlen. itt svédeknél amit látom, hogy a környéken nagyon keresnek ebből az a C# és a Java. Java lehet nem a leg"gyors"abb (performance definíciófüggő), de egy valósidejű rendszernek alapvetően nem gyorsnak, hanem pontosnak kell lennie. mivel Ada programozókat egyre nehezebb találni, ezért a cégek kezdenek áttérni Adaról Javara. plusz ott az Android, ha tudsz Javat akkor kis túlzással tudsz Androidot is.
sima C első nyelvnek kemény dió, nagyon könnyű hibázni benne és elég nehéz debugolni. C++ egy fokkal jobb. Pascal programozót nem igazán keresnek/használnak, akkor meg inkább már Java szvsz.
más, az előző Eclipse M2Mre megvan a megoldás, az eclipse heap sizeot kell magasabbra állítani, illetve a többszálú végrehajtást engedélyezni (1.5 Juno M2M x86ban ez defaulton ki van kapcsolva, x64 meg instabil).
-
proci985
MODERÁTOR
az létezik, hogy az x64es Eclipse java.lang.reflect.Invocation.TargetException hibaüzivel elszáll, ahol az x86os még stabil?
egy 1.000.000 soros XMI file alatt jött a hibaüzenet (ATL pluginnel M2M transzformációt benchelek épp, amiatt kell ilyen horror méretű file mert sokkal kisebbekkel nem látszik a skálázódás)
kieg: 1.200.000 sornál már a 32bites is elszáll.
a beépített xmi editor már olyan 200k sor másolgatásánál is összeomlott mondjuk heap errort dobva.
amargo: a májusi information and software technologyban volt erről egy érdekes cikk ami végigvette a Gang of Four féle Design Patterneket. az eredmény eléggé érdekes volt, hármat használnak, három megosztó -Singleton nem meglepő módon, illetve a Concrete Classok egyszerűségük miatt pár ember szerint nem minősül annak- a többi nagyon nem volt használatban a 21ből.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- AKCIÓ! ASUS ROG Strix G513IE 15 Gamer notebook - R7 4800H 16GB RAM 512GB SSD RTX 3050Ti 4GB WIN
- DELL PowerEdge R640 rack szerver - 2xGold 6150 (18c/36t, 2.7/3.7GHz), 512GB RAM,10G, H740p 8GB, áfás
- Csere-Beszámítás! RTX Számítógép játékra! I5 7500 / RTX 2060 6GB / 32GB DDR4 / 500GB SSD
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
- Csere-Beszámítás! Számítógép játékra! R5 5500 / RX 5700XT / 32GB DDR4 / 256GB SSD + 1TB HDD
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest