játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5511
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2529

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [17]
newversion - Tag | 197 hsz       Online status #85900   2008.04.26 18:36 GMT+1 óra  
az Ifekkel nagyon vigyázni kell, két féle if van
az egyik az amikor a valoszinüség a 2 állapot között fifty-fifty, na ekkor már baj van , ez tud lassitani cefetül
a másik if pl amik ciklusoknál van az egyik állapot 90%> a másik kicsi
ilyenkor az utasitás pipelineban nem keletkeznek lyukak, ez szabadon használhato

persze azokon a procikon ahol mindkét ág végrehajtodik nem számit, nemtudom az uj intelek ilyenek e régota leálltam a követéssel
konzolon általában nem ilyen okos procik dübörögnek, bár relativ mit nevezünk okosnak
   
newversion - Tag | 197 hsz       Online status #85899   2008.04.26 18:31 GMT+1 óra  
érdekes egy algoritmus, de nem hatékony

mért nem jo dinamikus objectekre? csak tudod valamiröl hogy van vagy nincs
én ugy szoktam csináni hogy egy scenemanager felügyel mindent
és minden létezö object ID-t tartalmazza, ha valami megszünik törlödik
minden frame kirajzolás elött rendezés
   
Asylum - Törzstag | 5511 hsz       Online status #85891   2008.04.26 18:04 GMT+1 óra  
ha már erröl van szó még egy lineáris rendezö

http://fi.inf.elte.hu/adatszerkezet/ii_felev/bead0304/ocsai_katalin/leszrend.doc

szerk.: objektrendezés: ha ezalatt pl. mélység szerinti rendezésre gondolsz, akkor az szerintem ugy se hatékony a dinamikus objok miatt, én inkább priorsort használnék igy elsöre.

