@uMoR said:

Secondo me per il discorso punteggiatura (inteso come parentesi o segni scarsamente utilizzati) ti conviene fare un'espressione regolare o qualcosa del genere e rimuovere direttamente cià che non è sintatticamente corretto.

Aggiungerei dei filtri sulla densità delle chiavi, mettiamo che fai una doorway basata su un testo di 15 mega byte sui cani pazzi, non credi che la parola cani pazzi apparirà troppe volte ?

Oppure becchi del testo sfigato tipo:
"Il cane il il il il pazzo manga il il il il il il il gelato il con il il il becco il."

Penso che il risultato sarebbe qualcosa tipo:
"il il il il il" non trovi ?

Allora secondo me conviene ragionare diversamente:
io con questo algoritmo genero 1500 frasi su un determinato argomento, mi creo dei filtri (tipo anti duplicazione e cose cosi) e ne elimino un tot (probabilmente ne rimarranno diciamo la metà, o meno).
Da qui verifico per dire densità e cose del genere, in base alla statistica media di tutti i siti nelle serp di G per una determinata chiave, se rientro nei parametri allora prendo le frase rimaste per generare x pagine.

All'incirca ci siamo capiti ?
Poi le idee sono infinite, io non darei il codice in giro a tutti, sono sicuro che tanti ne farebbero cattivo uso

Secondo me la tua idea è troppo complessa e incasinata

cmq ho appena implementato un codice per gestire le parentesi tonde, ma adesso ovviamente serve un testo più lungo per generare un output abbastanza lungo.

quando dici "io con questo algoritmo genero 1500 frasi su un determinato argomento," vuoi dire che hai creato uno script del genere :O? o è un esempio?

P.S. Il testo sfigato non capiterà perchè lo sceglie un uomo non una macchina. (infatti per l'esempio ho scelto il testo di low perchè è molto ordinato..mette addirittura il punto prima di andare accapo! )

Il testo sfigato non capiterà perchè lo sceglie un uomo non una macchina. (infatti per l'esempio ho scelto il testo di low perchè è molto ordinato..mette addirittura il punto prima di andare accapo

Allora si spiega tutto..
Ovvio che quello che dico io va bene per testi fatti tutti a pc!

News dell'ultima ora: adesso gestisco ottimante tutti i tipi di parentesi (tonde, quadre, graffe) e uso 48kb della guida di low per generare un testo di massimo 500 parole (limite settato da me)

Fino a domani aspetto tutte le vostre considerazioni su come migliorarlo e poi metto il link al file zip + mini-guida

Io ho già dato

Bel lavoro, kerouac3001!

Circa la sistemazione delle parentesi, noto ancora alcune parentesi aperte che non vengono poi chiuse.

Circa l'aumento delle probabilità di scelta di una keyword, io (all'epoca) implementai l'algoritmo in maniera diversa da come hai fatto tu. In poche parole invece di memorizzare in un array tutte le parole ('che', 'che', 'di', 'che', 'che'), memorizzavo le loro quantità ('che' -> 4), ('di' -> 1).

Questo mi consentiva, successivamente, di calcolare le percentuali di probabilità e di incrementarle a piacimento. Inoltre è un ottimo modo per risparmiare memoria per le variabili, e si possono gestire testi chilometrici.

Circa il pericolo che l'algoritmo crei testi a cavolo, esso è praticamente impossibile, tenuto conto che si parte da un testo normale. Un testo normale genera testi normali.

Visto che non usi una singola pagina del mio sito ma un mix, non c'è alcun pericolo circa i fattori di similarità delle pagine. Beh... ci sarebbe almeno un modo per accorgersi di un'anomalia... ma è improbabile che venga usato dai motori.

Ho notato che a volte vengono generate frasi piuttosto lunghe presenti nel testo originale, tipo "non solo perché un uso eccessivo può abbassare considerevolmente la leggibilità del testo, ma anche perché i motori". Questo si risolve partendo da testi più lunghi.

Aggiunto: Ah, un'altra cosa: bisogna evitare che l'algoritmo generi frasi uguali. Un buon modo per ottenere ciò è, oltre che partire da un testo più lungo (100k, ad esempio), anche modificare le probabilità durante la generazione. (in questo modo si violenta un po' il concetto di catena di markov, ma queste sono considerazioni matematiche).

Circa l'aumento delle probabilità di scelta di una keyword, io (all'epoca) implementai l'algoritmo in maniera diversa da come hai fatto tu. In poche parole invece di memorizzare in un array tutte le parole ('che', 'che', 'di', 'che', 'che'), memorizzavo le loro quantità ('che' -> 4), ('di' -> 1).

Usavi un array associativo o bidimensionale ? (io penso associativo)

@uMoR said:

Usavi un array associativo o bidimensionale ? (io penso associativo)

Premesso che son passati 4 anni e che non ricordo praticamente nulla, ad intuito direi di aver usato un array associativo, in quanto molto più comodo.

Ma anni ancora prima, feci un'implementazione in C usando solo numeri e array numerici (ed ovviamente un indice con la corrispondenza numero -> termine).

Secondo me c'è da lavorare ancora molto su cose tipo:

"che potrebbero spingere il motore di ricerca decidono la posizione"

secondo me i motori di questa frase si accorgono che non va bene, per il tempo del verbo dico io..

oppure finire frasi con "che"

@LowLevel said:

Bel lavoro, kerouac3001!

Circa la sistemazione delle parentesi, noto ancora alcune parentesi aperte che non vengono poi chiuse.

Circa l'aumento delle probabilità di scelta di una keyword, io (all'epoca) implementai l'algoritmo in maniera diversa da come hai fatto tu. In poche parole invece di memorizzare in un array tutte le parole ('che', 'che', 'di', 'che', 'che'), memorizzavo le loro quantità ('che' -> 4), ('di' -> 1).

