Newsgroup: it.comp.lang.c
Titolo: [OT?]DJGPP

Domandina: ma perchè mai usate tutti DJGPP? Solo perchè è gratis o anche per
altre ragioni?
Io in realtà ho dovuto smettere con C/C++ da quando è uscito windows e
relativi sdk/mfc e "billate" varie. (tra l'altro nel frattempo mi hanno
anche cambiato il mio bel C++ con lo standard ANSI e STL)
Ora mi sto adattando al VC :(
Se mi dite che è equivalente al WC ;) ma che ricalca il favoloso Turbo C (il
migliore mai realizzato in tutti i tempi), lo scarico subito.
Alessandro Monti
P.S.
La Microsoft non ha mai imparato a fare compilatori (basic escluso).

Ora mi sto adattando al VC :(
A me il VC piace.
Sara' perche' mi e' costato un occhio e dunque DEVE essere un buon
compilatore...:)
Scherzi a parte come struttura va bene. Il problema e' che chi ha progettato
le MFC dovrebbe decidersi a cambiare spacciatore.
Marco

 migliore mai realizzato in tutti i tempi), lo scarico subito.
Tu confondi il compilatore con l'ambiente di sviluppo. Un compilatore
C++ deve semplicemente prendere un programma sorgente e tradurlo in
codice oggetto attenendosi allo standard ISO. Nient'altro. Io sono
abituato ad utilizzare compilatori a linea di comando e mi trovo bene
così. Comunque, volendo, hai anche la possibilità di utilizzare l'RHIDE,
un ambiente, a quanto mi dicono, simile a quello del TurboC.
EMG

 un ambiente, a quanto mi dicono, simile a quello del TurboC.
Un po' è vero, l'ambiente del Turbo C era favoloso, ma anche il compilatore
in sè era (secondo me) superiore.
Comunque con VC è un po' difficile scrivere e compilare codice "standard".
Nell'help Microsoft (per non parlare dei wizard) si fa di tutto per
scoraggiare l'adozione di uno standard, essendoci solo le varie estensioni
MS, MFC, SDK, librerie non portabili ed altro. Le cose standard sono molto
nascoste.
Io ho provato a realizzare un Client ed un Server Internet (così, di prova,
uno scriveva e l'altro rispondeva "Ciao") e volevo usare i socket (standard
o quasi): una tragedia!!! Con l'help che suggeriva di NON usare proprio le
cose che avrebbero funzionato anche su Unix. Esiste una documentazione
passo-passo per creare appunto Client e Server, ma SOLO con estensioni
Windows!!!
Ma si può?
Aggiungiamo che sono abituato ad imparare i linguaggi dagli esempi e
dall'help in linea, dovrei PRIMA impararmi lo standard, poi usare il VC. (lo
standard che conoscevo io sembra non esistere più!)
Comunque se è solo per DOS mi sa che non mi sarebbe molto utile.
Grazie a tutti per le risposte. (Anche quelle future nel caso...)
Alessandro Monti

you wrote :
#Domandina: ma perchè mai usate tutti DJGPP? Solo perchè è gratis o anche per
#altre ragioni?
"solo" ? ;)
Io ritengo che la caratteristica di essere gratis non sia un aspetto
di importanza secondaria, quanto la prerogativa principale.
D'altronde il djgpp viene distribuito aderendo alle regole dell'"open
source" e puo' essere, almeno potenzialmente, ottimizzato da chiunque.
E' in base a questo principio, d'altronde, che e' nato RHIDE,
l'ambiente di sviluppo che si integra molto bene con il compilatore a
riga di comando.
#La Microsoft non ha mai imparato a fare compilatori (basic escluso).
La MS non ha mai cominciato a scriverne uno.
Le versioni del MFC non sono altro che una riscrittura del Lattice C,
comprato inizialmente e rinominato come Microsoft.
--------------------------------------------------------
. Andrea Laforgia        (
andrea_...@bigfoot.com
) .
--------------------------------------------------------

 comprato inizialmente e rinominato come Microsoft.
Questo non lo sapevo. In effetti mi domandavo come mai funzionassero davvero
:)
Però adesso siamo sicuramente OT.
--
Alessandro Monti

 La Microsoft non ha mai imparato a fare compilatori (basic escluso).
Ma perche' il basic e' compilato???
Comunque e' vero, viva il commodore 128 e il suo MS-BASIC VERSION 7.0 !!!
Vincenzo 

> Ma perche' il basic e' compilato???
Hai ragione.
Allora non ci sono eccezioni alla regola: MS non sa fare compilatori. (e
anche sugli interpreti ci sono problemi)
--
Alessandro Monti

you wrote :
#Ma perche' il basic e' compilato???
Parecchio tempo fa venne fuori un certo BASCOM (BASic COMpiler) che
traduceva da .bas a .obj e per mezzo del famoso LINK si produceva il
.exe. Ovviamente si era sempre legati alle routine di run-time in un
modulo .exe a parte.
In ogni caso anche il Visual Basic, oltre che p-code, puo' produrre
codice nativo.
--------------------------------------------------------
* Andrea Laforgia        (
andrea_...@bigfoot.com
) *
--------------------------------------------------------

 codice nativo.
La discussione in effetti sarebbe piuttosto complessa.
Se produce un .exe è un compilatore?
Si potrebbe rispondere di si.
Anche il discorso sulle librerie run-time non è sufficiente: anche il C si
porta dietro un bel po' di librerie, eppure si dice che sia compilato.
Il P-code è una via di mezzo, ma tutto sommato è semplicemente una
codifica/compressione del sorgente, che in effetti è recuperabile da P-code,
per cui è interpretato. Però anche la cosiddetta "compilazione" può essere
vista come una codifica/compressione del sorgente, e in teoria si può
ricavare il sorgente dall'exe (anche i simboli se attivo il debug), per cui
è interpretato tutto? O niente?
La questione è più filosofica che altro. Nella pratica anche il VB si
considera interpretato, poichè fa largo uso delle librerie di run-time,
anzi, senza di esse non fa proprio niente, essendone composto, mentre il C
"sfrutta" tali librerie nel senso che le incorpora invece che esserne
incorporato.
Non è chiaro? In effetti neanche per me.
In ogni caso il punto è che non mi sono mai trovato bene con i linguaggi MS,
soprattutto perchè non riescono mai ad adattarsi ad uno standard, e anche
quando questo c'è, trovano sempre il modo di imporre le proprie estensioni,
semplicemente perchè riescono a fare in modo che usando tali estensioni
diventa facile programmare (wizard, help nutriti, esempi di ogni tipo),
mentre è dannatamente difficile farlo usando solo gli standard. Tanto per
fare un esempio, se con il mio VC5.0 decido di fare un'applicazione che usa
le dannate MFC, il wizard mi prepara una manciata di sorgenti, una finestra
principale, un minimo menù e una finestra "about", mentre se scelgo di non
usarle, l'unica cosa che fa è di aprirmi un bel file .cpp completamente
vuoto!
Questa secondo me è una politica "non corretta".
E a questo punto abbiamo superato anche la soglia dell'OT, sconfinando
nell'OAT (out of all topics)
--
Alessandro Monti

 in teoria si può ricavare il sorgente dall'exe
