Ciao a tutti,
L'altro giorno mio figlio ha chiesto di suonare la versione cartacea di "Battleship". Ogni persona aveva 5 "navi" di 5, 4, 3, 3 e 2 unità di lunghezza (e un'unità di larghezza). Le "navi" sono state posizionate su una griglia 10 per 10 nello spazio XY; ogni "nave" aveva un insieme unico di coordinate (x,y). Ad esempio, una delle 3 unità "navi" potrebbe avere coordinate (3,4), (4,4) e (5,4). Non più di una "nave" può occupare la stessa coordinata (x,y). Le "navi" possono essere eseguite solo in verticale o in orizzontale: non è consentita la disposizione diagonale.
Poi, a turno, abbiamo chiamato coppie di coordinate (x,y) per vedere chi ha colpito direttamente la "nave" di qualcun altro. Ognuno di noi aveva solo 16 turni per cercare di colpire (o affondare) altrettante "navi" dell'altra persona. Mentre stavamo attraversando questo, ho pensato tra me e me che doveva esserci un approccio migliore per massimizzare le possibilità di colpire (e/o affondare) la "nave" di un'altra persona piuttosto che chiamare casualmente le coordinate. Ovviamente, non chiameresti una coordinata (x,y) che hai già utilizzato poiché sapresti se hai colpito una "nave" o meno.
All'inizio, ho pensato che forse la piattaforma Custom Design sarebbe stata la strada giusta da percorrere, ma se crei un progetto in cui Y è "Hit" (0/1 per no/sì) e X1 = x e X2 = coordinate y (numerico discreto a 10 livelli), la piattaforma genererà un progetto in cui utilizza solo i livelli alto e basso per ogni X e Y. A proposito, i termini del modello sono solo x, y e il termine incrociato x*y. Quindi, sfortunatamente, il Custom Design non funziona.
La piattaforma Full Factorial DOE non funzionerà perché vuole eseguire 100 esecuzioni (10x10 fattoriale) e abbiamo solo 16 esecuzioni (tentativi) ciascuna.
La piattaforma RSM DOE funziona solo sui livelli alto/basso e inserendo 1 e 10 per i livelli basso/alto. Le opzioni di progettazione del CCD non riempiono davvero lo spazio della griglia 10 per 10 in cui verrebbero posizionate le "navi" - troppe piste centrali per coprire lo spazio della griglia.
L'unica altra piattaforma applicabile a questo sarebbe lo Space Filling Design. Usando le stesse impostazioni basso/alto, 1/10 per xey e "Hit" come risposta (questo sarebbe binario, 0/1 per no/sì), posso ottenere una tabella DOE con accoppiamenti (x,y) che riempiono lo spazio della griglia. Non sono sicuro di quale sarebbe la scelta migliore per i metodi di progettazione del riempimento dello spazio, FFF o Uniform, o Latin Hypercube, ecc.
Penso che la cosa più importante sia che il DOE è fisso, non è "adattabile" nel senso che in base al risultato della prima esecuzione, come verrebbe modificato il DOE per tenere conto delle informazioni note. Usando le coordinate della barca a 3 unità dall'alto, diciamo che la mia prima corsa è chiamare le coordinate (3,4) e ottengo un successo. Conoscendo la disposizione delle "navi" come orizzontale o verticale, la mia prossima chiamata non sarebbe seguire affatto il DOE, ma piuttosto chiamare (3,5), (3,3), (2,4) , o (4,4) -- aumenterei x o y di un'unità e vedrei qual è il risultato. E così via fino a quando la barca non viene affondata o si passa alla successiva coordinata di partenza possibile.
Mi piacerebbe trovare un metodo più scientifico per generare un DOE adattivo in grado di ottimizzare le 16 esecuzioni per generare "hit". Uscire da un DOE statico non lo farà perché dopo ogni corsa, una coordinata viene "esaurita" e imparo se è un successo o meno. Ciascuna corsa informa la n+1 corsa successiva. Per quanto ne so, non esiste un DOE in grado di gestire qualcosa del genere, ma non sono nemmeno un esperto in questo campo.
La selezione casuale di un punto di partenza è la migliore che si possa fare in "Battleship"? Non credo, ma sto avendo difficoltà a capire come avere un DOE adattivo che fondamentalmente contiene affermazioni "if/then" in modo da ottimizzare l'uso dei miei 16 tentativi tenendo conto delle informazioni da il passaggio precedente. Sarebbe bello avere un DOE "adattabile" che ottimizzerebbe le tue scelte per ogni corsa in modo da massimizzare le tue possibilità di vincere in 16 tentativi.
Grazie per la discussione!,
ds
PS, cercando JMP e "Battleship", ho trovato questo inviare di @Jordan_Hiller che mostra come JMP può essere utilizzato per giocare a diversi giochi, e @brady_brady ha scritto il codice JSL per giocare effettivamente a "Battleship". Molto bello! Presto scaricherò quel JSL!
Ciao @Jordan_Hiller ,
Grazie per il link al blog, l'articolo mi è piaciuto.
In genere capisco il concetto alla base di come hanno calcolato la probabilità che una nave si trovi in un determinato quadrato: questo sarebbe diverso per ogni tipo di nave. Tuttavia, poiché lo stato di probabilità per il tabellone cambia dopo ogni round di gioco, la scelta per la casella successiva su cui sparare cambia, che per me non è altro che un progetto di riempimento dello spazio riottimizzato che tiene conto di colpi/mancati/ dimensione della barca/e numero di corse rimaste.
Il poster del blog è stato in grado di generare un algoritmo che può con il gioco in 34 mosse, che è esattamente il doppio del numero di caselle occupate dalle barche. Presumibilmente, sarebbe possibile generare un percorso decisionale ottimale che potrebbe avvicinare a 17 il numero di mosse necessarie per vincere. Forse non esattamente 17, ma molto vicini.
Certamente un approccio ML/AI può costruire un algoritmo per vincere la partita, ma sono d'accordo, è eccessivo e non quello che sto veramente cercando. Sono più interessato forse a una miscela di ciò che ha fatto la persona del blog e all'utilizzo di un DOE. Chiaramente la funzione di densità di probabilità per il tabellone di gioco è fondamentale nel prendere decisioni. Ma si potrebbe modificarlo da un calcolo puramente probabilistico a uno basato su un riempimento dello spazio ottimizzato, quasi come alimentare la funzione di probabilità del tabellone come funzione di "ponderazione" per il DOE in modo tale che il DOE generi i risultati più probabili. Mi sembra che generare prima il numero di colpi più alto e poi concentrarsi sull'affondamento porterebbe a una vittoria più rapida rispetto a come l'ha fatto il blogger, che consisteva nel concentrarsi prima sull'affondamento di una nave prima di passare alla modalità di caccia.
Ad ogni modo, l'ho trovato interessante da considerare e riflettere, e a quanto pare anche altri lo hanno fatto!
Grazie!,
ds
Idea divertente, Diedrich!
Ecco un vecchio post sul blog su questo argomento, qualcuno ha capito come calcolare la probabilità che una nave si trovi su ogni quadrato della griglia per un dato stato di gioco. https://www.datagenetics.com/blog/dicember32011/ Dopodiché, non hai nemmeno bisogno di un modello, puoi semplicemente scegliere il quadrato più probabile. Ci sono anche alcuni progetti di machine learning là fuori, ma sembra eccessivo!
Giordania
