Conversione Dec-Bin

[Steve85]

Ciao raga! Ho un problema con un programmino che converte i numeri interi decimali in codice binario:


#include <stdio.h>

#define DIM 16

main()
{
int i;
int vet[DIM];
int dec=0;
printf("------BENVENUTO NEL PROGRAMMA DI CONVERSIONE DEC-BIN------\n\n");
printf("Inserisci il valore decimale: ");
scanf("%d",&dec);
printf("\n");
for (i=0;i<DIM;i++)
{
vet[DIM-16+i]=dec%2;
dec=dec/2;
printf("%d ",vet[DIM-16+i]);
}
printf("\n");
scanf(" ");
}


Questo codice mi stampa le cifre da sinistra verso destra.
Pero risulta poco comprensibile, perche i numeri binari si leggono da destra verso sinistra.


#include <stdio.h>

#define DIM 16

main()
{
int i;
int vet[DIM];
int dec=0;
printf("------BENVENUTO NEL PROGRAMMA DI CONVERSIONE DEC-BIN------\n\n");
printf("Inserisci il valore decimale: ");
scanf("%d",&dec);
printf("\n");
for (i=0;i<DIM;i++)
{
vet[DIM-1-i]=dec%2;
dec=dec/2;
printf("%d ",vet[DIM-1-i]);
}
printf("\n");
scanf(" ");
}


Quest'altro invece "dovrebbe" stamparmi i numeri da destra verso sinistra come voglio io...pero me li stampa esattamente uguali come il codice di prima.

Questo è strano perche nel primo ciclo For la prima posizione dell'array è:
vet[16-16+0]---> posizione 0

Nel secondo ciclo For la prima posizione è:
vet[16-1-0] ----> posizione 15

Aiuto pls :)

[Steve85]