A me sembra che sia esattamente il contrario dato che non c'è
corrispondenza uno-a-uno tra istruzioni macchina e istruzioni C e quindi
una serie di istruzioni macchina può essere tradotta in modi diversi in
C e questo, creando ambiguità, rende impossibile risalire alle
istruzioni originali. Sbaglio?
EMG

 istruzioni originali. Sbaglio?
No, non sbagli, ma c'è corrispondenza 3 a 1, o 2 a 1, o 4 a 1, ecc.
Certo non è facile risalire al codice C, e pertanto i decompilatori (o
chiamali come vuoi) di solito ritornano assembler, solo in rari casi (leggi
pochi particolari linguaggi) risalgono ad un codice di livello più alto.
Complici anche le eventuali ottimizzazioni del compilatore, risalire a
codice C è solitamente impossibile, nel senso che sarebbe un'impresa
titanica costruire un tale decompilatore.
Ciònondimeno è teoricamente possibile.
Basti pensare che alcuni compilatori hanno (avevano) delle macro-variabili
che permettono di indirizzare direttamente i registri. In questo caso (e
scordiamoci la portabilità e ogni standard), è possibile ricavare C da
assembler (e quindi anche da .exe).
Ovviamente non è l'unica soluzione.
Se pensiamo che il compilatore è una funzione (e qui il discorso si fa
complesso), allora è anche possibile trovare l'inversa di tale funzione.
Tornando con i piedi per terra, in pratica hai ragione tu.
Come dicevo, il discorso è filosofico.
Si potrebbe pensare che un programma interpretato sia "lanciato" da qualche
funzione delle librerie run-time, mentre uno compilato semmai "lancia"
alcune funzioni delle librerie run-time. E quindi usare una nozione
gerarchica programma/librerie, indipendentemente dal formato
dell'eseguibile.
Ma per i compilatori JIT (just-in-time)?
--
Alessandro Monti

you wrote :
#La discussione in effetti sarebbe piuttosto complessa.
#Se produce un .exe è un compilatore?
#Si potrebbe rispondere di si.
La discussione non e' affatto complessa, se la si vuole complicare e'
un altro discorso.
La differenza tra "compilatore" e "inteprete" e' chiara sin dalla
notte dei tempi : premesso che "interpretare" significa implementare
una "macchina virtuale", la compilazione e' la traduzione diretta del
codice sorgente in istruzioni macchina ; l'interpretazione e' la
traduzione da codice sorgente a pseudo-istruzioni macchina.
#Anche il discorso sulle librerie run-time non è sufficiente: anche il C si
#porta dietro un bel po' di librerie, eppure si dice che sia compilato.
#Il P-code è una via di mezzo, ma tutto sommato è semplicemente una
#codifica/compressione del sorgente, che in effetti è recuperabile da P-code,
#per cui è interpretato. Però anche la cosiddetta "compilazione" può essere
#vista come una codifica/compressione del sorgente, e in teoria si può
#ricavare il sorgente dall'exe (anche i simboli se attivo il debug), per cui
#è interpretato tutto? O niente?
Mamma mia che confusione pazzesca !
A parte il fatto che un normale compilatore non fa si' che il codice
prodotto "si porti dietro" alcuna libreria, ma semplicemente ne
incorpora, avvalendosi del linker, le routine contenute e *necessarie*
(sottolineo questa parola) la traduzione del codice, sia essa diretta
all'interpretazione o alla compilazione, non e' affatto una
"compressione" del codice, per usare le tue parole, ma semmai il
contrario : una singola istruzione sorgente "esplode" in piu'
istruzioni macchina. La compilazione, inoltre, e' un processo
assolutamente irreversibile e cio' significa che non essendoci
corrispondenza biunivoca tra l'insieme delle istruzioni sorgenti e
l'insieme delle istruzioni macchina generate, non c'e' modo di attuare
l'operazione inversa, ovvero generare il sorgente dal codice macchina.
"In teoria" si potrebbe dire che la relazione y = compilazione(x) dove
x e' il codice sorgente e y il codice oggetto generato non e' una
funzione e, a maggior ragione, non e' invertibile.
#La questione è più filosofica che altro.
La questione non e' affatto filosofica !!!
Anzi, e' piu' che concreta !
#Non è chiaro? In effetti neanche per me.
Infatti si vede che hai le idee molto confuse.
A mio avviso, la distinzione tra interpretazione e compilazione
dovrebbe essere molto chiara per un programmatore, ma vedo che non e'
cosi'.


you wrote :
#> A me sembra che sia esattamente il contrario dato che non c'è
#> corrispondenza uno-a-uno tra istruzioni macchina e istruzioni C e quindi
#> una serie di istruzioni macchina può essere tradotta in modi diversi in
#> C e questo, creando ambiguità, rende impossibile risalire alle
#> istruzioni originali. Sbaglio?
#No, non sbagli, ma c'è corrispondenza 3 a 1, o 2 a 1, o 4 a 1, ecc.
#Certo non è facile risalire al codice C, e pertanto i decompilatori (o
#chiamali come vuoi) di solito ritornano assembler, solo in rari casi (leggi
#pochi particolari linguaggi) risalgono ad un codice di livello più alto.
#Complici anche le eventuali ottimizzazioni del compilatore, risalire a
#codice C è solitamente impossibile, nel senso che sarebbe un'impresa
#titanica costruire un tale decompilatore.
#Ciònondimeno è teoricamente possibile.
#Basti pensare che alcuni compilatori hanno (avevano) delle macro-variabili
#che permettono di indirizzare direttamente i registri. In questo caso (e
#scordiamoci la portabilità e ogni standard), è possibile ricavare C da
#assembler (e quindi anche da .exe).
#Ovviamente non è l'unica soluzione.
#Se pensiamo che il compilatore è una funzione (e qui il discorso si fa
#complesso), allora è anche possibile trovare l'inversa di tale funzione.
#
#Tornando con i piedi per terra, in pratica hai ragione tu.
#
#Come dicevo, il discorso è filosofico.
#Si potrebbe pensare che un programma interpretato sia "lanciato" da qualche
#funzione delle librerie run-time, mentre uno compilato semmai "lancia"
#alcune funzioni delle librerie run-time. E quindi usare una nozione
#gerarchica programma/librerie, indipendentemente dal formato
#dell'eseguibile.
#
#Ma per i compilatori JIT (just-in-time)?