Questo mi consentiva, successivamente, di calcolare le percentuali di probabilità e di incrementarle a piacimento. Inoltre è un ottimo modo per risparmiare memoria per le variabili, e si possono gestire testi chilometrici.

Circa il pericolo che l'algoritmo crei testi a cavolo, esso è praticamente impossibile, tenuto conto che si parte da un testo normale. Un testo normale genera testi normali.

Visto che non usi una singola pagina del mio sito ma un mix, non c'è alcun pericolo circa i fattori di similarità delle pagine. Beh... ci sarebbe almeno un modo per accorgersi di un'anomalia... ma è improbabile che venga usato dai motori.

Ho notato che a volte vengono generate frasi piuttosto lunghe presenti nel testo originale, tipo "non solo perché un uso eccessivo può abbassare considerevolmente la leggibilità del testo, ma anche perché i motori". Questo si risolve partendo da testi più lunghi.

Aggiunto: Ah, un'altra cosa: bisogna evitare che l'algoritmo generi frasi uguali. Un buon modo per ottenere ciò è, oltre che partire da un testo più lungo (100k, ad esempio), anche modificare le probabilità durante la generazione. (in questo modo si violenta un po' il concetto di catena di markov, ma queste sono considerazioni matematiche).

Le parentesi aperte sono normali, perchè non ho ancora gestito la chiusura del file, ovvero leggo l'ultima parola e se è sprovvista di punto lo aggiungo (anche se questo può essere pericoloso e può portare ad anomalie come un articolo seguito da un punto)..se prima dell'ultima parola c'è una parentesi aperta allora la chiudo e poi aggiungo il punto.

Il modo per risparmiare memoria lo posso gestire così:

il mega array iniziale lo gestisco come dici tu e poi prima di passare all'output creo un secondo array provvisorio che contiene unicalmente il caso le parole che possono seguire l'ultima coppia presa in considerazione ..e le gestisco come le gestivo prima ..per esempio trasformo ('che' -> 4), ('di' -> 1) in ('che', 'che', 'di', 'che', 'che') e poi procedo come sempre..alla fine elimino l'array provvisorio..così occupo meno memoria e funziona esattamente come dici tu (farlo semplicemente con percentuali è difficile e lo script subirebbe rallentamenti..secondo me questo è il modo migliore..il più veloce in assoluto)

Per evitare che l'algoritmo generi frasi uguali posso memorizzare le ultime 5 parole generate dallo script e prima di trovare la sesta parola vedo se esiste nel testo originale la sequenza parola1 parola2 parola3 parola4 parola5..se esiste mi trovo le parole che seguono questa combinazione nel testo originale e le elimino dall'array provvisorio.

Che ne pensi? Questo potrebbe rallentare un pò i procedimenti, ma è perfetto.

P.S. cosa è un array associativo?

http://www.dei.unipd.it/~tigre/b/PerlTutorial/perl-tutorial-10.html

@uMoR said:

http://www.dei.unipd.it/~tigre/b/PerlTutorial/perl-tutorial-10.html

Ok allora ho io ho usato un array al 50% associativo mentre quello di Low è al 100% associativo.

@uMoR said:

"che potrebbero spingere il motore di ricerca decidono la posizione"

secondo me i motori di questa frase si accorgono che non va bene, per il tempo del verbo dico io..

Personalmente dubito che i motori si spingano fino alla correzione grammaticale per qualunque lingua esistente, e in particolare per l'italiano.

Il Web è pieno anche di testi scritti da asini e per un motore sarebbe errato desumere che un testo sgrammaticato sia un testo fasullo.

Non escludo invece che esistano bonus di posizionamento per testi scritti correttamente o con un grado di leggibilità maggiore, visto che conosco diversi algoritmi per il calcolo di fattori simili. Quand'anche esistessero, l'influenza di tali algoritmi sulla posizione presumo sia trascurabile, comparata al beneficio di avere decine di pagine con testo "coerente" create in pochi secondi.

se prima dell'ultima parola c'è una parentesi aperta allora la chiudo e poi aggiungo il punto.

Questo non potrebbe condurre a testi tra parentesi anche molti lunghi?

I motori tengono conto delle parentesi (così come delle virgolette). Tra avere lunghe frasi tra parentesi e non avere affatto parentesi, è meglio la seconda cosa.

Il modo per risparmiare memoria lo posso gestire così:

Ma no... fregatene della mia vecchia implementazione. Io l'avevo fatto per necessità prestazionali (le percentuali possono andare anche più veloci dell'array lineare, se si usano certe ottimizzazioni) e per esigenze di risparmio di risorse.

