View Full Version : [Task 9.1] 71104 Vs. TigerShark Pair Reloaded
^TiGeRShArK^
25-01-2006, 21:23
Allora..
dopo tutte 'ste incomprensioni finalmente abbiamo deciso di iniziare stasera..
e io spero anche di finire dato che nei prox giorni non posso...:mbe:
a tra poco a tutti i nostri internet-ascoltatori! :D
^TiGeRShArK^
25-01-2006, 22:21
Allora..
dopo un'accesa discussione abbiamo deciso di seguire il suggerimento di fek e di fare estendere inizialmente alla calsse Chest il tipo Gem.
Questo ha alcune conseguenze...
a quanto abbiamo capito i test per la creazione dei Chest e per tutti i metodi in comune con la classe Gem sono già testati, quindi la prima parte del nostro task consiste in un semplice refactoring.
Invece per la seconda parte dovremo testare che la probabilità di estrazione dei Chest sia quella voluta....
Per questo direi che ci sono essenzialmente due test fondamentali:
1)Che i Chest vengano generati in media alla frequenza voluta
2)Che due Chest consecutivi non possano uscire (è corretta quest'assunzione???Joc, Vic, Fek????)
secondo me si, il secondo punto è esatto.
2)Che due Chest consecutivi non possano uscire (è corretta quest'assunzione???Joc, Vic, Fek????)
No, non devono uscire due chest dello stesso tipo consecutivi...guardate l'ltimo post di Jocchan nel thread delal storia 9...
^TiGeRShArK^
25-01-2006, 22:56
ecco il codice del primo test:
public void TestChestType()
{
assertTrue("EMERALD_CHEST is not correctly recognized as a Chest", GemType.EMERALD_CHEST.isChest());
assertTrue("RUBY_CHEST is not correctly recognized as a Chest", GemType.RUBY_CHEST.isChest());
assertTrue("SAPPHIRE_CHEST is not correctly recognized as a Chest", GemType.SAPPHIRE_CHEST.isChest());
assertTrue("TOPAZ_CHEST is not correctly recognized as a Chest", GemType.TOPAZ_CHEST.isChest());
assertTrue("DIAMOND_CHEST is not correctly recognized as a Chest", GemType.DIAMOND_CHEST.isChest());
assertFalse("EMERALD is not correctly recognized as a Gem", GemType.EMERALD.isChest());
assertFalse("RUBY is not correctly recognized as a Gem", GemType.RUBY.isChest());
assertFalse("SAPPHIRE is not correctly recognized as a Gem", GemType.SAPPHIRE.isChest());
assertFalse("TOPAZ is not correctly recognized as a Gem", GemType.TOPAZ.isChest());
assertFalse("DIAMOND is not correctly recognized as a Gem", GemType.DIAMOND.isChest());
}
ok, ed ecco come è diventata la classe GemType:
public final class GemType
{
public static final GemType EMERALD = new GemType("emerald", 40, false);
public static final GemType RUBY = new GemType("ruby", 50, false);
public static final GemType SAPPHIRE = new GemType("sapphire", 60, false);
public static final GemType TOPAZ = new GemType("topaz", 80, false);
public static final GemType DIAMOND = new GemType("diamond", 100, false);
public static final GemType EMERALD_CHEST = new GemType("emerald", 40, true);
public static final GemType RUBY_CHEST = new GemType("ruby", 50, true);
public static final GemType SAPPHIRE_CHEST = new GemType("sapphire", 60, true);
public static final GemType TOPAZ_CHEST = new GemType("topaz", 80, true);
public static final GemType DIAMOND_CHEST = new GemType("diamond", 100, true);
private final String name;
private final int score;
private final boolean isChest;
GemType(String name, int score, boolean isChest)
{
this.name = name;
this.score = score;
this.isChest = isChest;
}
public String name()
{
return name;
}
public int score()
{
return score;
}
public boolean isChest()
{
return isChest;
}
}
ora, spiegazione: siccome ci è stato richiesto di derivbare una classe Chest da Gem, io e TigerShark abbiamo deciso di implementare quel metodo per capire quand'è che il metodo statico Gem.create deve creare un oggetto Gem e quand'è che deve creare Chest, in base a cosa ritorna il metodo isChest dall'oggetto gemType passato come parametro a create.
ora ci sarebbe da testare se create in base a cosa viene ritornato da isChest capisce se creare un oggetto Gem o un oggetto Chest, e la cosa riesce un po' difficoltosa a causa del fatto che in Java che io sappia non è direttamente possibile ricavare RTTI sul tipo di un oggetto, quindi penso di aggiungere un metodo virtuale isChest anche in Gem e di sovrascriverlo in Chest; fek e vic, se pensate che non ne valga la pena fermateci e reverteremo. :)
intanto scrivo il test per questo metodo che TigerShark implementerà.
prossimi test:
public void testGemIsNotChest()
{
Gem gem = Gem.createForTesting();
assertFalse(gem.isChest());
}
public void testChestIsChest()
{
Gem gem = Chest.createForTesting();
assertTrue(gem.isChest());
}
questi due test servono a testare che isChest funzioni correttamente e che sia un metodo virtuale.
ora, spiegazione: siccome ci è stato richiesto di derivbare una classe Chest da Gem, io e TigerShark abbiamo deciso di implementare quel metodo per capire quand'è che il metodo statico Gem.create deve creare un oggetto Gem e quand'è che deve creare Chest, in base a cosa ritorna il metodo isChest dall'oggetto gemType passato come parametro a create.
Ti spezzo un braccio se ci provi. (Adoro le minacce fisiche :p)
Evitare metodi tipo isChest(), getType(), etc etc, sono l'esatto motivo per il quale esistono praticamente meta' dei Design Pattern. Trovate sicuramente un modo alternativo (un factory method in GemType?).
prossimi test:
public void testGemIsNotChest()
{
Gem gem = Gem.createForTesting();
assertFalse(gem.isChest());
}
public void testChestIsChest()
{
Gem gem = Chest.createForTesting();
assertTrue(gem.isChest());
}
questi due test servono a testare che isChest funzioni correttamente e che sia un metodo virtuale.
REVEEEEEEEEEEEEEEEEEEEEERT!
Fek...ma tu quindi la Reflection la usi?? :D
^TiGeRShArK^
25-01-2006, 23:54
è stata colpa mia ke avrei dovuto pensarci avendolo usato un paio di volte questo pattern....
ma stasera sono proprio fuso :muro:
:cry:
eh...? :|
non ho capito cos'è che non devo fare... O_o'
che tipo di metodi devo evitare?
mi sembrava una soluzione semplicissima quella che avevo inventato... o_O' e funzionava pure...
TigerShark dice di aver capito che dobbiamo cambiare e fare in modo che Gem e Chest derivino da una stessa classe di base, ma... non eri stato tu a imporci di derivare Chest da Gem??? :|
boh, a me sembrava che andasse tutto liscio... che dobbiamo fare di preciso?
AAAAAAAAAAHHHHHHHHHHHHHHH FERMIHOCAPITOTUTTO!!! :D
Scusatemi... Dal momento in cui avete GemType.isChest() cosa ve ne fate della derivazione? Tenete la classe Gem ormai no?
^TiGeRShArK^
25-01-2006, 23:58
....mi sa ke io sono OUT..... :cry:
stasera nn capisco piu' niente e nei prox giorni sono a reggio....:(
ke si fa?
TigerShark, ricominciamo daccapo, e stavolta andremo più veloci; allora, ho capito il democratico suggerimento di fek, dobbiamo cancellare isChest e mettere un public static Gem createByType, giusto? :)
scrivo il test...
Scusatemi... Dal momento in cui avete GemType.isChest() cosa ve ne fate della derivazione? Tenete la classe Gem ormai no? no, serviva anche la derivazione, altrimenti era tutto più complesso, ma adesso cambiamo tutto.
^TiGeRShArK^
26-01-2006, 00:03
C'è un volontario x continuare con 71104 ke io nei prox giorni non ci sarò???
Io prima di sabato niente mi spiace :p
le cose si complicano: a TigerShark è caduta nuovamente la linea e a me per continuare serve di sapere la sintassi di instanceof, che serve in Java per ricavare RTTI; lo devo usare per forza nei test se non devo fare metodi virtuali, altrimenti il metodo statico Gem.create rimarrà non testato...
siccome s'è fatto tardi è meglio continuare domani, faccio un commit per essere sicuri che la codebase non contenga quei metodi virtuali che avevamo iniziato a scrivere.
serve un altro partner -.-'
le cose si complicano: a TigerShark è caduta nuovamente la linea e a me per continuare serve di sapere la sintassi di instanceof, che serve in Java per ricavare RTTI; lo devo usare per forza nei test se non devo fare metodi virtuali, altrimenti il metodo statico Gem.create rimarrà non testato...
siccome s'è fatto tardi è meglio continuare domani, faccio un commit per essere sicuri che la codebase non contenga quei metodi virtuali che avevamo iniziato a scrivere.
Ragazzi, ne parliamo domani, ci si sta complicando la vita inutilmente. Niente reflection, niente isChest in Gem, niente instanceof, niente RTTI.
A che serve il polimorfismo se poi volete decidere la differenza di comportamento fra una Gem e un Chest con un if su un metodo isChest()? Assolutamente a nulla.
La differenza di comportamento va codificata nella differenza di implementazione di uno o piu' metodi fra le due classi. Grid non deve fare nulla di questo tipo:
if (gem.isChest())
{
// comportamento di Chest
}
else
{
// comportamento di Gem
}
Ma solo questo:
gem.doSomething();
Togliere quell'if e' l'essenza del concetto di polimorfismo. E noi di Diamonds che programmiamo bene sappiamo queste cose e non commettiamo questi errori :)
Non avevo mica prorposto la reflection...se lo facessi per una cosa del genere sarei un pazzo!!! :Prrr:
E' solo che leggendo getType mi è venuta in mente e ho fatto una domanda che già da tempo mi ronzava nella testa... :cool: e alla quale non hai risposto :mad: ( :D )
Comunque secondo me il problema di fondo è che non si è capito come portare avanti questo task: bisogna fattorizzare adesso o dopo che il task è completato?!?!
Perchè se bisogna fattorizzare adesso...bhè si può già pensare al famoso droppableObject. ;)
Altrimenti si aggiungono delle gemme con una texture che casualmente è un baule e si modifica GemFactory perchè le gemme di vario tipo abbiamo probabilità prefissate. :O
Domani alle 12:30 circa sono a casa...collaboro per qualsiasi cosa !!!
Vedendo la "lentezza" con cui procediamo, probabilmente questa è la storia più difficile che abbiamo incontrato...anche perchè abbiamo ancora i rimasugli di BigGem...e quindi non mi perdo neanche un task!!!! :D ;)
Ragazzi, ne parliamo domani, ci si sta complicando la vita inutilmente. Niente reflection, niente isChest in Gem, niente instanceof, niente RTTI.
A che serve il polimorfismo se poi volete decidere la differenza di comportamento fra una Gem e un Chest con un if su un metodo isChest()? Assolutamente a nulla.
La differenza di comportamento va codificata nella differenza di implementazione di uno o piu' metodi fra le due classi. Grid non deve fare nulla di questo tipo:
if (gem.isChest())
{
// comportamento di Chest
}
else
{
// comportamento di Gem
}
Ma solo questo:
gem.doSomething();
Togliere quell'if e' l'essenza del concetto di polimorfismo. E noi di Diamonds che programmiamo bene sappiamo queste cose e non commettiamo questi errori :) il problema è che quell'if noi volevamo metterlo nel metodo statico Gem.create, il quale deve capire quand'è che deve istanziare un Gem e quando un Chest; adesso che mi suggerisci la storia del factory method in GemType per me va benissimo, ma c'è un problema: come facciamo da dentro GemType a decidere se istanziare un Gem o un Chest? con un mega-switch sul nome del diamante?? puoi anche trovare una soluzione migliore (ad esempio un index passato al costruttore di GemType riferito a un array statico di stringhe contenenti i nomi delle gemme), ma ti assicuro che in un modo o nell'altro quell'if ci va per forza... ;)
altrimenti il programma non è in grado di istanziare bauli.
Domani alle 12:30 circa sono a casa...collaboro per qualsiasi cosa !!!
Vedendo la "lentezza" con cui procediamo, probabilmente questa è la storia più difficile che abbiamo incontrato...anche perchè abbiamo ancora i rimasugli di BigGem...e quindi non mi perdo neanche un task!!!! :D ;) le storie più complicate che abbiamo sai quali sono? quelle in cui si devono fare decisioni di design! :cry:
e siccome a fare i pair programming (cioè i task difficili, comprensivi di decisioni di design) sono quasi sempre io, alla fine toccano sempre a me! :cry:
comunque mi ci diverto anche :D
ok, ho trovato l'altro pair programmer in sostituzione di TigerShark :)
a domani Bonfo ;)
Sto andando a letto... :coffee: :ronf:
Prima di potermi considerare l'altro pair programmer aspetterei l'approvazione.
Io sono già prenotatoper il 9.1.3. e poi c'è anche il 9.1.2 che, per adesso non fa nessuno, sul quale ho comunicato una mia possibile disponibilità... :confused: ...non è che poi si incacchiano che voglio arraffare tutto :stordita:
:ot:
Un'altra domanda: non sapevo che volesse dire RTTI..ora lo so (Run Time Type Information). Ma è la stessa cosa delle reflection o no?
public static final GemType EMERALD_CHEST = new GemType("emeraldchest", 40);
public static final GemType RUBY_CHEST = new GemType("rubychest", 50);
public static final GemType SAPPHIRE_CHEST = new GemType("sapphirechest", 60);
public static final GemType TOPAZ_CHEST = new GemType("topazchest", 80);
public static final GemType DIAMOND_CHEST = new GemType("diamondchest", 100);
Per il vostro task...l'unico che deve discriminare se creare un chest o una gem è GemFactory con il 90% di probabilità ;)
Poi sarà chi si occupa del task successivo a pensare come discriminare se è una gemam o una chest e se bisogna o meno fare eliminazioni...
Sto andando a letto... :coffee: :ronf:
Prima di potermi considerare l'altro pair programmer aspetterei l'approvazione.
Io sono già prenotatoper il 9.1.3. e poi c'è anche il 9.1.2 che, per adesso non fa nessuno, sul quale ho comunicato una mia possibile disponibilità... :confused: ...non è che poi si incacchiano che voglio arraffare tutto :stordita:
:ot:
Un'altra domanda: non sapevo che volesse dire RTTI..ora lo so (Run Time Type Information). Ma è la stessa cosa delle reflection o no?
Bonfo i task vanno portati a termine... Se nessuno si è proposto per i task (e sono lì da qualche giorno) vuol dire che nessuno ha il tempo da dedicarci in questo periodo... Secondo me non c'è problema se te ne fai 3 o 7 l'importante è che vengano portati a termine... Specialmente il task 9.1.1 che blocca tutto il resto :)
La reflection è una API che viene viene usata solo per scrivere software per debugging (ES. JUnit da qualche parte usa la reflection se non erro...). Il RTTI è semplicemente, come dice la parola, l'identificazione del tipo in real-time...
Ora guardo se c'è qualcosa su wikipedia...
http://en.wikipedia.org/wiki/Reflection_API
http://en.wikipedia.org/wiki/RTTI
public static final GemType EMERALD_CHEST = new GemType("emeraldchest", 40);
public static final GemType RUBY_CHEST = new GemType("rubychest", 50);
public static final GemType SAPPHIRE_CHEST = new GemType("sapphirechest", 60);
public static final GemType TOPAZ_CHEST = new GemType("topazchest", 80);
public static final GemType DIAMOND_CHEST = new GemType("diamondchest", 100);
Per il vostro task...l'unico che deve discriminare se creare un chest o una gem è GemFactory con il 90% di probabilità ;)
Poi sarà chi si occupa del task successivo a pensare come discriminare se è una gemam o una chest e se bisogna o meno fare eliminazioni...
Infatti... secondo me non bisogna introdurre la nuova classe Chest in questo task... Basta che la creazione avvenga con il rapporto giusto "Gem / Chest"
Infatti... secondo me non bisogna introdurre la nuova classe Chest in questo task... Basta che la creazione avvenga con il rapporto giusto "Gem / Chest" omg :cry:
allora, facciamo così: riformulateci il task in maniera più precisa e definitiva e io lo svolgerò con Bonfo.
@cionci: se quell'if fosse andato a finire nel metodo statico create come io e TigerShark avevamo pensato, poi non sarebbe stato necessario in GemFactory, e ciononostante si sarebbe potuto progettare un algoritmo corretto che distribuisse "uniformemente" la probabilità con il 90% alle gemme e 10% ai bauli (almeno tutto imho).
PS: ho notato che hai evidenziato i nomi errati che avevamo messo nel codice: ad essere precisi erano errati anche i punteggi, comunque ormai quel codice non c'è più :D
Secondo me è un task davvero banale... Ti dico il mio parere:
In GemFactory:
Gemme e Chest in due array separati
createRandomGem crea una Gem a random partendo dall'array di GemTypes
createRandomChest crea una Chest a random partendo dall'array di ChestTypes
Credo che i test per createRandomChest puoi imitarli da quelli per createRandomGem.
ti implementi un bel createRandomDroppable che al 90% delle volte chiama createRandomGem ed al 10% createRandomChest.
Niente inheritance per voi. Ci penseranno gli altri task.
p.s. Onde evitare incomprensioni io ovviamente parlo di implementazione ma sottintendo prima i test :)
Se sei online in questo momento mi smessaggi su MSN e lo facciamo in pair io e te sennò aspetta Bonfo...
^TiGeRShArK^
26-01-2006, 12:43
omg :cry:
allora, facciamo così: riformulateci il task in maniera più precisa e definitiva e io lo svolgerò con Bonfo.
@cionci: se quell'if fosse andato a finire nel metodo statico create come io e TigerShark avevamo pensato, poi non sarebbe stato necessario in GemFactory, e ciononostante si sarebbe potuto progettare un algoritmo corretto che distribuisse "uniformemente" la probabilità con il 90% alle gemme e 10% ai bauli (almeno tutto imho).
PS: ho notato che hai evidenziato i nomi errati che avevamo messo nel codice: ad essere precisi erano errati anche i punteggi, comunque ormai quel codice non c'è più :D
ma i punteggi erano giusti...
era stato jocchan a dire che dovevano avere punteggio nullo...:mbe:
Secondo me è un task davvero banale... Ti dico il mio parere:
In GemFactory:
Gemme e Chest in due array separati
createRandomGem crea una Gem a random partendo dall'array di GemTypes
createRandomChest crea una Chest a random partendo dall'array di ChestTypes
Mi piace.
Eccomi qua...anzie eccoci qua.
Sostituisco ufficialmente ^TiGeRShArK^ .
Comunico la compresenza, gradita, di Ufo oltre a me e a 71104
Primo test, aggiunto a TestGemFactory:
public void testChestCreation()
{
Gem gem = factory.create(DIAMOND_CHEST);
assertEquals("does not return Chest of type diamond", DIAMOND_CHEST,
gem.getType());
gem = factory.create(RUBY_CHEST);
assertEquals("does not return Chest of type ruby", RUBY_CHEST,
gem.getType());
gem = factory.create(SAPPHIRE_CHEST);
assertEquals("does not return Chest of type sapphire", SAPPHIRE_CHEST,
gem.getType());
gem = factory.create(EMERALD_CHEST);
assertEquals("does not return Chest of type emerald", EMERALD_CHEST,
gem.getType());
gem = factory.create(TOPAZ_CHEST);
assertEquals("does not return Chest of type topaz", TOPAZ_CHEST,
gem.getType());
}
Serve a testare che la factory sia in grado di generare dei Chest.
Ci tengo a sottolineare le forti assunzioni di questo test: i Chest non sono altro che gemme e l'unica cos che cambia è il tipo di gemma.
Se è sbagliato...siamo già fermi al primo test :D
In ogni caso io continuerei fino a terminarlo...poi REFACTORING!!!
^TiGeRShArK^
26-01-2006, 13:39
Eccomi qua...anzie eccoci qua.
Sostituisco ufficialmente ^TiGeRShArK^ .
vai e fatti onore :O
:D
ecco qua, l'ho fatto passare così:
public final class GemType
{
public static final GemType EMERALD = new GemType("emerald", 40);
public static final GemType RUBY = new GemType("ruby", 50);
public static final GemType SAPPHIRE = new GemType("sapphire", 60);
public static final GemType TOPAZ = new GemType("topaz", 80);
public static final GemType DIAMOND = new GemType("diamond", 100);
public static final GemType EMERALD_CHEST = new GemType("boxes/emerald", 0);
public static final GemType RUBY_CHEST = new GemType("boxes/ruby", 0);
public static final GemType SAPPHIRE_CHEST = new GemType("boxes/sapphire", 0);
public static final GemType TOPAZ_CHEST = new GemType("boxes/topaz", 0);
public static final GemType DIAMOND_CHEST = new GemType("boxes/diamond", 0);
[...]
ok, adesso stando a quanto detto da Ufo13, dobbiamo procedere così:
public void testRandomChestSequence()
{
Gem gem = factory.createRandomChest();
assertEquals("does not return Chest of type topaz", TOPAZ_CHEST,
gem.getType());
gem = factory.createRandomChest();
assertEquals("does not return Chest of type diamond", DIAMOND_CHEST,
gem.getType());
gem = factory.createRandomChest();
assertEquals("does not return Chest of type diamond", DIAMOND_CHEST,
gem.getType());
gem = factory.createRandomChest();
assertEquals("does not return Chest of type ruby", RUBY_CHEST,
gem.getType());
gem = factory.createRandomChest();
assertEquals("does not return Chest of type ruby", RUBY_CHEST,
gem.getType());
gem = factory.createRandomChest();
assertEquals("does not return Chest of type sapphire", SAPPHIRE_CHEST,
gem.getType());
}
vediamo che succede... :D
a te Bonfo
era stato jocchan a dire che dovevano avere punteggio nullo...:mbe:
Infatti i bauli devono avere punteggio nullo :mbe:
Infatti i bauli devono avere punteggio nullo :mbe: eh, solo che io per errore ieri facendo un banale copia-incolla non avevo messo punteggio nullo, avevo messo lo stesso punteggio delle gemme corrispondenti... :mbe:
Modificata GemFactory:
private static final GemType CHEST_TYPES[] = { DIAMOND_CHEST, RUBY_CHEST, SAPPHIRE_CHEST, EMERALD_CHEST, TOPAZ_CHEST };
public Gem createRandomChest()
{
int module = CHEST_TYPES.length - 1;
if(firstExtraction)
{
module = CHEST_TYPES.length;
firstExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= secondRandomGemIndex)
{
randomIndex = (randomIndex + 1) % CHEST_TYPES.length;
}
secondRandomGemIndex = firstRandomGemIndex;
firstRandomGemIndex = randomIndex;
return create(CHEST_TYPES[randomIndex]);
}
Green
ragazzi non capisco a cosa serve firstExtraction... c'era anche prima lo so
Ok...prossimo test per controllare che le percentuali di creazione siano del 90 e 10 rispettiavamente per Gem e Chest:
public void testCorrectGemAndChestProportion()
{
int[] percentages={0,1,89,1,90,1,99,1};
factory = GemFactory.createForTesting(new MockRandomGenerator(percentages));
Gem gem=factory.createRandomDroppable();
assertFalse("does not return a Gem", gem.getType().isChest() );
gem=factory.createRandomDroppable();
assertFalse("does not return a Gem", gem.getType().isChest() );
gem=factory.createRandomDroppable();
assertTrue("does not return a Chest", gem.getType().isChest() );
gem=factory.createRandomDroppable();
assertTrue("does not return a Chest", gem.getType().isChest() );
}
...speriamo vada bene.
Sotto col codice :D
ragazzi non capisco a cosa serve firstExtraction... c'era anche prima lo so come non quotare... :D
chiedi a cionci ;)
ragazzi non capisco a cosa serve firstExtraction... c'era anche prima lo so
Perchè nella prima estrazione la popolazione deve essere pari a "tutte le gemme"...mentre nella seconda deve essere "tutte le gemme meno quella che non dobbiamo estrarre"... La cardinalità di "tutte le gemme" è N, quella di "tutte le gemme meno quella che non dobbiamo estrarre" è pari a N-1...
Se tiriamo fuori le estrazioni successive da una popolazione pari a N dobbiamo aumentare di 1 se la gemma è uguale a quella che non può essere estratta... NO, è un procedimento errato in quanto c'è un elemento che avrebbe probabilità 2/N di essere estratto, mentre gli altri avrebbero probabilità 1/N (ve lo assicuro che si notava nella sequenza delle gemme estratte che c'era qualcosa che non andava)...
Ora succede questo:
Popolazione prima estrazione: 1 2 3 4 5 (firstExtraction serve proprio per questo caso)
Popolazione successive estrazioni 1 2 3 4
Mettiamo che la penultima gemma estratta sia 2, quindi se la gemma estratta è maggiore o uguale a 2 ne verrà incrementato di 1 il valore, la nuova estrazione è stata di fatto su una popolazione composta da: 1 3 4 5
in questo modo si mantiene una probabilità uguale per TUTTE le gemme...
Attenzione che se mantenete first e secondRandomGemExtracted così come sono un diamond_chest non potrà essere estratto dopo un diamond_gem e viceversa...
Lo so cionci...ma i test passavano ;)
Quindi mi sa che dobbiamo fare un test anche su quello. :(
Cionci capisco che è corretto così ma non sarebbe più semplice un:
"continua ad estrarre finchè estrai una gemma diversa da quella che non dobbiamo estrarre"
Così mi pare complicato da interpretare ed introduce un po' tante variabili... IMHO eh :p
edit: effettivamente capisco che così ci togliamo il problema del caso sfortunato in cui infinitamente estrae la stessa gemma...
A parte che introduce solo la variabile firstExtraction... non vedo quale altra variabile ci sia in più....forse module, ma è locale...
"continua ad estrarre finchè estrai una gemma diversa da quella che non dobbiamo estrarre"
Lo sai vero che in teoria può essere un ciclo infinito ? A me hanno sempre insegnato a non mettere mai un ciclo del genere... Senza contare che in questo modo sputtani la randomicità (finta) del generatore pseudocasuale...
Cerco di rispiegare...così forse riesco a farvi capire meglio:
popolazione = N-1;
Se è la prima estrazione: popolazione = N;
numero = estrai(popolazione);
Se numero >= numero_che_non_può_essere_estratto: numero++;
Le altre variabili servono comunque ad ogni costo...indipendentemente dall'estrarre nuovamente un numero o dal togliere firstExtraction...
Poi se a fek va bene...ben venga...
cionci, ora ho capito perfettamente il motivo percui hai usato la variabile firstExtraction, ma non puoi lasciare non testato un aspetto del codice: è giusto che il programma funzioni così, ma la cosa deve essere formalizzata; se non riesci a fare un test per quell'aspetto ci provo io quando finisco questo task :)
Al fatto del ciclo infinito ci sono arrivato e sono d'accordo con te però il metodo mi pare un po' complicato ora come ora... vabè vediamo...
firstRandomIndex non mi pare serva... e poi non ho ancora capito perchè se è >= dell'indice incrementa...
Cioè mi sono spiegato male... Non capisco il ruolo di first e second...
Al fatto del ciclo infinito ci sono arrivato e sono d'accordo con te però il metodo mi pare un po' complicato ora come ora... vabè vediamo...
firstRandomIndex non mi pare serva... e poi non ho ancora capito perchè se è >= dell'indice incrementa...
Popolazione prima estrazione: 1 2 3 4 5 (firstExtraction serve per dare una popolazione pari a N elementi nella prima estrazione)
Popolazione successive estrazioni: 1 2 3 4
Mettiamo che la penultima gemma estratta sia 2, quindi se la gemma estratta è maggiore o uguale a 2 ne verrà incrementato di 1 il valore, la nuova estrazione è stata di fatto su una popolazione composta da: 1 3 4 5
in questo modo si mantiene una probabilità uguale per TUTTE le gemme...
ma non puoi lasciare non testato un aspetto del codice: è giusto che il programma funzioni così, ma la cosa deve essere formalizzata;
Sono d'accordo...ma credo che trovare un modo per formalizzarla sia molto complicato...
codice per risolvere il precedente test:
public Gem createRandomDroppable()
{
if (randomGenerator.extract(100) >= 90)
{
return createRandomChest();
}
else
{
return createRandomGem();
}
}
prossimo test:
public void testSameIndexForGemAndChest()
{
int[] percentages={1, 0, 1};
factory = GemFactory.createForTesting(new MockRandomGenerator(percentages));
Gem gem = factory.createRandomGem();
assertSame(gem.getType(), RUBY);
factory.createRandomGem();
gem = factory.createRandomChest();
assertSame(gem.getType(), RUBY_CHEST);
}
Cioè mi sono spiegato male... Non capisco il ruolo di first e second...
E' una specie di coda FIFO...di dimensione due... Quando viene estratto un elemento esce il più vecchio (che è in second...), ed entra l'ultimo elemento estratto in first...
Serve appunto per fare in modo che il nuovo elemento estratto sia diverso dal penultimo estratto (e non dall'ultimo, altrimenti bastava una sola variabile)...
71104: quando avete finito testa che sia possibile estratte un diamond_gem dopo un diamond_chest
Popolazione prima estrazione: 1 2 3 4 5 (firstExtraction serve per dare una popolazione pari a N elementi nella prima estrazione)
Popolazione successive estrazioni: 1 2 3 4
Mettiamo che la penultima gemma estratta sia 2, quindi se la gemma estratta è maggiore o uguale a 2 ne verrà incrementato di 1 il valore, la nuova estrazione è stata di fatto su una popolazione composta da: 1 3 4 5
in questo modo si mantiene una probabilità uguale per TUTTE le gemme...
perchè >= e non == ?
Le gemme precedenti hanno probabilità maggiore di uscire rispetto a quelle successive così o no?
mi spiego meglio... se la gemma che non deve uscire è la nr 3. se esce 4 diventa 5 se esce 5 diventa la 0. Ma se esce 0 rimane 0. Quindi la 0 ha probabilità doppia di uscire!!! Giusto?
71104: quando avete finito testa che sia possibile estratte un diamond_gem dopo un diamond_chest l'ho appena testato :)
adesso Bonfo deve risolvere...
mi spiego meglio... se la gemma che non deve uscire è la nr 3. se esce 4 diventa 5 se esce 5 diventa la 0. Ma se esce 0 rimane 0. Quindi la 0 ha probabilità doppia di uscire!!! Giusto?
ahhh no perchè c'è il -1 nel module... ho capito... però continuo a non essere sicuro sul firstGemExtraction e secondGemExtraction... boh :p
e ora ho capito anche quelli... però ora li rinomino :p
mi spiego meglio... se la gemma che non deve uscire è la nr 3. se esce 4 diventa 5 se esce 5 diventa la 0. Ma se esce 0 rimane 0. Quindi la 0 ha probabilità doppia di uscire!!! Giusto?
Sì questo se la popolazione fosse N...ma grazie a firstExtraction la setto a N-1...quindi 5 non può uscire ;)
Se la gemma estratta è la 3 e N = 5 (quindi al massimo posso estrarre 4) di fatto la popolazione su cui estraggo è: 0, 1, 2, 4
Infatti passando al random generator N-1 (cioè 4) posso tirare fuori N-1 numeri da 0 a 3...ma se l'ultima gemma estratta è 3, tutti i numeri che posso estrarre >= 3 vengono incrementati...quindi mi riporto in una situazione corretta, esattamente come sopra: 0, 1, 2, 4...
sìsì capito tutto... era il first ed il second che non mi ritornava più che altro... ma ora ricordo anche che la gemma deve essere diversa non dall'ultima ma dalla penultima :)
ahhh no perchè c'è il -1 nel module... ho capito... però continuo a non essere sicuro sul firstGemExtraction e secondGemExtraction... boh :p
Nell'estrazione bisogna fare in modo che la gemma estratta debba essere DIVERSA, non dall'ultima estratta, ma dalla PENULTIMA gemma estratta... Come fare altrimenti te ?
PS: questa cosa è testata...
Modificata GemFactory:
private int firstGemRandomIndex = GEM_TYPES.length;
private int secondGemRandomIndex = GEM_TYPES.length;
private int firstChestRandomIndex = CHEST_TYPES.length;
private int secondChestRandomIndex = CHEST_TYPES.length;
private boolean firstGemExtraction = true;
private boolean firstChestExtraction = true;
Ora vengono usati indici differenti per createRandomGem e createRandomChest
public Gem createRandomGem()
{
int module = GEM_TYPES.length - 1;
if(firstGemExtraction)
{
module = GEM_TYPES.length;
firstGemExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= secondGemRandomIndex)
{
randomIndex = (randomIndex + 1) % GEM_TYPES.length;
}
secondGemRandomIndex = firstGemRandomIndex;
firstGemRandomIndex = randomIndex;
return create(GEM_TYPES[randomIndex]);
}
public Gem createRandomChest()
{
int module = CHEST_TYPES.length - 1;
if(firstChestExtraction)
{
module = CHEST_TYPES.length;
firstChestExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= secondChestRandomIndex)
{
randomIndex = (randomIndex + 1) % CHEST_TYPES.length;
}
secondChestRandomIndex = firstChestRandomIndex;
firstChestRandomIndex = randomIndex;
return create(CHEST_TYPES[randomIndex]);
}
Prossimo Test:
public void testNotTwoEqualChestSequence()
{
int[] percentages={1, 1};
factory = GemFactory.createForTesting(new MockRandomGenerator(percentages));
assertNotSame(factory.createRandomChest(),factory.createRandomChest());
}
Testate anche questa sequenza di estrazioni che DEVE funzionare: diamond_chest, diamond_gem, diamond_chest
Testate anche questa sequenza di estrazioni che DEVE funzionare: diamond_chest, diamond_gem, diamond_chest
Penso sia già testata con questo no?
public void testSameIndexForGemAndChest()
{
int[] percentages={1, 0, 1};
factory = GemFactory.createForTesting(new MockRandomGenerator(percentages));
Gem gem = factory.createRandomGem();
assertSame(gem.getType(), RUBY);
factory.createRandomGem();
gem = factory.createRandomChest();
assertSame(gem.getType(), RUBY_CHEST);
}
Secondo me no...basta provare ;)
Testate anche questa sequenza di estrazioni che DEVE funzionare: diamond_chest, diamond_gem, diamond_chest
Ah...nel mezzo ci puoi mettere anche un emerald o qualsiasi altra gemma o chest...l'importante è che il primo e il terzo siano un chest dello stesso tipo...
public Gem createRandomGem()
{
int module = GEM_TYPES.length - 1;
if(firstGemExtraction)
{
module = GEM_TYPES.length;
firstGemExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= secondGemRandomIndex)
{
randomIndex = (randomIndex + 1) % GEM_TYPES.length;
}
secondGemRandomIndex = firstGemRandomIndex;
firstGemRandomIndex = randomIndex;
return create(GEM_TYPES[randomIndex]);
}
public Gem createRandomChest()
{
int module = CHEST_TYPES.length - 1;
if(firstChestExtraction)
{
module = CHEST_TYPES.length;
firstChestExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= secondChestRandomIndex)
{
randomIndex = (randomIndex + 1) % CHEST_TYPES.length;
}
secondChestRandomIndex = firstChestRandomIndex;
firstChestRandomIndex = randomIndex;
return create(CHEST_TYPES[randomIndex]);
}
Ullalla' quanto bel codice duplicato. Urge refactoring alla fine del task.
che post? il numero 74; stavo per scrivere una sciocchezza, ma ho editato in tempo :p
mi spiego meglio... manca ancora un test per il task... Ovvero quello che testa che Grid inserisca una GemsPair con un Chest (o 2 :p )
mi spiego meglio... manca ancora un test per il task... Ovvero quello che testa che Grid inserisca una GemsPair con un Chest (o 2 :p ) ok, allora mettiamo questo affare in TestGemQueue :)
public void testGemQueueCreatesChestsToo()
{
int mockValues[] = {0, 1, 99, 1};
MockRandomGenerator randomGenerator = new MockRandomGenerator(mockValues);
gemQueue = GemQueue.createForTesting(randomGenerator);
gemQueue.fillQueueRandomly();
assertSame(gemQueue.extract().getType(), RUBY);
assertSame(gemQueue.extract().getType(), RUBY_CHEST);
}
Testate anche questa sequenza di estrazioni che DEVE funzionare: diamond_chest, diamond_gem, diamond_chest
Ah...nel mezzo ci puoi mettere anche un emerald o qualsiasi altra gemma o chest...l'importante è che il primo e il terzo siano un chest dello stesso tipo...
Mi sento un po' ignorato :(
public void testChestGemChestSequence()
{
int indexes[] = {99, 1, 0, 4, 99, 1};
factory = GemFactory.createForTesting(new MockRandomGenerator(indexes));
GemType firstChest = factory.createRandomDroppable().getType();
factory.createRandomDroppable().getType();
GemType lastChest = factory.createRandomDroppable().getType();
assertSame("first chest was not of same type of last chest", firstChest, lastChest);
}
public void testGemGemChestGemSequence()
{
int indexes[] = {0, 1, 0, 2, 99, 3, 0, 1};
factory = GemFactory.createForTesting(new MockRandomGenerator(indexes));
GemType firstGem = factory.createRandomDroppable().getType();
factory.createRandomDroppable().getType();
factory.createRandomDroppable().getType();
GemType lastGem = factory.createRandomDroppable().getType();
assertSame("first Gem was not of same type of last Gem", firstGem, lastGem);
}
Questi test secondo me non devono fallire...
Oppure ve ne posso fornire un altro che fallisce:
DIAMOND - CHEST (qualsiasi) - DIAMOND - DIAMOND
Secondo me devono poter essere estratte queste sequenze...
Cionci fai update e dimmi che ne pensi :)
Può andare bene, ma nella sequenza precedente ho fatto un errore :stordita:
Intendevo questa:
DIAMOND - CHEST (qualsiasi) - GEMMA (qualsiasi) - DIAMOND
Ora...con la soluzione tua hai risolto esattamente quello che aveva scritto io...
Basta decidere se questa sequenza possa essere permessa o meno:
DIAMOND - CHEST (qualsiasi) - DIAMOND - DIAMOND
Mi sembra che comunque giocando renda molto bene anche così...che ne pensi ? Bello davvero :)
hmmm questo lo deve dire jocchan...
secondo me il livello di randomizzazione è buono ed abbiamo già complicato abbastanza il tutto... vediamo che dice Joc :)
hmmm questo lo deve dire jocchan...
Sono d'accordo !!! :)
certo che... ho preso 27 in statistica e lo sapevo già come rubato... Ora ne ho la conferma :D
edit: ok niente partita sfortunata :D
Ho provato l'ultimissima build, ed ancora non è possibile giudicare se l'occorrenza dei bauli è quella giusta. Potremo farlo solo alla fine della storia, quando le cancellazioni funzioneranno, e solo allora si potrà procedere per tutti i bilanciamenti necessari.
Per ora, quindi, avanti tutta. ;)
Eccomi qua tornato...scusate se ho lasciato tutto a metà, ma dovevo proprio scappare.
Penso che 71104 abbia già finito tutto il task, ma volevo chiedere se sono stati testati i punteggi nulli per i chest e se è stato testato l'inserimento dei chest in grid.
Per il test delle sequenze, sono d'accordissimo con Jocchan...c'è solo l'imbarazzo della scelta di che test fare per fare il tuning giusto delle probabilità.
@Fek: è stato duplicato "apposta" il codice di createRandomGem e createRandomChest per rendere chiaro il funzionamento e per soddisfare nella maniera più semplice i test...era ovvio che lì ci sarebbe stato un bel e grosso refactoring! ;)
Volevo ringraziare tutti...più che un PAIR è stato un ALL :D :D
Mi raccomando...sbizzaritevi coi test!! :p
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.