you wrote :
#Complici anche le eventuali ottimizzazioni del compilatore, risalire a
#codice C è solitamente impossibile, nel senso che sarebbe un'impresa
#titanica costruire un tale decompilatore.
#Ciònondimeno è teoricamente possibile.
No che non lo e' !, non e' un'impresa titanica, e' semplicemente
"impossibile" e la cosa e' ben diversa !
#Se pensiamo che il compilatore è una funzione (e qui il discorso si fa
#complesso), allora è anche possibile trovare l'inversa di tale funzione.
No ! assolutamente !
Il compilatore non e' affatto una funzione !!!
Una relazione che lega ad un elemento dell'insieme di partenza (codice
sorgente) piu' elementi dell'insieme di arrivo (codice macchina) NON
PUO' essere una funzione e tantomeno e' invertibile !
Ma *hai* studiato analisi matematica ?


PUO' essere una funzione e tantomeno e' invertibile !
Non sai di cosa parli. Può darsi che mi sbagli e che non sia invertibile (ma
ne dubito), ma OGNI programma è una funzione dei suoi input, che ti piaccia
o meno. (e dovresti spiegarmi cosa c'entra Analisi, sono curioso)
Di più, OGNI programma è numerabile, nel senso che potrei dire che il
compilatore BC++ è il programma numero 123456789 secondo una certa
numerazione, e i suoi input pure. Si chiama (per la numerazione dei
programmi) Godelizzazione, con due puntini sulla o. Per l'input, invece è
più banale.
Se la cosa ti suona strana, considera che l'eseguibile di un programma,
metti i suoi 300Kb, è memorizzato come una sequenza di bit. Prendi questa
sequenza, trasformalo in un numero (di 300K*8 bit) e avrai il suo numero
secondo la numerazione "naturale" della CPU che usi. Ovvio che se due
programmi hanno lo stesso numero (e quindi ogni bit dell'eseguibile è uguale
nei due programmi) saranno lo stesso programma, mentre se un solo bit è
diverso, saranno diversi. (anche se magari computano la stessa funzione)
Idem per gli input, essendo comunque sequenze di bit.
Ciao
--
Alessandro Monti

 cosi'.
Le idee sono confuse se ritieni che queste 2 operazioni debbano per forza
avere, nella loro accezione comune, un significato univoco e antitetico. Da
questa premessa seguono tutte le complicazioni di cui sopra. Se invece le
consideri dei concetti sovrapponibili invece tutto file via liscio. Ma per
capire questo non basta Analisi, e neanche Algebra. Io ho provato con il
buon senso e qualche spiegazione, ma potresti provare anche con una logica
cosiddetta "fuzzy", se sai cosa intendo.
Volevo porre la cosa su un tono scherzoso, visto che in effetti: "who
care?".
E non vorrei neanche farne questioni di principio, solo ti chiederei di non
attaccare per primo.
Preferirei che la cosa rimanesse su un livello accademico, non personale. Ti
assicuro che ho delle buone basi sia matematiche che di programmazione, e
che se animo un po' la discussione con idee non propriamente "comuni", è
solo per poter scambiare opinioni "intelligenti" con qualcuno che, magari
sapendone più di me, potrebbe dirmi qualcosa di nuovo o farmi riflettere su
qualche argomento che non avevo approfondito abbastanza.
Per questo motivo mi vedrai spesso usare espressioni del tipo "a mio parere"
o "supponendo che", o "non mi è molto chiaro".
Intendo con queste frasi esprimere opinioni personali, senza il rischio di
offendere nessuno, e auspicabilmente senza essere offeso da nessuno.
Non che mi turbi essere definito un "cattivo programmatore" (potrei essere
io a dire la stessa cosa di me), ma preferirei che fosse fatto sulla base di
ciò che faccio, non perchè mi sono permesso di dire che il Basic o il C
potrebbero essere compilati e eventualmente de-compilati.
Spero che ci saranno altre occasioni per disquisire su questo o altri
argomenti, magari con la stessa opinione. :)
--
Alessandro Monti

Non sai di cosa parli. Può darsi che mi sbagli e che non sia invertibile
(ma
Non e' invertibile perche' non e' biunivoca.
a = a+1 e a++ potrebbero generare lo stesso codice.
Se escludiamo le ottimizzazioni e descrivi il prg. con la semantica
denotazionale allora forse si, ma per come sono fatti i compilatori la
compilazione e' irreversibile.
Comunque hai ragione, *E'* una funzione. Ma non tutti studiano
informatica...;-)
Marco

 interpretato.
No, perché non sanno neanche cosa significa. Ma sanno vagamente cos'è
Visual Basic o Access e allora ti chiedono se il programma è fatto con
questi strumenti "alla moda".
EMG

 compilazione e' irreversibile.
Credo che ci siamo capiti, comunque si intende invertibile "a meno di
sorgenti equivalenti".
E' un po' come per le operazioni in un campo di resti con modulo.
La divisione per 2 (con resto) genera una classe di equivalenza tra tutti i
numeri che hanno resto 0 e quelli che hanno resto 1.
L'operazione inversa, non è certo univoca, ma possibile.
!0 = 0, 2, 4, 6, ...
!1 = 1, 3, 5, 7,...
Ogni decompilatore perciò sarebbe libero di scegliere i "rappresentanti" del
campo a suo piacimento. Nell'esempio potrebbe scegliere 4 e 9, senza che la
semantica venga cambiata. (rifacendo la divisione, ottengo gli stessi
numeri).
Questo, sarai, d'accordo, è fattibile. Non è l'inversa "matematica",
d'accordo, e ci sono anche dei problemini, cui avevo accennato, per la
ricostruzioni dei nomi di variabile (e di funzioni ecc.) se non sono incluse
tali informazioni nel codice oggetto, e per le possibili ottimizzazioni
effettuate dal compilatore (che poi di solito sono "riorganizzazioni" e
"cancellazioni" di istruzioni).
Ancora scusa per il tono, forse troppo... (non trovo una parola adatta,
forse "aggressivo")
Ogni tanto mi faccio trasportare. Considera che spesso mi collego la sera e
sono stanco. Dovrei decidermi a rispondere solo il giorno dopo.
Ciao
--
Alessandro Monti

 _tutte_ a disposizione.
