Newsgroup: it.comp.os.dibattiti
Titolo: interrupt, interrupt vector, eccetera

Ciao a tutti! Qualcuno può spiegarmi che cosa sono, a cosa servono e come
funzionano le interruzioni, i vettori di interruzioni e i gestori delle
interruzioni? Ho letto qualcosa in proposito ma non c'ho capito un
cacchio. Grazie mille!


$ cd /pub
$ more beer

 era clock (1/18 di secondo), 19h era reboot (ctrl+alt+canc, e se mettevi 
Ah, chi mi ricorda quale altro era? Mi pare 0Ch e veniva richiamato 
dall'int 08 (o viceversa)...



Un'interruzione, come dice la parola stessa, e` un
qualunque evento che interrompe il normale flusso
del programma.
Questo puo` essere HW, cioe` un segnale elettrico,
oppure SW, cioe` un'istruzione particolare oppure
una non-istruzione od un "fault" (per esempio, se
supportata, divisione per zero).
Nel momento in cui l'interruzione viene identificata
dalla CPU, questa, di solito, verifica di quale si
tratti e salta ad una subroutine particolare (gestore).
L'associazione tra "tipo" di interruzione e subroutine
e` fatta mediante i vettori di interruzione, ovvero
una tabella che contiene, per ogni interruzione,
l'indirizzo della subroutine che la gestisce.
Chiaro? ;-)
bye,
-- 
piergiorgio

 modificati). 
assopuffamente no, è l'interrupt handler che ha il compito di costruire 
il trap frame. INT, di suo, fa solo il push di EFLAGS, CS e EIP (non so 
se necessariamente in quest'ordine)
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

 
Sono almeno 7 anni che non scrivo in ASM... Cmq, la sostanza che voleva 
sapere è cosa sono.


 Sono almeno 7 anni che non scrivo in ASM...
era solo per amore della verità, ovviamente. Niente di personale


Grazie 1000 a tutti, ora mi è pò più chiaro, anche se di tutti quei numeri
e cose in assembly non c'ho capito na mazza. L'assembly è arabo ancora per
me. 
Comunque, se ho capito bene, l'interrupt viene generato da "qualcosa"
(periferiche, o anche qualcos'altro?) per "chiedere l'attenzione" della
cpu, così la cpu blocca il processo attualmente in esecuzione e elabora la
richiesta di quel "qualcosa" e poi riparte da dove aveva interrotto.
Giusto? Se sì, può la cpu decidere di ignorare l'interrupt?

 era solo per amore della verità, ovviamente. Niente di personale
Tra l'altro, una long call è un push e jmp, solo che su cisc si sono 
divertiti a mettere valanghe di istruzioni. jcxz _end
_end
:)



Si. Giusto per quelli hardware. Sono tutti mascherabili tranne l'NMI... 
era l'int 0, mo' cosa è diventato?
Per quelli sw sono semplici chiamate a funzioni. Ora si preferisce usare 
CALL.


 era l'int 0, mo' cosa è diventato?
Cos'è l'NMI?

 CALL.
Non credi che queste spiegazioni siano un tantino
troppo specifiche? Cioe` legate ad un solo modello
di CPU?
Che mi dici di 68K? E di PPC? E di Alpha?
E di MIPS? E di ARM? E di IA-64?
bye,
-- 
   Piergiorgio Sartor

 Giusto? Se sì, può la cpu decidere di ignorare l'interrupt?
Dipende dall'interrupt.
Di solito e` possibile fare alcune cosette, ad
esempio "mascherare" uno o piu` interrupt, in
modo che la CPU gli ignori.
Alcuni interrupt potrebbero non essere mascherabili
per design, tipicamente il RESET e, se presente,
quello che viene chiamato NMI, ma magari anche altri.
Esiste un altro problema, che e` quello della
"priorita`", nel caso diversi interrupt siano
supportati dalla CPU.
Cioe`, cosa deve fare la CPU se una seconda
interruzione arriva mentre sta servendo una
precedente.
Deve saltare alla seconda subito od aspettare
di aver finito la prima?
Spesso e` possibile assegnare priorita` ai
diversi interrupt in modo da consentire tempi
di risposta piu` brevi nei casi in cui sia
necessario avere latenze minori.
bye,
-- 
   Piergiorgio Sartor

 Cos'è l'NMI?
Non-Maskable Interrupt
Cioe` Interruzione Non Mascherabile.
bye,
-- 
   Piergiorgio Sartor

 diciamo che potrebbe essere consuetudine.
Gia' che ci siamo... una macchina con interrupt e' ancora una macchina di
Turing?
Saluti.


Perche' no?
Alessandro.

 Turing?
Arrivi tardi, abbiamo gia` avuto un thread
al riguardo ed e` stato dimostrato (?) che
lo e`... Od almeno si vorrebbe che lo fosse.
;-)
bye,
-- 
   Piergiorgio Sartor

 Perche' no?
