Newsgroup: it.scienza.informatica
Titolo: Programmi poliglotta: incoerenza teoria-pratica

[Repost: non vedo la prima copia del post spedito il 11/06/04. Ci sono
problemi con la moderazione?]
Siano {phi_n} e {psi_n} due distinti sistemi di programmazione
accettabili (S.P.A.).
Troviamo un programma con codifica p (dato l'isomorfismo con i
naturali parliamo solo di codifica), tale che phi_p = psi_p. Vale a
dire la funzione calcolata dal programma p nel modello {phi_n} e'
uguale a quella calcolata da p nel modello {psi_n}.
E' facile osservare che tale p esiste.
Infatti, poniamo t una traduzione/compilazione dal primo al secondo
sistema:
t : ProgrammiPhi --> ProgrammiPsi
quindi
phi_p = psi_t(p)
cioe'
psi_p = psi_t(p)
E questo ci e' garantito dal teorema di ricorsione, poiche' la
funzione t e' ricorsiva totale.
E' interessante notare anche che esiste un programma p tale che la sua
esecuzione su qualunque SPA abbia la stessa semantica, ossia calcoli
la stessa funzione. Infatti basta definire tante traduzioni quanti
sono i SPA.
Eppure in realta' non e' rose e fiori come descritto.
Chi riesce a trovare un file (una codifica di un programma) che sia
eseguito su sistemi diversi (es. x86, mips, pascal, c) e dia lo stesso
risultato per ogni input? Non riesco a trovare un file, eseguibile su
x86 e mips, neanche rotolando sui carboni ardenti, figuriamoci
pretendere che calcoli la stessa funzione.
Qualcuno ha idea a cosa sia dovuta questa incoerenza nei sistemi
reali?
-- 
Linux Registered User #181013
[Exokernels] Although one approach to eliminating bloated, buggy,
unreliable operating systems is to make them smaller, a more radical
one is to eliminate the operating system altogether.

 writes:
Sephiroth> Siano {phi_n} e {psi_n} due distinti sistemi di
Sephiroth> programmazione accettabili (S.P.A.).
Sephiroth> Troviamo un programma con codifica p (dato l'isomorfismo
Sephiroth> con i naturali parliamo solo di codifica), tale che
Sephiroth> phi_p = psi_p.
Sephiroth> Vale a dire la funzione calcolata dal programma p
Sephiroth> nel modello {phi_n} e' uguale a quella calcolata da p nel
Sephiroth> modello {psi_n}.
Sephiroth> E' facile osservare che tale p esiste.
Sephiroth> Infatti, poniamo t una traduzione/compilazione dal primo al
Sephiroth> secondo sistema: t : ProgrammiPhi --> ProgrammiPsi
Sephiroth> quindi phi_p = psi_t(p) cioe' psi_p = psi_t(p)
Sephiroth> E questo ci e' garantito dal teorema di ricorsione, poiche'
Sephiroth> la funzione t e' ricorsiva totale.
Sephiroth> E' interessante notare anche che esiste un programma p tale
Sephiroth> che la sua esecuzione su qualunque SPA abbia la stessa
Sephiroth> semantica, ossia calcoli la stessa funzione. Infatti basta
Sephiroth> definire tante traduzioni quanti sono i SPA.
Sephiroth> Eppure in realta' non e' rose e fiori come descritto.  Chi
Sephiroth> riesce a trovare un file (una codifica di un programma) che
Sephiroth> sia eseguito su sistemi diversi (es. x86, mips, pascal, c)
Sephiroth> e dia lo stesso risultato per ogni input?
Risposta breve:
make bootstrap
Il compilatore si compila tradizionalmente circa con  make bootstrap
e cosi` via, sui sistemi unix (ma non solo), per architetture diverse
si effettua crosscompilazione, quindi per input identici e
crosscompiling specificato da parametri (che sono altro input)
si produce output che a fatica arriva ad essere identico.
Sephiroth> Non riesco a trovare un file, eseguibile su x86 e mips,
Sephiroth> neanche rotolando sui carboni ardenti, figuriamoci
Sephiroth> pretendere che calcoli la stessa funzione.  Qualcuno ha
Sephiroth> idea a cosa sia dovuta questa incoerenza nei sistemi reali?
Tu chiedevi un file, ma il compilatore e` un sistema di file
e non uno solo per comodita` di integrazione con il sistema operativo
allo stadio evolutivo precedente (o da cui si parte).
Nota: I passaggi chiave evolutivi del compilatore e` sufficiente che siano
      compiuti una sola volta, in un solo computer, con esecuzione
      accompagnata integralmente dall'ingegno.
      L'astrazione dell'ingegno *altrui* e` mancanza grave di
      rispetto se si scrive "e` facile osservare che p esiste...").
