Newsgroup: it.comp.os.dibattiti
Titolo: BAML

Una delle proprieta' piu' interessanti di XML (l'unica ?) e' che e'
human readable, con annessi e connessi.
Una delle innovazioni di Longhorn pare essere tale XAML e BAML, che
altro non e' che XAML compilato in binario.
Perche' compilare XML ? Perche' usare XML se poi me lo compili in
binario ?
-- 
                                                __Nicholas Wieland
Now is better than never.
Although never is often better than *right* now.
                                                __The Zen of Python

 binario ?
Perchč sennņ č opensource, e sarebbe roba coatta!
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

per aumentare la velocita' di interpretazione?
no, cosi', la butto eh?

 no, cosi', la butto eh?
Anch'io ci ho pensato, ma perche' usare XML allora ?
-- 
                                                __Nicholas Wieland
In the face of ambiguity, refuse the temptation to guess.
                                                __The Zen of Python

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true. [J. Robert Oppenheimer]

 binario ?
Perchè usare un linguaggio di programmazione se poi me lo compili in
binario?
Forse perchè magari quando ho scritto uno XAML complicatissimo con una user
interface spaventosa non gradisco che la gente me lo cipolli come
preferisce? O perchè visto che comunque (da quel che ho capito) XAML ha
comunque dietro del codice invece di fare una compilazione "a runtime" la
faccio "a design time".
La più probabile comunque mi sembra la prima.
Saluti
Massimo

 Anch'io ci ho pensato, ma perche' usare XML allora ?
usare xml non contraddice il fatto di compilarlo successivamente...
dipende da che uso ne vuoi fare...
per cose normali puoi interpretarlo lentamente con un parser testo, per
altre e' necessario compilarlo e usare opcode..


Questa mi sembra piu' plausibile.
Alessandro.

 decompilatori.
E si, vabbe`...
bye,
-- 
piergiorgio

 decompilatori.
E' una trasformazione irreversibile.


 perche' usare XML allora ?
Perchè in concomitanza con win2003 per ogni transazione risparmi 5
centesimi ;-)
-- 
Saluti,
Muttley
"non c'è peggior cattivo del buono che diventa cattivo"

 ?
Ecco, questa e' una bella domanda :)
Cmq, piu' che altro, visto il video "Lap around Longhorn" devo dire che XAML fa 
proprio una bella bella bella figura. (Non ho mai visto codare in XUL o SwingML 
cmq).
-- 
  _|O|_ Davide Silvio Inglima-Modica     | "Mana is rapidly disappearing from"
  _|_|O mailto:
hades...@despammed.com
 | "the Earth, even the mana tree has"
  O|O|O 
http://limacat.blogspot.com
      | "begun to wither" Seiken Densetsu 3
Posted from X-Privat Free NNTP server - 
www.x-privat.org

 binario ?
Il vero problema comunque e' che XAML ricoprira' la parte che oggi e' ricoperta 
dalla form, pero' un modo leggermente diverso.
XAML gestisce solo la GUI. In C# 2.0 infatti sara' possibile dichiarare una 
classe "partial", che e' molto simile al meccanismo di "extern" di C/C++. Il 
compilatore comincia a compilare la classe, ma poi msbuild (l'"ANT" del prossimo 
visualstudio) finisce l'oggetto linkando la gui (scritta in XAML e compilata) e 
la tua classe C# che gestisce la logica dei pulsanti...
Oggi comunque l'oggetto e' uno solo, ovvero una classe che ha una parte di gui 
(creata automaticamente dall'editor grafico di VStudio) e dei metodi. 
Probabilmente hanno fatto cosi' per permetterti con una form xaml di linkare 
assieme piu' classi di logica diverse. (Va a capire cmq).
Ad ogni modo, XAML ha un bel po' di flessibilita' (immagina avere una textbox, 
un bottone, e del testo in mezzo che wrappa come se fosse nell'html, e dietro 
come sfondo un video che continua in loop, mentre le scritte sono piu' o meno 
trasparenti).


   _|O|_ Davide Silvio Inglima-Modica     | "Mana is rapidly disappearing
from"
--
.A  [Microsoft MVP .NET]
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
Read my blog at: 
http://www.ugidotnet.org/4.blog

 E' una trasformazione irreversibile.
Calma, diciamo che non e` unicamente reversibile.
Nel senso che si puo` decompilare in infiniti modi,
quindi trovare l'esatto sorgente potrebbe non essere
proprio ovvio...
bye,
-- 
piergiorgio


Irreversibile nel senso che se si compila un programma scritto in un 
linguaggio ad alto livello --- non assembler :) --- non è possibile 
ricreare il codice originale dal binario. A meno che non fai una 
immersione strana del codice...


 immersione strana del codice...
Appunto, ma il motivo e` che sono possibili infinite
rappresentazioni ad alto livello che portano a quel
binario, per questo non si riesce a trovare l'originale.
bye,
-- 
piergiorgio

 binario, per questo non si riesce a trovare l'originale.
Dicesi processo irreversibile.


 binario ?
Perchè XML è stupido proprio per questo.
 

 binario?
XML è rappresentazione dati, non linguaggio di programmazione.


Ma interessa veramente ottenere l'originale?
Spesso ci si puo' accontentare di un sorgente equivalente purche' abbastanza
intelleggibile.
Alessandro.

 intelleggibile.
Il problema e` che "intellegibile" e` una cosa "umana", quindi
si deve sempre e comunque agire a mano, di conseguenza la cosa
risulta equivalente ad andare di debugger & disassembler.
bye,
-- 
piergiorgio

 Dicesi processo irreversibile.
Si, ma c'e` il rischio di creare confusione tra "irreversibile"
nel senso che vi sono zero possibili decompilazione ed il fatto
che ve ne siano infinite.
Non e` proprio la stessa cosa, dato che nel secondo caso si
potrebbe essere "fortunati" e trovare l'originale, mentre nel
primo caso e` proprio impossibile.
bye,
-- 
piergiorgio

 Dicesi processo irreversibile.
MD5 è irreversibile. JPEG è irreversibile. Non BAML
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 MD5 è irreversibile. JPEG è irreversibile. Non BAML
Quindi hanno implementato una compilazione che non è altro che un 
isomorfismo? Non ha proprio senso...


 MD5 è irreversibile. JPEG è irreversibile. Non BAML
Ma JPEG non e` una compilazione, dato che _esplicitamente_
elimina informazione.
bye,
-- 
piergiorgio

 <icq:241572242>
But still I fear, and still I dare not
Laugh at the mad man (The Prophet's song)

 Qualunque trasformazione è una applicazione, e come tale bisogna 
Eh?
Cosa vuol dire?
Comunque il concetto di "compilare" e` ben definito ed
implica, tra le altre cose, una totale possibilita` di
passare da un linguaggio formale all'altro.
Se cosi` non fosse, cioe` se vi fosse perdita di informazione,
non si passerebbe ad un linguaggio formale.
Il concetto di "trasformazione" e` piu` vasto, include
la compilazione, ma anche altro.
JPEG non e` una compilazione, e` una trasformazione, ma
che vuol dire?
Uno puo` anche considerare la trasformazione nulla, che e`
irreversibile, ma non puo` mica dire che e` una compilazione.
bye,
-- 
   Piergiorgio Sartor

 che vuol dire?
E' uguale.


 sorgenti? No. Questo *non* dimostra che non siano entrambi linguaggi 
Non c'e` perdita di "informazione".
Dal punto di vista "informatico", od "informativo", il
sorgente ed il binario hanno _esattamente_ lo stesso
contenuto, solo che il secondo e` "piu` difficile" da
leggere per un essere umano.
Esiste un teorema che afferma l'assoluta trasformabilita`
di tutti le rappresentazioni da un linguaggio ad un altro.
bye,
-- 
   Piergiorgio Sartor

 di tutti le rappresentazioni da un linguaggio ad un altro.
Applicazione non biettiva. E qui non puoi che consentire.


 Quale č il linguaggio non formale? La DCT č un linguaggio formale. 
Mettiamola diversamente: per essere compilazione
deve essere sempre Turing-computabile con lo
stesso risultato.
Se non lo e`, come nel caso della quantizzazione,
ma anche della DCT, allora non e` compilazione.
Quindi JPEG non e` compilazione, solo trasformazione.
Cosi` la trasformazione nulla.
In questo senso tu puoi sempre compilare un linguaggio
formale in un altro, mantenendo le proprieta` e la
quantita` di informazione.
In piu`, puoi aggiungere ridondanza (tipo "nop", per
semplificare), quindi qualunque rappresentazione di un
algoritmo puo` essere realizzata in infiniti modi.
Probabilmente, dovrei pensarci un po', anche in infiniti
modi "minimi" (cioe` senza ridondanza).
bye,
-- 
   Piergiorgio Sartor

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.


 \begin{defin}
   ^^^^^^
\end


 sia iniettiva o suriettiva.
Che sia una trasformazione non vi e` dubbio.
Che tutte la trasformazioni sia compilazioni e` in questione.
Molto semplicemente non avrebbero dato un nome diverso, se
fosse stata la stessa cosa.
JPEG non e` compilazione, per il semplice fatto che
l'inverso, che esiste ed e` anche calcolabile, non da
piu` l'originale. Nel senso dell'informazione.
bye,
-- 
   Piergiorgio Sartor

 piu` l'originale. Nel senso dell'informazione.
E secondo te non si applica alla compilazione?
DIMOSTRALO!
Ecco il programma:
int main(void)
{
	int i = 0, k = 0xFF;
	for (; i <= 10; ++i)
	{
		k &= i;
	}
	return 0;
}
Compilalo e poi decompilalo. Ottieni lo stesso mio codice?


 Compilalo e poi decompilalo. Ottieni lo stesso mio codice?
Ottengo esattamente lo stesso algoritmo, quindi non
ho perdita di informazione.
L'informazione non sta nella leggibilita` del codice.
Allora se prendo quel sorgente e lo passo per zip, perderei
informazione per il semplice fatto che non si riesce piu`
a leggere? Non credo.
Se tu intendi "informazione" con il fatto che sia "leggibile",
allora si, la perdi.
Ma in senso informatico no, perche` viene rimosso il superfluo,
in senso "computazionale".
Se tu riempi il tuo codice di commenti contenenti la Divina
Commedia, lo passi per il preprocessore, alla fine la
quantita` di informazione sara` esattamente la stessa che
avevi quando c'era tutto il poema.
Esempio:
main()
{
/* vispa teresa */
  for(i=0; i<2; i++) {
   print(i);
  }
}
Compilato:
mov #0, r1
call print(r1)
mov #1, r1
call print(r1)
Decompilato:
main()
{
  r1=0
  func(r1)
  r1=1
  func(r1)
}
func(int a)
{
  print(a)
}
Questi tre programmi contengono esattamente la
stessa quantita` di informazione.
Anche se il commento e` sparito e pure il ciclo for().
Sono esattamente la stessa cosa.
La decompilazione non ha perso nulla che non sia superfluo.
Certo, gli ultimi due sono meno chiari, ma non per
la macchina che li esegue.
bye,
-- 
   Piergiorgio Sartor

 Compilalo e poi decompilalo. Ottieni lo stesso mio codice?
Questa e' una rappresentazione dell'algoritmo. Questo algoritmo, 
interpretato, compilato, decompilato, ricompilato ecc. deve dare sempre 
lo stesso risultato. Se tu prendi una immagine gif la trasformi in jpeg 
e poi la ritrasformi in gif, sara' cambiata!

 lo stesso risultato.
Vi darò ragione quando qualcuno mi *dimostrerà* che è vero. Fino ad ora, 
dite che è vero. Dimostratelo. Fatemi vedere:
$ gcc -o prog prog.cpp
$ gcc --decompile -o prog is-it-the-original.cpp
$ cmp prog.cpp is-it-the-original.cpp
$


 $
E` la "cmp" sbagliata, non e` questa quella che ti serve.
Bensi` la "mdtcmp".
Stai mescolando concetti diversi di informazione.
Se consideri la teoria (credo sempre Shannon), secondo cui
la quantita` di informazione dipende dalla probabilita` di
simbolo, allora potresti (potresti) avere ragione.
Ma informazione non e` solo quello.
Consideriamo la lingua italiana, consideriamo la probabilita`
di ogni simbolo (lettera), calcolata relativamente ad un
qualche insieme di testi, chesso` un enciclopedia.
Se generassimo simboli con un generatore casuale tarato in
tal modo, tanti simboli quanti ve ne sono nell'enciclopedia,
secondo la teoria avremmo la stessa quantita` di informazione.
Tu capisci che cosi` non e`, dato che l'enciclopedia ha ben
piu` informazione di quella data dalla probabilita` di simbolo.
Allo stesso modo, qualunque "compilazione", intesa come
trasformazione tra linguaggi formali (ci aggiungo equivalenti,
tanto per stressare), mantiene la stessa quantita` di
informazione (per definizione), relativamente, pero`, alla
"calcolabilita`" dell'algoritmo rappresentato.
La tua "cmp" fallisce, tanto quanto fallirebbe con il generatore
di numeri causali tarato.
bye,
-- 
   Piergiorgio Sartor

 di numeri causali tarato.
Questo sempre perchè dai un significato semantico a qualcosa che in 
realtà è grammaticale. E' come quello che smadonna perchè il T9 del 
cellulare che fa anche il caffè quando si premono tasti a caso continua 
a generare parole.
Non mantiene assolutamente la stessa informazione: nei linguaggi ad alto 
livello c'è una semantica.
L'assembly è pura grammatica.
Si possono generare programmi semanticamente sballati ma 
grammaticalmente corretti. Questo vale ovunque.
Quando si parla di informazione, si hanno pochi strumenti: spettri, 
probabilità, entropia, confronto bit/bit. E solo questi consentono di 
confrontare l'informazione.
Bene inteso che l'italiano scritto con le 26 (+ blank) lettere contiene 
informazione sovrabbondante ed inutile. Basta fare l'albero di huffmann, 
scrivere il nuovo stream di bit. Quello che ottieni è l'informazione 
effettivamente scritta in un testo. Dal punto di vista semantico... 
perdi tutto.
Se fondassimo altre basi più complesse, ovvero semantiche, non avremmo 
cellulari, PC...


 confrontare l'informazione.
No. Questo e` assolutamente falso.
Quello e` solo uno dei possibili metodi, valido in
alcuni contesti.
L'informazione puo` stare a diversi livelli.
E ti ripeto l'esempio dei commenti: un programma C
contiene la stessa quantita` di informazione prima e
dopo il passaggio al preprocessore.
Se fai un'analisi _statistica_, questo non ti risulta.
L'informazione del programma e` l'algoritmo che
rappresenta, non la sequenza di simboli specifici
che lo realizzano.
Se tu hai una scatola nera, che esegue un certo algoritmo,
dal punto di vista informatico sei in grado di dire
esattamente quanta informazione vi e` dentro, sapendo solo
l'algoritmo implementato e non quanti byte sono necessari
per implementarlo in quella scatola.
Lo spazio di misura non sono i simboli, ma gli algoritmi.
Le cose coincidono per una _specifica_ MdT, dove ogni algoritmo
e` un unico  "simbolone" (un numero diverso per ogni algoritmo).
Per passaggi da MdT diverse, dato che il "simbolone" non e`
portabile, si deve compilare e, conseguentemente, si deve
passare da uno spazio ad un altro, come per la compressione.
In questo passaggio, come per la compressione, non vi e`
perdita di informazione, l'algoritmo _deve_ rimanare identico,
la rappresentazione no.
bye,
-- 
   Piergiorgio Sartor

 writes:
[snipponissimo]
Ma come la fate lunga :)...
In [2]: def stampa_roba():
   ...:     for indice, occorrenze in enumerate([1,2,3,4,5,6]):
   ...:         print indice, occorrenze
   ...: 
In [3]: stampa_roba()
0 1
1 2
2 3
3 4
4 5
5 6
In [4]: dis.dis(stampa_roba)
  2           0 SETUP_LOOP              53 (to 56)
              3 LOAD_GLOBAL              0 (enumerate)
              6 LOAD_CONST               1 (1)
              9 LOAD_CONST               2 (2)
             12 LOAD_CONST               3 (3)
             15 LOAD_CONST               4 (4)
             18 LOAD_CONST               5 (5)
             21 LOAD_CONST               6 (6)
             24 BUILD_LIST               6
             27 CALL_FUNCTION            1
             30 GET_ITER            
        >>   31 FOR_ITER                21 (to 55)
             34 UNPACK_SEQUENCE          2
             37 STORE_FAST               0 (indice)
             40 STORE_FAST               1 (occorrenze)
  3          43 LOAD_FAST                0 (indice)
             46 PRINT_ITEM          
             47 LOAD_FAST                1 (occorrenze)
             50 PRINT_ITEM          
             51 PRINT_NEWLINE       
             52 JUMP_ABSOLUTE           31
        >>   55 POP_BLOCK           
        >>   56 LOAD_CONST               0 (None)
             59 RETURN_VALUE    
In [5]: def stampa_roba_diversa():
   ...:     for i,k in enumerate([1,2,3,4,5,6]):
   ...:         print i,k
   ...: 
In [6]: stampa_roba_diversa()
0 1
1 2
2 3
3 4
4 5
5 6
In [7]: dis.dis(stampa_roba_diversa)
  2           0 SETUP_LOOP              53 (to 56)
              3 LOAD_GLOBAL              0 (enumerate)
              6 LOAD_CONST               1 (1)
              9 LOAD_CONST               2 (2)
             12 LOAD_CONST               3 (3)
             15 LOAD_CONST               4 (4)
             18 LOAD_CONST               5 (5)
             21 LOAD_CONST               6 (6)
             24 BUILD_LIST               6
             27 CALL_FUNCTION            1
             30 GET_ITER            
        >>   31 FOR_ITER                21 (to 55)
             34 UNPACK_SEQUENCE          2
             37 STORE_FAST               0 (i)
             40 STORE_FAST               1 (k)
  3          43 LOAD_FAST                0 (i)
             46 PRINT_ITEM          
             47 LOAD_FAST                1 (k)
             50 PRINT_ITEM          
             51 PRINT_NEWLINE       
             52 JUMP_ABSOLUTE           31
        >>   55 POP_BLOCK           
        >>   56 LOAD_CONST               0 (None)
             59 RETURN_VALUE
 
Direi che non c'e` da andare oltre. Per quanto mi riguarda ho
sperimentalmente dimostrato che se chiamo una variabile i invece di
indice non cambio il risultato di nulla. Le istruzioni che la macchina
virtuale python esegue sono sempre le stesse e dato che dalla macchina
virtuale al processore il procedimento resta per forza di cose
identico ne deduco che il codice generato con l'assembler e`
identico. Ovviamente un disassemblatore non ne sa un cavolo di come
hai chiamato le variabili tu, se le chiama var1, var2, var3 invece che
buf, index, memptr non cambia nulla. E tutto questo anche senza tirare
in ballo MdT o roba piu` astratta (che per parlare di roba cosi`
pratica poco c'azzecca IMHO).
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 pratica poco c'azzecca IMHO).
No, la pratica che tu dici č diretta istanza delle MT.


 più profondo del riesco a decompilare?
Dimostrami tu che non sono uguali, ovvero che hai cambiato
l'algoritmo, NB: i nomi di variabili non sono indicativi della bonta`
del codice ottenuto dal disassemblatore.


 del codice ottenuto dal disassemblatore.
Hai un codice C/C++ che ho scritto. Fallo vedere.
Poi, per qunato riguarda *me*, sbagli di grosso.
La *tua* tesi è da dimostrare. Io ti dico che non c'è lo stesso 
contenuto informativo (bit). Ti ho pure detto come guardarlo, anche se a 
te non frega nulla di spettri, quella è la via più facile. Non ti 
interessa, non dire certe cose allora. La compilazione *non* è una 
biezione. E si dimostra sai come? Baste *UN* caso singolo in cui tu non 
possa farlo. Mi pare che finora nessuno abbia mostrato che
\forall f \in \mbox{Compilers} : \exists f^{-1} \wedge \forall x \in 
\mathcal{L} : f^{-1}(f(x)) = x
E non azzardo a dire che è unica perchè potrebbe non esserlo.
Basi della teoria delle dimostrazioni. Dovrebbe esserti evidente, se non 
lo è... prendilo per buono.


 non possa farlo. Mi pare che finora nessuno abbia mostrato che
Fammi vedere il singolo caso in cui se compilo:
a=c+b
ottengo:
pippo=pluto**b


Forse non mi sono spiegato bene.
Se mi fai vedere --- e finora non vedo nulla --- un *singolo* caso, vuol 
dire che *quel* caso funziona. Ciò ci dice che in *quel* *preciso* caso 
funziona, ma non dice _assolutamente_ nulla per gli altri.
Bene inteso: la tua pseudo-dimostrazione è del tipo: tutti i numeri 
dispari sono primi. 3 è primo. Tutti i numeri dispari sono primi. Questo 
è quello che fai tu. Con l'aggravante che non tiri fuori un file ASM, 
poi lo maneggi (NON CON LA TUA MENTE!!!) con un programma ed hai un 
programma equivalente. Ma anche se lo fai non dimostri nulla.
Io ti faccio vedere che per un caso non vale, la tua tesi decade 
completamente. Hai presente la diagonalizzazione? Bene, per far vedere 
che un insieme non è numerabile, ti si fa vedere UN elemento che non è 
compreso nella numerazione. Questo è quello che faccio io.
Te l'ho detto. Se leggi le basi della teoria della dimostrazione noti 
l'errore che commetti.


 l'errore che commetti.
Non taglio nulla del post perche` rispondo a tutto in un botto solo:
Fammelo vedere questo caso in cui la decompilazione mi ritorna un
algoritmo diverso. La mia dimostrazione non e` proprio neanche
lontanamente quella che dici tu... Ma piuttosto e` del tipo:
Finche` non mi dimostri che quello che dico e` falso, mostrandomi
quell'unico caso, allora per me e` vero.
Mi viene il dubbio che tu non sappia cosa sia una macchina virtuale
vero? Io ti ho mostrato l'asm di python, poi verra` bi-univocamente
trasformato in gruppetti di istruzioni asm x86.
So benissimo come si fa a dimostrare una cosa, ma so anche che se mi
viene troppo difficile dimostrarlo, preferisco chiederti quali sono i
casi in cui questo non funziona. Sara` poco ortodosso ma visto che
funziona comunque... Diciamo che per essere spiritosi e` una sorta di
dimostrazione per assurdo: Tu dici che l'informazione si perde, basta
trovare almeno un caso in cui questo accade no? Fallo.


 trovare almeno un caso in cui questo accade no? Fallo.
O cazzo... prendi quei due cazzo di file e fai il confronto degli spettri!
Se non capisci il perchè, non è colpa mia.


 Se non capisci il perchè, non è colpa mia.
Io invece mi sono stufato, per l'ennesima volta, di parlare con te,
ragion per cui thread chiuso per quanto mi riguarda.


Bella per te.
Fino a questo punto, nessuno mi mostra un compilatore con un 
decompilatore. O meglio più formalmente:
Un algoritmo (decompilazione) il cui input sia un binario compilato, in 
output fornisce il codice sorgente del compilatore.


 output fornisce il codice sorgente del compilatore.
Ti ho gia` detto che e` banale, ne trovi infiniti.
Ti ho anche fatto l'esempio.
Basta che ogni istruzione assembly sia decompilata
in una chiamata a funzione C.
Hai decompilato il programma, hai lo stesso algoritmo,
hai lo stesso contenuto informativo.
E per tornare all'informazione, ti sbagli, la semantica
e` quella che conta, proprio perche` le MdT interpretano
la grammatica e non la semantica.
Esempio:
a=cos(log(abs(x)))
ha lo stesso contenuto informativo, dal punto di vista
statistico, di:
a=log(cos(abs(x)))
Solo che la prima, nei reali, esiste sempre, la seconda no.
Quindi l'informazione _non_ puo` essere la stessa.
Tu stai mescolando, ripeto, il concetto di informazione
statistica (probabilita` di simbolo), con il concetto di
informazione come rappresentazione algoritmica.
Sono cose diverse, che non possono essere scambiate.
Quello che conta nella decompilazione, non e` ottenere lo
stesso identico codice, cosa impossibile, dato che quanto
meno i commenti sono semplicemente eliminati e non possono
piu` essere recuperati, bensi` lo stesso algoritmo solo in
un linguaggio diverso.
bye,
-- 
   Piergiorgio Sartor

 altre e' necessario compilarlo e usare opcode..
Ma non ha senso ...
Insomma, la particolarita' di XML e' che e' human readable (ripeto), se
cosi' non e' XML e' piu' che inutile, e' un costo.
Insomma, ci sara' una motivazione ufficiale, qualcuno, tra la schiera di
MVP ecc, si sara' fatto una domanda ...
-- 
                                                __Nicholas Wieland
Readability counts.
                                                __The Zen of Python

 faccio "a design time".
Puo' essere, ma basterebbe fare una cosa tipo GLADE: il parsing di una
interfaccia grafica definita con XML a runtime non e' costoso, anche se
l'interfaccia e' complessa.
Anche se fosse, resta un mistero sul perche' abbiano usato XML, dato che
le qualita' di XML vanno perse.
-- 
                                                __Nicholas Wieland
Flat is better than nested.
                                                __The Zen of Python

 MVP ecc, si sara' fatto una domanda ...
Domande? E perche'? La risposta e' nota da sempre: "Embrace & extend"
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 <icq:241572242>
But still I fear, and still I dare not
Laugh at the mad man (The Prophet's song)

 sempre nella definizione di informazione --- non di semantica.
Ancora, la definizione che dai tu di informazione
e` *sbagliata* in questo contesto.
La definizione corretta e` sulla semantica del
algoritmo implementato.
bye,
-- 
   Piergiorgio Sartor

 le qualita' di XML vanno perse.
Leggi qui: 
http://longhornblogs.com/rrelyea/posts/1336.aspx
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com

 Leggi qui: 
http://longhornblogs.com/rrelyea/posts/1336.aspx
Mi dice SQL Server does not exist, SUX, or access denied.
Ok, forse non dice esattamente cosi'.
-- 
                                                __Nicholas Wieland
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
                                                __The Zen of Python

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.


 <icq:241572242>
The optimist thinks this is the best of all possible worlds.


 possibile... altrimenti no.
E` lo spazio degli algoritmi, invece che dei simboli.
Riferito ad un MdT, potrebbe dipendere dalla complessita`
dell'implementazione minima.
Vi e` un problema non da poco, forse irrisolvibile:
date due implementazioni, e` possibile stabilire
con certezza che si tratti dello stesso algoritmo?
Cioe` e` possibile confrontare implementazioni, senza
sapere a priori di che algoritmi si tratti?
Ad occhio direi di no.
bye,
-- 
   Piergiorgio Sartor

 sapere a priori di che algoritmi si tratti?
Credo proprio di no.
Ma non è questa la situazione: qui sappiamo che siamo in presenza di due 
algoritmi che sono in realtà uno. Il problema sta nella quantificazione 
dell'informazione: serve una funzione.


 dell'informazione: serve una funzione.
Se sono lo stesso algoritmo, hanno la stessa quantita`
di informazione.
Se sono algoritmi diversi, puoi definire la cosa come ti
pare, dato che il problema verte sulla *conservazione*
dell'informazione, non sulla misura di una eventuale differenza.
Cioe` quello che interessa non e` stabilire se, chesso`,
la DCT abbia piu` informazione o meno di quicksort,
bensi` il fatto che la DCT, scritta in C, Pascal, assembly,
ADA o quello che e`, sia sempre la stessa cosa (ovviamente
la stessa implementazione...).
Non potendo stabilire se due implementazioni sono lo
stesso algoritmo, non si puo` verificare l'invarianza
a posteriori, ma ci si deve affidare al teorema (non mi
ricordo piu` di chi) che ne dimostra l'invarianza.
bye,
-- 
   Piergiorgio Sartor