Digitalna evolucija

seveda spremeni ravno to ti tupim vse cas. naredi neumno distribucijo stevilk. posebej za to funkcijo,ki je cudna ze sama po sebi pa se toliko bolj, mislim jaz te nerazumem , ce ena števka ne sovpada greš žile rezat ko je dve miljarde pogreškov si pa frapiran nad natačnostjo. criticalov algoritem je primerljiv z lutom zgolj za prvi if v proceduri , pri tretjem ifu v critticaovei proceduri je ze hitrejši lut.

gor sem dal en link na prirejene benche, igraj se ,ce se hočeš. lahko pa dodaš še to obtežitev zraven, da bo slika bolj popolna.

spregledal da tvoj dela le do 20 bitov , dd3 daje pravilen output na celem int območju.

8 bitna distribucija in ostale distribbucije niso nesmiselne, če iščeš all rounderja med procedurami.
in tudi z stališča analize so uporabne. če popraviš tvojo proceduro na int domeno lahko pričakujemo pohitritev?
ali ga diskvalificiramo zaradi napačnega outputa?

Še ni dobro. Manjkajo distribucije, ali pa so vse razen enakomerne, kjer ima vsako število enako verjetnost, odveč.

Ti si naredil distribucije, ki favorizirajo DD3, čeprav so - numerično gledano - te v manjšini.

Toda tudi za kakršnokoli vnaprej znani distribucijo sploh, obstaja varianta CRI (binarija), ki je najhitrejša.

Zadeva je podobna ugibanju števila. Kako z najmanj koraki uganiti neka (recimo 10 bitno) število?

Je x >= 512?

Če ni, je x >= 512-256?

Če je, je x >= 512-256+128?

Če je, je x >= 512-256+128+64?

Če ni, je x >= 512-256+128+64-32?

itd, 10 korakov vedno, do naprimer:

je x>= 512-256+128+64-32-16+8-4+2-1?


TOLE je teoretično najhitrejši način, da to ugotovimo.

Kaj pa "real life distribucije" števil, ne "samo za enakomerno", kjer so vsa števila enako verjetna?

Za večino možnih distribucij je tole optimum. Za kakšne posebne, je treba popraviti konstante, pa je binary spet najhitrejši možen.

Pri ugibanju števil ne moreš premagati binarija. Lahko samo zafejkaš, da si ga, kot to zafejka test, ki ga je sestavil noraguta.

To je corner stone informacijske teorije, da je binary algoritem ugibanja vedno najboljši.

Ker za ugibanje gre. V katerem intervalu [2ⁿ, 2ⁿ⁺¹] je število x - in zgornja meja intervala je potem odgovor.

Največji je končni možni interval, kjer bi število znalo biti. 50% števil se nahaja tam. V 50% primerov nam torej da odgovor že prvi if, po njem zapustimo funkcijo.

Od preostanka nam 50% primerov zaključi druga vrstica binarija (CRIja), itd.

Pravzaprav ne iščemo na intervalu [2ⁿ,2ⁿ⁺¹] pač pa na (2ⁿ,2ⁿ⁺¹]. Kar pa nič ne spremeni.

> jes grem na per.

ob tej uri?

pohvalno

čemu še slepomišiš? preštej konju zobe(pomerimo hitrost), verjemi da znam prešteti zanke tudi sam,na roke brez evolucije pa vsega tega sranja.

moj benchmark je na mizi. je dal svoje rezultate od sebe le ti še po malem mimosuvaš ampak bres argumentov.

ibid

 times 32 32h 24 16 8 
 Critt: 562 641 469 1000 1360 1781 
 n2DD3: 360 516 515 485 484 453 
 

o čemer je times irelavanten.
32h pa trivial.

ničla ni panike(manj kot 5% pribitka).
ne spremeni bencha.
32h je trivial in ne rabim ne cri ne 32h za to ,da mi pove nekaj kar vem. je preobtezena distribucija pri kateri se izvede le en if.za to tudi dodana notri. 32 je relavanten in ostale podistribucije saj je le to zadeva ki cloveka zanima. ker v nasprotnem bi zadevo lahko zreducirali na
if (n>1073741824) return 2147483648;

ali na( v najblosem primeru )

if (n>1073741824) return 2147483648;
if (n>536870912) return 1073741824;

in se pocutili blazno fino.to je komajda isti problem .

Kot da bi ugibal števila do 1000, pa bi vedno najprej vprasal:

Je vecje kot milijarda?

Je vecje kot pol milijarde?

Je vecje kot cetrt milijarde ...