Ezt a hozzászólást Asylum módosította (2008.04.26 18:12 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
newversion - Tag | 197 hsz       Online status #85890   2008.04.26 18:04 GMT+1 óra  
sok féleképpen lehet használni, engine-ben pl az objecteket lehet sorbarendezni, vagy pl az átlátszó polygonokat, stb...
   
Asylum - Törzstag | 5511 hsz       Online status #85888   2008.04.26 17:59 GMT+1 óra  
ez ilyen edényrendezés féle nem? (valamikor én is tanultam) hasheléssel tényleg sokat lehet turbózni csak nem mindenhez lehet jó hash fv-t találni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
newversion - Tag | 197 hsz       Online status #85887   2008.04.26 17:56 GMT+1 óra  
a radix alap, ha gyorsat akarunk irni, ha jol rémlik minimum 50-100-szor gyorsabb mint bármilyen más rendezö, , de ez nemcsak amiatt mert az algoritmus ennyire hatékony lenne
hanem mert stream olvasás kell hozzá, nincs véletlen elérés, optimizálhato pipeline szinten
és az algoritmus egyszerüsége folytán asm-ban szét lehet tuningolni
   
fpeti - Törzstag | 1295 hsz       Online status #85878   2008.04.26 17:00 GMT+1 óra  
Natessék :
Másik topicban felvetődött a Radix-sort, ami egy rendezés, és nem kell bele IF,
'54-ben találták ki (jó friss dolog ), eseteg lehet még valaki nem ismeri:
http://www.cs.auckland.ac.nz/software/AlgAnim/radixsort.html
Lap alján még animáció is van hozzá, nagyon könnyen megérteti a dolgot.
   
Asylum - Törzstag | 5511 hsz       Online status #85396   2008.04.18 18:04 GMT+1 óra  
valahogy olyan hihetetlen hogy az egész rohadt számitogépet egy csomo ilyen kis vacak müködteti
és ráadásul strapabiro is többnyire
és hogy a programok is feszültségváltozásokbol állnak
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
newversion - Tag | 197 hsz       Online status #85395   2008.04.18 17:21 GMT+1 óra  
több tranzisztor kell hozzá, a Cell-ben is csak 16 bites integer szorzás van , 2 menetben ugrik neki a drága , igaz hogy egyszerre 4 adatnak
   
Asylum - Törzstag | 5511 hsz       Online status #85394   2008.04.18 17:13 GMT+1 óra  
hát ha a szorzást összeadással helyettesited az lassabb szerintem ugyanis a mod 2 maradékosztálytestben a szorzás is legalább olyan trivi mint az összeadás.
igazából nem értem h miért nem tudtak normális mul -t irni a processzorokhoz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
newversion - Tag | 197 hsz       Online status #85393   2008.04.18 17:07 GMT+1 óra  
én tudom mennyi , mindenesetre ezt az engine-t ugy irtam hogy a mátrix szorzás , csak összeadással volt, persze volt még más speedup trükk is, 16 mhz -es volt a drága

http://www.gbadev.org/demos.php?showinfo=356
   
Asylum - Törzstag | 5511 hsz       Online status #85391   2008.04.18 16:21 GMT+1 óra  
szeretnéd tudni, hogy hány müvelet egy logaritmus vagy egy exp?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
newversion - Tag | 197 hsz       Online status #85389   2008.04.18 14:25 GMT+1 óra  
a logaritmikus azonosságokat nem lehet használni? néha brutál gyors tud lenne
mivel a szorzásbol összeadás az osztásbol kivonás, a hatványozásbol szorzást csinál

exp(x*y)=log(x)+log(y)
exp(x/y)=log(x)-log(y)
   
Asylum - Törzstag | 5511 hsz       Online status #85377   2008.04.18 08:39 GMT+1 óra  
sub eax, ebx
...
imul ...

asszem az imulnak nemmindegy hogy mi hol van

mov eax, [ebp+valami] ;indexet berakja
mov ecx, [esi+eax] ;tömb elemét berakja

szal szerintem az utóbbi gyorsabb de ezt csak igy hasból irtam
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #85376   2008.04.18 08:32 GMT+1 óra  
Melyik a gyorsabb: kivonás egy előjel nélküli byte típusú változóból majd az eredmény szorzása 4 byte-os lebegőpontos számmal (utóbbi tudom hogy lassú csak azt nem hogy mennyire) vagy egy 256 elemű előjel nélküli byte típusú tömb indexelése egy másik byte-tal (ez is lassú ha nincs cache-elve csak kérdés mennyire)?

Szerk: C opció: az első művelet MMX-el megoldva 8 byte-on egyszerre, a szorzás viszont két részletben (a szorzó le van bontva egy egész számra és egy osztóra ami kettő hatványa, az elsővel szorzok a második kitevőjével meg biteltolással osztok). Kiegészítésként megemlíteném hogy MMX-el nem tudok 1 byte-os számokat szorozni csak 2 byte-osakat és az eredmény is 2 bytenyi lesz szóval egy adag kombinálás kell mire a végeredményt megkapom.

Ezt a hozzászólást TheProGamer módosította (2008.04.18 08:39 GMT+1 óra, ---)
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5511 hsz       Online status #85296   2008.04.16 10:47 GMT+1 óra  
fmod
fmodf
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
kicsy - Szerkesztő | 4304 hsz       Online status #85295   2008.04.16 10:45 GMT+1 óra  
Ugyanezt csinálja az
Y = Y % 360
azaz modulo 2 pi
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
Lazarus - Törzstag | 313 hsz       Online status #85292   2008.04.16 10:22 GMT+1 óra  
Erről a modulo 2 pi-ről nem sok infót találtam

viszont egy kis fejtörés után sikerült
Kód:
while (Math::Abs(Y-X) > Math::Abs(Y-360-X))
  Y -= 360;
while (Math::Abs(Y-X) > Math::Abs(Y+360-X))
  Y += 360;
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
   
Asylum - Törzstag | 5511 hsz       Online status #85286   2008.04.16 09:16 GMT+1 óra  
modulo 2 pi és müködni fog
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Lazarus - Törzstag | 313 hsz       Online status #85284   2008.04.16 08:12 GMT+1 óra  
Hi! Lenne egy (valószínűleg) egyszerű kérdésem. van egy X és egy Y változóm amik 1-1 szöget tárolnak. A loop folyamán az Y próbálja követni az X forgását az által hogy hozzáadok vagy kivonok belőle 1-et.



A problémám az hogy nem tudom hogyan lehetne úgy megcsinálni, hogy a legrövidebb úton kövesse az Y, ha a forgás során át kéne ugrani 360-ról 0-ra inkább teljes fordulatot tesz a másik irányba. Lehet hogy egyszerű kérdés, de én mindíg belezavarodok o_O

Jelenleg így néz ki a kód:
Kód:
if(X > Y)
{
Y += time;
if(Y > X)
Y = X;
}
else if(X < Y)
{
Y -= time;
if(Y < X)
Y = X;
}
else
Y = X;
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
   
Asylum - Törzstag | 5511 hsz       Online status #82697   2008.03.04 16:14 GMT+1 óra  
egy db gráf igen, lehet benne irányítatlan kör bár szerintem anélkül is megoldható.
amin még nekem is gondolkodnom kell, hogy ugye a transzformációk nyilván kombinálhatóak tehát pl.

forog -> Föld -> kering -> Hold

azaz a Hold forog is meg kering is tehát a mátrixokat valahogy kombinálni kell
a másik, hogy az anyagokat meg nem kombináljuk (igy ez nemis probléma)
a fényeket megint lehet kombinálni

szal vannak ilyen nyitott kérdések még

Ezt a hozzászólást Asylum módosította (2008.03.05 12:44 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1295 hsz       Online status #82696   2008.03.04 16:08 GMT+1 óra  
Huh, ez scenegraph féle dolog, mi? Ez több fát jelent, vagy van valami általános gráfod, amihez mindent hozzá tudsz csatlakoztatni? Eléggé automatizált dolognak tűnik amúgy - erre ránézek.
   
Asylum - Törzstag | 5511 hsz       Online status #82695   2008.03.04 15:41 GMT+1 óra  
nos hát igen rossz megoldás nálam is született már sok. én ugyan ennyire még nem tartok elöl de a következöképpen néz ki most:

vannak az erőforrások (mesh, textúra, effekt) ezekröl semmi plsuz infót nem tárolok.
vannak ezeknek megfelelö gráf csucsok pl. GeometryNode ehhez hozzá lehet kapcsolni egy mesh-t
vannak speciális csúcsok pl. TransformNode ennek gyerekként odaadok egy GeometryNode-t monjuk, és igy pl. forogni fog ha azt állitottam be. Ez eléggé memória takarékos megoldás szerintem. Fényeknek majd hasonloan lesz ilyen csúcsa, az anyagoknak szintén.

minden elntitásnak nem érdemes külön osztályt irni mert ugy 1) rengeteg osztályod lenne 2) még több objektum. meg pl. a kövek általában statikusak ahogy igy elnéztem a játékokat tehát beleépithetök a pályába.