Beh, perche`, per esempio, potresti risolvere
l'halting problem.
In particolare, le interruzioni aggiungono
un qualcosa di non-deterministico alle
macchine computazionali, almeno a prima vista.
Quindi bisogna stare molto attenti a quello
che si definisce, in questo caso.
bye,
-- 
   Piergiorgio Sartor

 lo e`... Od almeno si vorrebbe che lo fosse.
Ah beh allora... :)
Saluti.

 macchine computazionali, almeno a prima vista.
E l'halting problem sarebbe decidibile su macchine non deterministiche?
Saluti.
-- 
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |
\_______Like the Phoenix I rise from the ashes of life________/

 E l'halting problem sarebbe decidibile su macchine non deterministiche?
L'halting problem delle macchine deterministiche
e` decidibile in un qualche spazio opportuno.
Magari alcune macchine non-deterministiche ad hoc,
possono risolverlo (purche` queste seconde includano
le prime, altrimenti non ha senso).
Tra l'altro, l'halting problem e` decidibile, caso
per caso, anche sulle machine deterministiche.
Il problema e` che non e` decidibile in generale.
bye,
-- 
piergiorgio

 per caso, anche sulle machine deterministiche.
Ovvio, ma manca un metodo generale.
Saluti


 i problemi NP diventerebbero trattabili).
Definisci "non deterministica".
bye,
-- 
   Piergiorgio Sartor

 
Beh, voglio vedere chi sa come è fatta una motorola 68XXX con i ?-oni di 
registri... Ho assunto che chiedesse informazioni su una x86.


 
Il problema della fermata *NON* è risolubile con una MT. La 
dimostrazione è anche semplice.


 registri... Ho assunto che chiedesse informazioni su una x86.
Si, ma il problema e` che la gestione degli irq e`
una delle cose "system specific" (di un SO).
Voglio dire, fra le poche cose non portabili di un
SO vi e` la gestione degli irq, per cui non ha molto
senso parlare di un sistema specifico, dato che in
un altro contesto le cose potrebbero differire.
bye,
-- 
   Piergiorgio Sartor

 dimostrazione è anche semplice.
Non e` risolubile "in generale", ma in
particolare lo e`.
Per esempio, il seguente programma BASIC:
10 GOTO 10
non termina mai.
Quindi ho risolto l'halting problem in
questo "specifico" caso.
Mentre:
10 A = 0
20 PRINT A
30 END
Termina sempre.
Si puo` fare la seguente affermazione:
qualunque linguaggio (o programma) che
non supporti la ricorsione (implicita od
esplicita) e` decidibile.
Solo che eliminare la ricorsione significa,
in pratica, eliminare gli "if", quindi avere
un sistema che fa ben poco di utile (niente
loop, niente branch, ...)
bye,
-- 
   Piergiorgio Sartor

 
Io... ho imparato l'assembler sul glorioso Amiga e anche al corso di 
microcontrollori ci hanno insegnato l'asm del 68000!
Ciao
Scola

 Definisci "non deterministica".
Me lo chiedi sapendo che non ho fatto informatica teorica? :P
Una MdT non-deterministica, di fronte a un albero di scelte, dovrebbe essere
in grado di percorrere l'albero in ampiezza, ovvero di tentare
contemporaneamente tutte le possibili storie di esecuzione di un determinato
algoritmo. Ciascuna delle realizzazioni dell'algoritmo dovrebbe comportarsi
come se fosse eseguita su una MdT canonica.
A quanto ne so, una macchina del genere non potrebbe decidere il problema
della fermata, o perlomeno questo č ciň che comunemente si dice.
Saluti.


 della fermata, o perlomeno questo è ciò che comunemente si dice.
