[Musica]
Eh, ok, ok. Salve a tutti, sono il
professor Enrico Malizia, sarò il vostro
docente di informatica teorica.
Iniziamo questo corso, non so se strano
o usuale per voi, per è un corso un po'
teorico rispetto, non so a cos'altro
avete visto. Prima domanda in fondo, mi
sentite? Perché vorrei evitare di usare
il microfono, ok? Perché gestitolo,
quindi avere un microfono in mano mi dà
fastidio, eh. Ok. Allora, come vedete da
questo numero bassissimo qua, abbiamo
tre slide, chiudiamo la lezione, poi ce
ne andiamo tutti quanti. In realtà sono
le uniche slides che vedrete, perché
slides non ne voglio usare. Ok?
Ho insegnato questo corso in Inghilterra
per un po' di anni e quello che ho in
genere visto è che a scrivere,
innanzitutto in Inghilterra lo
chiamavano diporama, cioè gli studenti
dicevano che quando fai slide su slide
poi non si capisce niente perché insomma
una dopo l'altra stiamo semplicemente a
rincorrere quello che ci sta scritto,
no? Quindi io preferisco evitare perché
la lezione io la voglio calibrare su di
voi.
Che significa? che io ho
una scaletta di cose da fare, cioè ho in
mente che cosa dobbiamo trattare,
però non mi voglio legare non mi voglio
legare a delle cose scritte, a delle
slide perché potrebbe essere necessario
cambiarle sul momento perché me ne posso
accorgere da voi se avete gli occhi
persi o cose del genere. Quindi
questo questo qua. Ok, allora facciamo
un'introduzione veloce al corso,
eh. Ok. Le nostre lezioni ce l'hanno
messe a degli orari disgraziati.
Oggi fino alle 6:00 e venerdì, no?
Questo è giovedì. Giovedì all'ora di
pranzo, quindi quando proprio siamo
affamati e non ci capiamo proprio
niente. E poi venerdì mattina
prestissimo, così ci siamo andati a
darci qualcosa. La sera prima non non
capiamo una mazzature lì. Ok, vabbò. A
parte gli scherzi, allora cercherò per
quanto possibile di trasmettervi alcune
cose in questo corso che adesso adesso
vi dirò,
alcune alcune notizie prima di prima di
iniziare. A me il corso l'hanno dato in
corso d'opera tipo un due mesi fa, una
cosa del genere, è stato formalizzato,
quindi non ho potuto cambiare la pagina
online perché quella va fatta l'anno
prima. I libri di testo che che vi
consiglio, allora, sono innanzitutto
questo qua, Calautti, sono le sue
lezioni del corso di calcolabilità e
complessità. Lo trovate disponibile il
link, se andate su virtuale, ok? C'è
proprio il link alla pagina su Gitlab,
da lì prendete ve le scaricate. Ok,
preso le slide di Marco, perché Marco è
stato un mio studente tanti anni fa che
mi hanno dato il corso di informatica
teorica qualche anno fa a Trento e a
Milano. Lui si è messo giuste note ha
detto "Sai che me le riutilizzo". Mi ha
detto non c'è problema. Quindi seguirò
le per gran parte delle cose, seguirò le
sue le sue le sue note.
Ok, abbiamo stili differenti io e Marco,
cioè alcune cose io le definisco un po'
differenti, vabbò, eh, ve ne farete una
ragione, però è abbastanza preciso e ci
dà più o meno un'idea di tutto quello
che vorrei fare durante il corso. Alcune
cose cambierò l'ordine, altre cose le
taglio, altre cose le aggiungo, insomma
è un po' a gusto, però secondo me quelle
note sono abbastanza
compatte e contengono tutto quello che
ci serve. Allora, quelle note
sono basate su questo libro
prevalentemente, Introduction toata
Theory, Languages and Computation.
È un testo classico. Classico significa
che la prima edizione risarà agli anni
70, il che significa che un testo molto
revisionato nella sua terza edizione,
molto semplificato. La prima edizione di
quel testo era sostanzialmente
sofisticata. dalla seconda edizione in
poi l'hanno semplificata parecchio.
Allora, io ho guardato le eh le lecture
notes di di Marco e sostanzialmente
segue quel libro, anche perché era il
corso che seguivano noi tanti anni fa.
Quindi quello è il vostro
riferimento primario. Secondo me il
essendo un testo classico
è facile da trovare. Ok?
Avete capito? Insomma,
siccome è un testo che è stato in giro
per tantissimo tempo, se lo cercate lo
trovate, esattamente come quello. Questo
qua sono additional reading che io vi
consiglio in caso vogliate approfondire
cose.
Zipser Introduction to the theory of
computation. Pure questo testo classico,
cioè che significa che si trova, ok?
Beh, è tutta roba che si trova questa,
eh? E quest'altro, se proprio volete
approfondire, Computational Complexity,
questo è un libro un po' piuttosto che
ah si focalizza più sulla complessità
computazionale che non sulla sulla
calcolabilità. Ok? Questi questo corso
noi lo chiamiamo informatica teorica, in
tante altre università lo chiamano
calcolabilità e complessità. Adesso
vedremo un po' che cos'è questa cosa.
Oggi faremo più che altro una lezione
introduttiva. Voglio interagire con voi,
voglio capire qual è il vostro
background, così insomma un po' da
calibrare il eh la lezione. Ok?
Sulla pagina virtuale m metterò, almeno
ci tengo la prima volta che lo faccio,
userò delle note che io scrivo sul
tablet, quelle là. Poi preparo dei PDF,
li metto su virtuale e voi ve li potete
prendere. Guardate che io uso adesso vi
spiego come uso io la scrittura su su
queste note che prendo. È come se stessi
scrivendo alla lavagna, nel senso che
cioè non è che andrete e troverete cose
scritte, ci stanno. Cioè, invece di
buttarlo qua e dover fare le foto, lo
scriviamo là e così abbiamo abbiamo
tutto. Però saranno più che altro
schizzi, disegni, cose del genere, ok?
Cioè, sarà difficile studiare da quello
che io scrivo su quelle su quelle note.
Ok? Quello che io vi consiglio sono le
lecture notes di Marco Calauti,
il libro di Opcroft, quello là, perché è
molto semplice, poi l'altro agli
additional readings, se proprio ne
volete scegliere uno, io vi consiglio
Sipser perché è più semplice da capire,
ok? rispetto a computational complexity.
Per esempio, su computational
complexity, come dice il titolo, tutta
la parte di calcolabilità non c'è perché
è un corso mirante alla complessità,
molto sofisticato, cioè si capisce, però
vi prende tempo, non so quanto tempo
abbiate, ok? Quindi se proprio volete
stringere al massimo lecture notes di
Calauti, Opcroft e Zipser, ok? ci sarà
più o meno tutto. Se poi io mi rendo
conto che tra le cose che facciamo c'è
spiegheremo cose che non sta su nessuno
di di tutte queste sorgenti, scrivo giù
due note e ve le e ve le giro. Ok?
Eh? Ok. Allora,
m
risorse, ok, sono queste, l'abbiamo
l'abbiamo detto. Un'altra risorse,
ovviamente, venire a lezione, appunti,
libri, eccetera. Un'altra risorsa sono
io, ovviamente mi fate domande. Ok?
Allora, una cosa che è importante che ce
lo diciamo, a me piace interagire
durante la lezione. Uno perché mi aiuta
a capire se vi siete fermati da qualche
parte a recuperare, no? E poi per fare
la cosa un po' cocreativa, perché sennò
alla fine sentite la mia voce che un po'
rompiballe, no? E andare avanti per due
ore così potrebbe essere un po'
scocciante per voi e anche per me, eh.
Quindi quando farò domande
sto facendo una domanda, cioè non la sto
buttando là a caso, mi aspetto, cioè
sarebbe carino che in qualche modo
riusciamo a interagire, ok? È una cosa
che in Inghilterra dovevo dire
esplicitamente perché lì proprio niente,
la gente ti guardava, no, così, ma aveva
la bocca sigillata. Quindi dovevo dire,
ragazzi miei, mi serve una risposta che
sono è un po' un problema. Ok. Allora,
quello con cui iniziamo oggi,
la prima cosa che facciamo oggi è
questo, dare la parola a voi. C'ho
quattro domande là, vorrei sentire
qualcuno di voi per capire un po' che
idea c'avete in testa. Ok, allora le
quattro domande su cui vorrei
focalizzarmi per un po', ok? izzata
tutta la lezione su questa.
Cosa pensate che questo corso tratti?
Come pensate che tratteremo queste cose?
Quali difficoltà pensate che andremo a
incontrare? Cosa pensate di fare per
superare quelle difficoltà? Ok? Questa è
una cosa prevalentemente metodologica
per capire se avete in testa un modo
esplicito per
affrontare eventuali difficoltà. che si
potrebbero manifestare.
Ok.
Ovviamente non c'è il voto
a caso.
Uno di voi
devo essereissimo.
Vai. Certo. È tipo Corrieri due. Come è
tipo Corrieri due. Ok. Io non conosco il
colleghi
che vuol dire
c'ha prodotto autonomo. Ah ah. E quindi
e sfruttando quella conoscenza già
pregressa introduciamo di tuning e
introduciamo risultati. Ok. Ok. Quindi
posso assumere che voi automi stati
finiti sapere cos'è linguaggi, queste
robe qua. Ok. Boh, meglio. Ok. E secondo
te che cosa facciamo? Secondo lei cosa
facciamo?
Venendo dall'Inghilterra do lo you a
chiunque. Quindi cosa faremo in questo
corso? Buttala là. Cioè il corso si
divide in due parti abbastanza piccola.
Ah ah lo sentite? No. Il corso si divide
con due parti piccole perché sono 6 CPU.
Una parte è di complessità e invece
l'altra è di computabilità. Sì. E
casomai e se riesci a sostanziare questa
cosa. Cioè quando parliamo di
calcolabilità secondo lei che cos'è?
Il film bisogna definire e anzi
riprendere cosa significa computare. M m
e ci hanno accennato che può computare e
cioè la la definizione di computare
viene da un paper di Touring. Ah, ok. E
siete più preparati dell'Ingilterra.
Ok. Ok. E dopodiché si analizza la parte
di complessità m e immagino che eh
verranno mostrati dei regeni che
dimostrano che casomai un problema è
intrinsecamente
riuscite a sentire un problema
intrinsecamente un problema appartiene
intrinsicamente a una classe di problemi
sì sì sì sì sì poi avere vari tecnic non
deve non deve dare la risposta giusta
quello che crede che questo corso
Sì, sì. Poi varie tecniche. Sì, secondo
lei come faremo questa roba?
Eh, dimostreremo teoremi. Dimostreremo
teoremi. Ok. Quindi saremo formali?
Spero di sì. Ah, spero di sì. Ok.
Secondo lei, quali difficoltà potremmo
incontrare durante questo corso?
è una domanda una domanda è una domanda
un po' particolare. Questo proviene da
dagli studi del funzionamento della
mente. Se noi sappiamo quale genere di
difficoltà potremmo affrontare, le
riconosceremo nel momento in cui si
manifestano e se abbiamo una strategia
possiamo casomai preso un problema
dimostrare che quel problema lì non è
risolutibile. Ok. Ma quale difficoltà
avremo nello svolgimento del corso?
Intendo,
cioè nello studio, nell'approccio di
questo corso individua delle possibili
difficoltà che potremmo incontrare. Poi
magari non incontriamo niente. No, ok,
andrà liscio. Benissimo. Cioè è più
complicato il dopo, ovvero prendere un
problema che ci viene posto che stare
che usciamo che non è possibile
risolver. Ok. Ok. Ah. Ok. Tià. Sì,
l'esame se sarà la parte di Ok? No,
speriamo di arrivare assieme all'esame
in modo che che siamo pronti, eh, cioè
non voglio fare nulla che vi devasti o
cose del genere, eh, però essendo Vabbò,
poi ve lo dico. Ok, un altro eh, lei no,
sulle difficoltà volevo dire che No,
partiamo dalla prima.
Anche se magari ripeto second Sì, perché
voglio capire qual è il sentimento
dell'aula. No, vabbè, per quello mi
aspetto sì teorica, quindi unità
principalmente. Sì. M mi aspetto tanti
teorie anch'io, non aspettative se non
quelle di teorie. Ok. Ok. Ok. No, e
questo per lei o per la classe, secondo
lei questo è un problema. Cioè io non ho
idea di quanto è sia stato formale il
vostro corso di laurea finora.
Finora direi che abbiamo avuto l'esame
di equipaggi di programmazione al
secondo anno. Una parte di un po'
decorare. Ah, ho capito. Sì. E poi Ma
quindi finite state automating
glam, questi teoremi li avete proprio
dimostrati come le hanno Ok. Ok. Poi al
primo anno. Logica. Logica. Ok. Quindi,
insomma, un po' di sta roba l'avete
vista. Ok. Ok. Buono. Buono. No, come
difficoltà. Appunto, è avendo tutte le
cose,
cioè essendo essendo in un così teorico,
ah a volte le cose possono essere troppo
teoriche, cioè ok, almeno può diventare
difficile capire poi per bene cosa
stiamo facendo. Sì, interessante. Eh,
come pensa che potrà superare questa
difesa? Eh, non so se ci sono dei casi
pratici rispetto a tutto quello che
vediamo, perché alcune cose a volte
rimangono sempre Sì. un po' fumose, però
ho capito. Quando dice fumose intende
poco chiaro che non le può applicare o
che non vede un'applicazione
che non de propria applicazione, cioè
nel senso Ok, ho capito. Sì, sì, sì. Ok,
ok, ok, ci sta, ci sta. Grazie. Qualcun
altro? Sì,
vai.
Io Sì, sì. Allora, io in realtà
programma diversi perché matematica.
Matematica. Ok. Quante di matematica ci
stanno qua?
Eh, quindi voiete
a fondo. Ok.
Alr, quindi in realtà sono state le
risposte che dato dei due ragazzi, cioè
io non non ho conoscenza queste, cioè
non c'ho nemmeno a capire in particolare
cosè un linguaggio questa cosa qua ad
esempio quell di auto auto. Vabbè,
riprendiamo velocemente tutte in queste
primissime che una domanda a lei che
secondo lei è sono in grado di seguire
questo corso? Allora, io direi di sì.
Allora, domanda per i matematici.
Avete programmato in vita vostra? Cioè,
sapete cos'è un programma? Un po' di
Pyon. Un po' di Python. Ok, va
benissimo. Sapete pensare
algoritmicamente? C'è dato un problema
pensare un algoritmo e un po' di codice?
Certo, anche pseudocodice, cioè sapere
come si fa a mettere assieme dei passi
algoritmici. Quello lo sapete fare?
Sapete che da un programma noi possiamo
chiamare una funzione?
Ok, questo è quello che ci serve. Vabbè,
proprio basico. Basico. Poi cos'è un
automa? Questa rompetta qua voi non
l'avete mai visto questo concetto di
automa? Cioè prossima lezione partiamo
proprio dagli autom così
facciamo un passo pregresso rispetto
alla martina di Touring, dedichiamo un
po' di tempo al concetto di automa e poi
passiamo a Theory Machines che sono
automi un po' più sofisticati. Ok.
Secondo lei di cosa ci occuperemo?
Ma eh le poche cose di cui abbiamo
sentito parlare anche noi matematici
sono contestato computazionale.
Che cos'è secondo lei? Eh cercare di
quantificare in variabili eh le
variabili che scegliamo all'inizio
quanto un algoritmo eh
cioè come questo algoritmo dipende dal
dato che camo inizialmente. Ok. Ok. Ok.
No. E secondo lei come affronteremo
queste topics? Io mi aspetto molto molto
diciamo come fa matematici adi problemi
forse non sarò così teorico come dei
aspetti o così formale per per per
grande rf degli altri studenti. Però
però cercheremo di essere formali.
Questo sì. Cercherò per quanto possibile
di essere formale. Ok. Secondo lei quali
difficoltà ci potrebbero essere? Però
capisco che il background per voi è
sostanzialmente differente, quindi per
voi l'approccio di secondo lei quali
difficoltà potrebbero esserci
nell'approccio di questa materia?
Certo, dal punto di vista penso che
grand
non mi spaventa la teorica, mi
spaventano avere magari tutte le
conoscenze, alcune conoscenze che mi
servono per sapere. Sì, sì, sì, sì, sì,
sì. Ok, giusto per per ricapitolare,
così io sono sicuro che poi ci mettiamo
in linea. L'importante è che chi
proviene da matematica abbia
programmato,
cioè quindi no, non è necessario
conoscere uno specifico linguaggio di
programmazione, cioè l'importante è
avere lo skill che dato un problema io
riesco a pensare a una soluzione
algoritmica. Questo è quello che ci
serve. ci serve uno skill, non la
conoscenza di un linguaggio e questo è
un primo pezzo e poi aver verificato con
mano che da un programma io ne posso
chiamare altri. Questi sono i due
concetti che utilizzeremo forse proprio
alla fine quando parliamo di oracoli.
Ci serve giusto questa cosa qua. Per il
resto vi introduco tutto io. Alcune cose
potrebbero risultarvi già note, però
per gli altri studenti no. Quindi,
insomma, alcune cose da voi saranno
viste, magari spiegate male da me
rispetto ad altro modo migliore di cui
avete visto. Ok. Ok. Vabbè, grazie mille
così c'ho questa idea in mente, quindi
prossima volta auton. Alright, qualcun
altro
e poi rispondo io alle domande.
Someone else noi.
Ok, cool. Adesso rispondo io alle
domande
per spiegarvi un po' il taglio che
voglio dare a questo corso, ok?
Di cosa di cosa ci occupiamo in questo
corso? Ok, noi ci occuperemo, come ho
già mezzo accennato all'inizio, di
essenzialmente due topic
della dell'informatica teorica.
L'informatica teorica è un è un
è un'area vastissima, ok? Però noi di
quello che di cui ci occuperemo sono due
arie e sarà anche non troppo
approfondito, ok? Vedremo da un lato la
calcolabilità,
ok? E dall'altro la complessità, ok? In
genere queste cose vengono insegnate
assieme perché sono più o meno legate e
perché alla base del loro studio hanno
questa nozione di macchina di Touring
che è una cosa che non introdurremo fino
a prossima lezione. Ok? Come ho
accennato prima, la macchina di Touring
è un autonoma, quindi per voi che avete
già visto il corso di linguaggi sapete
cos'è un automa. Per voi che non avete
visto cos'è un automa lo spieghiamo la
prossima la prossima volta. Ok? Quindi
quello che mi preme è che questo corso
sia sostanzialmente autocenuto. Cioè
ovviamente non vi posso spiegare come si
fanno le addizioni, però tutto quello
che è relativo a questa materia spero di
riuscire a concentrarlo in maniera tale
che insomma ci sia quanto minimo
possibile la necessità di conoscenze tra
ingressi. Ok?
Ok. Alrgri. Quindi, da un lato abbiamo
la calcolabilità dei problemi e
dall'altro abbiamo la complessità dei
problemi. La prima cosa su cui voglio
che voi facciate attenzione è le parole
che ho usato adesso:
calcolabilità
dei problemi
e complessità dei problemi. Ok? Qui
magari per voi che siete informatici che
siete più abituati allo studio di
algoritmi eccetera, avete magari spesso
sentito parlare della complessità degli
algoritmi,
ma non della complessità dei problemi.
Ok? Il nostro focus in questo corso non
saranno tanto gli algoritmi, cioè ne
vedremo tantissimi di algoritmi, ok? più
che altro idee algoritmiche, perché non
ci fracasseremo guardando alberi, ste
cose qua, magari le useremo perché ci
servono, però cioè il nostro focus
principale in questo corso non sarà
tanto studiare proprietà degli
algoritmi. Io assumo che voi gli
algoritmi sappiate gestirli, ok?
Adesso non è necessario una conoscenza
super approfondita, ma sapere come
risolvere, come istruire una macchina
per risolvere in maniera automatica è un
problema. Ok? Questo questo è uno sill
che mi aspetto che voi abbiate. Ok?
Allora, da un lato, quindi, abbiamo
calcolabilità dei problemi e complessità
degli algoritmi, dei problemi, sorry,
dei problemi. Ok? Quindi il nostro focus
non sarà tanto gli algoritmi, ma saranno
i problemi, perché noi dei problemi
vogliamo capire quali problemi si
possono risolvere con un computer e
quali problemi non si possono risolvere
con un computer. Ok? Adesso
riferisco soprattutto agli informatici
che ne avrete visti molti di più
rispetto ai vostri colleghi di
matematica, ok? avrete fatto progetti,
seguito corsi, tesine, cose varie e
insomma vi avranno riempito di ste cose.
Voi vi siete mai scontrati con un
problema che è irrisolvibile, ma non
perché non ci siete riusciti voi o
perché non ci sono riuscito io, ma che è
un problema che cioè possiamo sbatterci
la testa?
Non se fa, non si fa. Ti è mai capitato?
Vabbè, ci sono quelli che ci hanno
disegnato qua. Ah, ok. che conoscete,
ok? Sì, sì. La terminazione di un
programma, per esempio, equivalenza fra
programmi sopra un certo livello dià.
Sì, sì. Eh, poi vabbè, il fatto che un
programma calcolo via costante, una
funzione costante Sì. Sì. E cose del
genere. Ok. Ma voi mentre dovevate fare
i vostri progettini eccetera, vi siete
mai scontrati con un problema che cavolo
questo non si fa?
Io no,
ok.
È abbastanza naturale perché perché la
nostra testa, la nostra mente lavora su
cose che siamo in grado di risolvere.
Cioè i problemi, vedremo che i problemi
irrisolvibili sono molto di più dei
problemi irrisolvibili, ma sono proprio
tanti di più. Solo che noi ne conosciamo
molto pochi perché il nostro modo di
ragionare sulle cose fa sì che la nostra
testa vada su cose che riusciamo a
gestire. Per quello in genere ci
focalizziamo su problemi che siamo in
grado di risolvere perché è così che li
approcciamo. Ok?
Adesso voi tutti avete un computer,
voi tutti avete un computer, voi tutti
vi sarete, immagino, scontrati con il
problema
di dover scegliere un antivirus o
qualcosa del genere, ok? Non lo so, ce
l'avete un antivirus? Io non ce l'ho.
Ok, ce l'avete un antivirus? Ok?
Come avrete notato, magari scegliendo
l'antivirus, no? Avrete notato,
magari che ci sono le comparazioni,
fanno dei test bla bla e così, eh no,
avrete notato che non ci stanno
antivirus perfetti.
L'avete notato questa cosa?
Cioè io non posso andare, che ne so, da
Microsoft, da chi altro. Scusa, me lo
fai un antivirus perfetto? C'è un
antivirus, no, che ogni volta che ricevi
in input un pezzo di codice è in grado
di stabilire se quel codice è malevolo o
meno. Ok? Questo dovrebbe saper fare un
antivirus perfetto, no? Che visto un
pezzo di codice qualsiasi, magari pure
compilato, che ne so, quindi un pezzo di
codice macchina che alla fine comunque
se noi lo disassembliamo
possiamo tirare fuori il codice
assembler, alla fine è un programma, no?
Allora, il nostro il nostro problema
potrebbe essere dato un pezzo di codice
in input, noi vogliamo stabilire se quel
pezzo di codice è malevolo o meno. Ok?
Questo è un problema irrisolvibile.
Si può dimostrare che fare l'antivirus
perfetto non si può fare. Ha detto, ma
noi li compriamo, cioè che stiamo
pagando? Allora, come potete notare, gli
antivirus che noi compriamo sono tutti
approssimati, sono tutti programmi che
danno una risposta approssimata, hanno
falsi positivi, hanno falsi negativi,
eccetera. Perché? Perché si può
dimostrare, e magari in una delle
esercitazioni lo faremo, che scrivere
l'antivirus perfetto, quando io dico
perfetto intendo che è un pezzo di
programma che è in grado di ricevere in
input pezzi di codice ed è sempre,
questo è la chiave del tutto, no? ed è
sempre in grado di rispondere
correttamente se l'input in l'input,
cioè il programma che riceviamo input è
male o meno. Questa cosa non si può
fare, cioè non si può fare in maniera
automatica. Ok? Qualsiasi programma che
noi scriviamo, che noi potremmo scrivere
per la risoluzione di questo tipo di
problema, sarà sempre un programma
approssimato, cioè un programma che o ci
darà ci darà risposte sbagliate in
alcune circostanze, falsi positivi,
falsi negativi, eccetera. Infatti loro
si erano inventati, chi ha lavorato sul
mondo degli antivirus, si erano
inventati sta cosa delle firme che
andavano sempre aggiornate, no? Perché?
Perché io devo avere un database di
virus che ho visto in giro e quindi li
riesco a riconoscere. Ok? Perché in
linea di principio, se io vedo un pezzo
di codice che non ho mai visto prima, è
impossibile
è impossibile per una macchina riuscire
con certezza a discriminare pezzi di
codice malevoli da pezzi di codice non
malevoli. Ok? si può dimostrare, è una
cosa abbastanza semplice, si parte dal
problema della terminazione che è
qualcosa che voi avete visto, e si fa
vedere che quel problema si può mappare
sul problema di risolvere il problema
del virus, no? E si fa vedere, siccome
questi due problemi, l'intuizione,
siccome questi due problemi sono
isomorfi, se fossi in grado di risolvere
il problema dell'antivirus, allora sarei
in grado di risolvere il problema della
terminazione. Ok? Questa è la la
dimostrazione, molto semplice. Ok? Ok.
Quindi ci occupiamo, abbiamo detto di
calcolabilità e complessità di problemi.
Di cosa si occupa la calcolabilità?
l'abbiamo già detto, la calcolabilità di
un problema è dato un problema,
quello che noi vogliamo stabilire è ma
esiste o no un algoritmo
che gira su una macchina costruibile,
perché ovviamente se gira su una
macchina fantascientifica magari ne
troviamo, no? Allora, esiste un
algoritmo che gira su una macchina
realizzabile fisicamente
che è in grado di risolvere questo
problema. Quando diciamo è in grado di
risolvere questo problema, noi
intendiamo
noi intendiamo che dato un input o che
noi chiamiamo anche istanza di un
problema,
vogliamo essere sempre in grado di dare
la soluzione corretta. Ok? Questa èal la
calcolabilità dei problemi. Ok?
Noi non ovviamente ci dobbiamo
interessare della parte algoritmica per
risolvere queste cose bla bla, però
ovviamente noi la guarderemo da un
livello molto più astratto. Ecco perché,
come dicevo ai nostri colleghi da
matematica, non ci serve una conoscenza
approfondita di un linguaggio, ci serve
solo lo skill della capacità di pensare
a modi automatici e descrivibili in
qualche linguaggio di riuscire a
ottenere un risultato partendo da un
input. Ok?
Allora,
qua magari
posso pure scrivere qua.
Alri, quindi la nostra prima distinzione
che faremo nella prima parte del corso,
quello che saremo interessati è andare a
capire quali sono i problemi risolvibili
o decidibili. Sono tutte sinomini,
sinonimi, vi spiegherò perché, no? è il
nostro è il nostro primo task, no, della
prima parte del corso. Ci occuperemo di
capire se un dato problema si colloca
qua dentro o si colloca qua fuori. Ok?
Tutto quello. Quindi ci occuperemo di
capire ma io come faccio a capire se un
problema è irrisolvibile?
Ok? e quindi studieremo tutta una serie
di tecniche eccetera che ci permettono
di stabilire se un problema sta qua o un
problema sta qua. Ok? A intuito, secondo
voi come facciamo a stabilire che un
problema sta qua dentro?
Il modo più semplice è che esprimiamo un
gruppo che che lo risolve che lo
risolve. Ok? Cioè, siccome la per
definizione un problema è risolvibile se
esiste un algoritmo che lo risolve, se
dato un problema siamo in grado di tirar
fuori un algoritmo che lo risolve,
allora sta qua. Ok?
Come faremo a dimostr a mostrare che un
algoritmo che un problema sta qua?
Per assurdo.
Ok. Sì. Oppure per assurdo, cioè per
assurdo, ok? Oppure di solito si
riconuce al problema della fermata che
si dimostra in maniera abbastanza facile
per assunto che Sì. Ok. Quindi questo
problema della schermata lo conoscete
proprio bene, quindi siccome avevo in
mente di farlo dopo mi avete tagliato
metà della lezione. Ok? Allora, qual è
la parte qual è la parte comune alle
cose che avete detto? La parte comune è
che serve una dimostrazione formale, ok?
Perché secondo voi a intuito, no?
Supponiamo che stiamo lavorando per
un'azienda, no? E il nostro gran capo
ci dice m voglio battere la concorrenza,
ora scriviamo l'antivirus perfetto. Ok?
E ci molla questo problema da risolvere,
ok? Ci lavoriamo un mese, niente, due
mesi nulla,
ci sbatchiamo la testa per 6 mesi, va
avanti così abbiamo sempre risposte
approssimate. Ok, andiamo dal capo. Ci
siamo riusciti. Sei tu che non sei in
grado? Come? Ma io c' ho lavorato
tantissimo. No, sei tu che non sei in
grado. Allora, noi dovremmo in qualche
modo riuscire a argomentare questa cosa,
no?
Allora,
il fatto che
ci abbiamo lavorato sopra per mesi, no?
E abbiamo provato, che ne so, un
centinaio di soluzioni e nessuna di
quelle funzionava.
È sufficiente a dire che il problema è
risolvibile?
No. Che cosa dimostra?
Che quelle 100 soluzioni non andavano
bene? Tutto qua. Questo è quello che
arriviamo. Noi ci possiamo provare
100000 volte. Ok? Se tutti i nostri
tentativi non risolvono il problema, non
ci stanno dicendo che il problema è
irrisolvibile, sebbene ci possano dare
un'intuizione a riguardo, ok? Ci stanno
solo dicendo che i tentativi fatti non
vanno bene. Ok?
Supponiamo di essere ancora al lavoro su
questa problema dell'algoritmo bla bla.
Ok?
Secondo voi quanti supponiamo di star
programmando in Python? Python lo
conoscete tutti?
Quanti programmi si possono scrivere in
Python?
Quanti?
Infiniti. Infiniti. Ok. In Pyon possiamo
scrivere infiniti programmi. Ok. Come
facciamo a essere sicuri che nessuno di
quelli risolve il problema
dell'antivirus?
Una soluzione è che li proviamo tutti,
no? Mettiamo tra uno dopo l'altro.
Ecco, pure che ciamo che un minuto ad
algoritmo, quanto tempo ci serve a
provarli tutti? Abbastanza. Abbastanza.
Abbastanza. Saremo un po' invecchiati
quando saremo arrivati al milionesimo
algoritmo. Ok? Il provarli tutti non è
una strategia, cioè è una strategia, ma
è una strategia per impazzire, cosa che
vorremmo evitare. Allora, vieni già
un'altra cosa, ok? Dobbiamo dimostrare
che nessuno di quegli algoritmi è in
grado di risolverlo. Ok? Per far questo
ci serve una dimostrazione formale, cioè
noi dobbiamo entrare nella struttura del
problema
e far vedere che per come è strutturato
il problema possiamo sbattere la testa
quanto vogliamo, non avremo mai un
algoritmo che è in grado di risolverlo.
Ok? Cioè, quindi questa è la differenza
sostanziale fra provare che un problema
sta fuori l'insieme e provare che un
insieme sta che un problema sta dentro
l'insieme, ok? Qui ci basta un solo
algoritmo, ok? per dimostrare
che eh il problema è risolubile, qui ci
serve una dimostrazione formale, cioè
qui noi dobbiamo andare sulla struttura
del problema per mostrare che il
problema non si risolve. Ok? Quindi il
la questione della complessità sarà
essenzialmente, dato un problema,
riuscire a collocarlo qua dentro o qua
fuori. Tutto qua. Ok? ci inventeremo dei
modi, vi spiegherò delle tecniche
eccetera. Prego. Dimostrando che un
problema non è risolvibile, posso
dimostrare che anche che è risolvibile,
cioè cioè piuttosto che andare, diciamo,
forza a cercare un algoritmo che me lo
dimostra, io parto dalla dimostrazione e
da questa dimostrazione, cioè la mia
domanda è scopro solo che non è
risolvibile o di conseguenza scopro
anche che è risolvibile, quindi mi metto
a 50.
Allora, la questione è che ovviamente se
io devo dimostrare che un certo problema
è risolvibile, io devo arrivare a un
algoritmo che sia in grado di
risolverlo. Ok? Adesso
provare tutti gli algoritmi per vedere
se arriviamo a qualcosa che risolva un
problema è è impegnativo, cioè come
strategia per dimostrare che qualcosa è
risolvibile. Ok? Però è interessante,
nel senso io posso pure,
ad esempio, parliamo dai, dei programmi
Python, no? I programmi Python noi li
possiamo codificare in delle stringhe,
alla fine un programma Python e una
stringa. Le stringhe le possiamo
ordinare, no? Per lunghezza quelle che
sono lunghe uguali le ordiniamo in
maniera alfabetica. Ok? Quindi in linea
di principio io mi posso costruire un
while talmente grosso che mi gira su
tutti i programmi Python risolvibili ma
scrivibili. A un certo punto se un
tentativo di quello mi risolve il
problema, potrei dire sì, questo
problema è risolvibile. Il la questione
di questo approccio è che prende una
marea di tempo e se il problema non è
risolvibile io non lo saprò mai perché
quel guai mi girerà all'infinito. Ok?
Quindi, però in linea di principio uno
lo potrebbe fare. La questione è che non
mi dà garanzia di uscita. Ok, prego.
Sempre su questo tema, cioè, quindi noi
l'unico modo che abbiamo di dimostrare
labilità è la cioè non possiamo
dimostrare laità senza creare un
algoritmica.
Questo lo vedremo. Allora, quello che si
può fare, questo lo vedremo. C'è una
tecnica particolare che si chiama
riduzione, la vedremo poi come dimostro
che l'antivirus è isomorfo al problema
della fermata e che quindi quel
problema, siccome il problema della
fermata è irrisolvibile, allora l' il
problema dell'antivirus è irrisolvibile
perché i due problemi sono isomorfi. Se
io dimostro che un certo problema è
isomorfo a un altro che so risolvere,
allora io ottengo la decidibilità di
quell'altro. Ok? Però questa è una cosa
che vedremo tra qualche lezione, ok?
Però sì, è un approccio. Poi c'ho un
aneddoto di quando ero studente di come
abbiamo risolto delle cose e vi farò
vedere, però sì, in linea di principio
uno può fare questa cosa qua, ok?
mostrare che due problemi sono isomorfi.
Se uno dei due lo conosco essere
decidibile lo deve essere per forza
l'altro. Ok?
Quindi per rispondere alla seconda
domanda, how are we going to achieve
that?
Siccome noi dobbiamo dimostrare,
dobbiamo dimostrare che un problema sta
qua, dovremmo essere formali, ok? Quindi
avremo teoremi, eccetera, ok? Però mi
sembra di capire, e questa è una cosa
buona, che voi ne avete già visti un
po', quindi un'infarinatura di
formalismo ne avete, ok?
Mi sembra mi sembra di capire che vi
metto in una posizione molto migliore
rispetto agli studenti che avevo in
Inghilterra dove era il primo corso
formale che vedevano li vedevo un attimo
spaesati, era da inventarsi un po' la
cosa. Prego. Quindi il problema di
classificare un problema come decidibile
indecidibile non è un problema
decidibile, è indecidibile.
Quindi anche noi faremo delle
approssimazioni, cioè capiamo in un
programma un programma specifico magari
si può sapere se è decidibile o no,
mentre un problema non un un problema,
mentre tutti i problemi, cioè capirlo su
tutti i problemi è indeciso, non lo non
lo si può automatizzare, no? Cioè è una
questione di inventiva, quindi quello
che facciamo noi è indecibile. Cioè
quello che noi umani facciamo, cioè
stabilire se un problema è decidibile o
meno è di per sé una questione
indecidibile, cioè una questione che non
può essere automatizzata. Ok? Quindi
ovviamente ci stiamo buttando in un'area
abbastanza, cioè dove la creatività
nostra fa la differenza. Il computer non
sarebbe in grado di farlo. Ok?
Alright. Finisco di rispondere alle
domande e poi facciamo pausa. Ah, quindi
vedremo cose formali, bla bla eccetera
che però, insomma,
sono confident a questo punto che siete
in grado di di seguire perché ne avete
già fatte. Ok?
Che difficoltà andremo a incontrare?
Ovviamente la difficoltà di approcciare
le questioni da un punto di vista
formale. Questa è la cosa che renderà il
tutto un po' più complicato, ok? Perché
dobbiamo sviluppare un linguaggio
formale. Quello che veramente mi preme
da questo corso
è questa cosa qua, più che trasferirvi
contenuti, perché quelli vabbò so cose
che aprire i libri e si fa. Quello che
mi preme
è trasferirvi degli skill, ok? La
capacità di formalizzare problemi, la
capacità di pensare in maniera precisa.
Ok, è chiara. Quello è lo skill che mi
mi preme trasmettervi, perché tra
qualche non dico nemmeno fra qualche
anno, fra dopo due settimane che avete
passato l'esame di sta roba ve la sarete
dimenticata con buona probabilità e con
altissima probabilità non la rivedrete
più in vita vostra, ok? Perché è una
cosa talmente settoriale
dell'informatica, cioè che quando
andrete a lavorare nessuno vi chiederà
il teorema di Rise o come fai a
dimostrare che il problema dell'arresto
è indecidibile. Ok? Però quello che mi
preme che rimanga a voi è la capacità di
formalizzare. Ok?
Questo è veramente importante perché
questo lo potrete riutilizzare nel mondo
del lavoro. Cioè io non assumo che molti
di voi perseguiranno una carriera nella
ricerca né accademica né industriale.
Molti di noi alla fine fanno altri
lavori, ok? Però in tutti questi lavori
essere precisi, cioè viene il
committente, mi chiede di progettare
qualcosa, no? E inizia a parlare di aria
frutta, ok?
Allora, qual è il problema di un
committente che ci chiede aria fritta?
Ambiguo e quindi è difficile capire cosa
vuole. È cap è difficile capire cosa
vuole e quindi
fa capire cosa vuole possibilità e
quindi e quindi lui si può lamentare
sempre.
Sapete dove sta l'inghitto. Se uno viene
e vi fa richieste che non sono precise,
quello vi può armare questioni dalla
mattina alla sera perché eh, ma io non
volevo questo. Eh, ma tu non me l'hai
detto, eh, ma tu non me l'hai chiesto.
Ok? Cioè, quindi la capacità di
formalizzare in realtà è di essere
precisi e è questo è il mio scopo in
questo corso, ok? sfruttare
il topic dell'informatica teorica bla
bla, ma più che altro per imparare ad
organizzare il pensiero in maniera un
po' più precisa, ok? In maniera
puntuale,
come supereremo la problematica,
appunto, della formalizzazione? Quindi
il formalizzare per noi sarà solamente
una scusa, ok? per impratirci nel
diventare più precisi e nel diventare
abili a gestire, no, le ambiguità, ok?
Che quello nel mondo del lavoro ci
serve. Come lo faremo? Ok? Ovviamente il
modo usuale, vi spiegherò le cose,
interagiremo perché vorrò vedere un po'
come mi state appresso. Cercheremo di
inventarci cose assieme.
Per quanto mi è possibile, una cosa che
io ho imparato durante la mia carriera,
quello che cercherò di fare è spiegarvi
cosa faccio io nella mia testa, perché
io vi posso pure scrivere le cose alla
lavagna, però vedete il prodotto di
quello che faccio io nella mia testa,
no? In genere questo non viene spiegato
il processo interno. Ok? Allora, uno dei
miei obiettivi sarà, per quanto
possibile spiegarvi, guardate che io
nella mia testa faccio questo per
arrivare a questa cosa qua, ok? in
maniera tale da trasferirvi lo skill mio
che quello sui libri non ci sta scritto.
Ok?
Quindi, come potete vedere stiamo
registrando la lezione. Quelle le
metterò disponibili, una cosa che ci
sono abituato da tanti anni in
Inghilterra era proprio così di default.
C'era un tasto enorme sul
tavolo, premevi, partiva la
videoregistrazione. Ok? Quindi era
proprio di default la cosa, tutto che mi
ha registrato, quindi ci sono abituato
per me farmi registrare, ok? So che è
importante per voi per riuscire a
riguardare le lezioni eccetera. È
importante per me perché io l'anno
prossimo mi riguardo le registrazioni e
ehm
e poi mi serve per riorganizzarmi perché
insomma questa è la prima volta che lo
faccio dopo tanti anni perché lo
insegnavo in Inghilterra. Mi devo un
attimo organizzare gli argomenti, quindi
voi purtroppo siete un pochino cavi, eh.
Però mi serve a me per spostare
argomenti, ma cosa faccio fino alla
pausa? Cosa faccio dopo pausa? Io sono
questi appunti che mi prendo alla fine
della lezione e me la devo riguardare,
ok? Quindi mi serve a me,
quindi voi potrete riutilizzarlo. Quello
che ho visto in Inghilterra spesso è che
dopo qualche settimana l'attendance
delle lezioni precipita perché se è
disponibile registrarlo, per quindi
dovrei andare a seguire la lezione alle
8:30, lo capisco, farei la stessa cosa.
Ragazzi miei, fate un po' come volete.
La questione è che se siete qua
ci sono due ordini di cose positive. Da
un lato voi essendo qua avete la
possibilità di farmi domande, ok? Eh, su
su come sto ragionando, eccetera. Se ve
la guardate in televisione e dovete
limitarvi alle domande che faranno i
vostri colleghi. Alle volte ci
acchiappano, fanno le stesse domande
vostre, altre volte no. Quindi vedete un
po' voi
la vostra presenza qua serve a me perché
gradirei l'interagire e perché io
calibro la lezione sulle vostre risposte
non verbali
perché cioè voi tutti avete
un'espressione in volta, insomma riesco
a capire se mi state seguendo o meno,
no? Se siete dietro una telecamera io
questo non lo riesco a fare perché non
vi riesco a guardare in faccia, ok?
Quindi la calibrazione sul non verbale,
quella la riesco a fare solo se siete
presenti in aula. Eh, per il resto
mi sa che abbiamo detto tutto, giusto?
Mi guardo gli appunti, se mi ero segnato
altro.
Una domanda. Sì, queste registrazioni
per caricar su virtuale sono forno?
Come? Scusa, queste registrazioni
verranno caricate su virtuale o su
unaltra piattaforma? Verranno carite car
virtuale. Sì, le registro con Panopto e
le metto là sopra il link subirtuale.
Metto tutti i link da lì potete
accedere.
Structure of problems.
Yes. Penso che ci possiamo fare una
bella pausa.
Alr,
[Musica]
facciamo 10 minuti di pausa. 10-12.
Ok,
cool. Mi sono dimenticato ovviamente di
prima una cosa su questo perché abbiamo
parlato solo di calcolabilità, ok? Cioè,
dato un problema, noi ci vogliamo
vogliamo capire se esiste un algoritmo,
esisterà mai un algoritmo che risolve
questo problema con me. Ok? Questa è la
questione della decidibilità, ok?
Questo task, decidere se un arrivare a
capire se un problema è decidibile o
meno è esso stesso una questione
indecidibile, cioè una cosa che ci
arriviamo se ce la inventiamo noi. Ok?
Interessante. Non ci avevo mai pensato a
questo. E questa è la calcolabilità. Ok?
Prima parte sarà P 3 4 settimane, una
cosa del genere. Dopodiché abbiamo
dall'altro lato complessità.
Cos'è la complessità?
fra tutti i problemi decidibili.
Ok? Quindi ora stiamo portando il focus
dell'attenzione
a questo insieme qua, no? Quindi fra
tutto quello che c'è qua dentro,
dai, se è una cosa ovviamente che non vi
ho sottolineato, ma è semplice. Se non
capite mi fermate, eh.
Sono ben contento di ripetere e
inventarmi modi diversi di spiegare le
cose per farvi capire. Poi un'altra
cosa,
tendo a parlare veloce.
Se vado troppo veloce mi dite di
rallentare, ok? Perché io poi a un certo
punto non ci penso più. Questione della
decidibilità dentro fuori, decidibile,
non decidibile. Poi c'è la questione
della complessità. la questione della
complessità, la complessità di un
problema. Eh, ok, questa è la parte
importante di tutto ciò. Non siamo più
all'interno del corso di algoritmi e
strutture dati nella quale per la gran
parte immagino, vi siete occupati di
stabilire "Ma questo algoritmo è
efficiente o questo algoritmo è lento?",
cioè quanto è complesso l'algoritmo? Qui
stiamo passando ad un livello. Quello
che noi ci stiamo chiedendo qui non è
quanto complesso è un algoritmo, ma
quanto complesso è un problema, che è
un'altra cosa. Ok? Quindi, fra tutti i
problemi che stanno qua dentro,
noi ci
premerà
capire quali sono quelli facili
e quelli difficili.
Ok? Quindi in una prima parte noi ci
occupiamo, dato un problema, stabilire
se sto coso riusciremo a mai a
risolverlo, ok? Quella è la questione
della calcolabilità. Dopodiché l'altro
focus attentivo sarà: "Ok, ma fra tutto
ciò che è risolvibile
ci sono cose facilmente risolvibili e
cose difficilmente risolvibili, ok?
Quindi noi ci occuperemo di studiare la
complessità di un problema. dici "Ok,
questo problema si risolve. Ho un
bell'algoritmo che ci mette un'eternità
a risolverlo, ma lo risolve. Ok,
ma questo algoritmo ci mette un'eternità
perché non siamo stati intelligenti noi
a trovarne uno migliore o perché il
problema è talmente complicato che noi
non possiamo sperare di avere un
algoritmo efficiente. Cioè, quello sarà
il piano su cui ragioneremo.
stabilire se un problema ha una
struttura che ammetta un algoritmo che
lo risolva in poco tempo o un problema o
una struttura per i quali qualsiasi
algoritmo che lo risolve richiederà
comunque tanto tempo. Ok? Quindi la
complessità sarà sostanzialmente
studiare se un problema che è decidibile
stabilire se è facile o è difficile. Ok?
Tutto qua.
Magari, no, questa cosa potrebbe
tornarvi utile, che ne so, quando
andiate a lavorare vi danno un problema
tosto da da risolvere, quelli vi rompono
le balle, dice "No, sto algoritmo ci
mette troppo e
c prende un sacco di tempo e voi siete
in grado di dimostrare che il problema è
difficile", no?
A quel punto sapete che se il problema è
intrinsecamente difficile, se volete una
soluzione veloce
vi serve un algoritmo approssimato. Ok?
Quindi questo è un genere di skill che
potrebbe tornarvi utile una volta che
andrete a lavorare in azienda, cioè
poter riconoscere che vi girano da
risolvere problemi che siete in grado di
dimostrare essere tosti. A quel punto è
inutile che ci sbattete la testa a
cercare un algoritmo polinomiale. Non lo
troverete. Allora, quello che potrete
fare è inventarvi delle soluzioni
approssimate, cioè, ok, vogliamo una
soluzione veloce, benissimo, dobbiamo
usare delle oristiche, usare altri
approcci che ci permettono di avere una
soluzione velocemente, però a scapito
magari dell'ottimalità, ok? Magari non
troviamo la soluzione migliore, capito?
Che ne so, eh. Ok, facciamo qualche
esempio,
ok? Qualche definizione.
Cos'è
formalmente per noi un problema? Qua
iniziamo.
Complexity bla.
Definizione di problema, ved. Allora,
cos'è un problema?
Un problema è una relazione
che associa al momento non saremo
estremamente formali perché ci serve un
concetto che introduciamo la prossima
lezione, però per avere un'idea, un
problema è per noi una relazione
che associa
stringhe di input a stringhe di output.
Ok? Questo per noi è un problema. che ne
so il problema
della somma. Facciamo che gli appunti li
la prossima volta. Problema della somma,
ok? Un problema banalissimo, ok? per noi
è una relazione, quindi sono coppie, è
una lista di coppie in cui in prima
posizione abbiamo una stringa che è
l'input, per esempio, somma di due
numeri.
Ok? Quindi questo è l'input
e l'output è una stringa che è il
risultato che noi gradiamo,
ok?
Quindi
bla bla bla bla. Ok? Quindi noi possiamo
pensare a un problema come
essenzialmente una relazione, una
relazione tra stringhe. La stringa in
queste sono coppie, ok?
La stringa in prima posizione è l'input,
la stringa in seconda posizione è
l'output. Ok? Un problema viene
caratterizzato da questa relazione input
output. Ok?
Supponiamo di voler descrivere questo
semplicissimo problema che è il problema
della somma. Ok? Quanti di questi
elementi in lista dobbiamo mettere?
Infiniti. Ok? Quindi questa non è una
rappresentazione per noi funzionale, ok?
Perché non abbiamo spazio infinito. Che
cosa facciamo? Allora, noi invece di
dare una lista infinita, no, che è la
nostra relazione, la relazione noi la
descriviamo
a parole, ok? Quindi questo è il salto
che noi facciamo. Un problema
formalmente per noi sono coppie, ok? È
una relazione.
Siccome noi non possiamo descrivere
roba infinita, no? Ok. Quello che noi
facciamo è che la corrispondenza fra
input e output la descriviamo a parole.
Il problema di questa soluzione però,
cioè il descrivere questa relazione a
parole è che noi il potenzialmente
introduciamo della vagzza, ok? Perché la
descriviamo a parole,
possiamo risolverla in maniera completa
e totale? No, sta a noi riuscire a
utilizzare una descrizione abbastanza
precisa, ok? Quando descriviamo i
problemi, ok? Nella descrizione del
problema, allora noi tre elementi,
quando descriviamo a parola un problema,
noi tre elementi andiamo a cercare sui
quali noi dobbiamo sempre essere chiari,
ok? in maniera tale che per noi, nel
momento in cui andiamo a pensare un
algoritmo che risolve un problema,
possiamo stabilire se l'algoritmo è
corretto o non corretto, perché non so
se ve l'hanno mai detto, ma la proprietà
di correttezza degli algoritmi non è
intrinseca all'algoritmo stesso.
Cioè è come se io andassi all'uscita
dell'autostrada in Bologna, è corretto
andare a sud o andare a nord?
Dipende dove voglio andare. Dipende dove
voglio andare. Quindi un algoritmo non è
corretto di per sé. Un algoritmo è
corretto rispetto a un problema che deve
risolvere. Se risolvere quel problema,
allora è corretto per quel problema, seò
no no. Ok?
Per riuscire a risolvere questa
questione, allora noi quando descriviamo
un problema dobbiamo fare una
descrizione di tre elementi molto
semplice. Input. Che cos'è l'input del
problema? Cioè la string input che
cos'è? Cosa rappresenta? In questo caso
abbiamo cifre, solo numeri. Ok?
Quindi uno serve sapere cos'è l'input.
Quello che io vi invito, quando pensate
ai problemi, andateci proprio con questa
meticolosità, nel senso cos'è l'input,
come è rappresentato l'input, perché a
un certo punto inizieremo a usare roba
un po' strana tale per cui, cioè capire
che cos'è un problema, quali sono, cos'è
l'input, cos'è l'output, ci permetterà
di mettere ordine in una cosa che
altrimenti è un caos. Ok? Quindi il
primo strumento da imparare, secondo me,
qui è avere precisione nella descrizione
dei problemi. Quindi cos'è l'input, che
cosa rappresenta, com'è rappresentato.
Ok? Quindi dobbiamo sapere questa cosa
qua.
Ovviamente secondo pezzo della relazione
cos'è l'output?
Comeè rappresentato l'? Che cos'è? È una
stringa, no? È un insieme di cifre bla.
Ok? Che cos'è? Come è rappresentato?
input, output, verzo elemento è la
relazione, cioè l'output come dipende
dall'input, ok?
Dico, in questo caso,
problema della somma. Cos'è l'input? Due
numeri. Cos'è l'output? Un numero. Che
relazione c'è fra l'output e l'input?
L'output è il numero che è la somma dei
due numeri input. Ok?
Adesso, giusto un attimo, adesso voglio
sottolineare qui che questo problema è
di una banalità sconcertante. Quindi,
nel momento in cui stiamo descrivendo
cos'è l'output, stiamo anche dicendo
come si ottiene l'output dall'input. Ma
in linea di principio, su problemi più
sofisticati, questo non è detto che
nella descrizione dell'output noi siamo
in grado di dire come si ottiene
l'output dall'input. Anzi, per la gran
parte delle volte noi non lo diciamo,
non lo sapremo. Teorema del problema
della fermata.
Ok.
Problema della fermata, poi lo vedremo,
eh ce la dobbiamo fare. Problema della
fermata. Cos'è l'input del problema
della fermata? L'input è una stringa
che rappresenta un programma.
Ok? No, facciamo così, facciamo una
coppia.
Ok?
Così è simile a quello che c'è noi.
Cos'è l'input per il problema della
fermata? È una coppia in cui la prima
stringa è il codice di un programma, se
p Java, quello che vogliamo. E poi c'è
una seconda stringa che è l'input che
noi diamo a quel programma che riceve
una string input. Ok?
Cos'è l'output? L'output
è una risposta
y no.
Sì, no. Quindi è un puleano la risposta.
Che relazione c'è? Quindi l'input è una
coppia di stringhe in cui la prima
stringa è un programma, la seconda è una
stringa data in input a questo
programma. Ok? La risposta è un buleano,
cioè sì, no? Che relazione c'è sta fra
questi due?
Rispondiamo. Noi ci aspettiamo sì quando
il programma P ricevendo la stringa I in
input a un certo punto si ferma.
Rispondiamo o no? Se il programma P
ricevendo input la stringa I non si
ferma mai. Ok? Va il loop. Ok? Quindi
nella descrizione, questa è una cosa
importante, nella descrizione che
abbiamo fatto del problema, abbiamo
detto che queste sono stringhe, abbiamo
detto che questo è un bule a questo
sostanzialmente è come dare la firma di
una funzione, no? Questo è quello sono i
parametri in input e questo è il tipo
del del risultato in output. Ok?
Dopodiché la relazione l'abbiamo
descritta a parole in quel modo, cioè
noi vogliamo dire, vogliamo rispondere
se il programma P processando la stringa
in input si ferma o meno. Adesso in
questa descrizione che stiamo facendo,
come potete notare,
non stiamo in alcun modo dicendo
come si ottiene questa risposta.
Partendo da questo punto, stiamo solo
descrivendo che relazione c'è fra. Di
fatto, come voi sapete già da dai vostri
studi, un algoritmo del genere non
esiste. Ok? Dovrei riuscire a farvelo
vedere anche oggi, ok? È chiaro? Quindi,
primo concetto che è importante, cos'è
un problema? Un problema è una relazione
input output fra string.
Lo descriviamo a parole e per questa
ragione dobbiamo essere il più precisi
possibili. Che cosa ci richiede a
descrivere un problema? mi chiede
descrivere cos'è l'input codificato, che
significato ha, cos'è l'output, come
codificato, che significato ha. Terzo,
qual è la relazione dell'output rispetto
all'input, cioè che cosa ci aspettiamo
di vedere qua nella seconda colonna? Ok?
Noi non siamo tenuti nel momento in cui
descriviamo il problema a stabilire come
l'input, come l'output viene calcolato
dall'input. Ok? Quello è il problema di
è una questione che si di cui si occupa
colui che scriverà semmai esiste un
algoritmo per risolvere quel problema.
Ok? Chiaro per tutti? Alri. Prego. La
definizione di problema non collassa al
sulla definizione di funzione? Non
sempre perché
eh
tu si può avere un input su cui si hanno
più risultati. Più risultati. Sì.
Algoritmi istruttori dati l'avete fatto?
Cos'è un grafo, un albero? Questo è i
matematici. Cos'è un grafo? Pallini e
ges. Ok. Pallette e archi. Ok? È una
sorta di mappa in cui abbiamo i pallini
che sono i nodi, ne vedremo tanti di ste
cose, eh? e gli archi che le collegano.
Ok, problema.
M pa
del percorso,
dato in input un grafo,
un nodo sorgente e un nodo destinazione.
Ok? Quindi sto descrivendo
l'input che è una tripla, un grafo, un
nodo sorgente e un nodo destinazione. Io
voglio in output un percorso, se esiste
dal nodo sorgente al nodo destinazione.
Tipo voglio andare
da qui a qui,
uno è questo, l'altro è questo, un altro
è questo qua, ad esempio. Quindi cosa
abbiamo? che l'input è lo stesso.
Abbiamo lo stesso grafo, lo stesso nodo
sorgente, lo stesso nodo destinazione.
L'output sono tre percorsi distinti,
quindi una funzione, sebbene uno può
scegliere di modellarlo in quell in quel
modo, in questo modo un po' ci salta, ci
perdiamo il fatto che possiamo avere più
risposte. Ok? E questa è la ragione per
cui preferisco definirla come relazione.
Se guardate le lecture notes di di
Calauti per lui un un problema è una
funzione. Ok? Però per me lo trovo
meglio descriverlo come una relazione.
Ok? Quindi eh la definizione di problema
collassa alla definizione di funzione
non deterministica.
Sì, però quello che noi vorremmo avere è
che le funzioni siano relazioni nel
quale però per ogni pezzo, per ogni
stringa specifica in prima posizione c'è
una sola stringa specifica in seconda
posizione. Ok? E questa è la ragione per
cui la definisco come relazione. Poi,
insomma, non è che sto concetto di
relazione la la useremo spesso. Era
giusto per farvi vedere che, insomma,
per farvi vedere che
serve formalità nel momento in cui
descriviamo i problemi, ok? Ci serve
descrivere l'input, l'output e la
relazione fra i due, ok?
Allora,
uno dei problemi, per esempio, è dato un
grafo, problema della connzione o del
percorso, no? Dato un grafo e un nodo
sorgente S è un nodo target T, noi
vogliamo dare in output un percorso. Ok?
Questa cosa accade comunemente, non sui
nostri cellulari. Io voglio andare da
qui a Portafatello. Vediamo un po' che
suonano stasera. Google Maps mi dà la il
percorso. In genere quando voi fate
questa ricerca quanto tempo ci mette a
rispondere?
Pochissimo. Il problema è facile. Questo
problema è un problema che ricade qua
dentro.
P sta qua.
È un problema facile per noi. I problemi
facili sono, vedremo, i problemi che si
risolvono in tempo polinomiale. Esiste
un algoritmo che risolve PA in tempo
polinomiale, quindi Path sta qua dentro.
Problema simile su un
sempre su un grafo.
Dato un grafo
input, quindi l'input è veramente
simile, eh? Dato un grafo,
vogliamo in output un Hamiltonian Cycle.
Sapete tutti cos'è un Hamiltonian Cycle
su un su un grafo? No. Ok. È quel
giochino che facevamo quando er quando
eravamo bambini, no?
Su questo grafo noi vogliamo un percorso
cycle, quindi è un percorso che parte da
un nodo, gira e ritorna allo stesso
nodo, quindi per questo lo chiamiamo
cycle perché è un ciclo.
Un ciclooniano. S è un ciclo, quindi è
un percorso che parte da un nodo, li
attraversa tutti esattamente una volta
senza passare due volte per lo stesso
nodo. Quello è la parte importante. Ok?
Noi facciamo la casetta, c'era quel giro
strano e facciamo l'emiltone cycle sulla
casetta. Ok? Allora, si può dimostrare e
dimostreremo che il problema di dato un
grafo, quindi l'input è veramente molto
simile rispetto al problema del fatto,
ok? Là abbiamo un grafo, qua abbiamo un
grafo. Calcolare un evintonian cycle è
un problema molto più complicato. È un
problema che sta qua,
un problema di quelli tosti, non
estremamente tosto, ma tosto. Ok? Poi ci
stanno i tosti, i tostissimi, insomma,
andando sempre più verso il bordo. Ok?
Hemonian è un problema di quelli
difficili, cioè quello che si possiamo
dimostrare a un certo punto è che
Hamiltonian cycle, cioè riuscire a
stabilire se c'è esiste uniltonian cycle
su un grafo, non abbiamo modo migliore
che non generare tutti i possibili
percorsi. Cioè quello che si può
dimostrare lo vedremo che è un problema
inerentemente combinatorico, cioè non
possiamo fare meglio di così, possiamo
inventarci dei trucchi, delle uristiche
per velocizzare la cosa, però se
vogliamo un algoritmo corretto non ci
possiamo esimere da testare tutte le
possibilità sostanzialmente. Ok? Quindi
questa è la ragione per cui Emiltonyle è
difficile rispetto a path. Perché path
vi do giusto un'intuizione
per il percorso è come se per vedere se
possiamo andare da qui a qui è come se
potessimo dirigere la nostra attenzione
verso la destinazione. Dice ok,
guardiamo solo verso là. Emiltoan con
l'intuitivamente sta cosa non si può
fare, dobbiamo provare tutto. E siccome
tutti i possibili percorsi dentro un
grafo in numero esponenziale, sono
tanti, allora esplorarli tutti richiede
tanto tempo. Ok? Quindi puff è un
problema facile e Miltonian Cycle è un
problema difficile, ok? È un problema
difficile,
spiegheremo perché.
La definizione è un po' strana. È un
problema difficile perché non esiste un
algoritmo efficiente. Cioè questa sarà
la nostra distinzione fra problemi
facili e problemi difficili. Problema
facile è se esiste un algoritmo
polinomiale. Il problema è difficile se
non ci sta un algoritmo polinomiale. Ok?
Siamo molto rough su questi qua. Ok? un
attimo. Prego. E io ho una domanda che
praticamente due insieme e cioè la
distinzione tra decidibile e non
decidibili è una cosa
oggettiva e atemporale, nel senso che
con l'avanzare delle tecnologie delle
sospette di magari nuove strutture dati
usate non cambia.
Una domanda e seconda domanda. Invece la
differenza tra problemi facili e
problemi complessi non è così perché più
vado avanti più scopro. Cioè
se magari è un problema recidibile ma
con le conoscenze che abbiamo
attualmente ancora non c'è stato un
algoritmo che lo risolve, però io so che
prima o poi potrà trovarlo. Idem un
problema che adesso magari è complesso,
so che cioè posso sapere che poi Sì, sì.
Avete sentito tutti? Chiara per tutti la
domanda? Domanda molto interessante. Poi
vedremo i dettagli, però vi do
un'intuizione. Mi sa che halt problem
per oggi salda. Allora,
problema decidibile indecidibile?
La questione è una volta che un problema
è indecidibile, questa cosa è scolpita
nella pietra o no? Cioè, una volta che
stabiliamo che qualcosa è indecidibile,
è indecibile per la tecnologia che
abbiamo ora o lo sarà da ora per il
resto dell'eternità? Prima domanda.
Seconda, se un problema ora lo
classifichiamo come difficile, rimarrà
difficile per sempre o no? Ok, quindi
riguarda proprio la complessità
strutturale dei problemi, cioè che
riguarda la struttura del problema.
Allora,
quando un problema noi lo
classificheremo qui, sarà un risultato
scolpito nella pietra. Cioè, una volta
che noi siamo in grado di dimostrare che
un problema, almeno per la
formalizzazione che stiamo dando
correntemente, che un problema è
indecidibile, significa che non esiste
e non esisterà
in questo universo
un qualsiasi dispositivo fisico in grado
di risolvere il problema in questione.
Ok? Quindi è un'assunzione molto forte.
Nel momento in cui noi dimostriamo che
una cosa non è risolvibile,
non è che l'iPhone 15 non ci riesce, ma
l'iPhone 16 ci riuscirà. Non si fa.
Non esisterà
intelligenza in questo universo in grado
di produrre un dispositivo nella fisica
che conosciamo al momento che sia in
grado di risolvere una cosa che sta qua.
Cioè il problema dell'alting è
irrisolvibile per noi ed è irrisolvibile
per i marziani.
Non non esiste dispositivo fisico in
grado di fare questa cosa. Ok? Quindi
alla tua domanda, una volta che noi
stabiliamo che un problema è
irrisolvibile, questa irrisolvibilità è
un risultato stabile o dipende dalla
tecnologia? No, è un risultato stabile.
La cosa interessante è che il i primi
risultati di indecidibilità
che furono che furono
individuati da Alan Turing
furono dati in un in un'epoca storica,
gli anni 30, nel quale i computer
nemmeno esistevano. Ok? Quindi non era
una questione di "Ma quale tecnologia è
in grado di risolvere questa cosa?
La questione che Turing fu in grado di
risolvere fu molto più profonda, fu del
tipo "Ma se io ho un dispositivo
automatico che è in grado di seguire
delle istruzioni,
questo dispositivo sarà in grado di
risolvere qualsiasi cosa".
In quel momento lui dimostrò, sebbene
non esistessero fisicamente dei
computer, perché stiamo parlando degli
anni 30, non ci stavano le
le calcolatrici a macchinetta, eh quello
quello era il computer del tempo, ok? Ci
stava la però quella per esempio non era
ancora stata costruita la differenzial
engine di Babbag. Quello era un computer
che ora sappiamo essere avere avere la
potenza di calcolo dei computer moderni.
Cioè se avessimo una differenza all
engine enorme avrebbe il potere di
quello che sappiamo fare. Ora magari
sarebbe più lento, però sarebbe in grado
di calcolare tutto. Quindi non c non
c'avevano
dei computer fattivi. I primi computer
fattivi sono degli anni 40 che furono
sviluppati per il calcolo dei missili,
no? Le traiettorie balistiche eccetera.
Ok? Quindi i risultati di di
calcolabilità precedono la tecnologia.
Noi sapevamo già negli anni 30 che sem
mai fossimo stati in grado di costruire
delle macchine
programmabili,
quelle macchine non sarebbero state in
grado di risolvere alcune questioni che
Turing individuò. Tipo il problema
dell'arresto lo individuo lui. Ok?
Eh, questione complessità.
Ma se noi piazziamo qualcosa fra i
problemi facili o difficili, quella cosa
tenderà a a rimanere così com'è. Allora,
qui la questione e direi chiudiamo con
questo. Oggi la questione è un po' è un
po' più sofisticata perché in quel caso
da un certo punto di vista dipende dalla
tecnologia disponibile. Allora,
nel momento in cui noi dimostriamo, no,
vi faccio un anticipo
e che
facili
esponenza
sperabilmente. ente le riusciremo a
vedere a fine a fine corso. Ok? Allora,
noi abbiamo all'interno della classe dei
problemi decidibili problemi per i quali
esistono algoritmi che li risolvono in
tempo polinomiale
e problemi per i quali noi sappiamo che
l'algoritmo più efficiente richiede
tempo esponenziale.
Vi ricordo che poi rivedremo tutte
queste cose, quindi anche per i colleghi
matematici tutti i concetti che
rivedremo. Quando parliamo di algoritmi
esponenziali significa che il tempo
richiesto, il numero di passi che
l'algoritmo deve fare per prima di
arrivare a soluzione è esponenziale
nella grandezza della rappresentazione
dell'input. Ok?
Allora,
nel momento in cui noi dimostriamo che
un un problema
appartiene alla classe dei problemi
esponenziali, eh per voi informatici che
magari avete già visto alcune classi di
complessità, exp non è NP. NP è una cosa
che sta qua dentro, è più piccolina. Eh,
qua parliamo di exponential time, sono
cioè problemi talmente tosti di cui
abbiamo la certezza che serva tempo
esponenziale per risolverle, ok? Cioè
che l'algoritmo più efficiente non può
fare meno di un numero esponenziale di
passi.
Questo risultato
è stabile o non stabile? Questo
risultato è stabile, cioè una volta,
però ora dovremmo introdurre una piccola
differenzia,
questo risultato è stabile nel senso che
una volta che noi sappiamo che il
problema richiede tempo esponenziale per
la sua soluzione, non si scappa, serve
tempo esponenziale. Ok?
Però qui c'è una questione di tecnologia
dietro perché magari riusciremo a
sviluppare dei manufatti, no, che
computano talmente velocemente che
aspettare tempo esponenziale diventerà
pollerabile, ma il problema avrà sempre
quella complessità. Ok? Quindi quando
poi alla fine si parla di quando si
parla di calcolabilità, quello è proprio
un territorio in cui non si non si può
arrivare, cioè il problema non si
risolve in maniera automatica, ti puoi
inventare il cavolo che vuoi, non
funziona.
Quando si parla di complessità, quello
che noi andiamo a a mostrare è che il
problema richiede una certa quantità di
tempo per essere risolto rispetto alla a
quanto grande è l'input. Ok?
Però qui è la questione, una volta che
noi sappiamo che strutturalmente il
problema richiede tempo esponenziale, la
questione è ok, ma questi passi
esponenziali quanto velocemente siamo in
grado di eseguirli? A quel punto fa la
differenza la tecnologia.
Quindi il fatto che un problema sia
risolvibile, cioè noi lo abbiamo
collocato nella classe expiolibili
in tempo esponenziale, quello è un
risultato che non cambia, però la
disponibilità di tecnologie che ci
permettono di processare ad altissima
velocità fa sì che quel problema
potrebbe diventare tollerabile
risolverlo, ok? però sempre esponenziale
rimane. Per quanti di voi stanno
pensando "Ah, ma il quantum computer?"
Quantum computer riescono a risolvere
una cosa che sta qua in mezzo, eh?
Nemmeno ANP riescono ad arrivare in
quantum computer. Questo qua. Ok, ultima
domanda. E qui si chiude? Ho visto una
mano alzata. Quantum computer. No, come
ha già risposto? Quantum computer. Ok. E
per oggi chiudiamo qua. Grazie mille.
Buona serata.
[Musica]