egy csúcsnak ilyen általános függvényei vannak hogy pl. Draw() szerintem más nemis nagyon kell a mozgatásokhoz ott van a TransformNode.
a kamera szintén egy ilyen csúcs, rendereléskor innen indul el a bejárás.

gyakorlatban még ugy igazán nem teszteltem ezt a modszert szal vedd inkább csak egy ötletnek (de nagy része már implementálva van).

egyébként egy véletlenül talált VRML jegyzetböl jött az ötlet merthogy az pont igy oldja meg az egész bulit.

szerk.: ja a bejárás ugy történik, hogy paraméterben végigmegy egy akció objektum (ra mutató pointer) ami minden csúcsra végrehajt valamit, ez is elég gazdaságos.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1295 hsz       Online status #82694   2008.03.04 15:21 GMT+1 óra  
Azt szeretném elérni, hogy minden objektum a gémben ugyanúgy elérhető legyen, függetlenül attól, milyen típus, egyelőre még csak kettő van, fal típus, meg fényforrás típus. A fal típusnak más változói (is) vannak, mint a fényeknek, de még ezután sokféle lehetne, pl npc-k, felvehető tárgyak, ilyesmi.
Mindegyiknek más adatstruktúra kell - nyilván más kell egy sziklának, meg egy embernek.
Jó lenne ezeket egy tömbben tárolni, sokmindent leegyszerűsítene.
Most plö a frustum-cullinggal szórakázok, és az minden objektumnak lekéri az AABB-jét, és megnézi, látszik-e.
Ha minden külön veszek, külön leszenk a kövek, fények, emberek stb., akkor mindegyikre meg kell írni mindent, pl a feljebb említett frustum-c-t is külön le kell futtatni mindre - kb ilyen esetben kéne tempate típust adni a fr-culling classnak (lehet nem is rossz ötlet!), minden objektumtípusra lenne egy példánya.
Az igazság az, hogy szeretném valahogy normálisabban megírni egyszer, mert rosszul már sikerült .
Ezen felül még van az, hogy minden objekthez tartozhat egy kis szöveg, ami kb. a script szerepét tölti be, amiben nevekkel lehet(ne) hivatkozni bármelyik objektumra, és generálna ott valami action-t, ha egy tömbben lennének, csak abban az egyben kellene keresni nevek után- mondjuk ez tán nem olyan nagy baj.