Beh, per quella che hai definito tu, potrebbe
anche darsi che l'halting problem rimanga.
Comunque chiedevo riguardo al "non deterministico",
perche` spesso e` sinonimo di "stocastico".
bye,
-- 
piergiorgio

 perche` spesso e` sinonimo di "stocastico".
Ed e' errato? Fisicamente non mi pare.
Una macchina non deterministica, letta quella definizione di Xellos, e' un
quantum computer...
Saluti.

 quantum computer...
Che _non_ e` stocastico.
bye,
-- 
piergiorgio

 Che _non_ e` stocastico.
Mi definisci stocastico?
Saluti

 Mi definisci stocastico?
Ripensandoci ho capito dove'e` il problema.
Stiamo confondendo stocasticita` in essere
ed in divenire.
Il computer quantistico e` "stocastico" in
essere, ma e` ben definito in divenire.
Infatti l'equazione d'onda determina perfettamente
cosa succedera` (l'algoritmo).
La MdT con interrupt, invece, e` stocastica
in divenire.
In ogni istante lo stato e` ben definito, ma
lo stato successivo non lo e`, dato che potrebbe
essere diverso da quello aspettato, se arriva
un interrupt.
Per questo chiedevo cosa si intendesse con
"macchina non deterministica".
I due casi suesposti sono entrambi non deterministici,
ma sono diversi nella sostanza.
bye,
-- 
   Piergiorgio Sartor

 Mi definisci stocastico?
Ovviamente e` sinonimo di "casuale" e non di "causale"... ;-)
Piuttosto, ma a che ora del giorno (o della notte) sei in giro
per internet a parlare di stocasticita`? :-)
bye,
-- 
   Piergiorgio Sartor

 per internet a parlare di stocasticita`? :-)
Sempre nelle ore piu' proficue (cioe' dalle 2 di notte in avanti) ;)
Saluti.


Cioe' risolvi l'halting problem spegnedo la macchina?-o
Alessandro.


Ma non si puo' ricondurre l'evento "interrupt al momento x" ad un
valore dell'input?
Alessandro.

 valore dell'input?
Non proprio.
L'input e` definito apriori nella MdT.
D'altro canto un irq esterno non e` noto
a priori per definizione.
Potrebbe anche non avvenire.
Il caso che dici tu supporrebbe che sia
gia` noto quando l'irq arrivera`, cosa
che in realta` non e` dato sapere.
Facciamo l'esempio dell'halting problem.
Se io, nel mio programma, metto un counter
che, dopo X iterazioni, termina l'elaborazione,
avro` un programma che finisce sempre.
Ma questo e` uno specifico, singolo, programma,
non rappresenta la categoria "generale" di
tutto cio` che e` MdT-computabile.
bye,
-- 
   Piergiorgio Sartor

 Cioe' risolvi l'halting problem spegnedo la macchina?-o
Beh, il risultato e` che "qualunque"
programma termina.
Tra l'altro il valore di output potrebbe
identificare l'uscita regolare o per timeout.
Tra l'altro e` ancora piu` restrittivo, dato
che termina sempre entro un'ora... :-)
bye,
-- 
   Piergiorgio Sartor


Si, io mi riferivo a questo problema in particolare.
Per quel che mi ricordo l'halting problem riguarda la terminazione di
in algoritmo su tutti gli input possibili.
Se introduco in "tutti gli input possibili" anche "tutti gli eventi
interrupt possibili" inserendo quindi gli interrupt nell'input
non mi riconduco allo stesso problema?
Alessandro.


Si, ma se l'interrupt per definizione non puo' essere noto a priori,
ha i valutato solo uno dei casi possibili.
Tra i vari casi possibili (come hai fattto notare in un altro post) 
c'e' anche il caso nel quale l'interrupt non si verifichera' mai, 
quindi ti riconduci esattamenete al problema dell'halting problem.
Alessandro.

 programma termina.
Ouch. Questo si che e' uscire dal sistema...
(Ma la macchina di Turing si puo' spegnere? :) )
Saluti.

 microcontrollori ci hanno insegnato l'asm del 68000!
:,) ricordi...


 particolare lo e`.
