Digitalna evolucija

Torej imaš DD3A verzijo, ki dela prav. Praviš da je hitrejša od binaryja (ki ga Critticall iznajde).

Praviš pa tudi, da je hibridna verzija CRI_DD3A še hitrejša?

> vendar zgolj za all-range distribucijo inputa

Tega, na kakšne drugačne distribucije mislite, niste znali nikoli povedati.

Ko si videl, da je DD3_CRI napačen, si mu popravil šurka.

Zdej praviš, da je (po tvoji meritvi) najhitrejši in TVOJ.

Hehe ...

Najprej. Tukaj se Critticall ne meri z nikomer. Njegovi algoritmi se.

DD3 je počasnela pa pri drugih inputih, kot tale CRI. Velikih številih, recimo.

Le da Critticall lahko naredi CRI1, CRI2, CRI3, CRI4, CRI5, CRI6, ... za vsako vrsto inputov.

To vam gre v nos.

Kdo pa je rekel, da bi moralo biti ravno drevo. Lahko tudi poznamo profil input data streama in ga pričakamo z zanj fine tuned algoritmom.

DD3, ki ga imate tako radi, ni nujno dober za vselej in povsod. Sicer je pa precalculated CRI, kjer se izvajajo bloki ifov naenkrat.

Spet je čas za citiranje Zipsterja:

There, you won. "Your" hybrid turned out to be the fastest with all the optimizations turned on, in addition to when turned off. I just hope I never have to debate with you again, because I don't think I can hold on to my sanity.

Sej pravi, lastiš si kodo algoritma. Izvoli, objavi jo na Gamedev.net kot najhitrejšo.

Ali pa tukaj.

> ako me spomin ne vara, so.

Te vara.

Jest bi zdej rad samo tahitrejšo kodo vidu. Da bi vidu, če imam kaj zraven.

Ni CRI, temveč je binary (kar sem seveda že povedal). Glede na debato dokaj pomembna sematična razlika.

Jasno.

Te vara.

Me ne:

Q : In which context do you use such a function. I just wonder if it's of general use. I thought of mem allocation algos, or putting arbitrary images into power of two texture chuncks, but that's not obvious.
---
Nothing critical, as you guessed, i use this function to convert the resolution of my display to fit in a 2^n texture ...

pomoje distribucijo misli...

se pravi, da rang nekaj tisoc pikslov

Aja. Binary je? Torej ni nobeno originalno Critticallovo (z mojo pomočjo) odkritje? Nekaj kar je bilo znano že prej, v nasprotju z drugimi algoritmi, tam objavljenimi, originalnimi in 100% avtorskimi?

Preden začnem mahati okoli s sarkazmom, ali je jasno, da govorimo o DD3 (prvi ga je v temo na gamedev.net prispeval DigitalDelusion).

aj si pa prebral iz citiranega angleškega teksta, katero resnico vidiš notri, pa ne vem.

Tisto, da je bilo povedano o kakšni distribuciji je govora (ta tvoja "nevednost" bi skorajda implicirala, da negiraš kar vse po čez ... Kaj nismo govorili o "znanstvenem" pristopu k argumentiranju in debatiranju?).

Vsak ne, jest pa. Če je moj algoritem za NP2 najhitrejši, se tolčem po prsih.

Nisem tako skromen kot ti, ki se ne bi.

Samo sem povedal. To je binary, h kateremu Critticall zna skonvergirat.

Če binarija baše množica ifov, se ga potem morda splača prevest v nekakšen DDX. Ampak samo za manjši del vrednosti.

Še nekaj.

Če dopustimo, da je program poljubno kompleksen v smislu Kolmogorova, to pomeni, da ima zelo veliko vrstic, po domače ... kar DD3 gotovo ima, potem kje bomo postavili mejo?

Da naredimo kar tabelo za vsa števila? a[]={1,1,2,4 ....2*1048576}.

Potem je program:

return a[x];

Tudi to sem predlagal na Gamedev.net. To je najhitrejše, "sploh ker imajo sodobni procesorji dovolj cachea".


Zakaj DD3 ja, to pa ne? Kje je tista meja?

Če pa ostanemo resni, potem je dober samo neprirejen binary, ki ga Critticall najde.

Se pravi zanke:

