Utente:DracoRoboter/De civitate Dei contra Paganos
Proposte di modifiche vandal fighter per raggiungere alla costruzione del fork Contra Paganos. Home page temporanea del progetto Contra Paganos su source forge.
Il canale IRC ufficiale di contra-paganos è:
Vedi anche cs:Wikipedista:Beren Altro sviluppatore che vuole fare una cosa simile. Per ora (23 nov 2006) stiamo aspettando notizie da henna che ci indichi il termine dei lavori.
Developer
[modifica | modifica wikitesto]Richieste committente
[modifica | modifica wikitesto]- m7-01-27-10: la wl dovrebbe permettere di non oscurare gli edit "non di contenuto", ossia quelli verso le pagine di servizio, MediaWiki, talk etc.
- 10 Pomodori
- m7-02-27-10: la wl non dovrebbe oscurare mai gli edit "di servizio", ossia i rollback, block, move, protect etc.
- 10 Pomodori
bachi
[modifica | modifica wikitesto]- gvf-01-31-10 se cambi l'ordine delle colonne e la larghezza al successivo riavvio fa un po' di confusione, sembra metta le larghezza alle colonne sbagliate
- ?? Pomodori
- gvf-02-31-10la schermata viene sempre visualizzata a 1024 x 768 mentre sembra ci sia del codice per gestire le dimensioni del video e forse memorizzarle
- ?? Pomodori
- gvf-03-31-10unificare formato file setup che ora sembrano essere un file di tipo testo, uno binario, e uno in xml (riferimenti nel codice forse non richiamato) i file di configurazione sono vfdata2.txt e vfdata2.dat (in dat forse proprio l'ordine e la larghezza delle colonne)
- ?? Pomodori
richieste fattibili solo caricando modifica
[modifica | modifica wikitesto]- lusum-11-27-8 : identificare quelle modifiche che comportano solo l'aggiunta o rimozione di spazi o la correzione di accenti
- 1 Pomodori
- lusum-04-27-10 : identificare l'inserimento di link esterni che possono portare spam.
- 2 Pomodori
- lusum-05-27-10 : identificare creazione pagine con nessuna wikificazione
- 4 Pomodori
- lusum-03-27-10: identificare gli edit che comportano l'inserimento o la cancellazione di un template
- 8 Pomodori
- lusum-09-27-10 : identificare gli edit che comportano l'inserimento o la cancellazione di un'immagine
- 8 Pomodori
- lusum-07-27-10 : l'oscuramento o meno della WL riguardo alle pagine "di servizio" dovrebbe essere opzionale
- 10 Pomodori
- sbisolo-01-28-10 Collaborative Vandal Fighter ovvero la lista delle cose da controllare sia comune ad un gruppo di utenti e, se l'ha controllata uno del gruppetto, sparisca dalla coda degli altri. Eventualmente con doppio check cioè che dev'essere controllata da almeno due
- 100 pomodori
- lusum-08-27-10 : categorizzare gli edit secondo il tipo: immagini, voci, categorie.
- 100 Pomodori
- lusum-02-27-10 :identificare gli edit che comportano l'inserimento o la cancellazione di una categoria e se questa categoria esista o meno
- 100 Pomodori
Richieste non abbastanza specifiche
[modifica | modifica wikitesto]- lusum-01-27-10 e usare regex per categorizzare gli edit.. tipo categoria, aggiunta template?
- ? Pomodori
- lusum-06-27-10 : sostituire con: identificare l'inserimento di redirect ( esatti o errati) e la dimensione in byte delle nuove pagine (possibili WND)
- ? Pomodori
Nuove richieste
[modifica | modifica wikitesto]- Includere i messageBundle nel CVS
- Indentare meglio il codice
- Aggiungere commenti al codice
- Integrare parte del codice della classe vf nella classe config
- Integrare un browser ( possibili browser) :
- Chiarire che tipo di info passano tramite IRC
Lusum 15:02, 21 nov 2006 (CET)
- scrivere un driver standar java per usare le api di mediawiki mediawiki api. Non è esattamente collegato al vf ma secondo me si potrebbe integrare in futuro.
Richieste in lavorazione
[modifica | modifica wikitesto]- lusum-10-27-8 : identificazione, se possibile di nick utenti negli edit.
- 1 pomodoro
Consigli generali
[modifica | modifica wikitesto]- bisognerebbe distinguere tra le cose cui si hai accesso attraverso il feed irc e quelle che richiedono un'analisi dei contenuti (via rss?)
diff
[modifica | modifica wikitesto]sto cercando un algoritmo per fare dei diff per scoprire i copyviol mi serve una metrica di uguaglianza tra testi normalizzati (tolte virgole e caratteri buffi e maiuscole divise per parole) Grazie all'utente:rojelio per l'algoritmo
Primo modo "bag of words"
[modifica | modifica wikitesto]può dare una grande quantità di falsi positivi io immaginavo una metrica che tende a zero se sono uguali e a infinito (o a un numero) se sono diversi
sostanzialmente hai una mappa parola->numero di occorrenze nel documento e il coefficiente di somiglianza è il "prodotto scalare" tra i due vettori però questo è in grado per lo più di dirti quando due documenti "parlano della stessa cosa" più che "sono uguali"
- prodotto scalare, esempio
[2,2] * [3,4] = 2 * 3 + 2*4 ??
le "componenti corrispondenti" dei vettori sono le occorrenze della stessa parola beh, innanzitutto dovresti dividere per i due moduli dei vettori (il che poi significa normalizzare sul numero di parole) a quel punto hai il "coseno" dell'angolo tra i due documenti che tende a 1 se i due usano le stesse parole e con lo stesso rapporto di numerosità tra loro e a 0 se usano set di parole completamente disgiunti
ogn itesto è u nvettore in uno spazio ndimensionale (facciamo con due che così riesco a fare i ldisegno) il vettore delle frequenze d'uso normalizzato è un vettore di che giace sulla circonferenza unitaria nel primo quadrante
uno è [0,1] l'altro [1,0] A scal B = 0 geometricamente il prodotto è il coseno dell'angolo quindi son odiversi perchè non hanno parole a comune uno ha usato solo la "parola 1" l'altro solo la "parola 2"
in questo caso il coseno di 90° se io ruoto in modo che uno dei due testi sia sopra l'ascissa è il coseno dell'angol osotteso ad a l'angolo non può essere superiore a 90 quindi lo scalre è limitato tra 0 e 1 o= diversi 1 uguali ok?
che 1 non significa esattamente "uguali"
significa "usano le stesse parole con la stessa frequenza"
tu metti le parole dei due documenti in un unico vettore contiguo con un separatore nel mezzo non ti servono le "lettere", non sono vettori di char sono vettori di interi: a numero uguale, parola uguale
- esemplifico
[1, 2] [3, 4] --> [1,2,0,3,4]
dato un generico vettore di n elementi esistono n "suffissi" dove l'i-esimo suffisso è il vettore che parte dall'elemento di indice i e va fino alla fine del vettore originale
- es
[1,2,3,4] -->[1,2,3,4] [2,3,4] [3,4][4]
anche stesso è lo 0-esimo suffisso
ora, questi suffissi possono essere ordinati in "ordine lessicografico" quindi ordinati sul primo elemento.... a parità del primo, ordinati sul secondo, etc etc
il cosiddetto suffix array è un vettore di lunghezza n in cui il primo elemento è l'indice del primo suffisso dell'ordine lessicografico e così via quindi a partire da [1,2,3,1,2]
suffissi [1,2,3,1,2] [2,3,1,2] [3,1,2] [1,2] [2] suffix array: [3,0,4,1,2] [1,2] [1,2,3,1,2] [2][2,3,1,2] [3,1,2] ordinati
"longest common prefix" per ogni coppia di indici consecutivi del suffix array corrispondenti quindi a suffissi consecutivi nell'ordine lessicografico
30, 04,41...
conti quante parole hanno a comune all'inizio [0,2,0,1,0] (il primo 0 è fittizio)
e 2 è il nuemro che andavo cercando? il longest hai appena scoperto quali sono, quante, e quanto lunghe le sottostringhe ripetute dell'array originale
beh, questo è il dato "grezzo" come faccio a trasformare 0 2 01 0 a questo punto puoi scegliere
beh, per essere utile ci va una variante minima: il nostro vettore originale sono due documenti con un separatore devi prevedere, nel calcolo del longest prefix che se incontri il separatore ti fermi (nel nostro caso c'è un solo separatore e quindi *non può* proseguire ma nei casi in cui è usato sul serio (migliaia di documenti) questa regola serve :-) ora hai a disposizione, nel caso più semplice la più lunga sottostringa comune
2 (1,2)
che può cmq essere usata come parametro di massima di somiglianza o meglio: una sottostringa di lunghezza > di una soglia di attenzione altrimenti si puù fare uan roba più fine è quella che ti dice "qui qualcuno ha copiato quanto meno un'intera frase" poi il rapporto lunghezza sottostringa / lunghezza documento è un altro ottimo indicatore di "ha copiato paro paro l'80% dell'altro documento"
qui puoi liberare la tua fantasia perché non esiste *la* risposta corretta ma una serie di euristiche più o meno fini
- possibile metrica
se conto uno ogn ivolta che incontro un ugiuaglianza maggiore di 4 e poi faccio qualche calcolo sommatorio normalizzato? (4: esempio di soglia)
ora, per le dimensioni dei documenti in ballo (<10000 parole)
ed in considerazione del fatto che sono solo coppie di documenti
anche un'implementazione qui e là quadratica non fa danno
ti serve tenere d'occhio che le sottostringhe comuni *appartengano ai due diversi documenti*
l'algoritmo ti dice "la sottostringa compare 5 volte"
la roba del sepaatore no nfa quel lavoro lì?
quello serve ad impedire che vengano prese sottostringhe che "scavallano" tra la fine del primo e l'inizio del secondo :-)
semplicemente tu hai sempre sotto mano il suffix array che ti dice dove partono le sottostringhe in questione indice > indice del separatore -> secondo documento < -> primo documento una roba del genere temo sarebbe megli ofarla in un c.. in realtà se nn vuoi usare l'algoritmo iper-ottimizzato, qualsiasi linguaggio va benissimo perché non va tanto oltre di 2-3 array ed un paio di for
se cerchi "suffix array" e "longest common prefix" trovi un botto di roba, in rete comprese figure estremamente esplicative l'unica che non trovi è il trucchetto del separatore e il fatto di voler distinguere il conto di "da quale" documento vengono le sottostringhe
ma i vari diff che ci sono i nfìgiro usano questa roba?
considera che un diff se ci sono due blocchi di testo identici ma "invertiti" nella copia ti dicono che la fine dell'originale coincide con l'inizio della copia e che dall'originale manca l'inizio e dalla copia manca la fine infatti mentre questo trova le parti a comune indipendentemente da dove si trovino puoi anche fare il conto di quante parole dei documenti sono "coperte" da sottostringhe a comune di lunghezza superiore a soglia
così ottieni il grado di "copertura" dovuta a parti copiate
puoi anche farci sopra un'integrazione a finestra mobile per far emergere *zone* di documento copiato della serie: il documento nel suo complesso è stato copiato al 5% ma questa zona qui, di 70 parole di lunghezza, è stata copiata al 96% e quindi è copyviol toni di grigio quindi? calcoli la "concentrazione" di parti copiate all'interno di una finestra scorrevole lungo il documento
stesso calcolo di normalizzazione (parole copiate su parole totali) solo che invece che essere parole totali del documento sono parole totali della finestra
Appunti sulla ricerca di copyviol
[modifica | modifica wikitesto]Non ho molto esaminato il codice che mi hai mandato perché mi sono messo a provare a implementare un po' anche io ;) Ho fatto qualche test utilizzando un suffix tree (che sapevo implementare meglio, ma che dovrebbe essere ripetibile usando un suffix array), scrivo qui i problemi e le considerazioni che sono emerse (varie me le hai dette tu in chat, ma visto che non le hai scritte... ;)), mi riferisco spesso ai consigli qui sopra:
- ci servirebbe un algoritmo per estrarre testo semplice da una voce di wikipedia, questo comporta o l'analisi del wikicode o quella della pagina web (non scarterei a priori la seconda possibilità, anche se un parser di wikicode farebbe comodo per altri motivi)
- fa comodo, ma non è indispensabile, un algoritmo per estrarre testo semplice da una pagina web qualsiasi; l'utente potrebbe comunque fare copia/incolla dei testi da solo
- è necessario un algoritmo per "normalizzare" il testo: dobbiamo suddividerlo in parole, dato lo scopo che ci si prefigge possiamo consentirci di ignorare parole ma dovremmo quanto più possibile ridurre il numero totale delle parole ed evitare che le correzioni che i wikipediani fanno al testo non mascherino le somiglianze. Si possono ignorare accenti ed apostrofi, saltare articoli e preposizioni, ignorare la punteggiatura e le lettere maiuscole. Questa operazione non può essere mostruosamente lenta visto che va ripetuta per ogni testo da esaminare. Si può mantenere un carattere speciale, come il punto, per indicare le separazioni tra le frasi. Una volta normalizzato il testo si può trasformare ogni parola nel proprio hash, in modo da ridurre il testo ad una sequenza di numeri interi (token), per essere carini ogni token può mantenere un indice alla posizione corrispondente nel testo non normalizzato.
Posso fornire qualche informazione sull'uso di un suffix tree: ho costruito un suffix tree a partire da alcuni documenti, ogni nodo del tree memorizza un token e una mappa (token successivo/nodo successivo); l'albero è in teoria ottimizzabile fino a poter essere scorso in tempo lineare sul numero di token N del documento da confrontare, l'albero va costruito una volta sola per ogni voce di wikipedia che si desidera controllare. La dimensione in memoria dell'albero dipende dal numero di nodi e dal grado di ottimizzazione che si desidera dare alla ricerca, scegliendo di analizzare solo sequenze di lunghezza L la complessità va da N*L a N. La costruzione di un albero non molto ottimizzato su una voce come Roma (circa 10000 parole) nel mio pc del lavoro (1Gb ram/centrino 1.8GHz) richiede meno di un secondo, con una soglia a 10 si ottengono circa 100000 nodi (nella pratica nella costruzione di un tree con soglia S si costruiscono N*S nodi). A confronto un suffix array userebbe solo N*2 - N*3 nodi (Riccardo)
- Su meta è disponibile uno script utile per scopi simili