[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]