Förhindra att IE & FF avbryter javaskript

Nej inte allt på en gång, men man kan lura webbläsaren med setTimeout. Nu har jag skrivit om det och gett exempel på hur man kan göra det med en while-sats då dessa exekverar snabbare i javascript. (En while som räknar neråt är ännu snabbare.)

<script>
y=d=1;
function Loo() {
var i=0;
while (i<10000) {
y+=d;
if (y>50000000){
	alert(y);
	return;
}
i++;
}
setTimeout(Loo,100);
}
Loo()
</script>

Kanske inte ultimat, men kan ge en funderare.

colione skrev:

Kanske inte ultimat, men kan ge en funderare.

Högintressant! Det fungerar ju faktiskt! :)

Frågan är hur jag ska montera in detta i sökalgoritmen. I verkligheten har jag en rekursiv djupet-först-algoritm som både tar argument och returnerar värde.

Princip:

negamax( ... )
{
Om det finns drag att testa
{
gör draget
if (förutsättningar) rt=negamax( ... )
ta tillbaka draget
justera värde på r
}
return r
}

Var skall man montera in denna lösning? Måste jag skapa en egen stack med funktionens argument och returnvärde? Då kunde jag lägga in setTimeout på det rekursiva anropet med begränsningen att det enbart görs på djup=0 annars lär det väl sinka programmet enormt. Antal drag i varje nivå är i snitt 35 så då borde programmet klyvas tidsmässigt i 35 delar.

Frågan är också om detta trix med timeout:en blottar ännu enklare sätt att nollställa den interna sats-räknaren? Hur kan det fungera internt?

Snyggast av allt; Efter att min kung är uppäten :l så borde jag ju varit shackmatt, men då kunde jag spela med de svarta (alltså datorns pjäser) ... höhö.. roande! :e

Men snyggt i alla fall, det är ju som sagt inte färdigt! :)

Fredde Mannen skrev:

Efter att min kung är uppäten :l så borde jag ju varit shackmatt, men då kunde jag spela med de svarta (alltså datorns pjäser) ... höhö.. roande! :e

Du kan spela med motspelarens pjäser från start. Det är ingen bugg. Det är en flagga, som just nu är satt att tillåta vad som helst.

I övrigt för att kunna se vad som är en bugg och inte måste man ha lite basic kunskaper om min/max.

Exempel: Om datorns drottning hotar kungen och du inte flyttar kungen så är det inte säkert att datorn slår ut kungen nästa drag. Om däremot datorns häst kan slå ut drottningen men avstår från detta, då är det sannolikt en bugg (om det skulle hända).

Men, men, ... det är en hel del kvar. Min bästa vän i detta projekt är firebug. :)

Nu när jag tänker efter så ställde jag en liknande fråga för länge sen, hade också problem med en loop som käkade cpu.

du kan ju kika på den lösningen också om du vill

http://www.webforum.nu/showthread.php?t=136466&highlight=loop

sen vart det ju som jag sa från början, en timeout på några hundradelar :p . fast jag hade ju inget script att komma med.

stattin skrev:

sen vart det ju som jag sa från början, en timeout på några hundradelar

Jo, det kanske löser problemet. Det är ju grymt intressant att det går att nollställa den interna stats-räknaren. Så det är ju en del-seger helt klart. Det hade ju kunnat vara så att det inte går och då hade man ju inte behövt fortsätta. Nu går det och det är ju grymt intressant.

However:

Om du studerar min pseudokod för negamax och tittar på det inre rekursiva anropet. Där skulle man då lägga ett timeout. Men timeout-en ligger ju inte och väntar. Jag måste alltså skapa någon slags semafor.

while (vänta) { do_nothing; }

och lägga den precis efter timeout'en. Och frågan är om inte det sätter hela trixet ur funktion. Saken är ju den att jag behöver returvärdet från det rekursiva anropet innan jag kan fortsätta. Annars fungerar ju inte minimax.

Ett alternativ är att designa om hela minimax så att det på något sätt skulle fungera med timeout -tekniken men då börjar det kännas lite overkill.

Problemet är alltså inte löst ännu och det är fortfarande inte säkert att det går.

Jag ska försöka komma på ett bättre expriment än loopen för att projicera problemet på något gripbart.