Dove scrivi "e` facile osservare" non lo e` affatto, tant'e` vero che
poi incontri difficolta` proprio in quell'"osservabilita`" in quei
sistemi che chiami reali.
E` chiaro che  ``far funzionare il traduttore t'', cioe` averlo
capito nel suo significato piu` ampio, e` la chiave di volta di
quella teoria che altrimenti ti sembra surreale.
Sephiroth> -- 
Sephiroth> Linux Registered User #181013 [Exokernels]
Io sono unregistered user <1000 (stima) (1992)
Sephiroth> Although one approach to eliminating bloated, buggy,
Sephiroth> unreliable operating systems is to make them smaller, a
Sephiroth> more radical one is to eliminate the operating system
Sephiroth> altogether.
Dopo che hai eliminato i SO ti rimane solo la teoria, ma ti accorgi che
non basta perche hai imparato a memoria i passaggi chiave.
Il sapere e` servito,
MARco
-- 
xref: 
http://mar.i.am/~u16590.10351/it.scienza.informatica/makebootstrap,it
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1  ; 0<t<14

non basta perche hai imparato a memoria i passaggi chiave.
Hehe ;-) E' una citazione da non prendere alla lettera. E' da
interpretare. E la questione degli esonuclei permette di capirla.
Comunque ragionandoci su, la mia convinzione e' che il problema sia da
ricercare nella traduzione sui sistemi reali, in quanto non totale,
come invece richiesto dalle ipotesi della proprieta'.
-- 
Linux Registered User #181013
[Exokernels] Although one approach to eliminating bloated, buggy,
unreliable operating systems is to make them smaller, a more radical
one is to eliminate the operating system altogether.


Sephiroth> writes:
           Sephiroth> Eppure in realta' non e' rose e fiori come
           Sephiroth> descritto.  Chi riesce a trovare un file (una
           Sephiroth> codifica di un programma) che sia eseguito su
           Sephiroth> sistemi diversi (es. x86, mips, pascal, c) e
           Sephiroth> dia lo stesso risultato per ogni input?
         > >
         > > Risposta breve:
         > >
         > > make bootstrap
         > > Il compilatore si compila tradizionalmente circa con make
         > > bootstrap e cosi` via, sui sistemi unix (ma non solo), per
         > > architetture diverse si effettua crosscompilazione, quindi
         > > per input identici e crosscompiling specificato da
         > > parametri (che sono altro input) si produce output che a
         > > fatica arriva ad essere identico.
