davide.fruci ha scritto:
Perché no?
Innanzitutto il concetto di mark/reset può essere supportato oppure no. C'è markSupported() che lo indica. E FileReader deliberatamente NON lo supporta (basta guardare i sorgenti del JDK o fare una prova veloce). Neanche FileInputStream, per la cronaca.
CharArrayReader ad esempio lo supporta ... ma perché trattando un char[] è abbastanza banale/ovvio come si possa riportare indietro la posizione! Anche BufferedReader lo supporta, perché dentro ha un buffer.
Comunque, a parte queste spiegazioni, potrei anche spiegarti il concetto di mark/reset ma onestamente ti sconsiglio di usarlo.
davide.fruci ha scritto:
List<String> diz = new ArrayList<String>();
try{
String s = null;
do
{
s = in.readLine();
if(s != null)
{
s = s.trim();
diz.add(s);
}
}while(s != null);
while(frase.hasNext())
{
if(diz.contains(frase.next()))
countWord++;
}
andbin ha scritto:
in un HashSet o TreeSet
Io ho utilizzato un ArrayList, che differenza c'è?
Il problema è che cercare in un List (con contains o indexOf) vuol dire dover fare una ricerca "lineare", dall'inizio, fino alla fine o fino a quando si trova l'elemento.
Ora .... supponendo come esempio una frase di 10 parole e un dizionario di 1000 parole, per ogni parola nella frase devi cercare potenzialmente nelle 1000 parole del dizionario!
Non è proprio quello che si può definire "efficiente" ...
davide.fruci ha scritto:
So che nelle collezioni di tipo Set, gli oggetti non hanno un ordine.
Set in generale non prescrive alcun criterio di ordine .... alcune implementazioni però possono definirlo e garantirlo!
TreeSet è una collezione "sorted" e quindi è anche "ordered".
Ok, ora chiarisco anche questi due termini:
Una collezione è "ordered" se l'iterazione è in un ordine prevedibile. Tutte le List sono ordererd. HashMap/HashSet ad esempio no.
Una collezione è "sorted" se gli elementi sono tenuti, e mantenuti nel tempo, già ordinati all'interno della collezione basandosi sul contenuto degli oggetti. È il caso di TreeMap (per le chiavi) e TreeSet.
davide.fruci ha scritto:
Però sono organizzati in modo da renderne la reperibilità più efficiente.
Sì, o si basano su hash-table (es. HashSet) o su un albero (es. TreeSet), che sono approcci più veloci di una ricerca "lineare".
davide.fruci ha scritto:
Praticamente, ogni oggetto ha un proprio numero intero identificativo univoco.
Univoco no .... Tutti gli oggetti hanno il hashCode(). Questo è il dato usato nelle collezioni basate su hash-table! Ma in generale il valore non è appunto univoco, due oggetti dello stesso tipo ma con contenuto differente,
possono avere lo stesso hashCode.
davide.fruci ha scritto:
Tutti questi numeri si trovano all'interno di un HashTable che si presenta come una lista linkata.
Ehm ... per dirlo meglio: una hash-table è fatta innanzitutto da un array, dove ogni elemento rappresenta un
bucket ("secchio") che contiene tutti gli elementi con le stesse affinità. Il concetto di affinità è dato proprio dal hashCode e per indirizzare nell'array dei bucket si usa un certo calcolo (quale, dipende dalla implementazione) che prende in input il hashCode.
Dietro ogni elemento nell'array ci può essere un lista linkata, dove ad esempio per HashMap contiene le entry chiave/valore. Dico "ci può essere", perché se la implementazione è "furba" usa dei reference nell'array, che possono quindi essere null (=nessuna lista) se nessun oggetto "cade" in quel bucket.
davide.fruci ha scritto:
Mentre, i TreeSet sono un'estensione degli HashSet con in più l'ordinamento.
TreeSet NON è una "estensione" (se intendi nel senso della ereditarietà) di HashSet.
davide.fruci ha scritto:
Ma non riesco a vedereil vantaggio nell'usare i TreeSet rispetto agli ArrayList.
Non hai più una ricerca "lineare" .... ma una ben più veloce.