Még az jutott eszembe közepes megoldásként, hogy csinálok két fő irányvonalat, az egyik a sztatikus objektumoké, ezekből sokkal több van, a másik a dinamikus dolgok tömbje lenne, amit vituális cuccokkal lehetne bővíteni.

A sok tömb esetén viszont a két tömb közötti reláció lesz nehézkesebb, például, ha a szkriptek betöltésekor a neveket indexekkel akarom helyettesíteni, hogy ne kelljen közben keresgélni, akkor azt is meg kell mondani, melyik tömbben..

Lehet végül is ez lesz, talán jobb, mint a semmi (nemértekénehhez )
   
Asylum - Törzstag | 5511 hsz       Online status #82692   2008.03.04 14:29 GMT+1 óra  
hát ha közös erőforrásokat tudnak használni akkor vond őket össze valahogy...de ha konkrétabbat mondasz akkor talán tok mondani jobbat is.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1295 hsz       Online status #82683   2008.03.04 12:06 GMT+1 óra  
Szerint-attack , ha van egy csomóféle objektum, aminek mind másféle adatstruktúra kell (más-más class), azt hogy érdemes megcsinálni, hogy egy tömbben legyenek, és könnyen le lehessen kérni a hasonló adataikat?
A legnyilvánvalóbb nekem a vituális fv-k lennének, minden egy alap class-ból származna, satöbbi.
De elég sok fv-hívás miegymás lenne velük (framenként több ezer akár), és biztos van gyorsabb módszer erre, mint ez.
Gondoltam arra is, hogy én foglalok le minden class példánynak annyi helyet, amennyi kell, egy mondjuk *void tömbbe, majd kényszerítem arra a típusra, amilyen, de sokféle class esetén ebből meg egy nagy switch-case blokk keletkezhet.

Van ezeknél gyorsabb/biztonságosabb?
   
Asylum - Törzstag | 5511 hsz       Online status #79503   2008.01.11 14:36 GMT+1 óra  
Van egy ilyen probléma hogy scrollbar.
Ugye van egy sín amiben a gomb mozoghat, ezt elöre megmondjuk, hogy a kép melyik része legyen .
Amikor a képet átméretezem akkor nyilván a sínt és gombot is át kell, csak az a baj, hogy a kerekítési hibák miatt nem lesz pontos : /
oké látom a windowsban fix mérete van a scrollbarnak..de nincs mégis erre vmi algoritmus?

bár lehet azlesz hogy a szélessége fix amard és csak a magasságot lehet változtatni..szvsz kevesebb fejfájás...

vagy egy másik hogy a kép két szélét megtartom, a közepét pedig pumpálom mint a CSS...csak ez meg ugye lassúnak tünik...viszont nem fog torzulni a kép és a probléma is meg lenne oldva