vedo se esiste nel testo originale la sequenza parola1 parola2 parola3 parola4 parola5..se esiste mi trovo le parole che seguono questa combinazione nel testo originale e le elimino dall'array provvisorio.

Mi sembra un ottimo approccio. Evita comunque di andare a cercare fisicamente la sequenza nel testo originale ogni volta. E' meglio crearsi in fase di scansione del testo originale un secondo array con la sesta parola che segue ogni sequenza di cinque parole, esattamente come già fai con le sequenze di due parole. Così la ricerca della sesta parola è molto più veloce.

@LowLevel said:

@uMoR said:

"che potrebbero spingere il motore di ricerca decidono la posizione"

secondo me i motori di questa frase si accorgono che non va bene, per il tempo del verbo dico io..

Personalmente dubito che i motori si spingano fino alla correzione grammaticale per qualunque lingua esistente, e in particolare per l'italiano.

Il Web è pieno anche di testi scritti da asini e per un motore sarebbe errato desumere che un testo sgrammaticato sia un testo fasullo.

Non escludo invece che esistano bonus di posizionamento per testi scritti correttamente o con un grado di leggibilità maggiore, visto che conosco diversi algoritmi per il calcolo di fattori simili. Quand'anche esistessero, l'influenza di tali algoritmi sulla posizione presumo sia trascurabile, comparata al beneficio di avere decine di pagine con testo "coerente" create in pochi secondi.

se prima dell'ultima parola c'è una parentesi aperta allora la chiudo e poi aggiungo il punto.

Questo non potrebbe condurre a testi tra parentesi anche molti lunghi?

I motori tengono conto delle parentesi (così come delle virgolette). Tra avere lunghe frasi tra parentesi e non avere affatto parentesi, è meglio la seconda cosa.

Il modo per risparmiare memoria lo posso gestire così:

Ma no... fregatene della mia vecchia implementazione. Io l'avevo fatto per necessità prestazionali (le percentuali possono andare anche più veloci dell'array lineare, se si usano certe ottimizzazioni) e per esigenze di risparmio di risorse.

vedo se esiste nel testo originale la sequenza parola1 parola2 parola3 parola4 parola5..se esiste mi trovo le parole che seguono questa combinazione nel testo originale e le elimino dall'array provvisorio.

Mi sembra un ottimo approccio. Evita comunque di andare a cercare fisicamente la sequenza nel testo originale ogni volta. E' meglio crearsi in fase di scansione del testo originale un secondo array con la sesta parola che segue ogni sequenza di cinque parole, esattamente come già fai con le sequenze di due parole. Così la ricerca della sesta parola è molto più veloce.

Le parentesi purtroppo vanno fatte così..al massimo faccio in modo che quando una parentesi è aperta sia privilegiata (percentualmente) una parola che termina con una parentesi chiusa.

Ho già fatto lo script alla tua vecchia maniera..è molto più veloce adesso.

Poi ho anche aggiunto la funzione che gestisce la similitudine..purtroppo funziona..funziona così bene che lo script non produce più di 10 parole.