Allora, partiamo dalle basi. Non esiste il ``particolare'' ed il 
``generale''.
Il problema della fermata è uno tra i primi intrapresi da Turing, ed è 
di una semplicità assurda dimostrare --- leggi bene --- che non esiste 
una macchina di turing che, dato un algoritmo (ovvero una macchina di 
turing), stabilisca se l'algoritmo termina oppure no.
Se vuoi te lo dimostro, ma è banale.
Questo dimostra tra l'altro che gli IRQ non risolvono il problema, ne 
creano altri (RAM <==> MT) tipo il deadlock: gli IRQ sono stati 
inventati per supplire appunto a problemi di concorrenza e di priorità 
tra processi (eventi).
Quello che hai mostrato è semplicemente un algoritmo banale. Mostrami un 
algoritmo che abbia in input un algoritmo e determini se questo si 
fermi, ed allora avrai il primo premio nobel disponibile :) e ricorda 
però che una dimostrazione è per sempre e non esistono controindicazioni...


 (Ma la macchina di Turing si puo' spegnere? :) )
Si puo` "terminare"... :-)
bye,
-- 
piergiorgio

 non mi riconduco allo stesso problema?
Uhm, dunque, fammi pensare...
Se l'irq fa terminare l'esecuzione, e` la stessa
cosa che avere un "timer" interno, nell'algoritmo,
per farlo finire in tempo.
Quindi ti riconduci ad una "funzione" particolare,
non ad una generica funzione "g".
L'unica condizione sarebbe quella della persistenza
della funzione "g", cioe` l'irq deve sempre ritornare
allo stato iniziale, prima che sia avvenuto, senza
avere il permesso di modificare nulla della funzione
"g", ne` il codice, ne` i dati.
bye,
-- 
piergiorgio

 quindi ti riconduci esattamenete al problema dell'halting problem.
No, perche` lo decido io quando avverra`,
ma la MdT non lo sa, cioe` non e` insito
nel suo codice.
bye,
-- 
piergiorgio

 però che una dimostrazione è per sempre e non esistono controindicazioni...
Ancora, il teorema di Turing dice esattamente
che non esiste una funzione "f" che, avente come
input un'altra funzione "g(x)" sia in grado di
dire se questa termina oppure no.
Ma non dice che non esista una funzione "f" che,
avente come input:
10 GOTO 10
ti dica che questo non termina.
Chiara la differenza?
In _generale_ non si puo` risolvere, ma caso per
caso puo` essere che esiste la funzione "f".
Per dirtela in maniera piu` semplice, esistono
algoritmi in grado di dirti che:
10 GOTO 10
non termina mai (una semplice ricerca nel grafo).
E ti ripeto che se escludi la ricorsione,
allora la funzione "f" esiste, anche se,
ad occhio e` NP-hard (un TSP, per esempio).
bye,
-- 
piergiorgio


Ok, la funzione che tenga conto degli interrupt sarebbe diversa da quella
originale, per quanto mi sembra di poter dire che data una funzione
qualunque se ne puo' trovare sempre una che dia lo stesso risultato di
quella di partenza nel caso non vi sia alcun interrupt.
E qui si ritorna piu' o meno allo stesso punto dell'altro ramo del thread.
Alessandro.


Si ma in questo modo non hai *risolto* l'halting problem, hai solo fatto
terminare un algoritmo.
Alessandro.

 E qui si ritorna piu' o meno allo stesso punto dell'altro ramo del thread.
Il problema e` che la MdT con interrupt e` una MdT
modificata, quindi fare valutazioni al riguardo e`
una cosa che va presa con le molle.
Basta cambiare un po' le condizioni per spostare
il problema da una parte o dall'altra.
bye,
-- 
   Piergiorgio Sartor

 terminare un algoritmo.
E quindi posso dire senza alcun dubbio che
tutte le funzioni "g(x)" termineranno.
Se aggiungo l'opzione che sia notificata la
terminazione "naturale" od "artificiale", mi
trovo con un super-set MdT che risolve l'halting
problem delle MdT.
Naturalmente non lo risolve per questo super-set,
dato che, per esempio, protrei spostare il problema
da "termina o no?" a "termina correttamente o no?".
bye,
-- 
   Piergiorgio Sartor

 bye,


 richiedi non è buono.
Lo ripeto per la duecentesima volta, non so
come spiegarmi diversamente.
Se (capisci la parolina "se"?) rimuovo la ricorsione,
posso dimostrare la terminazione o meno della MdT.
Quindi esistono casi PARTICOLARI in cui e` possibile
avere una MdT che risolve l'halting problem.
Dato uno SPECIFICO programma, o funzione, non e` detto
che non si possa dimostrne la terminazione od esattezza.
PUO` ESSERE che esista un metodo FORMALE che sia in
grado di verificare che questo SPECIFICO programma
termina oppure no.
Quindi non esiste una UNICA MdT che risolve sempre il
problema, ne esistono infinite che risolvono SINGOLI
problemi, ma ovviamente non tutti.
Ti faccio un esempio piu` complicato.
Ho una MdT, tale g(x,y), che calcola l'ultima cifra
decimale della divisione tra x ed y (ovviamente interi).
La domanda e` g(M,N) termina oppure no?
Esiste una MdT che sia in grado di dirmi se g(M,N)
termina oppure no?
Certo che esiste.
E` la MdT che verifica se M/N e` periodico oppure no,
cosa che e` computabile totale.
Quindi ho trovato una SPECIFICA MdT che e` in grado
di dirmi se questa SPECIFICA g(x,y) termina oppure no.
Guarda un po'...
bye,
-- 
   Piergiorgio Sartor

 Guarda un po'...
Forse, ma la devi mostrare. Ovvero, rispondi alla mia domanda (sopra).


 periodico, e mostrare f.
Nonono.
E` un r che viene da x/y, che e` diverso.
r non sta in R, sta nei razionali, non nei reali,
ovviamente sta _anche_ nei reali, ma il contrario
non e` vero...
La classe di r e` sufficientemente limitata da
poterla analizzare in modo tale da decidere se
un r e` periodico oppure no.
C'e` una bella differenza.
Per i numeri reali, allora si, il problema della
"periodicita`" e` non computabile.
bye,
-- 
   Piergiorgio Sartor


No. Perche' non sai se l'algoritmo sarebbe terminato comunque dopo la tua 
interruzione o avrebbe continuato all'infinito.
Alessandro.

 interruzione o avrebbe continuato all'infinito.
Non e` questo che mi interessa del
problema, semmai questo e` il secondo
livello, non facciamo confusione.
bye,
-- 
   Piergiorgio Sartor


E cos'e' che ti interessa del problema?
Alessandro.

 E cos'e' che ti interessa del problema?
Che senso possa avere una MdT con irq.
Nella fattispecie non sono convinto che
tale "estensione" rientri nel concetto
di MdT formulato da A. Turing.
Il che mi porta a pensare che un moderno
computer non possa essere, in toto, considerato
alla stessa stregua di una MdT.
Potrebbe esserlo un sottoinsieme limitato
ad un preciso scopo computazionale, date
alcune restrizioni, per esempio proprio
sugli irq.
bye,
-- 
   Piergiorgio Sartor

+++++++++[<++++++++>-]<----.>+++++[<+>-]<.>++++[<-->-]<.>+++++[<++++>-]<.

 togliendo espressività al linguaggio il problema non si pone
Esattamente.
Ma uno puo` avere un linguaggio, tipo BASIC
per esempio, che e` ricorsivo, e scrivere
programmi senza usare la ricorsione.
Questa classe (infinita) di programmi e`
decidibile ed appartiene all'insieme di
tutti i programmi BASIC.
Idem per le MdT, non e` che si elimina la
ricorsione nella MdT, bensi` si considera
solo quella classe di funzioni che non la
usano. Questa classe e` decidibile, quasi
totalmente inutile, ma decidibile...
bye,
-- 
piergiorgio

 "periodicita`" e` non computabile.
Ah, allora c'è stato un misunderstanding... io ho sempre creduto che tu 
parlassi in R non in Q.


 parlassi in R non in Q.
Ma se ho scritto x/y con x,y interi, dove
cavolo si mappa questo spazio?
Ed anche se x,y fossero floating point, data
la loro "finitezza" la cosa non cambierebbe
di una virgola.
bye,
-- 
piergiorgio

 di una virgola.
Beh, su questo non sono d'accordo, in quanto rappresentazioni in basi 
diverse di reali possono essere non finite, mentre in altre finite. Ora 
non mi ricordo riguardo la periodicità... è passato tempo... :(

 non mi ricordo riguardo la periodicità... è passato tempo... :(
Se hai un FP 32 bit 24+8, questo e` un numero
_finito_, non rappresenta infiniti, nella sua
base ovviamente, ma non importa, dato che la
MdT opera nella sua base, non in altre basi.
bye,
-- 
   Piergiorgio Sartor

 MdT opera nella sua base, non in altre basi.
Intanto, io parlo dal punto di vista matematico. Dal punto di vista mio 
(ingegneristico) questo introduce un problema di rumore. Non si possono 
rappresentare tutti i numeri, e la precisione di R(x) è alta con x ~= 0 
e bassa per x grande, con x \in R e R(x) rappresentazione finita in 
forma di mantissa ed esponente.

 non mi ricordo riguardo la periodicità... è passato tempo... :(
Vero. Similmente numeri periodici possono risultare finiti cambiando base.
Invece, numeri trascendenti (e irrazionali, mi pare) rimangono tali
(aperiodici) in tutte le basi razionali.
Saluti.

 (ingegneristico) questo introduce un problema di rumore. Non si possono 
Buonanotte...
bye,
-- 
   Piergiorgio Sartor

 (aperiodici) in tutte le basi razionali.
Giustissimo

 Vero. Similmente numeri periodici possono risultare finiti cambiando base.
Scommetti che ti scrivo 0.3 in binario
con un numero finito di bit?
bye,
-- 
piergiorgio

 con un numero finito di bit?
Procedi pure.. ma senza trucco e senza inganno ;)
Saluti.

 con un numero finito di bit?
Guarda che la teoria dei numeri non è opinabile. Una MT non può 
riconoscere numeri razionali perchè in qualunque base tu scelga tale 
numero può essere infinto. L'input di una MT è finito.
Una MT può riconoscere *solo* _rappresentazioni_ NON esenti da rumore di 
numeri R (o Q se preferisci).

 Procedi pure.. ma senza trucco e senza inganno ;)
0000 1111 0011
Il fatto e` che state mescolando rappresentazioni
in base e "rappresentazioni" numeriche.
La MdT, come detto in precedenza, tratta stringhe,
per cui un numero puo` anche essere la rappresentazione
ASCII di quel numero (tanto per dire).
bye,
-- 
piergiorgio

 numeri R (o Q se preferisci).
Vabbe`...
bye,
-- 
piergiorgio

Giusto? Se sě, puň la cpu decidere di ignorare l'interrupt?
Oltre al fatto che e' possibile disabilitare gli interrupt, anche
temporaneamente, esiste anche un discorso di priorita' diversa per
ogni interrupt.
Nel caso degli Intel x86, c'e' anche la possibilita' di generare un
interrupt da programma, questo meccanismo (molto utilizzato) viene
chiamato 'interrupt software' e non ha nulla a che vedere con il caso
classico, se non la modalita' di esecuzione del relativo codice e di
rientro al termine.
Questo sistema viene utilizzato in genere per eseguire delle routine
software senza conoscerne l'effettivo indirizzo in memoria.
Un esempio semplice sono le routine del BIOS, che si trovano sulla
ROM, ma chissa' a quale indirizzo?  Dipende dalla macchina, dalla
versione del BIOS etc.  Ma se tu sai che per chiamare una particolare
routine e' sufficiente far scaturire un determinato interrupt (ad es.
il numero 16) indipendentemente dalla posizione in memoria della
routine, dalla versione del BIOS, etc. troverai piuttosto 'ingegnoso'
questo sistema.  Quando poi scoprirai i tempi di latenza introdotti da
questa diavoleria, specie quando questo dovesse comportare il
passaggio da Protected a Real mode e ritorno (si spera...) allora lo
maledirai >:->.

 in base e "rappresentazioni" numeriche.
Mi sono inserito a questo punto solo perche' mi interessava il discorso basi
e conversioni.
Immagino pero' tu neanche tu sostenga che fissata una modalita' di
rappresentazione, questa possa rappresentare in modo finito qualunque numero
razionale.
Saluti.

 razionale.
"razionale"?
Qui andiamo di fino sulle definizioni...
Che mi dici di: M/N?
Voglio dire, questo rappresenta qualunque
razionale in modo finito... In qualunque base.
Oppure intendi altro?
bye,
-- 
   Piergiorgio Sartor

 Oppure intendi altro?
Quello di cui sopra...
So anche io che bastano M e N per qualunque numero razionale, addirittura
c'e' un interessante paradosso sulla compattazione dei files...
Saluti.

 non di "razionali".
E l'output è un razionale. Si cercava se non sbaglio il risultato di p/q 
che è razionale e potenzialmente infinito.
... non è che invece si cerca p mod q?

 che è razionale e potenzialmente infinito.
Si cercava una MdT che sia un grado di dirti
se la MdT che calcola p/q termina oppure no.
Tale MdT esiste, per p,q interi, ed esiste
anche per p,q floating point (FP).
bye,
-- 
piergiorgio

 c'e' un interessante paradosso sulla compattazione dei files...
A si?
Quale? Quale?
bye,
-- 
piergiorgio

maledirai >:->.
Con processori con velocita' nell'ordine dei gigahertz ??
E chi sei, Neo che deve battere sul tempo le fiamme nel palazzo che
sta' esplodendo?? In quel caso anche il millesimo in piu' o in meno
fa' la differenza :-p, ma in un normale uso non lo vedo. ^____^
-- 
Annunziamo la tua nuova versione, proclamiamo il tuo aggiornamento,
nell'attesa che funzioni. (una anonima dedica a mswin?)

addirittura c'e' un interessante paradosso sulla compattazione dei files...
Racconta, racconta ...


 Racconta, racconta ...
Prendiamo per esempio l'intera enciclopedia britannica, e codifichiamola in
qualche modo, carattare per carattere, disegni, bitmap. Scriviamo il numero
che si ottiene, mettendo tutti i codici uno dopo l'altro. Facciamolo
precedere da un "0.".
Otteniamo quindi un numero 0< x <1, finito... come lo rappresentiamo?
Possiamo prendere una sbarra, di lunghezza unitaria, e incidere una tacca
sulla sbarra, suddividendola in due pezzi a e (1-a).
Essendo x finito e minore di uno, sara' sempre possibile scegliere a tale
che a/(1-a) = x.
E se mi interessa ritrovare x? Riprendo la sbarra, misuro a e faccio la
divisione.  Vien voglia di tornare ai computer analogici eh? ;)
Saluti.

 Quale? Quale?
L'ho scritto sopra... forse non e' un paradosso propriamente, forse lo
conoscete gia', comunque mi aveva colpito quando me l'avevano raccontato ;)
Saluti.

fa' la differenza :-p, ma in un normale uso non lo vedo. ^____^
Sono d'accordo con te che se prendi come esempio il tempo impiegato da
un intero programma allora il problema non si pone, ma nel caso di
specifiche routine a volte un millisecondo puo' essere inaccettabile.
Prova per un attimo ad immaginare se la routine che si occupa di
trasferire i byte letti dal controller del tuo hard disk ci mettesse
un millisecondo per ogni byte, per trasferire un MB occorrerebbero un
mille secondi (piu' di sedici minuti), anche ipotizzando che tu abbia
un controller a 32 bit (quindi dividendo il tempo per 4) credo
rimpiangeresti il mangiacassette del C64.

 divisione.  Vien voglia di tornare ai computer analogici eh? ;)
Ah! Si, c'e` chi sostiene lo stesso metodo di
"rappresentazione" nei riguardi dell'Universo...
bye,
-- 
piergiorgio

 perso qualcosa...
No, si parlava di identificare quando M/N e`
finito oppure no, per verificare la terminazione
o meno della MdT che calcola M/N.
bye,
-- 
piergiorgio