La questione citata sopra potrebbe essere la risposta alle nostre divergenze
d'opinioni.
Nella mia dimensione il vb, quando genera un exe, "potrebbe" essere in grado
di discernere quali funzioni sono utili al programma che sta
"compilando/interpretando" e quindi non includere quelle non usate. A
maggior ragione se è interpretato, visto che in questo caso non contiene
indirizzi fissi di funzione, ma riferimenti ad essi (bisognerebbe essere più
precisi, ma passamela per buona).
In realtà mi risulta che ogni exe VB sia di dimensioni mostruose (contando i
run-time) in tutti i continuum spazio-temporali con cui sono in contatto,
per cui si suppone sia ancora interpretato, nonostante la facciata ".exe".
--
Alessandro Monti

 numeri che hanno resto 0 e quelli che hanno resto 1.
L'operazione inversa della divisione è la moltiplicazione. Se x = n / 2
allora n = 2 * x. Non c'è alcuna ambiguità. Nella divisione intera
invece c'è perdita di informazione (proprio come in una compilazione)
per cui non c'è più nessun modo per sapere se l'operazione di partenza
coinvolgeva dei reali. Per esempio, x = 5 / 2 e x = 4 / 2 danno lo
stesso risultato 2. L'ipotetica operazione inversa n = 2 * x dovrebbe
dare come risultato, oltre all'ovvio 4, anche il 5 il che è assurdo.
Quindi a me sembra proprio che l'operazione non sia invertibile.
EMG

 "compilando/interpretando" e quindi non includere quelle non usate.
No, non può in quanto tali routine sono contenute all'interno di DLL che
l'installazione dell'applicazione scritta con il VB si deve portare
obbligatoriamente appresso.
EMG

you wrote :
#Non sai di cosa parli. Può darsi che mi sbagli e che non sia invertibile (ma
#ne dubito), ma OGNI programma è una funzione dei suoi input, che ti piaccia
#o meno. (e dovresti spiegarmi cosa c'entra Analisi, sono curioso)
C'entra la teoria degli insiemi, sempre che il concetto di funzione
che intendiamo sia lo stesso (non vedo quali altri ve ne possano
essere): la definizione di funzione, ovvero di relazione che lega ad
uno o piu' elementi dell'insieme di partenza uno ed un solo elemento
dell'insieme di arrivo e' di ambito prettamente matematico e la teoria
degli insiemi e' il preludio dell'analisi matematica. In base a questo
principio un programma *puo'* essere funzione del suo input come puo'
non esserlo. Quest'ultimo caso e' quello dei compilatori, in quanto ad
un elemento del codice sorgente fa corrispondere piu' elementi del
codice macchina. Il non essere una funzione fa si' che essa non sia
una relazione invertibile.


you wrote :
#Comunque hai ragione, *E'* una funzione.
Riprendendo il concetto di funzione dal linguaggio matematico, un
compilatore non e' funzione del proprio input per i motivi gia'
ampiamente spiegati.


you wrote :
#Non sono stato io. Io avevo ammesso che  C->compilato, VB->interpretato. Poi
#qualcuno ha detto che VB produce EXE...
Infatti e' cosi', il VB produce oltre al p-code anche codice macchina.
#Non che mi turbi essere definito un "cattivo programmatore" (potrei essere
#io a dire la stessa cosa di me), ma preferirei che fosse fatto sulla base di
#ciò che faccio, non perchè mi sono permesso di dire che il Basic o il C
#potrebbero essere compilati e eventualmente de-compilati.
Ma chi sta dicendo questo ?
A me sembra che continui a divagare senza centrare il problema !
Continui a parlare di questioni *filosofiche*, quando la realta' e'
una sola : la decompilazione codice oggetto -> codice sorgente non e'
un'operazione possibile.
Sinceramente non sono interessato a discutere in questo modo e per non
degradare in uno sgradevole off-topic chiudo qui le mie
considerazioni.


you wrote :
#In realtà mi risulta che ogni exe VB sia di dimensioni mostruose (contando i
#run-time) in tutti i continuum spazio-temporali con cui sono in contatto,
#per cui si suppone sia ancora interpretato, nonostante la facciata ".exe".
Non e' cosi'.
Non vedo perche' la MS avrebbe dovuto creare due modi alternativi di
intepretare il codice.
Confronta le velocita' di esecuzione del codice tra p-code e compilato
in .exe per la conferma.


 ampiamente spiegati.
Chi ha detto questa fesseria?
Il compilatore non è funzione di niente. Il compilatore E' esso stesso una
funzione, che traduce i suoi input (programma sorgente) in un output
(programma compilato).
Se volete usare il linguaggio matematico, ampliatelo un pochino. Certo è una
funzione un tantino più complicata che y=x*x;
Vedi la risposta a Enrico Maria ecc. per altre spiegazioni.
--
Alessandro Monti

 allora n = 2 * x. Non c'è alcuna ambiguità. Nella divisione intera
Mi dispiace, non hai ancora capito. Non sto parlando della divisione, ma
semmai del RESTO della divisione. Credevo che i campi quoziente siano
studiati in Algebra in tutte le facoltà scientifiche, anche se in effetti
non so se sei studente o meno. (magari l'hai scritto da qualche parte, non
ricordo, scusami)
La moltiplicazione è sì l'inversa della divisione, ma io non stavo parlando
di questa. Parlavo ella relazione di equivalenza generata dalla divisione
modulo 2 fra interi.
Quindi un'applicazione da N a {0, 1}, dotata di inversa univoca a meno di
equivalenze indotte appunto dalla divisione, (uffa, che fatica).
Se ti sembra astruso, considera che 2 programmi equivalenti, scritti da 2
programmatori saranno, in genere, diversi. Ma il programma assolve agli
stessi compiti! Ciò equivale a stabilire una classe di equivalenza tra 2
sorgenti diversi.
Se ancora non sei convinto che programma= funzione, non posso certo postarti
tutto il programma di un intero esame (sebbene questo sia una parte breve).
Spiegami però perchè, se programma != funzione, in C si scrive:
int main()
Non è forse una funzione?
E in C non esistono forse solo funzioni? Per cui OGNI programma C è una
composizione di funzioni, e allora i casi sono solo 3:
1) Il C non è un linguaggio abbastanza potente da esprimere ogni programma
computabile (il che potrebbe anche essere vero, ma per altre ragioni)
2) Il C è "troppo" potente, essendo l'insieme delle funzioni computabili
inferiore a quello delle funzioni
3) Il C è sufficientemente potente da esprimere ogni funzione computabile e
programma=funzione
Nota che nei casi 1 e 2, gli inventori del C hanno preso una cntonata quando
hanno pensato di esprimere main come una funzione, e sarebbe stato più
corretto usare una notazione diversa per descrivere il programma stesso.
A te la scelta...
Un'ultima precisazione: se così non fosse, chi mi garantirebbe di ottenere,
con un programma qualsiasi, non solo con i compilatori, l'output desiderato?
Se non ci fosse del rigore matematico, ogni compilazione darebbe un
eseguibile diverso. Come mai non accade?
Forse che l'output non è strettamente funzione dell'input (comprendendo
eventualmente tutti i parametri di compilazione)? Allora dovrebbe davvero
dare risultati diversi ad ogni esecuzione.
Certo che è difficile vedere un compilatore come funzione da N a N (numeri
interi naturali), forse è più facile vederlo come una funzione dall'insieme
potenza dei codici ASCII (il file sorgente) all'insieme potenza dei codici
macchina (codice oggetto).
Ma lo ripeto: E' UNA FUNZIONE, e così OGNI programma scrivibile ed
eseguibile da una macchina di Turing (computer).
Prima di aprire un thread per decidere se un PC sia o meno una macchina di
Turing, preciso che ogni programma è una funzione anche sui computer
(esistono entrambe le forme della dimostrazione, o meglio:verifica).
Rileggiti il post in cui parlavo della Godelizzazione dei programmi. (due
livelli più in su)
Chiaro che per ora spero che tu sappia cos'è un insieme potenza. Semmai in
un altro post te lo spiego.
--
Alessandro Monti

 una relazione invertibile.