Sephiroth> Cioe' make bootstrap crea un compilatore che funziona su
Sephiroth> almeno 2 architetture diverse?
Non solo, make bootstrap compila un compilatore,
cioe` lo rende interprete di Sistemi di Prograsmmazione Accettabili
Sephiroth> Va bene. In effeti conosco gia' dei sorgenti che funzionano
Sephiroth> equivalentemente su due linguaggi di programmazione differenti.
Sephiroth> Ce ne saranno in giro a bizzeffe.  Il problema su cui
Sephiroth> volevo porre l'accento e' che la proprieta' in questione
Sephiroth> non vale per ogni coppia di sistemi.
Sephiroth> Ad es. se ti dico di trovarmene uno per 386 e mips, riesci
Sephiroth> a trovarmelo? Anzi congetturo che non sia possibile
Sephiroth> trovarne manco uno (per 386 e mips)!
No, non devi pensare ad un "file" (che e` un concetto astratto e fuori
dalla teoria che hai citato), considera il compilatore scritto in
C che sono dati per il sistema operativo eseguibile su MIPS,
considera poi un sistema operativo in esecuzione su i386:
Hai cosi` due funzionali phi_p e psi_p (che non sono file) eseguiti
su due SPA differenti (mips e i386), ed a seguito del make bootstrap
puoi crosscompilare su uno dei due ed avere risultati identici.
Sephiroth> Non riesco a trovare un file, eseguibile su x86
Sephiroth> e mips, neanche rotolando sui carboni ardenti,
Sephiroth> figuriamoci pretendere che calcoli la stessa
Sephiroth> funzione.
Sephiroth> Qualcuno ha idea a cosa sia dovuta
Sephiroth> questa incoerenza nei sistemi reali?
Sephiroth> >
Sephiroth> >
Sephiroth> >Tu chiedevi un file, ma il compilatore e` un sistema di
Sephiroth> >file e non uno solo per comodita` di integrazione con il
Sephiroth> >sistema operativo allo stadio evolutivo precedente (o da
Sephiroth> >cui si parte).
Sephiroth> E cosa intendi per integrazione con il s.o. allo stadio
Sephiroth> evolutivo precedente?
Da piccolo facevo il compilatore di quello che pensavo, ed
il mio pensiero e` un SPA (almeno per me).
Sephiroth> >Nota: I passaggi chiave evolutivi del compilatore e`
Sephiroth> >sufficiente che siano compiuti una sola volta, in un solo
Sephiroth> >computer, con esecuzione accompagnata integralmente dall'ingegno.
Sephiroth> Cioe'? Spiegati meglio please.
PS: con questa domanda mi e` scappata la voglia di rispondere, e`
    rimasta comunque traccia di cio` che ho pensato in questo stato di
    minore interesse/impegno, mentre leggevo. [non togiere questo PS
    se si intende rispondere alla parte che segue]