Nessuno sa dirmi nulla? :(

[DanieleC88]

La soluzione e' semplice: il salvataggio della sequenza binaria viene fatto al contrario, e tu stampi il numero mentre converti, quindi lo stampi al contrario. Fai cosi': prendi il secondo esempio, dichiara "vet" come char[], e non come int[], lascia tutto com'e', ma sposta "printf("%d ",vet[DIM-16+i]); " fuori dal ciclo for, cambiandolo in "printf(vet); ".

bye!

[Steve85]

Quindi la variabile vet la devo dichiarare cosi?

char vet[DIM];
....
....
....
printf(vet);



EDIT: Ho provato a fare quello che ho scritto qui sopra....non mi fa nulla. Inserisco il numero decimale...premo enter ma non mi visualizza nessun risultato.

[LimiT-MaTz]

se vuoi ho qui il programma che stiamo commentando al corso di fondamenti.
http://www.laser.dist.unige.it/Repository/Fondamenti/Esercitazioni/
scarica binlib.

fammi sapere

[Steve85]

Ho scaricato il programmino...pero non me lo compila.
Ho messo nella directory assieme a bin.cpp e bin.h anche il file stdlib.h (preso dalla directory del programma che uso per compilare).

Mi da questo errore:
[Linker error] undefined reference to `WinMain@16'


Cmq nessuno sa come posso modificare il mio programmino?

[Fenomeno85]

/*
Conversione da un decimeale in binario
*/

#include <stdio.h>
#include <conio.h>

#define MAX 10

int main (){
int valore_bin [MAX], i=1;
int valore_da_convertire;
int resto, val ;
printf ("\nInserisci il numero da convertire in binario:\t");
scanf ("%d", &valore_da_convertire);
val = valore_da_convertire;

//annullamento del vettore

for (int y=0; y<MAX; y++)
valore_bin [y] = 0;

do{
resto = val % 2;
val = val / 2;
valore_bin [MAX-i] = resto;
i ++;
} while (val != 0);
for (i=0;i<MAX;i++)
printf ("%d",valore_bin[i]);
printf ("\n\n\nIl programma e' stato realizzato da Fenomeno85");
getch ();
}


bye ;)

avrei voluto mettere gli elementi in una singola variabile ma non ne ho la + pallida idea di come fare :P ... forse con lo shift si può fare :wtf:

~§~ Sempre E Solo Lei ~§~

[Steve85]

Cosi mi funzia...invece! Pero non capisco perche devo stampare vet[i] e non vet[DIM-1-i]. Mah :D



#include <stdio.h>

#define DIM 16

main()
{
int i;
int vet[DIM];
int dec=0;
printf("------BENVENUTO NEL PROGRAMMA DI CONVERSIONE DEC-BIN------\n\n");
printf("Inserisci il valore decimale: ");
scanf("%d",&dec);
printf("\n");
for (i=0;i<DIM;i++)
{
vet[DIM-1-i]=dec%2;
dec=dec/2;
}

for (i=0;i<DIM;i++)
printf("%d ",vet[i]);

printf("\n");
scanf(" ");
}

[repne scasb]

[DanieleC88]

Bene, visto che tutti hanno postato il proprio codice, un'altro giorno vi posto il mio elegantissimo codice :) Ora non ho il mio PC sotto mano, rimando.

[DanieleC88]

Ecco il mio codice:
#include <stdio.h>

#define MAX 16
#define bt(v,b) (((unsigned long) v & (1 << ((unsigned char) b - 1))) > 0)

int main()
{
char * buffer;
char num = 123;
char j = 0;

for (j = 0; j < MAX; j++)
{
buffer[MAX - j - 1] = ('0' + bt(num, j));
}

buffer[MAX - 1] = 0;
printf("%s\n", buffer);
return 0;
}


Tabsize: 2. GVIM theme: darkblue. Language: C. bt = bit test.

[Fenomeno85]

Originariamente inviato da repne scasb
Non sono un'eperta di C. Prova un po cosi':


#define SIZE_BIN (sizeof(dec)<<3)

do
{
printf("%d ",(dec&(1<<i))>>i);
} while (~--i&(1<<(SIZE_BIN-1)));
}


che sintassi trana :mbe: spiega un pò che fa :D

~§~ Sempre E Solo Lei ~§~

[repne scasb]

[repne scasb]

[fek]

Originariamente inviato da repne scasb

} while (~--i&(1<<(SIZE_BIN-1)));
}


Sembra tutto molto strano, ma serve solo per aiutare il compilatore. 1<<(SIZE_BIN-1) e' una costante ed e' il bit di segno di i (i e' dichiarato int come dec, quindi hanno la stessa lunghezza in byte). L'istruzione semplicemente: decrementa i e test il bit di segno, se il bit di segno e' settato esce dal loop (il not (~) serve proprio per la permanenza all'interno del loop). Tutto cio' serve per permettere al compilatore di utilizzare JNS invece di JNL e risparmiare una istruzione assembly, in sostanza il tutto (se il compilatore compila per bene) viene tradotto come:


dec [_i]
jns loop_dec


Rendendo pero' il codice piu' oscuro da leggere e quindi di minore qualita' ;)

Non e' codice migliore e piu' leggibile scritto cosi'?



--i;
}
while (i >= 0);


Ancora piu' leggibile con un semplice ciclo for.

[repne scasb]

[fek]

Originariamente inviato da repne scasb
E' necessario mettersi d'accordo sul concetto di migliore. Per migliore si puo intendere:


La definizione piu' semplice che si puo' dare di "migliore" e' un programma che risolve il problema che e' stato posto e nulla di piu'.

Fermo restando che le definizioni che hai dato dopo sono ottime.


In generale io svluppo in qualsiasi linguaggio utilizzando il modello del migliore tipo 4), indipendentemente dal mio interlocutore. Ne caso specifico non ho utilizzato (i>=0), in quanto il compilatore avrebbe tradotto la sequanza con:


So come avrebbe tradotto il compilatore la sequenza che ho scritto.
Il problema qui era la conversione da decimale a binario di un numero solo (non di un milione ad esempio, cosa che sarebbe stata decisamente diversa). Ho anche letto il manuale da te riportato.

La tua sequenza risparmia (a seconda del processore) dai 4 ai 10 colpi di clock in totale su tutta l'esecuzione del programma. Considerando che alla fine del programma riportato c'e' una printf che da sola usa almeno qualche decina di migliaia di colpi di clock, i 10 colpi di clock risparmiati rappresentano meno di una parta su mille. Ovvero un risparmio del tutto trascurabile su una sola esecuzione del programma. Anche immaginando un milione di esecuzioni, sarebbe stato enormemente piu' vantaggioso andare ad ottimizzare l'output con una funzione diversa dalla printf piuttosto che quei 10 colpi di clock sulla fine del ciclo.

Infine, quei 10 colpi di clock non arrivano gratuitamente, ma impongono una minore leggibilita' del codice, ed un maggior lavoro da parte di chi quel codice dovra' leggerlo e magari mantenerlo in futuro. Qual e' la risorsa piu' scarsa? Il tempo cpu o il tempo del programmatore? La seconda e per la seconda si deve ottimizzare, quindi, se devo scegliere se aiutare il compilatore o aiutare chi legge il mio codice, scelgo senza ombra di dubbio la seconda, a meno che dal profiling scopro che il codice che sto scrivendo e' un collo di bottiglia della mia applicazione. In questo caso, e solo in questo, e solo dopo che non sono riuscito ad ottimizzare algoritmicamente alloracerchero' di aiutare il compilatore salvo commentando in maniera diffusa le linee di codice che non sono chiare, magari aggiungendo una versione in codice o pseudo codice piu' leggibile.

Purtroppo i compillatori perfetti sono da venire, e quando scrivo codice in C, tento di aiutare in qualche modo il compilatore (e per fortuna che i e' signed, se fosse stato unsigned poiche' la dec [_i] non aggiorna il carry sarebbe stato necessario o la sub o la cmp (con il mio codice no)).

Ma il tuo codice ha imposto a me una decina di secondi per essere compreso, invece del secondo scarso che la mia versione avrebbe richiesto a chiunque, anche alle prime armi.
In sintesi, una versione del codice piu' leggibile e' preferibile nel 99% dei casi, salvo i casi dove e' richiesta un'ottimizzazione spinta del codice.
Quello riportato in questo topic non mi sembra uno di questi casi.

[LimiT-MaTz]

#include <iostream.h>
#include <stdlib.h>
// DEFINIZIONI UTENTE
#define EOS '\0'
#define MAX '10'

// FUNZIONE PROTOTIPO //
int bin2dec(char[]);
char *dec2bin(int);
// FUNZIONE PROTOTIPO //

int main(){

char str[MAX];
int result,select,dec;
int cicle = 0;
// INTRO
cout << " ***************\n " << " Conversion \n" <<" ***************\n " << endl;
cout << "\n\n";
cout << " # 1 # *** Bin2Dec *** " << "\n" << endl;
cout << " # 2 # *** Dec2Bin *** " << "\n" << endl;

while (cicle == 0){
cout << " Select: "; cin >> select;
// STRUMENTO DI SELEZIONE
switch( select ){

case 1:
cout << "\n\n\n ***************\n " << " Bin2dec \n" <<" ***************\n "<< endl;
cout << " Inserisci un numero Binario \n" << " " << endl;
cin >> str;
result = bin2dec(str) ;
cout << "il numero binario " << str << " corrisponde a " << result << " in base 10" << endl;
cicle = 1;
break;
case 2:
cout << "\n\n\n ***************\n " << " Dec2Bin \n" <<" ***************\n "<< endl;
cout << " Inserisci un numero Decimale \n"<< " " << endl;
cin >> dec;
cout << "il numero decimale " << dec << " corrisponde a " << dec2bin(dec) << endl;
cicle = 1;
break;
default:
cicle = 0;}
}



return 0;
}

// //
// FUNZIONE DECODER BINARIO TO DECIMALE //
// //
int bin2dec(char btr[]){
int d = 0;
int i;
if ( btr[0] == '1' ){
d = 1;}
for(i = 1; btr[i] != EOS ; i++){
d = d * 2;
if ( btr[i] == '1' )
d = d + 1;
}
return d;}

// //
// FUNZIONE DECODER DECIMALE TO BINARIO //
// //
char *dec2bin(int input){
char *bin;
int input2,i,value;
input2 = input;

for(int lenght=1; input2 != 0; lenght++){
input2 = input2 / 2; }

bin = (char *) malloc(lenght+1);

for(i=lenght;i >= 0; i--){
value = input % 2;
if (value == 0)
bin[i] = '0';
else bin[i] = '1';
input = input / 2;
}

bin[lenght] = EOS;
return bin;
}


iil programma nella decifrazione dec to bin mi da qualche problema mi visualizza valori del tipo: 0001010 invece che 1010 non riesco a capire dove sia il problema.
vi ringrazio in anticippo

[fek]

Originariamente inviato da LimiT-MaTz
iil programma nella decifrazione dec to bin mi da qualche problema mi visualizza valori del tipo: 0001010 invece che 1010 non riesco a capire dove sia il problema.
vi ringrazio in anticippo

Prova cosi':



char* str = bin;

bool firstOneFound = false;

for ( i = lenght; i >= 0; --i)
{
value = input % 2;

if (0 == value)
{
if (firstOneFound)
{
*str++= '0';
}
}
else
{
firstOneFound = true;
*str++ = '1';
}

input = input / 2;
}

length = str - bin;

*str++ = EOS;



Occhio che hai un memory leak nella funzione bin2dec, perche' allochi un blocco di memoria e non lo disallochi mai.
Non e' banale da risolvere, ma puoi seguire un paio di strade:

1) Usi la classe std::string e la restituisci per valore e non per reference; e' comodo da usare, risolve elegantemente il problema ma abusare della classe std::string puo' peggiorare notevolmente le prestazioni se non stai attento (non e' il tuo caso in questo esempio)

2) Passi esplicitamente alla funzione un blocco di memoria da riempire e la sua lunghezza, se ti servono piu' caratteri di quelli disponibili restituisci un errore; in genere e' il metodo preferibile.

Come regola generale non allocare mai memoria dentro una funzione per poi restituire il blocco allocato all'esterno: chi alloca una risorsa (metodo o classe) deve sempre occuparsi di liberare la risorsa. La seconda tecnica che ti ho suggerito segue questo principio.

[repne scasb]

[fek]

Originariamente inviato da repne scasb
E' chiaro che attribuiamo significati diversi allo stesso vocabolo (migliore). L'argomentazione e' intrinsecamente non convergente in quanto io discuto di "bianco" e tu di "nero".

Sarebbe pero' gradito, che come io comprendo che il mio "migliore" possa non essere non solo l'unico migliore ma neanche il "MIGLIORE", tu comprendessi che il tuo migliore possa non essere non solo l'unico migliore ma anche il "MIGLIORE", lasciando l'assolutismo dialettico soltanto al mio e al tuo creatore.

La definizione che ho dato di "migliore" e' univoca ed e' quella accettata in Ingegneria del Software. Su questo punto non c'e' spazio di discussione.

Il discorso si sposta su che cosa voglia dire "risolvere il problema dato": a me e' sembrato che nel tuo caso risolvere il problema significhi anche risparmiare quei colpi di clock per mezzo di una codifica meno leggibile.

Bene, nella formulazione del problema non era richiesto risparmiare quei cicli di clock, per questo ho affermato che la tua soluzione e' "peggiore". C'e' un criterio ben preciso di valutazione dei costi: la tua soluzione guadagna in termini di prestazioni e costa in termini di leggibilita'. E' chiaro perche' nulla e' gratuito, se guadagni da qualche parte, perdi da qualche altra parte. Resta solo da valutare quanto il costo della tua ottimizzazione sia giustificato dal guadagno prestazionale.
Direi che e' semplice da valutare: riesci nel problema proposto ad accorgerti del guadagno prestazionale? fornisce un vantaggio misurabile al cliente (qui uso un linguaggio piu' formale per capirci meglio)? fornisce una soluzione migliore misurabile in termini prestazionali?
La risposta a tutte queste domande in questo esempio e' ovviamente no (non e' sempre cosi' in tutti i casi). Di contro rimane il costo in termini di leggibilita', che viene sottolineato dal fatto che l'utente che ha proposto il problema ti ha chiesto una spiegazione su quella riga di codice, mostrando che non e' riuscito a comprenderla, e non e' una sua colpa perche' anch'io che programmo da 15 anni ho impiegato almeno una decina di secondi a leggere una riga di codice che in una versione alternativa mi avrebbe tenuto impegnato solo qualche decimo di secondo.

Per concludere: da una parte abbiamo un guadagno prestazionale non misurabile, dall'altra abbiamo una perdita in termini di leggibilita' misurabile e misurata. In questo caso (e non in assoluto ovviamente) una versione piu' leggibile del codice sarebbe sicuramente preferibile.

edit: vari errori di battitura

[DanieleC88]

Che senso ha impostare MAX a 16 se num e' un char?
Era solo per restare in linea con il codice di Steve85.

Quando trasformi num (che e' un char e che quindi ha un segno bit(7), in v di bt(v,b) che e' un (unsigned long) estendi il segno (prova con num=136 che e' maggiore di 127 e te ne accorgi).
Non ho capito questo "estendi il segno". Non sono per niente tecnico (a differenza tua, che sei un paio di istruzioni assembler già dal nome :D). Credi che debba essere rimossa la conversione nella macro? L'ho messa solo per assicurarmi che non venga passato come parametro qualcosa che non sia un numero, che ovviamente genererebbe un errore di compilazione nella conversione.

A parte queste cose, il codice e' "estremamente" inefficiente; b(v,t) per ogni test di bit "DEVE" eseguire un salto condizionato che avresti potuto risolvere con un AND. Il tuo codice C tradotto anche da un eccellente compilatore C, genera non meno di 19 linee di codice assembly, e se MAX=16 su un Intel i80486 necessitera' da 51 a 56 cicli di clock (dipende da num).
A parte il fatto che ormai le CPU non risentono più un granchè di cicli di clock sprecati, ma questo è un altro problema, io volevo solo mettere anche il mio codice per prendere spunto: in fondo ci si chiedeva come convertire un numero in binario, e non come ottimizzarne il processo. La cosa migliore in quel senso sarebbe scrivere tutto in assembler ed ottimizzarlo quindi il più possibile. Devo cominciare a lavorarci su, così faccio anche un bell'esame per l'assembler? (mi sembra di aver capito che nel C sono stato bocciato :D)

[repne scasb]

[repne scasb]

[fek]

Originariamente inviato da repne scasb
15 anni fa, pensavo la stessa cosa. Ho impiegato almeno 5 anni per disingegnerizzarmi. Stampati quello che hai scritto, e rileggillo tra 5 anni.

Posso dirti che dieci anni fa cercavo di risparmiale il colpo di clock in qualunque cosa scrivessi. Poi ho imparato a programmare e pensare a risolvere i problemi in maniera pragmatica.


Avrai capito che il nodo della discussione non e' piu' cilcli di clock, piu' tempo, piu' o meno leggibilita. Tutto cio e' una mia metafora per:

"Nessuno di noi e' la fonte delle conoscenza VERA (nonostante cio che dice il "Corso di Ingegneria del software"). Finche' non capisci cio', non potrai ne apprezzare ne confurare sensatamente altri modelli e schemi mentali "diversi" dal tuo, rimarrai ancorato al "Corso di Ingegneria del Software"."

IF pensiero_di_tizio!=ingegneria_del_software THEN pensiero_di_tizio=sciocchezza


Non capisco affatto il tuo discorso. Mi sembra di aver dato ampie motivazioni sul perche' nell'esempio citato una versione e' preferibile all'altra e non ho certamente rimandato la dimostrazione ad alcun discorso teorico.
Il mio e' un discorso assolutamente pragmatico, frutto dell'esperienza nel campo e che trova conforto negli studi teorici nel campo, e cerca di capire in questo esempio quale codice e' migliore.
Non ho fatto alcuna affermazione assoluta: per favore non metterla sul personale perche' non e' davvero il caso.

Possiamo da questo discorso, pero', tirare fuori un paio di considerazioni generali e dire che di solito (e non in tutte le situazione) e' meglio privilegiare la leggibilita' del codice e l'architettura piuttosto che ottimizzare prematuramente, e lasciare l'ottimizzazione quando e dove i risultati di un profiler lo richiedano. Direi che e' un suggerimento molto pragmatico.

Infine, esistono pratiche consolidate nella costruzione del software, che hanno dimostrato la loro efficacia nell'arco di diversi progetti anche (e soprattutto) di grosse dimensioni e tutte sconsigliano di scrivere codice come hai suggerito tu qui. La letteratura e' piena di casi di studio su progetti concreti che ne parlano.


Per puro diletto, studiati il "Corso di ingegneria del Software" com'era 25 anni orsono e com'e' oggi. Noterai che non e' costante nel tempo.

Ho un Phd. in Ingegneria del Software.


Tempo comunque di essere stata "precoce" nei tuoi confronti.

Che intendi dire?

[Steve85]

Scusate ragazzi...non volevo generare una "querelle" tra ingegneri del software e programmatori pragmatici :D
In ogni caso...ho capito molto bene i discorsi che avete fatto (un po' meno alcune righe di codice), pero non posso pretendere troppo: programmo in C da ben.....3 giorni! :)


Edit:
mia personale convinzione: tutto è relativo al contesto nel quale devi sviluppare il codice. Se stai lavorando per un'azienda che ti richiede il programma piu efficente, veloce, compatibile, che spreca meno risorse e da svilupparsi nel minor tempo possibile è ovvio che devi usare qualsiasi mezzo per ottenere il risultato per il quale sei pagato. Non te ne frega nulla delle leggibilita o altri aspetti. Conta i risultato!!
Se invece devi aiutare una persona niubba come me allora è ovvio che la leggibilità conta di piu rispetto ad un'ottimizzazione prestazionale che su un programma cosi banale non è nemmeno palpabile.
In ogni caso...ho fatto solo 2 o 3 lezioni di C all'universita, ma una cosa mi è entrata in testa: devo abituarmi a programmare senza sprechi inutili (ottimizzare penso sia un'altra cosa)....per sprechi intendo usare 10 cicli if che possono essere raggruppati in uno solo. Questo perche se mi abituo a programmare in questo modo...finche si tratta di programmini semplici fila tutto liscio su un Athlon Xp 3200. Quando pero iniziano ad essere programmi con qualche migliaio di linea di codice......beh le cose cambiano ovviamente.

[Steve85]

Originariamente inviato da fek


quote:
Tempo comunque di essere stata "precoce" nei tuoi confronti.




Che intendi dire?


Forse ha espresso giudizi un po' affrettati o fatto considerazioni precoci su di te senza conoscerti fino in fondo. Almeno questa è la mia interpretazione, del tutto soggettiva (specifico per evitare che mi saltino addosso :D)

Cmq apprezzo molto questo stile filosofeggiante di repne scasb. Non so....sono quelle frasi che stanno a meta tra la massima assoluta e il luogo comune, pero fanno un grande effetto :)

"Il dubbio nel ragionamento e' la base al "miglioramento" del ragionamento stesso." ------> Mi sa molto di Karl Popper :)

[DanieleC88]

Originariamente inviato da repne scasb
Assegna a num=136 compilla il tuo codice ed eseguilo. Ti sara' chiaro di cosa sto parlando.
Ci proverò.

Ti chiedo scusa, ho approfittato del tuo messaggio per dire qualcos'altro ad un ipotetico qualcun'altro, tramite il codice in C che ho scritto. Spesso getto queste esche provocatorie ed irritanti con il fine di adescare (intelletualmente parlando) qualcuno, e per dire in effetti qualcos'altro. Non ti sara' chiaro cio' che dico, e me ne scuso ancora, ma meritavi una risposta.
Mi devo scusare anch'io, forse sono sembrato un po' polemico.
Perchè dici "non ti sara' chiaro cio' che dico", metti in dubbio le mie capacità intellettive? :D :D :D

Tutt'altro, nonostante io sappia poco di C, per quanto ho capito, sei adeguatamente capace di migliorare le tue capacita' nello scrivere in C.
Veramente la mia era una battuta, anche quella sull'assembler (è meglio dire assembler o assembly? qualche giorno dovrò aprire un thread al proposito). Be', sembra che io abbia qualche possibilità di migliorare col C, almeno. E' già parecchio per un 16enne, almeno credo. Bye!

[fek]

Originariamente inviato da Steve85
mia personale convinzione: tutto è relativo al contesto nel quale devi sviluppare il codice. Se stai lavorando per un'azienda che ti richiede il programma piu efficente, veloce, compatibile, che spreca meno risorse e da svilupparsi nel minor tempo possibile è ovvio che devi usare qualsiasi mezzo per ottenere il risultato per il quale sei pagato. Non te ne frega nulla delle leggibilita o altri aspetti. Conta i risultato!!

Una tale azienda avrebbe costi di sviluppo improponibili. Purtroppo non conta solo il risultato, non si scrive il codice e poi non lo si tocca piu', va mantenuto (e la maggior parte delle volte da persone diverse rispetto a quelle che lo hanno scritto).
Se un'azienda avesse quelle richieste, scomparirebbe dal mercato in brevissimo tempo.

[71103]

scusate tanto il totale OT, ma colgo il thread per porre una domanda a repne scasb; ho consultato il reference Intel dei P4 e ho visto il significato dell'istruzione repne scasb (che oltrettutto hai messo anche in firma in forma esadecimale :D ), ma non capisco, come mai l'hai scelta come nickname?

[repne scasb]

[Steve85]

Originariamente inviato da fek
Una tale azienda avrebbe costi di sviluppo improponibili. Purtroppo non conta solo il risultato, non si scrive il codice e poi non lo si tocca piu', va mantenuto (e la maggior parte delle volte da persone diverse rispetto a quelle che lo hanno scritto).
Se un'azienda avesse quelle richieste, scomparirebbe dal mercato in brevissimo tempo.

Io ho sempre saputo che ad un'azienda interessa aver il miglior risultato con i minor costi. Poi ovvio che spesso il codice viene ripreso e rielaborato anche da terzi...pero non è scontato che un buon risultato significhi per forza una pessima leggibilita. Ho detto solo che non è lo scopo principale.

[fek]

Originariamente inviato da Steve85
Io ho sempre saputo che ad un'azienda interessa aver il miglior risultato con i minor costi. Poi ovvio che spesso il codice viene ripreso e rielaborato anche da terzi...pero non è scontato che un buon risultato significhi per forza una pessima leggibilita. Ho detto solo che non è lo scopo principale.

E' vero, un'azienda e' interessata ad aver il miglior risultato con i minori costi. Il problema e' capire come, ed e' un problema tutt'altro che semplice :)
Esistono svariate metodologie di sviluppo per raggiungere questi obiettivi, ed in genere si applicano in situazioni diverse.
Tutte pero' tendono a minimizzare i difetti e ad incrementare la qualita' del design e del codice, perche' secondo i dati che si sono raccolti su progetti reali, il costo di sviluppo e', in genere, proporzionale a al numero di difetti ed inversamente proporzionale alla qualita' del codice.

Nella costruzione del software, quindi, per minimizzare i costi di sviluppo si deve sempre tendere a diminuire il numero di difetti (bug) ed incrementare la qualita' del codice (coerenza del design e dell'architettura, leggibilita' e manutenibilita' del codice).

In sintesi, e' provato che progettando un'architettura coerente e pulita, avendo un design coerente con l'architettura, scrivendo codice pulito e leggibile, alla fine ci si ritrova con un'applicazione che risolve il problema dato ottimizzando le risorse e, se richiesto, nella maniera piu' ottimizzata possibile, scritta nel minor tempo possibile.

Purtroppo non e' facile scrivere codice pulito e richiede ottimi programmatori :)

L'ottimo programmatore non e' colui che conosce i trucchetti sporchi del linguaggio e scrive codice complicato e difficile da comprendere, al contrario, e' colui che scrive il codice piu' semplice possibile (e non e' facile), piu' chiaro, con meno difetti e che risolve il problema. Per raggiungere questo stato d'"illuminazione" ci vogliono anni ed, in genere, si passa per diverse fasi fra le quali "risparmia ovunque ogni ciclo di clock possibile".

[fek]

Originariamente inviato da DanieleC88
Veramente la mia era una battuta, anche quella sull'assembler (è meglio dire assembler o assembly? qualche giorno dovrò aprire un thread al proposito). Be', sembra che io abbia qualche possibilità di migliorare col C, almeno. E' già parecchio per un 16enne, almeno credo. Bye!

Assembly.

Iniziare col C a 16 anni e' ottimo, complimenti :)
Ed hai tantissime possibilita' di migliorare, basta concentrarti nello scrivere nella maniera piu' semplice possibile. Un consiglio: quando qualcosa che hai scritto "non ti sembra elegante", hai come un pensiero che ti dice che non va bene anche se fa quello che vuoi, riscrivila meglio. Vedrai che con gli anni quell'istinto migliorera' con l'esperienza e scriverai codice sempre migliori. Non aver paura di riscrivere quello che hai gia' scritto: lo fanno i migliori programmatori al mondo ed e' per questo che sono i migliori.

16 anni e' piu' o meno la stessa eta' alla quale ho iniziato io.

[71103]

Originariamente inviato da repne scasb
Ormai sono alcuni anni che nel centro di ricerca di cui sono a capo sto lavorando ad un simulatore software reolitico per materiali sia viscoelastici e elastoplastici. Durante le ricerche sul simulatore mi sono accostata agli automi-cellulari per risolvere con approsimazioni successive alcuni aspetti del simulatore (lungo da spegare).

Nel mio avatar e' visibile (purtroppo si e' persa la natura binaria dell'automa-cellulare in quanto ho dovuto restringere la stessa da 64x64 pixel a 50x50 pixel) il sorgente (scritto in un linguaggio da me creato per studiare tali oggetti), di uno speciale automa-cellulare. Tale automa-cellulare e' stato trovato per caso da me durante la ricerca sul simulatore reolitico e non c'entra nulla con ill simulatore; e' in grado di comprimere dei dati binari in un modo del tutto nuovo (con un automa-cellulare appunto). Era il 174-esimo della 242-esimo guppo; ho preso cio' come un "segno".

P.S. Per l'esattezza e' visibile nell'avatar il sorgente dell'automa-cellulare compresso dallo stesso automa-cellulare.

... caspiterina... :eek: :confused: :confused: :eek:

[DanieleC88]

Originariamente inviato da fek
Assembly.

Iniziare col C a 16 anni e' ottimo, complimenti :)
Ed hai tantissime possibilita' di migliorare, basta concentrarti nello scrivere nella maniera piu' semplice possibile. Un consiglio: quando qualcosa che hai scritto "non ti sembra elegante", hai come un pensiero che ti dice che non va bene anche se fa quello che vuoi, riscrivila meglio. Vedrai che con gli anni quell'istinto migliorera' con l'esperienza e scriverai codice sempre migliori. Non aver paura di riscrivere quello che hai gia' scritto: lo fanno i migliori programmatori al mondo ed e' per questo che sono i migliori.

16 anni e' piu' o meno la stessa eta' alla quale ho iniziato io.

Devo dire che non sono proprio agli inizi: programmo da circa tre anni (o quattro, non ricordo), e solo nell'ultimo anno ho usato il C. Ora sto provando anche a farmi un sistema operativo, ma visti i risultati è meglio lasciare al signor Torvalds. :D
Grazie cmq a tutti che continuate ad incoraggiare e consigliare i giovani come me. Siete mitici!
bye, jmc