Invece è una funzione e pertanto è invertibile, ma quarda un po'!
Non inventiamoci assurdità pseudo-matematiche per giustificare la non
conoscenza dell'argomento.
E una funzione che trasforma una stringa nella stessa ma eliminando gli
spazi ripetuti? In C non è una funzione? Eppure non trasforma ogni carattere
in un'altro carattere, modifica la lunghezza della stringa.
A proposito, che cos'è questa stringa? In matematica non esiste. Fa bene il
C a non definirle :)
Idem per liste, array dinamici, alberi, hash tables e ricorsività varie. In
matematica (secondo te) non esistono.
Sono void (ah, ecco a cosa serve!) :)
--
Alessandro Monti

 considerazioni.
Mi dispiace, non intendevo certo zittire nessuno.
Se non sei piů interessato, non fa niente, non credo ci debbano essre
"vincitori", ma gente che si scambia opinioni.
Spero solo che non ti sia offeso.
Alla prossima.
--
Alessandro Monti

ampiamente spiegati.
Hai le idee confuse. Un compilatore non e' funzione del proprio input, e'
l'eseguibile che e' l'immagine dell'input tramite la fuzione *compilatore*.
Prova a leggere qualcosa sulla teoria della computabilita' e linguaggi
formali.
Marco

una relazione invertibile.
Peccato che si stia parlando di informatica, e qui la definizione di
funzione e' diversa da quella che dai tu.
Marco

 spazi ripetuti?
Se gli spazi ripetuti vengono semplicemente sostituiti con uno spazio
allora la funzione non è invertibile in quanto non c'è modo di risalire
al numero degli spazi originali.
EMG

 Mah, che sia difficile è vero. Impossibile...
Allora si tratta di mettersi d'accordo su cosa si intende per
decompilazione. Se intendiamo ottenere un programma _semanticamente_
uguale a quello di partenza allora non mi pronuncio. Può darsi che sia
possibile. Ma se vogliamo ottenere un programma _esattamente_ identico a
quello originale allora dobbiamo stabilirne per forza di cose
l'impossibilità a causa dell'ambiguità prodotta dalla perdita di
informazione causata dal processo di compilazione.
EMG

 Se ancora non sei convinto che programma= funzione,
Ti risulta che abbia detto questo in qualche mio messaggio? Io ho solo
detto che la divisione intera non è invertibile, così come la
compilazione, a causa di perdita di informazione nel processo che genera
ambiguità.
EMG

 Andrea Laforgia ha scritto nel messaggio