Ezt a hozzászólást Asylum módosította (2008.01.11 15:22 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #78889   2008.01.03 12:14 GMT+1 óra  
Hát, ha rajtam múlna, szívesen átadnám a helyem.
Van valami országos szintű tehetséggondozó program, és annak az egyik központja Győrben van.
Egyik szünetben lehívtak a titkárságra hogy kaptunk valami levelet és abban volt a meghívó meg a leírás. Hogy honnét szereztek rólam tudomást, arról a mai napig fogalmam sincs (a másik srác okés, mert besegített az e-napló fejlesztésébe és az bentvolt a Kisalföldben is).
Az interneten csak ezt találtam róla:
http://www.tehetsegpont.hu/96-15051.php

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #78886   2008.01.03 11:48 GMT+1 óra  
Nekem is küldhetnél 1 ilyen meghívószerűséget
   
gaborlabor - Moderátor | 4449 hsz       Online status #78883   2008.01.03 11:43 GMT+1 óra  
[off]
nem is az én sulimban van az a szakkör
hanem egy másik srác meg én kaptunk egy meghívószerűséget 1 másik iskolából...
[/off]

   
BerbeckU - Tag | 506 hsz       Online status #78881   2008.01.03 11:31 GMT+1 óra  
Én már azt hittem gaborlabor hirtelen ilyen májer lett.
Amúgy nekem is nagyon ismerős volt valamelyik OKTV-ről, és ahogy megnéztem, ha nem is pont ez, valami hasnló sokszor van OKTV 2. fordulón.

[off]Kár, hogy az én sulimban semmiféle számtech oktatás nem folyik, ill. ami van az egy vicc...[/off]

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #78877   2008.01.03 11:12 GMT+1 óra  
1ébként én is ilyen OKTV feladatnak kaptam tanártól, csak nekem nem volt mellé leírás mellékelve, csak oldjam meg Mind1, igazából csak ezzel a feladattal volt gondom, meg egy geometriás feladattal, többivel megbírkóztam vhogy
   
gaborlabor - Moderátor | 4449 hsz       Online status #78876   2008.01.03 11:01 GMT+1 óra  
Nagyon szívesen.
Az gondolom lerí róla, hogy nem én írtam. Mert nem én írtam...
Csak láttam, hogy felvetetted itt a problémát, és egyszer csak hirtelen eszembe jutott, hogy honnét olyan ismerős ez a feladat.
Én járok egy ilyen... "számtech-szakkör" szerűségre, aminek pont az a célja, hogy OKTV feladatokat oldunk meg, magyaráznak el, stb.
És ott volt ez a feladat is, és kaptunk egy doksit, amiben megvolt ez a leírás. Ez onnét származik.
Örülök, hogy hasznodra vált

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #78873   2008.01.03 10:53 GMT+1 óra  
Köszi h ilyen részletesen leírtad, mert bárhol próbáltam eddig normál leírást keresni din prog-hoz, nem találtam olyat, ami vmi normális példán keresztül érthetően el tudta volna magyarázni, mind úgy volt megírva, hogy azt tanár már elmondta v el fogja mondani, én meg magamtól tanulgattam, egészen az idei évig nem volt számtech tanárom. Szal köszönöm még1x
   
gaborlabor - Moderátor | 4449 hsz       Online status #78785   2008.01.02 06:20 GMT+1 óra  
Megoldás:
Legyen {e1, . . . ,en} az ajándékok értékeinek egy felsorolása és jelölje E az összegüket. Feltehetjük, hogy A<=B. Mivel A+B = E,
ezért A a legnagyobb olyan szám, amelyre A<= E/2 és előállítható {e1, . . . ,en} egy részhalmazának összegeként.
Jelölje Fel az (A+B) div 2 értéket. Tegyük fel, hogy
A = ei1 +. . .+eik , i1 < . . . < ik
Ez akkor és csak akkor, ha
A−eik = ei1 +. . .+eik−1
azaz A−ei1 előállítható legfeljebb a első ik −1 (e1, . . . ,eik−1) szám v.m. részhalmazának összegeként.

Részproblémákra bontás:
Bontsuk részproblémákra a kiindulási problémát: Minden (X, i)(1<=X<=Fel,1<= i<=n) számpárra vegyük azt a részproblémát,
hogy az X érték előállítható-e legfeljebb az első e1, . . . ,ei szám valamely részhalmazának összegeként. Jelölje V(X, i) az (X, i)
részprobléma megoldását, ami logikai érték; V(X, i) = Igaz, ha az X előállítható, egyébként Hamis.

Kód:
Program Testveri; Const
MaxN=100; {az ajándékok max. száma }
MaxFel=20000;{ Max. összeg }
Var
N,i,Osszeg,A : Word;
E:Array[1..MaxFel] Of Word; { az ajándékok értéki }
BeF, KiF: Text;
Function F(M : Word) : Word;
{ F(M) a legnagyobb olyan szám, amely <=M és előáll az E[1..N] számok
összegeként }
Var
V : Array[0..MaxFel] Of Boolean;
x,i: Word;
Begin
For x:=1 To M Do V[x]:= False; {inicializálás}
V[0]:=True;
For i:=1 To N Do Begin
{ V[x]=True <=> x előáll az első i szám összegeként }
For x:=M DownTo E[i] Do
V[x]:= V[x] Or V[x-E[i]];
End{i};
For x:=M Downto 1 Do
If V[x] Then Begin
F:=x;
Exit
End;
End (* F *);
Begin { Program }
Assign(BeF,’testveri.be’);
Assign(KiF,’testveri.ki’);
Reset(BeF); Rewrite(KiF);
ReadLn(BeF,N);
Osszeg:=0;
For i:=1 To N Do Begin
Read(BeF, E[i]);
Osszeg:=Osszeg+E[i];
End;
Close(Bef);
A:= F(Osszeg Div 2);
WriteLn(KiF, A,’ ’,Osszeg-A);
Close(KiF);
End.


Ha azt is meg kell adni, hogy az egyes testvérek mely ajándékokat kapják egy testvéries osztozkodást során, akkor nem elég
lineáris tömb, minden (x, i)-re tárolni kell a V(x, i) értékeket, hogy elő tudjunk állítani egy osztozkodást.

Kód:
Procedure Osztozkodas(Const E:Ertekek; N: Word;
Var Db:Word; Var C :Megoldas);
Const
MaxN=100; {az ajándékok max. száma }
MaxFel=300;{ Max. összeg }
Var
N,i,Osszeg,A, F: Word;
E:Array[1..MaxN] Of Word; { az ajándékok értéki }
18
V:Array[0..MaxFel, 0..MaxN] Of Boolean;
i,X:Integer;
Begin{Osztozkodas}
Fel:=0;
For i:=1 To N Do Fel:=Fel+E[i];
Fel:=Fel Div 2;
For x:=1 To Fel Do
V[X,1]:=False; {az első sor, azaz V(X,1) számítása}
V[E[1],1]:= E[1]<=Fel;
For i:=2 To N Do {az i-edik sor,azaz V(X,i) számítása}
For X:=1 To E Do
V[X,i]:=(E[i]=X) Or V[X,i-1] Or
(X>E[i]) And V[X-E[i],i-1];
For x:=Osszeg Div 2 Downto 1 Do
If V[x,N] Then Begin
F:=x;
Break
End;
Db:=0; X:=F; i:=N { egy megoldás előállítása}
Repeat
While (i>0) And V[X,i] Do Dec(i);
Inc(Db); C[Db]:=i+1; {i+1 bejegyzése a megoldásba}
X:=X-E[i+1]; {X-E[i+1] felváltásával folytatjuk}
Until X=0;
End{Osztozkodas};

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #78750   2008.01.02 00:51 GMT+1 óra  
Először én is erre gondoltam de 1.: ez nem dinamikus programozás
2.: ha kipróbálod a példával, akkor az jönne ki, hogy: 52 45 (az optimális 48 49 helyett). Tehát továbbra is várom az ötleteket, hogy ezt mégis hogy a *** kéne DP-al megoldani...
   
Joga - Törzstag | 1791 hsz       Online status #78747   2008.01.02 00:42 GMT+1 óra  
Sztem először csökkenő sorba rendezed az ajándékok értékeit, majd utána sorban mész és mindig ahhoz a változóhoz adod az ajándék értékét, amelyiknek kevesebb az értéke
(ಠ ›ಠ) Stewie!

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #78745   2008.01.02 00:24 GMT+1 óra  
Hmm... sehogy sem tudok rájönni, hogy ezt a feladatot dinamikus programozással h kéne megoldani:
"Van 2 testvér és egy rakat ajándék [2;100] amiknek megvan az értékük [1; 200]. Ezeket az ajándékokat kéne úgy szétosztani, hogy minél egyenlőbb legyen és ki kell írni, hogy melyik testvér milyen értékben kapott ajándékot.

Pl. input:
28 7 11 8 9 7 27

erre ezt kéne adnia:
48 49"
   
Cow - Tag | 52 hsz       Online status #76241   2007.12.06 22:45 GMT+1 óra  
Lenne egy kérdésem azok számára, akik egy kicsit is jártasabbak az algoritmusok világában.
Szóval az a feladat, hogy egy gráfban, meg kell határozni azokat a pontokat, amelyket egyessével kiszedve, még összefüggő a gráf (tehát bármely két csomópontot összeköti legalább egy útvonal.) Irányítattlan gráfról van szó, és szomszédsági listával van megvalósítva a gráf.

Jelenleg azt a módszert használom, hogy csinálok egy mélységi keresést, majd a az elérési idők mellett meghatározom az egyes pontokhoz tartozó apát, valamint van L(p) is, ami annak a csúcsnak az elérési idejét tartalmazza, amelyet egy p gyökerű részfából elérhetőek legfeljebb egy visszaélen keresztül. Ezek közül az értékek közül is a legkisebbet tartalmazza.

A gond ezzel, hogy ha kiszedek egy pontot, akkor újra meg kell vizsgálni az egész gráfot, hogy nehogy olyat a szedjek ki, ami esetén már nem lesz összefüggő.

Hogyan gyorsíthatnék ezen az algoritmuson? Ötletem sincs
Eredetit, újat és ötleteset - bárhol és bármikor... avagy nem vetem meg az ágyat, mert megvetem.
http://cow.isgreat.org
   
kiskami - Tag | 265 hsz       Online status #54631   2007.05.13 22:52 GMT+1 óra  
Unix alatt van truncate függvényhívás, meg régen (dos?) alatt volt olyan trükk - ha jól emlékszem -, hogy 0 hosszal kellett appendelni adott pozícióban.
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
TPG - Tag | 3402 hsz       Online status #54582   2007.05.13 07:15 GMT+1 óra  
Idézet
ShAdeVampirE :
pseudo kóddal:

Kód:
if(last_existed_file_end != -1)
{
if( this_file_is_not_deleted )
{
copy(this_file, last_existed_file_end);
}
}


Alapból last_existed_file_end = -1, de ha már megvan, hogy hol törölsz file-t akkor onnantól mindíg a legutolsó létező (nem törölt) file végét mutatja, ahova be lehet illeszteni a következő létező file-t. Ezzel egyszerre akár több file is törölhető, mert ha törölni akarunk egy file-t, akkor mikor elérünk a file-hoz csak annyit kell tenni, hogy nem számoljuk ki a végét, ugyan annyin hagyjuk az offset-et és "ráírunk". Ez 1etlen dolog, ami itt gond lehet az a file végének törlése, mert ha mindent előre "tolunk" attól még a file vége megmarad és 2x is a file-ban lesz. Ezt utána talán átméretezéssel lehetne megoldani, de ezt nem tudom, hogy meg lehet e oldani.


Jaja ez nekem is eszembe jutott csak azt kéne kideríteni hogy hogyan lehet törölni a fájl végét.
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #54581   2007.05.13 07:13 GMT+1 óra  
Idézet
ferchild :
szerintem sem úszod meg az átindexelést
én spec azt csinálnám:
pack megmondja, honnan kezdődik a file, mekkora. Én a pack végéhez csapnám a filet újra, majd átoffsettelem az egészet ami az eredeti hely után van és a végén levágom a fölösleges filet.
remélem érthető

szerintem shade is vmi hasonlóról beszél


Hasonló nekem is eszembe jutott (végiglépkedek a packon és ha egy törlendő fájlt találok akkor az felülírom az utánalévővel és innentől kezdve a következő fájlokat ennyivel csúsztatom előre), csak azt nem sikerült még kitalálnom hogyan lehet a felesleges helyet levágni a fájl végéről.
Reality is almost always wrong. - House

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54574   2007.05.13 05:31 GMT+1 óra  
Igen Kérdés csak az, h file végének levágását meg lehet e oldani...
   
ferchild - Törzstag | 815 hsz       Online status #54561   2007.05.13 02:18 GMT+1 óra  
szerintem sem úszod meg az átindexelést
én spec azt csinálnám:
pack megmondja, honnan kezdődik a file, mekkora. Én a pack végéhez csapnám a filet újra, majd átoffsettelem az egészet ami az eredeti hely után van és a végén levágom a fölösleges filet.
remélem érthető

szerintem shade is vmi hasonlóról beszél
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54560   2007.05.13 01:19 GMT+1 óra  
pseudo kóddal:

Kód:
if(last_existed_file_end != -1)
{
if( this_file_is_not_deleted )
{
copy(this_file, last_existed_file_end);
}
}


Alapból last_existed_file_end = -1, de ha már megvan, hogy hol törölsz file-t akkor onnantól mindíg a legutolsó létező (nem törölt) file végét mutatja, ahova be lehet illeszteni a következő létező file-t. Ezzel egyszerre akár több file is törölhető, mert ha törölni akarunk egy file-t, akkor mikor elérünk a file-hoz csak annyit kell tenni, hogy nem számoljuk ki a végét, ugyan annyin hagyjuk az offset-et és "ráírunk". Ez 1etlen dolog, ami itt gond lehet az a file végének törlése, mert ha mindent előre "tolunk" attól még a file vége megmarad és 2x is a file-ban lesz. Ezt utána talán átméretezéssel lehetne megoldani, de ezt nem tudom, hogy meg lehet e oldani.
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54559   2007.05.13 01:08 GMT+1 óra  
És ha csak kisebb részeket vennél egyszerre? Úgy értem, hogy mondjuk file-onként mennél végig rajta: ezeket ha nem kell módosítani nem módosítod, ha törölni kell, akkor a köv file-t előre mozgatod annyival. Ezt lehet memóriába betöltéssel is (addit memóriában tárolod a mozgatni kívánt file-t), de lehet egy temp. file is.
   
TPG - Tag | 3402 hsz       Online status #54541   2007.05.12 16:06 GMT+1 óra  
Idézet
ShAdeVampirE :
Ok, bocs, késő van már Akkor mást kérdezek: miért nem lehet egy ideiglenes file-t létrehozni v memóriába beolvasni annyi időre?


Memóba beolvasni azért nem akarom mert úgy csináltam meg a pack fájl-t hogy maximálisan 4GB méretü lehessen és szeretném ha egy ilyen 4GB-s fájlból itthon 1GB memóval is tudnék törölni. A temp fájlos módszerrel már nem ilyen bajaim vannak, egyszerűen sztem nem túl elegáns (Ha a 4GB-s fájlból törlök akkor a törlés idejére akár 8GB-t is elfoglalhat az egész), kell lennie jobb megoldásnak is.
Reality is almost always wrong. - House

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54540   2007.05.12 16:00 GMT+1 óra  
Ok, bocs, késő van már Akkor mást kérdezek: miért nem lehet egy ideiglenes file-t létrehozni v memóriába beolvasni annyi időre?
   
TPG - Tag | 3402 hsz       Online status #54538   2007.05.12 15:34 GMT+1 óra  
Idézet
ShAdeVampirE :
Nem egészen értem a kérdést. Ez nem csak egyszerűen annyi, h pack leíró strukt-ban megkeresed a file leíró strukt-ját, ami meghatározza h a file hol is van (offset), oda seek-elsz, törlöd, leíró struct-ot is törlöd, és a bejegyzést is törlöd? Ennek van vmi akadája?


Annyi akadálya van ennek hogy nincs fájlból törlés funkció. Csak írni,olvasni és pozicionálni lehet a fájlban.
Reality is almost always wrong. - House

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54536   2007.05.12 15:26 GMT+1 óra  
Nem egészen értem a kérdést. Ez nem csak egyszerűen annyi, h pack leíró strukt-ban megkeresed a file leíró strukt-ját, ami meghatározza h a file hol is van (offset), oda seek-elsz, törlöd, leíró struct-ot is törlöd, és a bejegyzést is törlöd? Ennek van vmi akadája?
   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [17]