The next power of 2 is for the numbers from 0 to 15:

 p=5;
 if (i>=p) {
 p=8;
 labelcritticall15:;
 if (i>p) {
 p=p+p;
 }
 } else {
 p=2;
 if (i>=p) {
 goto labelcritticall15;
 }
 p=1;
 }
 
 
 
 i stands for input and p stands for power.
 
 
 p=8;
 if (i>p) {
 p=p+p;
 } else {
 p=5;
 if (i>=p) {
 p=8;
 } else {
 p=2;
 if (i>=p) {
 if (i!=p) {
 p=4;
 }
 } else {
 p=1;
 }
 }
 }
 
 
 
 
 Another one. Faster for 5%.
 
 And another 1% better.
 
 p=5;
 if (i>=p) {
 p=8;
 if (i>p) {
 p=p+p;
 }
 } else {
 p=2;
 if (i>=p) {
 if (i>p) {
 p=4;
 }
 } else {
 p=1;
 }
 }
 
 
 
 
 To generalize it now, to any bit number is quite easy. Isn't it?
 
 
 How we can generalize it to 5 bits numbers?
 
 This is an obvius way:
 
 if (i>16) {p=32;goto over;} 
 if (i==16) {p=16;goto over;} 
 p=5;
 if (i>=p) {
 p=8;
 if (i>p) {
 p=p+p;
 }
 } else {
 p=2;
 if (i>=p) {
 if (i>p) {
 p=4;
 }
 } else {
 p=1;
 }
 }
 
 over:;
 
 
 Critticall will smooth it to:
 
 p=16;
 if (i>p) {
 p=p+p;
 } else {
 p=5;
 if (i>=p) {
 p=8;
 if (i>p) {
 p=p+p;
 }
 } else {
 p=2;
 if (i>=p) {
 if (i>p) {
 p=4;
 }
 } else {
 p=1;
 }
 }
 }
 
 
 
 

V temle smislu.



Zadeva pride do while zanke, kjer razpolavlja kandidata za return, dokler ga pač mora.

Sapienti sat!

Če dopustimo, da je program poljubno kompleksen v smislu Kolmogorova, to pomeni, da ima zelo veliko vrstic, po domače ... kar DD3 gotovo ima, potem kje bomo postavili mejo?

Verjetno je omejitev stroj na katerem se bo program izvajal. Dokler primerjamo algoritme ambstraktno, kot matematične konstrukte, omejitev (vsaj kar se mene tiče) ni, v realni situaciji pa pravzaprav tudi ne, le finesa se spremeni (in niti ni nujno čas izvajanja, lahko je recimo tudi pomnilniška požrešnost).

Tudi CRI se debeli s povečevanjem domene.

CRI!=Critticall

CRI==Critticall's

(Ime nisem dal jest, pač pa drugi.)

Vem, ampak vseeno bi se prilegla kakšna okrajšava tudi za Critticall, lenoba dela svoje.

Prav.

dani primer je bil ze objavljen na game-dev kot lut 256k. tole kar navajaš je le variacija na temo.

Ja jaz tem tudi enkrat študiral da bi tisti kup ifov na koncu bilo pametno zamenjati s tabelo.

Taka super-duper-mega-large tabela pa seveda zmaga.. ampak to zame ni algoritem.


Na gamedev.net niso povedali kaka je distribucija, govorili so o nekih texturah, noben pa ni povedal razporeditve velikosti textur ali dal kakšnega dela programa, kjer se to izračunava.

Neumno je optimizirati del nekega programa, po enem bornem opisu, namesto da bi optimiziral dejanski algoritem.


Ja, Thomas ko si ravno sam omenil.. zakaj ne delaš benchmarkov? (Ja.. Critticall pove kak hiter je algo? )

Edit: Hm.. slo-tech dela z zamudo?

Moja poanta je ta, da notranjih 3/4 ifov, ki se vsi skupaj izvajajo v samo 1% primerih, nadomestimo s tabelo. Veliko kakšne megabyte.

Ali pa notranjo polovico ifov, ki se skupaj izvajajo 1 promilo primerov, nadomestimo s par 100 K tabelo.

Če že imamo tabelo, ane?

Od tukaj naprej o tem algoritmu ne vem res nič več povedati. Skleda poglodana do dna.


> .. zakaj ne delaš benchmarkov? (Ja.. Critticall pove kak hiter je algo? )

Jasno. Kako hiter je algo. Sploh še, ker lahko vrednost vsake komande naštelaš, tako da se ti razmerja rezultatov dobro ujemajo s tvojim PC in compilerjem.