Per quanto ne so io, dal punto di vista anche strettamente
matematico non esistono solo le funzioni che mappano uno o piu` valori
del "dominio" in uno e un solo valore del "codominio",
ma esistono anche funzioni che possono mappare un valore del "dominio"
in piu` valori del "codominio". In genere pero` queste ultime,
che per quanto ne so io vengono chiamate funzioni polidrome o qualcosa
di simile (un esempio dovrebbe essere la circonferenza) vengono
del tutto ignorate nel corso di laurea in Ingegneria Informatica (almeno
in quello che ho seguito io).
Quanto poi al fatto che siano invertibili o meno bisognerebbe capire cosa
si intende qui per "invertibili". Nello spazio delle funzioni polidrome
(sempre che si chiamino cosi`, e che il loro insieme sia uno spazio)
potrebbe anche accadere che le funzioni siano invertibili;
sinceramente sono troppo ignorante in materia. Ci vorrebbe forse un
matematico "puro".
In ogni caso, anche se non fossero invertibili, potrebbero esistere metodi che
consentano di trovare uno dei "punti" del dominio che vengono mappati in
uno dei punti del codominio.
Cioe` anche se le funzioni non fossero invertibili,  potrebbero esistere
dei metodi che consentono di trovare uno dei possibili sorgenti che da luogo
ad un certo eseguibile. Che poi si possa trovarli tutti non so.
Anche se non saprei come fare (nemmeno per trovarne uno),
non capisco come fate ad essere sicuri che esistano metodi per trovarne
o che tali metodi "sicuramente" non esistano.
Un esempio stupido:
Nel caso della circonferenza di raggio R, con centro nell'originep
osso trovare i valori di x corrispondenti a una data y con
x= +- sqrt(y^2-R);
se si ammette di lavorare nell'insieme delle funzioni polidrome, anche
questa e` una funzione, anche se ad una data y corrispondono due valori di x.
Pero` io non so dire se questo esempio e`
generalizabile (cioe` esistono sempre tecniche per trovare
"funzioni polidrome inverse") e nemmeno so dire se esistano tecniche
generali per trovare alcuni "punti" del "dominio" di partenza
(nel caso della circonferenza potremmo ad esempio essere interessato solo
ai valori positivi di x).
Se voi avete notizie maggiori rispetto alle mie (intendo se conoscete
alcuni teoremi relativi all'argomento), sarei grato se postate i relativi
riferimenti.
Grazie.
Marco Guidi.
 

<snip>
Non perdiamo di vista l'argomento principale, ossia la ricostruibilita' del
sorgente a partire dall'exe.
Tornando ai compilatori abbiamo che (per la numerabilita' delle macchine di
turing, o il che e' equivalente, dei programmi) un compilatore altro non e'
che un ente che prende un programma scritto in un modo e ne tira fuori uno
scritto in un altro. Ossia dato il programma x-esimo (in ingresso) fornisce
il programma y-esimo (in uscita). Questa e' la definizione (piu' o meno) di
funzione in informatica. Si puo', credo, anche usare la normale definizione
matematica come relazione tra elementi di insiemi, non dovrebbe cambiare
nulla.
E' ovvio che sorgenti lessicalmente diversi possono dare luogo a eseguibili
uguali (ad esempio se ci sono commenti o istruzioni inutili tagliate dal
compilatore).
Diverso e' il discorso sulla semantica. Sorgenti semanticamente diversi
forniscono eseguibili sempre diversi (1), dunque teoricamente a partire
dall'exe posso risalire a uno qualsiasi dei programmi che sono
semanticamente uguali al vero sorgente che ha creato quell'exe.
Ad esempio:
    int a;
    a = 0;
    a = a + 1;
    a = a + 1;
e' semanticamente identico a
    int a;
    a = 2;
Dall'exe del primo un ipotetico decompilatore potrebbe tirare fuori il
secondo. Sebbene i due programmi non siano uguali (e quindi la funzione di
decompilazione non abbia avuto successo, almeno come "inversa" teorica) essi
sono semanticamente identici.
Pero' occorre fare una ulteriore considerazione.
Un compilatore qualsiasi, escludendo le ottimizzazioni, e' realizzato
proprio tramite funzione da singola istruzione a blocco di istruzioni
macchina. Ad esempio le istruzioni
    a = 1;
    b = 1;
    c = a + b;
in genere (e senza ottimizzazioni) potrebbero essere tradotte nel seguente
modo, su una macchina generica ad un solo registro:
    load 1
    store a // a = 1
    load 1
    store b // b = 1
    load a
    add b  // a + b
    store c // lo metto in c
Questa traduzione e', per cosi' dire, fissa, ossia dovunque si trovi quella
sequenza di istruzioni (sorgente) si trovera' quella sequenza di istruzioni
nell'oggetto. Potrei dunque decidere che quando trovo la coppia
    load x
    store y
ho tradotto l'istruzione y = x, e dunque potrei risalire al sorgente (a meno
dei nomi delle variabili, ovviamente).
Anche se nella traduzione vengano usati gruppi uguali per tradurre
istruzioni diverse (ad esempio a++ e a  = a + 1) posso risalire a un
sorgente semanticamente uguale.
Il problema e' che la compilazione non e' surgettiva. Ossia esistono
combinazioni di codici macchina che non possono essere generate da nessuna
istruzione, o gruppo di istruzioni, per quel particolare linguaggio.
Ad esempio la sequenza seguente:
    load 1
    load 2
    store a
non puo' essere mai generata da un compilatore (sempre per macchina a un
solo registro), in quanto non esiste nessuna istruzione che generi load 1 e
basta.
Quindi, finalmente, la traduzione inversa di un programma exe NON E' in
generale fattibile nemmeno in via teorica, a meno di non definire un
linguaggio che abbia gli stessi costrutti dell'assembler di quella macchina.
La traduzione di un exe generato da un particolare compilatore PUO' in linea
teorica essere fatta, almeno a livello semantico. Dico in linea teorica
perche' poi intervengono altri fattori (sopratutto le ottimizzazioni) che
scombinano ulteriormente l'eseguibile e praticamente rendono impossibile la
traduzione inversa.
Anche se pure qui in realta' qualcosa si puo' fare: basta che, ad esempio,
un compilatore Pascal realizzi dell'exe in maniera strutturata e che le
ottimizzazioni avvengano solo a livello locale (eliminazione di caricamenti
ridondanti e cose simili) e posso risalire a un sorgente semanticamente
uguale. Ma se l'exe prodotto non e' piu' strutturato (potrebbe anche essere,
in virtu' di ottimizzazioni. Ad esempio lo switch del C spesso viene
tradotto in modi molto diversi con salti da tutte le parti) non posso
risalire al sorgente.
A meno che non ci si metta a enumerare i sorgenti, compilarli tutti, e
trovare l'eseguibile identico al mio exe. Cosa che tra l'altro, se l'exe e'
generato con quel compilatore e con quei settaggi, e' anche fattibile
(dunque la compilazione sarebbe revertibile!) in quanto sono sicuro che
prima o poi termina. Ma all'atto pratico ovviamente non e' una strada
percorribile.
Il tutto ovviamente imho.
Marco
(1) Nota: sorgenti semanticamente uguali non e' detto che fornicano
eseguibili uguali. I programmi
    int a;
    scanf("%d", &a);
    do
    {
        a++;
    } while (1)
    printf("%d", a);
e
    int a, b;
    scanf("%d", &a);
    do
    {
        a++;
        b = a + 2;
        if (a == b)
            printf("%d", a);
    } while (b != a)
sono semanticamente uguali (il loro codominio e' rappresentato dal solo
bottom) ma forniscono eseguibili del tutto diversi.

 funzione in informatica. 
potresti dire dove si puo` trovare tale definizione (libri, articoli,
riviste o quant'altro).
Grazie,
Marco Guidi.

Marco Guidi.
Beh, sono ricordi (spero non sbiaditi) del corso di laurea. Qualcosa trovi
sul classico Aiello, Albano, Attardi, Montanari "teoria della computabilita'
e logica dei linguaggi formali" ( o qualcosa di simile).
Se studi a Pisa lo trovi anche sui muretti del lungarno.
Marco

 Marco
Grazie.
In realta` sono gia` laureato, ma la parte di informatica teorica e simili
e` decisamente il mio punto debole.
Marco Guidi
 

you wrote :
#Hai le idee confuse. Un compilatore non e' funzione del proprio input, e'
#l'eseguibile che e' l'immagine dell'input tramite la fuzione *compilatore*.
Ci siamo fraintesi : e' evidente che volevo dire che un compilatore
non e' UNA funzione, nel senso che accetta come input il codice
sorgente e fornisce come output il codice oggetto.
Ad una istruzione del codice sorgente vengono associate piu'
istruzioni del codice oggetto.
La compilazione puo' essere una trasformazione ma non il risultato
dell'applicazione di una funzione.
Ribadisco : sempre che il concetto di "funzione" sia quello espresso
in matematica.


you wrote :
#Chi ha detto questa fesseria?
Vedi msg a M.Natoni per chiarimenti.


you wrote :
#Ma dove sta scritto? Perchè non consideri l'insieme potenza?. Se fosse vero
#quello che dici tu, ad ogni carattere ascii del sorgente dovrebbe
#corrispondere un'istruzione in codice macchina.
Nessuno sta dicendo questo....continui a divagare...
#Invece è una funzione e pertanto è invertibile, ma quarda un po'!
#Non inventiamoci assurdità pseudo-matematiche per giustificare la non
#conoscenza dell'argomento.
Ma per favore !
#E una funzione che trasforma una stringa nella stessa ma eliminando gli
#spazi ripetuti? In C non è una funzione? Eppure non trasforma ogni carattere
#in un'altro carattere, modifica la lunghezza della stringa.
Davvero ?
Sei in grado di ricostruire la stringa originale da quella appena
ottenuta ?


you wrote :
#Peccato che si stia parlando di informatica, e qui la definizione di
#funzione e' diversa da quella che dai tu.
Davvero ? e quale sarebbe la definizione *informatica* di funzione ?


you wrote :
#Se non sei piů interessato, non fa niente, non credo ci debbano essre
#"vincitori", ma gente che si scambia opinioni.
Chi sta dicendo questo ?
Come al solito non hai capito...
Fermiamo qui l'off-topic per cortesia.


in matematica.
Prova a studiare un po' di informatica. Sono sicuro che capirai.
Marco

Davvero ? e quale sarebbe la definizione *informatica* di funzione ?
Ok, te la dico, ma il resto te lo studi da solo.
In informatica per fuzione normalmente si intende un sottoinsieme delle
funzioni definibili in senso matematico (come relazioni tra insiemi).
Tale sottoinsieme e' composto dalle sole funzioni cosiddette "calcolabili",
ossia per le quali e' possibile, dato un certo sistema formale, scrivere un
algoritmo (la definizione cercatela sui libri) tale che, almeno nel campo di
definizione della funzione, termini e fornisca il risultato esatto.
Si dimostra che non esiste nessun formalismo S tale che Fs (l'insieme delle
funzioni calcolabili in S) e' equipotente all'insieme di tutte le funzioni.
Queste cose le trovi nelle primissime pagine di qualsiasi testo sulla teoria
della calcolabilita'.
Marco

 ambiguità.
L'argomento è lo stesso dell'altro post, dove critichi il mio esempio sulla
funzione che toglie spazi, rispondo qui:
Anche se sembrerebbe che dove c'è perdita di informazione non si possa
parlare di funzioni in senso stretto, in realtà non è così (e su questo
credo che tu sia d'accordo). Basta pensare alla media aritmetica di 2
numeri: c'è perdita di informazione nel senso che non è possibile poi
ristabilire l'esatto valore dei due numeri conoscendo solo la media.
Per l'invertibilità, il discorso è diverso. Nessuno dice che è possibile
ricostruire il sorgente originale, a meno di condizioni molto particolari e
di fatto irrealizzabili. Però un sorgente equivalente si.
Mi spiego meglio: nel caso della media aritmetica, posso sempre trovare 2
numeri che hanno quella media, per cui l'operazione è invertibile "a meno
di" equivalenze.
E qui l'equivalenza non s'intende nel senso di uguaglianza, ma semplicemente
che ripetendo la prima operazione ottengo lo stesso risultato.
Per il compilatore, è possibile, dato un codice oggetto, ricavare un
sorgente che, ricompilato, dà il codice oggetto originale.
In generale, il sorgente ottenuto sarà diverso da quello originale, ma
"equivalente" sotto tutti gli aspetti (escluso forse la comprensibilità).
Per la stringa, idem. In questo caso, la stringa ottenuta è anche l'inversa
di sè stessa, infatti riapplicando la funzione e riinvertendola a
piacimento, resta invariata. (L'originale è certamente persa, ma rispetta a
questa funzione, è equivalente a quella ottenuta)
Potrebbe sembrare un'interpretazione un po' forzata, specie nel caso della
stringa, ma mi sembra che il punto focale fosse quello di definire cosa si
intende per "programma equivalente", e, che piaccia o no, è così.
Spero di non essere stato "brusco", mi hanno già rimproverato per questo, ma
non era mia intenzione, giuro :)
--
Alessandro Monti

 ottenuta ?
Una equivalente.
(segue copia-incolla da un'altra risposta)
Nessuno dice che è possibile
ricostruire il sorgente originale, a meno di condizioni molto particolari e
di fatto irrealizzabili. Però un sorgente equivalente si.
Mi spiego meglio: nel caso della media aritmetica, posso sempre trovare 2
numeri che hanno quella media, per cui l'operazione è invertibile "a meno
di" equivalenze.
E qui l'equivalenza non s'intende nel senso di uguaglianza, ma semplicemente
che ripetendo la prima operazione ottengo lo stesso risultato.
Per il compilatore, è possibile, dato un codice oggetto, ricavare un
sorgente che, ricompilato, dà il codice oggetto originale.
In generale, il sorgente ottenuto sarà diverso da quello originale, ma
"equivalente" sotto tutti gli aspetti (escluso forse la comprensibilità).
Per la stringa, idem. In questo caso, la stringa ottenuta è anche l'inversa
di sè stessa, infatti riapplicando la funzione e riinvertendola a
piacimento, resta invariata. (L'originale è certamente persa, ma rispetta a
questa funzione, è equivalente a quella ottenuta)
Potrebbe sembrare un'interpretazione un po' forzata, specie nel caso della
stringa, ma mi sembra che il punto focale fosse quello di definire cosa si
intende per "programma equivalente", e, che piaccia o no, è così.
--
Alessandro Monti

 Fermiamo qui l'off-topic per cortesia.
Ormai...
Comunque essendo sullo stesso thread non dovrebbe dare tanto fastidio.
--
Alessandro Monti

 Vedi msg a M.Natoni per chiarimenti.
Scusami, ma non lo trovo (sarà la pigrizia).
Se l'ho detto io, devo essermi sbagliato a scrivere.
Ora credo di essermi corretto.
--
Alessandro Monti

 una relazione invertibile.
La premessa e' sbagliata. quindi l'implicazione e' giusta :-)
Ciao, Roberto

 In informatica per funzione..
..si intende funzione.
Tesi di Church-Turing:
tra tutte le funzioni quelle intuitivamente calcolabili lo possono essere con
una
macchina di Turing.
Credo che questo sia quello che intendevi. Una funzione calcolabile e' pur
sempre
una funzione. Metodi l'ho fatto anche io, perfavore mi citi il posto dove dice
che gli i programmi
non calcolano funzioni in senso matematico (cioe' funzioni nell'unico senso che
io conosca)  ?
Ciao, Roberto


Io ho le idee un po' confuse. Forse, avendo ottenuto circa 10 minuti fa
l'accesso alla biblioteca del S.Anna potro` chiarirmi un po' le idee).
Comunque riprendo un esempio ch avevo gia` fatto  in precedenza:
in senso "strettamente matematico" io conosco 2 tipi di funzione, non
solo 1:
 1. quelle che ad un valore del "dominio", associano al piu` un  solo valore
del
 "codomino" (esempio banale: la semicirconferenza)
 2. quelle che ad un valore del "dominio", associano uno o piu` un  solo valori
 del "codomino" (esempio banale: la circonferenza). Ripeto che credo
 che si chiamino funzioni polidrome.
NB se io prendo come "dominio" e "codominio" l'insieme dei numeri reali, vale
quanto sopra. Se invece come "domino" e/o "codomino" prendo delle n-ple
di numeri reali, allora il discorso puo` cambiare. Ma nulla dovrebbe vietarmi
di mettermi a studiare funzioni di tipo 2., scegliendo come "dominio" e
"codominio" quelli che voglio io, se lo ritengo opportuno.
 Ora io credo che, data una equazione del tipo x^2 + y^2 = R^2
 si possa ricavare
   x = +-sqrt(R^2- y^2).
Fissato R, la precedente formula mi permette di definire x come funzione
 di y, anche se come "dominio" e "codominio" ho scelto l'insieme dei reali
  (funzione in senso 2., non in senso 1.).
 Il fatto che le funzioni che appartengono al caso 2. non siano studiate
 in quasi nessun corso di laurea  (forse matematica ?) non vuol dire che
 non si possa costruire una teoria basata su di esse (o meglio,
 io non conosco motivi per cui non si possa farlo, pero` magari esistono).
 Quello che continuo a trovare strano e`:
 come fate ad essere cosi` sicuri che, estendendo il concetto di funzione,
 (quello di usare funzioni del caso 2 e` solo un esempio), non esistano
 tecniche, algoritmi, ecc., che consentano, magari in tempi infiniti,
 di trovare ad esempio tutti i sorgenti equivalenti a quello che ha generato
 un dato eseguibile (mi sembrerebbe una buona definizione di
 "funzione inversa generalizzata").
 Se fosse possibile, allora tra tutti  ci sarebbe anche
 proprio "quello" che ha generato il dato eseguibile. Magari non lo potrei
 trovare in tempi finiti e magari non potrei "distinguerlo" dagli altri,
 pero` non mi e` chiarissimo il motivo per cui sia impossibile trovarlo.
 Voglio dire: con le tecniche "classiche" che si studiano normalmente
 tipo teoria della computabilita` (che peraltro io conosco pochissimo)
 o quant' altro magari non si riesce a trovare l'inversa di una funzione
 di un certo tipo, pero`, secondo me nulla vieta di estendere questi
 concetti (funzione, inversa di una funzione) se lo si ritiene utile.
 Magari qualcuno lo ha gia` fatto e ha dimostrato che e` completamente
 inutile, pero` io non ne sono a conoscenza.
 Marco Guidi.
 

io conosca)  ?
Non ho detto questo, ma che le funzioni calcolabili (ossia quelle di
interesse in ambito informatico) non coincidono con tutte quelle possibili.
Per questo le *funzioni* di cui si parla in informatica non sono le stesse
di cui si parla in matematica (ma un loro sottoinsieme).
Questo implica che  non puoi semplicemente sostituire *funzione calcolabile*
laddove trovi *funzione matematica*.
Marco

 inutile, pero` io non ne sono a conoscenza.
Il discorso della decompilazione sarebbe affrontabile, forse, se ci si
riferisse a classi di programmi, dove tutti i programmi di una certa classe
implementano la stessa funzione.
Pero' per come sono costruiti praticamente i compilatori non si potrebbe
piu' parlare di *funzione*, nel senso che due programmi appartenenti alla
stessa classe (ad esempio due programmi che non terminano) possono generare
eseguibili diversi.
A meno che il compilatore non descriva il programma mediante semantica
denotazionale (non so se e' possibile, ma forse si), e allora avrei che
programmi della stessa classe verrebbero "riconosciuti" come uguali e
genererebbero lo stesso codice. Ma ora mi sto avventurando un po' troppo,
non vorrei dire cavolate.
Marco

 interesse in ambito informatico) non coincidono con tutte quelle
possibili.
Infatti, in ultima analisi, le funzioni calcolabili da un PC (o macchina di
Turing) sono quelle che lavorano su interi. (in generale su insiemi discreti
e numerabili).
Quelle matematiche su numeri reali, immaginari, trascendentali, ecc...
I numeri float sono solo approssimazioni grossolane dei numeri reali, e
difatti almeno in C non si chiamano real.
--
Alessandro Monti

> NB se io prendo come "dominio" e "codominio" l'insieme dei numeri reali,
vale
Nei PC (o macchine di Turing) i reali non esistono. Esistono solo
approssimazioni basate sugli interi.
Quindi ogni funzione matematica che lavori su interi non è neppure
implementabile, figuriamoci trovare l'inversa.
Se invece consideri l'approssimazione (con quante cifre vuoi, purchè in
numero finito) della stessa funzione, allora il discorso cambia.
Un esempio notevole (in matematica) è la trasformata di Fourier,
perfettamente approssimante e perfettamente invertibile.
Certo che se ti fermi all'n-esimo termine invece di prendere tutta la serie
infinita, non troverai mai la stessa funzione di partenza.
--
Alessandro Monti

 approssimazioni basate sugli interi.
Era solo un esempio per dire che le teorie esistenti possono talvolta essere 
generalizzate, se lo si ritiene opportuno.
Molti hanno risposto citando teorie esistenti ma io non so se le teorie 
esistenti nel settore in questione (codice sorgente <-> eseguibile) siano
generalizzabili o meno. Comunque ho iniziato a leggere
Aiello: "Teoria della computabilita`...". La premessa non e` delle migliori,
visto che nell'introduzione dice di voler studiare nel testo alcuni formalismi
(Macchine di Turing, ecc.) ma poi dice che non e` dimostrabile che ogni 
procedimento di calcolo sia traducibile in uno di quei formalismi.
Marco Guidi.

 procedimento di calcolo sia traducibile in uno di quei formalismi.
In effetti mi sembra che sia un'assunzione che PC=macchina di turing, e non
una dimostrazione.
Certo č che sono molto simili, e che un PC puň emulare una macchina di
turing, a parte il nastro infinito...
--
Alessandro Monti