že res ampak ampak v tem je point kompresije v lookup tabelo ,dvoje cincanj (ifov) za celo miljardo ali dve konstantno. ostale operacije pa poberejo cca 10% if-anja.

distribucije so sestavljene zadosti dobro da pokazeo odvisnost procedure od inputa. vse ostalo se da dosti dobro ekstrapolirat.

mar res misliš ,da boš dobil najhitrejši algoritem če pofrezaš zgornje ife pa recimo za 8 bina števila(distribucijo)?
ali tudi tu pričakujemo ,da bo 90% inputa med 128 in 255?(tu je celo možno da se kaj takega zgodi pi 32 bitni varijanti pa nekako ni).

Ampak edino tako je smiselno. Da se ne izvajajo prvi ifi zmeraj na prazno. Ti pa praviš da ne.

kar trdim jaz je da bo v rl problemih input na tem intervalu za vecino problemov precej skromen.oziroma skromnejši od 90% . pa recimo ,da je v 90% procentov inputa nad miljardo in tisto nekaj drobiža 10% pa sopodaj in lineariziran. in glej ,glej ifi spet suckajo.

seveda vem da mi boš ponudil 10.000 binarnih dreves za vsako dano distribucijo. ampak kaj če je ne vem v naprej? nisi ponudil odločitvenega logike kdaj kakšno uporabit. za linearno distribucijo na katerem koli ne ozkem intervalu itak suksa tvoje ifanje.

:~) ja v tistem tvojem orodju sem prepričan da.

(še vedno ti ni jasno , da ti če nimaš razreda ki ima vsaj 90% ne zastopansoti so ifi pocasni).

v rl bi bilo potrevno pa pogledat, samo ker na svetu ocitno ni cloveka ki bi razumel zadevo , ti pa ne znas spisat drugacnih testov kot ,da vracajo nicle, nam bo za vedno ostalo zastrto.

ša za linerano ne znaš.
ne na 32 na na 8ih biotih ne kjerkoli vmes.

In ja, seveda, preko 90% adres ima vsaj enega od prvih štirih bitov na ON. Pa naj bo to 32 ali 64 bitni procesor. Ali 1024. Če je memorija omejena na en sam megabyte, se pač adresira samo do 20 bitov, velja pa isto. Prvi 4 biti določijo 90% natančnosti, kam poknemo eno spremenljivko.

To je en tako zelo real life primer.

Jah ... zgubil sem te pač. Ko že mislim, da bo s tabo možno pametno debatirati, se ponovno začneš spakovati.

No, bom kasneje razložil bolj podrobno.

Mah, najprej o binariju še, znanem kot CRI.

Sit sem ga, in noragute z njim. Ljudje so dveh sort. Tisti ki kapirajo, da binary je tahitrejši, pa tisti ki kapirajo da ni. Totalen dolgcajt že.


Evolucija, kot pravi Vesoljc, gre dalje!

Pomeni, da bodo testirana števila v tem obsegu kot input vrednosti.

y(1,100) pri tebi nima nobenega smisla. Škodi pa tudi ne!

x(1,100) pri tebi pa pomeni, da bo algoritem skoraj zagotovo veljal za vse x med 1 in 100. Milijon ali več testov bo šlo skozi.

Sem gonil tale tvoj primer. Interesanten.

hmm, zanimivo,
pr x(1,100) y(2,100) sm pršu "samo" do tega-// The algorithm has been enhanced For 88.6117%

pr x(1,400) y(2,400) pa sm pršl do celo// The algorithm has been enhanced For 95.5078%

samo pr drugm nism pustu do konca(do tam k prekine kr je neregistrirana verzija)

V tem konkretnem primeru [formula za praštevila do 100?] boš kaj več težko dobil, tudi če zelo dolgo laufa. Ampak:

$rinvar x(1,1000)

in brez kakršnegakoli ipsilona pri $rinvar ... zna biti zanimivo.

y se določi doli v programu sam iz x-a, ne glede na to, kakšen je y pri inputu. Zato je vseeno če ga imaš ali nimaš.

Samo če Critticall vidi, da je več input spremenljivk, dela več preverjanja kode.

Kar dobiš je pa alien ko hudič, to pa ja.

A lahko daš optimizairat DNK?

Ubitsvu bi moral dat v evolucijo/simulacijo DNK z vsemi sistemi, ki sodelujejo zraven pri kopiranju, prepisovanju itd, itd.
Pa pustiti evoluciji (taki naspidirani v računalniku seveda) da poišče boljše sisteme, boljše substrate za nas.

Digitalna evolucija ... na urniku.

Downloadate lahko en resničen primer, samo priimki in imena so spremenjeni v bolj klingonske.

Kdo pride do manjšega ERROR rezultata?