Tu ti devi spiegare meglio, cosa vuol dire "Cioe`?" ?  ;-)
Provo piuttosto comunque a spiegarmi diversamente (cioe` buttando a
caso qualche concetto logico, la cui sottointesa potrebbe aver impedito
l'efficacia della comunicazione):
Il compilatore e` un automa a stati finiti che trasforma un
linguaggio in codice macchina. Di fatto solo con l'aumentare delle
funzionalita` di livello evolutivo inferiore si aggiungono
funzionalita` e idee atstraibili.
Questo aumento di funzionalita` permette l'introduzione di concetti
astratti come {file, linguaggi, traduttori ecc..} che sono parte
dell'evoluzione dei sistemi operativi(da intendersi in senso ampio).
Ognuno di questi passaggi evolutivi e` sufficiente che sia computo
una sola volta in un solo computer [accidenti mi sono ripetuto, comunque
tant'e` che tu ti installi la tua distribuzione linux da un
SistProgAccet saltando un passo evolutivo ventennale usando i binari].
Sephiroth> > L'astrazione dell'ingegno *altrui* e` mancanza grave di
Sephiroth> > rispetto se si scrive "e` facile osservare che p esiste...").
Sephiroth> Chi conosce quel poco di teoria della computazione non
Sephiroth> trovera' nessun problema a capire quel che ho scritto,
Sottolineiamo "quel poco" e sostituiamo "capire" con "credere di capire"
e sono d'accordo.
Sephiroth> e a notare che tale p esiste.  Chi non conosce quel poco di
Sephiroth> t.d.c... beh di certo non pretendo che capisca la mia
Sephiroth> frase... Quindi e' bene che si astenga da commenti, sulla
Sephiroth> mia frase, che ne evidenzierebbero l'ignoranza.
Secondo me l'ignoranza qui e` quella forma di accettazione passiva di ritenere
di aver capito la teoria di fronte all'evidente assurdo che la propria
comprensione esce -per se` inspiegabilmente- dai sistmi reali.
Chiaramente sto parlando dell'ultimo differenziale di ignoranza volontaria.
Leggi il tuo titolo assegnato al thread...
         > >Dove scrivi "e` facile osservare" non lo e` affatto,
         > >tant'e` vero che poi incontri difficolta` proprio in
         > >quell'"osservabilita`" in quei sistemi che chiami reali.
Sephiroth> Forse non hai capito, ma tutta la prima parte del post non
Sephiroth> fa un minimo accenno ai sistemi reali.  Quando mai ho detto
Sephiroth> che e' facile osservare che "esiste tale p nei sistemi reali"?
Se uno capisce, non c'e` distinzione tra sistemi reali e
sistemi non reali  o "teoria creduta _capita_" che dir si voglia.
Aggiungo una battuta:
Pochi sanno che c'e` la "teoria astratta" e la "teoria stratta"; anche studenti
diligenti le confondono credendo sia la stessa e unica, ma la seconda,
pur somigliando se mal percepita e` subdolamente inutile. -- MARco
         > >E` chiaro che ``far funzionare il traduttore t'', cioe`
         > >averlo capito nel suo significato piu` ampio, e` la chiave
         > >di volta di quella teoria che altrimenti ti sembra surreale.
Sephiroth> Per t indendi il traduttore da me precedentemente definito?
Si`, definito ed usato.
Sephiroth> Dove/quale sarebbe questo traduttore?
Sara` che terabit di memoria e registri danno origine a cosi` tante
combinazioni che la gente perde tra questi bit i concetti.
Dati e programmi sono due concetti astratti e come tali interpretati
di significato, ma nulla toglie che possano essere interpretati
a convenienza astratta.
Un traduttore scelto a caso dalle tante:
a2p  e` una sequenza di stati discreti in cui e` visibile e
     idealizzabile come "input"  una sequenza di bit interpretata da
     perl (compilato in c) che traduce programmi dal SPA awk a SPA perl.
La stessa sequenza di input puo` essere data ad un perl su un sistema
operativo differente, riconsiderando delle SPA piu` ampie del solo
singolo linguaggio di programmazione, si hanno funzioni con parti comuni
che danno lo stesso risultato.
         Sephiroth> Although one approach to eliminating bloated,
         Sephiroth> buggy, unreliable operating systems is to make
         Sephiroth> them smaller, a more radical one is to
         Sephiroth> eliminate the operating system altogether.
         > >
         > >Dopo che hai eliminato i SO ti rimane solo la teoria, ma
         > >ti accorgi che non basta perche hai imparato a memoria i
         > >passaggi chiave.
Sephiroth> Hehe ;-) E' una citazione da non prendere alla lettera.
Guarda che le citazioni terminano con "-- Autore", tu non lo hai
fatto, e visto il tuo livello di immersione dei sistemi operativi,
non te ne vedevo un contesto ampliabile.
Sephiroth> E' da interpretare. E la questione degli esonuclei permette
Sephiroth> di capirla.
La cultura per me non sta davanti alle etichette (sistemi operativi,
libos, esonuclei), tant'e` che mi hai fatto rispolverare un progetto
del MIT che avevo gia` notato anni fa, figurati come la considero io
che nell'89 avevo cominciato a creare un sistema operativo minimale
multitasking per 286.
Sephiroth> Comunque ragionandoci su, la mia convinzione e' che il
Sephiroth> problema sia da ricercare nella traduzione sui sistemi
Sephiroth> reali, in quanto non totale, come invece richiesto dalle
Sephiroth> ipotesi della proprieta'.
Prova a pensare di essere tu a non averla totalizzata, il dominio di t
e` l'insieme di tutti i programmi del SPA di partenza scelto (quelli
che hanno errori sintattici non centrano), un buon traduttore reale
li traduce tutti (se non vogliamo considerare inutilmente quelli
che idealmente possono superare i limiti di memoria).
Saluti,
MARco
-- 
xref: 
http://mar.i.am/~u16592.15689/it.scienza.informatica/
,


e` l'insieme di tutti i programmi del SPA di partenza scelto (quelli
Il dominio di t e' tutto N, mentre in sistemi reali non tutte le
combinazioni di caratteri/byte viene tradotta.
Ad ogni modo io sto ancora aspettando di vedere una sequenza di bit
(per non chiamarlo file) che gira sia su mips che su i386.
PS: Un lamer sa quotare meglio!
-- 
Linux Registered User #181013
[Exokernels] Although one approach to eliminating bloated, buggy,
unreliable operating systems is to make them smaller, a more radical
one is to eliminate the operating system altogether.