Kako z najmanj računanja dobiti globino postavitev na 4 šahovskih tablah tako, da se 32 postavljenih kraljic na vsaki tabli ne tepe in da so postavitve različne, je pa čeznočna optimizacija:

 
 $DECLAREINT y0 critticall1 x4 x3 i y2 critticall3 
 
 $DIMENSION x[24] y[24]
 $RETVAR y[] 
 $WEIGHTS commands=1
 
 // int y[24]; int y0=0;int critticall1=0;int x4=0;int x3=0;int i=0;int y2=0;int critticall3=0;
 
 $BES
 critticall1=3;
 x3=1;
 y0=1;
 critticall3=5;
 x4=1;
 goto labelcritticall10;
 while (critticall1>y2) {
 x4=3;
 y0+=1;
 if (y2!=x3) {
 critticall1=critticall3;
 critticall3=1;
 }
 i+=1;
 labelcritticall10:;
 y[i]=y0;
 i+=1;
 y[i]=critticall1;
 if (x3==critticall3) {
 critticall1=critticall3;
 y0|=1;
 i+=1;
 y[i]=critticall3;
 i+=1;
 critticall3=4;
 x4+=1;
 y2=1;
 y[i]=x4;
 i+=2;
 y[i]=y0;
 i+=1;
 y[i]=y0;
 goto labelcritticall2;
 }
 if (x4>critticall1) {
 y2=5;
 x4+=-1;
 critticall1=0;
 labelcritticall2:;
 i+=1;
 }
 i+=1;
 x4+=1;
 y[i]=critticall3;
 critticall1+=1;
 i|=1;
 y[i]=y2;
 i+=1;
 y[i]=x4;
 i+=1;
 y[i]=critticall1;
 }
 $EES
 

Nehumana, jasno, ampak izvršijo se povprečno manj kot 3 linije računanja na kraljico.

Kaj si mislim ko berem tole. Skoda topica. Skoda casa (zal sem se zavedel prepozno).

V glavi mam nekaj takega:

#1:
I only come to bash you, as the others did, because you do not want to face simple realities, which is your personnal problem, not something related to coding. This renders any objective discussion with you pointless. Unless you start to act as a scientist.

#2:
I've had enough of you. First it was your arrogance and stubbornness, but I could let that go. Then it was your incapacity to form a well-reasoned argument supported by evidence (a.k.a benchmarks) that made it frustrating to debate with you (I didn't know if I was talking to a human or a machine, all you did was spit out code). And finally it was the gall to tell me I've done a good job as if you're my fuckin' instructor or mentor, even after a I spent the time to rewrite a whole test which ended up showing your method to be statistically faster, if not practically (due to expansion).

in to:
That's enough. Closed.

Naj si to thomas prebere, mogoce se kej nauci. Ne pametuj kar nekaj. Tist tvoj if algoritem zna naredit vsak, ki pozna sintakso C++. In ko se je izkazalo, da ni najhitrejsi, si sel benchat v debug. Bravo. Ko programiras vedno glej, kaksen je koncni rezultat, ne pa kaksna je navidezna kompleksnost same kode.

Pa se nekaj te prosim: Odvadi se hocem link! daj mi link! .edu! tralala, ker s tem nic ne dosezes. Hvala.

Ce si tako pameten kot pravis, pojdi na neko hudo univerzo/institut in naredi ze nekaj, kar bo spremenilo svet in odresilo clovestvo vseh muk. Vse tiste tvoje metode nadzora in podobno. Ne zgubljaj dragocenih trenutkov s pisanjem po kar enem forumu. Do zdaj od tebe ni bilo se nicesar konkretnega, ampak samo pametovanje in frajarjenje s tvojo "inteligenco".

Critticall je ql. Brez dvoma. Vendar pa je totalno bedno, ker enostavno ne mores priznati, da ne more vedno doseci najbolsega rezultata, ker C++ koda je le C++ koda in optimalna C++ koda je lahko dalec od optimalne strojne kode. Tega se zavedi enkrat. In zelo ocitno (ceprav to ostro zanikas) vsako kritiko Critticallove superiornosti vzames kot osebno zalitev, kar izpade bedno.

tomas pa saj smo ze ugotovili, da je zipster malo zameštral definicijsko območje. in to hudo v prid tvoje procedure. ampak na žalost je pol tistih rezultatov napačnih.
4,294,967,295 !=4,294,967,296 pač .

zipster pa je gnal zanko skozi celi unsigned. za dano proceduro je definicisko območe lahko le int.

Malo preštej na roke koliko krat se kaj izvede ,saj je dokaj očitno. tudi če bi zeleli dobiti takšo obtezitev distribucije števil , tega nacina ne bi uporabili ker preprosto vraća napake.

je pa tovrstna obtežitev bolj ali manj neverjetna ali pa bolj milo rečeno nepredvidljiva.

> tega nacina ne bi uporabili ker preprosto vraća napake.

Kakšne napake pa vrača??? Smo se že strinjali, da dela prav.

Off topic: kaj ti to govoriš (lomiš) zaen jezik?

Če je on (Zipster) zamešal signed in unsigned, to ne spremeni ničesar.

Do nekega števila bitov dela prav. To je vedno tako, z vsakim programom, da nekje vrže ven. Potem se pač prilagodi bitnost spremenljivk, no big deal at all.