Conversione Dec-Bin

[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 ). 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 )

[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
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 )

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?

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 ), 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...

[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.
Grazie cmq a tutti che continuate ad incoraggiare e consigliare i giovani come me. Siete mitici!
bye, jmc