Questo significa che dovrò aumentare enormemente il testo originario.

Oppure evito la correzione sulla similitudine..tu cosa pensi sia meglio?

@kerouac3001 said:

Le parentesi purtroppo vanno fatte così..

Che succede se le elimini e basta?

Poi ho anche aggiunto la funzione che gestisce la similitudine..purtroppo funziona..funziona così bene che lo script non produce più di 10 parole.

Hai provato con altri testi originari oltre che con i miei? Magari dipende anche dal tipo di scrittura delle fonti. Prendi un paio di articoli di Repubblica.it

Questo significa che dovrò aumentare enormemente il testo originario.

Oppure evito la correzione sulla similitudine..tu cosa pensi sia meglio?

La terza opzione è allungare il controllo a dieci termini invece che cinque. O comunque un valore superiore a cinque.

Aggiunto: comunque la lunghezza del testooriginario la aumenterei comunque.

Ho messo a 10 il livello di similarità..il problema persiste. Aumenterò il testo con Repubblica..ma ormai se ne parla domani

Per ora è tutto funzionante e molto veloce..così veloce che potrei direttamente implementarlo in doorway dinamiche

Per eliminare il problema del testo troppo piccolo (neanche con 300kb siesce a superare una riga) ho inserito questa funzione:

se non ci sono elementi nell'array array['$seed'] allora $seed è uguale a $best..dove best è il miglior $seed tra quelli presi in considerazione fin dall'inizio dello script..con miglior seed intendo dire quello che è collegato a più parole.

In questo modo ci assicuriamo il seed migliore e ricominciamo alla grande.

Va un pò contro l'idea di Markov Chain ma fatemi sapere cosa ne pensate..si tratta di un piccolo taglietto una volta ogni tanto.

Comunque gli ho dato in pasto mezza Moll Flanders (di DeFoe) adesso sembra funzionare bene.

Finito: qui trovate lo [url=http://www.impattosonoro.it/posizionamento%20nei%20motori%20di%20ricerca%20roma/]script.

Positano mi ha proposto di implementarlo a un generatore di doorway..appena posso lo faccio, ma per ora metto online il link allo script base. C'è pure una miniguida, ma in funzionamento è veramente semplice

Per ogni suggerimento, postate qui e cercherò di migliorare lo script di volta in volta.

infatti è quello che pensavo pure io.....

le doorway generate tramite questo metodo riescono ad essere univoche e abbastanza verosimili....

non credo che i motori abbiano algoritmi talmente sofisticati da riuscire a scoprire che si tratta di pagine create in automatico...

vabbè si vedono doorway con i piedi in giro che hanno pure buoni ranking, credo che il metodo di Markov produca risultati di gran lunga migliori

@paolino said:

infatti è quello che pensavo pure io.....

le doorway generate tramite questo metodo riescono ad essere univoche e abbastanza verosimili....

non credo che i motori abbiano algoritmi talmente sofisticati da riuscire a scoprire che si tratta di pagine create in automatico...

vabbè si vedono doorway con i piedi in giro che hanno pure buoni ranking, credo che il metodo di Markov produca risultati di gran lunga migliori

Scusa mi sono dimenticato di te nei ringraziamenti eheh

Comunque anche io credo sia un ottima idea..molto facile da realizzare..esempio di doorway:

<html>
  <head>
    ....
  </head>
  <body>
    


      <?
        require&#40;'add_chain.php'&#41;;
      ?>
    </p>
  </body>
</html>

Il problema è che essendo io un perfezionista voglio trovare un modo di gestire i metatag in maniera ottimale.

Potrei inserire un array che raccoglie una serie di parole per cui si vogliono ottimizzare le doorway e far scegliere a caso 2 parole da questo array.

I metatag sarebbero:

Title: (Parola1)-Parola2-[Parola1]-Parola2-(Parola1)

Tanto Low è convinto che sti metatag non servano a nulla..io però al title ci tengo quindi lo inserisco.

Ovviamente se la key principale del title è Parola1 allora faccio in modo che il testo venga ottimizzato per la key Parola1.

Vi convince?

Inoltre inserisco un redirect lato server ad un indirizzo specificato.

Ovviamente chi vuole può modificare il codice della doorway e inserire il testo dove gli pare.

(Un pò come lo script che mi ha fatto vedere ieri positano)

Il problema finale è questo:

creo una cartella e delle doorway statiche all'interno di essa (in automatico)?

o creo doorway dinamiche?