[prog-it] Re: holaz :)

  • From: "XXXX" <xxxxwebmaster@xxxxxxxxx>
  • To: <prog-it@xxxxxxxxxxxxx>
  • Date: Sun, 12 May 2002 20:34:59 +0200


----- Original Message -----
From: "Seeman79" <Seeman79@xxxxxxxxx>
To: <prog-it@xxxxxxxxxxxxx>
Sent: Sunday, May 12, 2002 8:06 PM
Subject: [prog-it] Re: holaz :)


<cut>
> La mia mail e' in prima persona rivolta ad XXXX perche'
> e' quello che ha iniziato il thread.

smack :P
> ---
>
> Mi fa piacere che tu ti ricordi quello che ti ho detto un
> po' di tempo fa, ossia che la cosa piu' importante per un
> listato e' che ALMENO faccia quello che vuoi,

... hihih ongi tanto la memoria non mi tradisce :P

ma un minimo
> di "dignita'" nel codice bisognerebbe sempre mettercela :)

dignita'???? cos'e' la diognita' ?? :P

> Vediamo di focalizzare alcuni punti che, secondo me, sono
> il fattor comune di tutti i tuoi listati.

wwowowo ora si inizia a ragionare in termini di programmazione :P smack!
hihihi :P
>
> 0. Se guardiamo con attenzione il tuo listato, ci accorgiamo
> che tu hai bisogno di 7 variabili, di cui 6 dello stesso
> tipo (float).
> Come mai tu ne utilizzi 27? :)

perche' sono folle? hihihih

> Una possibile struttura dati da utilizzare potrebbe essere:
>
> #define MAX_LEN 50 /* il tuo 389 mi pare esagerato :) */
>     #define VOCI 6
>
>     typedef enum {Reddito_Imponibile, Oneri_Deducibili,
Detrazioni_Imposta,
>     Imposta_Netta, Ritenute_Subite, Imposta_Dovuta
>      } Nome_Voce;
>
>     typedef float Importo[VOCI];
>
>     typedef struct Info {
>     char nome[MAX_LEN];
>     Importo valore;
>     } Param;
>
> typedef struct Info *Options;
>
> In modo che poi accedi ai vari campi con la "coscienza" di quello che
> stai facendo; ad esempio:
>
> Options cliente = NULL;
>
>     /* allochi la struttura */
> cliente->nome;
> cliente->valore[Reddito_Imponibile];
> /* Indicano campi ben precisi, facili ed intuitivi da capire */
>
> Almeno elimini tutta la strage di variabili che hai fatto tu :)

mi fai un esempio di codice?

>
> 1. Perche' aprire il file all'inizio se poi ci scrivi solo
> alla fine? In questo modo se l'apertura fallisse, ti
> toglieresti anche la possibilita' di vedere a video i
> risultati.

perche' in questa versione del programma mi serve principalmente la stampa
sul file se cio' non avvenisse il programma mi e' inutile :)

>
> 2. Il logo celebrativo del programmatore, mettilo in una
> procedura cosi' lo richiami ogni volta che serve; fai
> si che la procedura accetti in input un "FILE *" e se
> vuoi stamparlo sullo schermo gli passi "stdin", mentre
> se ti serve stamparlo su file gli passi il puntatore
> alla struttura di tipo "FILE *" appunto.

...questa non l'ho capita che intendi per "logo celebrativo del
programmatore"?

>
> 3. Quando utilizzi la scanf, per leggere una stringa non
> necessiti dell'operatore '&' perche' gli operandi
> '&*' si annullano a vicenda (se hai un minimo di
> famigliarita' con i puntatori ti e' facile capire
> perche').

allora quando lo compilo con devc++ se non uso l'operatore '&' non mi
compila il codice e quindi sono stato costretto ad usarlo

>
> 4. Consideriamo questo pezzo del tuo codice:
> ---
>     if(med <= 129.11) med1=0; else med1 = med-129.11;
> ---
hihihih quanto mi piace :P hihih

> Tutto cio' si puo' risolvere con una macro e, visto
> che esegui una sottrazione ed un controllo sul medesimo
> valore, restituendo eventualmente zero, il controllo puo'
> essere tranquillamente un minore stretto.
> Nel senso: se il primo controllo fosse un minore stretto
> e "med" fosse proprio "129.11", il controllo fallisce
> e tu ritorni "med1 = med-129.11" che e' esattamente
> zero (ossia quello che volevi tu).
> Assicurati che i tuoi controlli non siano ridondanti.
> Potresti usare una cosa del tipo:
>
> #define LIMITE 129.11
> #define MEDICHE(x) ( (x < LIMITE) ? 0 : (x - LIMITE) )

chiarissimo senza dubbio e' migliore questa soluzione :)

>
> 5. Ragioniamo ora sul calcolo delle varie aliquote per
> scaglioni. Cosi' come hai scritto il codice tu saltano
> agli occhi subito un po' di difetti:

e te pareva ? :P

>
> a) Utilizzi costanti all'interno del codice senza assegnarle
> dei nomi; cio' significa che se un giorno dovrai modificare
> il codice, dovrai spulciarlo dall'inizio alla fine ricercando
> tutte le occorrenze e cambiarle.

no so gia che le ostanti per le varie aliquote corrispndon a quel numero che
si trova in quel punto di codice visto che in quel punto calcolo le aliquote
:)
[spiegazione stile Trap hihihih] ma volevo dire che non m i serve
identificare le costanti inquanto non cambieranno se non radicalmente anche
nel calcolo dell'irpef :)


>
> b) Molte parti del tuo codice sono ripetitive; occorre automatizzare
> con funzioni matematiche ben definite.

bhe che ti aspettavi da un ripetitivo come  me? hihih :P
>
> c) Fai uso di un numero di variabili spropositato, del tutto
> inutili; a parte il puro folclore non c'e' nessuna spiegazione
> (razionale) a tutto cio'.

razionalita?....esiste?
hihihi :P
>
> d) ecc. ecc.

questa mi incuriosisce :) :P

>
> Esaminiamo questo frammento del tuo codice:
> ---
> if(redr <= 10329.14) irpef1= redr*18/100;
> else irpef1=1859.25;
> ---
> Questa procedura e quella per il calcolo dell'aliquota piu' alta
> sono diverse da tutte le altre che risultano, invece, avere tutte
> una matrice comune. Tenendo presente quello che ti ho detto prima
> questo problema si puo' risolvere (tra i vari modi) con questa macro:
>
> #define ALIQUOTA_MIN 18
>     #define ALFA_MIN 10329.14
>     #define BETA_MIN 1859.25
> #define IRPEF_MIN(x) ( (x <= ALFA_MIN) ? (x * ALIQUOTA_MIN / 100) :
BETA_MIN )
>
> Sembra essere abbastanza Chiara (o Marta se preferisci): no?
> Se e quando cambieranno i "limiti" ma non il modo di calcolare l'irpef
> ti bastera' agire sulle aliquote e su ALFA_MIN e BETA_MIN senza toccare
> una riga di codice.

a parte le puttante che ho detto fin ora è tutto chiarissimo come sempre :)
e ripensandoci bene forse ho scritto una mega puttanta del tipo che se me
leggesse il presidente dell'albo dei consulenti del lavoro me radierebbe
hihih :P
infatti non cabiera' la procedura di calcolo ma ridurranno il Numero delle
aliquote da 5 passeranno a due quandio ci saranno solo due scaglioni di
reddito
giusto per semplificare il mio progz :)

>
> Esaminiamo ora le altre procedure, esclusa quella per il calcolo
dell'aliquota
> massima; sono tutte del tipo:
> ---
> ali(n)=redr-alfa(n);
> if (ali(n) <beta(n)) ali(n)=redr-alfa(n);
> if (ali(n) >=beta(n)) ali(n) = beta(n);
> if (ali(n) <=0) ali(n)=0;
> irpef(n)=ali(n)*aliq/100;
> ---
> Le variabili della serie "ali(n)" non servono assolutamente a nulla ed ora
> vediamo di dimostrarlo :)
> Esaminiamo un generico caso; tu imponi che:
>
> ali = redr - alfa;
>
> E poi ti chiedi:
>
> Se "ali < beta" allora "ali = redr - alfa"
>
> Allora io mi chiedo: chi e' "ali"? Beh "ali" e' "redr - alfa" a detta di
XXXX;
> allora sostituendo, la condizione logica diventa:
>
> Se "redr - alfa < beta" allora /* bla bla bla */
>
> Con un misero quanto banale passaggio matematico, si conclude che la
condizione
> corretta e':
>
> Se "redr < (alfa + beta)" allora /* bla bla bla */


if (redr<=0 ali=0)
if (redr <(alfa+beta) ali=redr-alfa)
else
ali=beta


gisto?

> Continuando nel ragionamento, ci accorgiamo che il tuo secondo "if" e' in
realta'
> un "else" del primo "if"... Chiaro no? Se non e' minore di una cosa allora
puo'
> essere solo maggiore/uguale (i saggi, che di analisi matematica non
sapevano
> nulla, dicevano "se non e' zuppa e' pan bagnato") :)

hihihih giustissimo :)

>
> Quindi lo tralasciamo perche' non ci serve per ora; l'ultimo "if" invece;
>
> Se "ali <= 0" allora /* bla bla bla */
>
> Solita cosa... ma chi e' "ali"? Sempre lui, per cui sostituendo:
> "redr - alfa <= 0" implica che "redr <= alfa"
> (piu' tardi ti faro' notare che questa condizione e' ridondante).

ok  continuo a leggere :)


>
> Le condizioni logiche che abbiamo fino ad ora sono:
> Se "redr < (alfa + beta)" allora /* bla bla bla */
> else /* bla bla bla */
> Se "redr <= alfa" allora /* bla bla bla */
>
> Che cosa puoi notare? L'ordine delle condizioni non e' corretto a livello
logico,
> infatti la prima condizione ci dice se "redr" e' minore di "alfa+beta", ma
non ci
> assicura che sia anche minore di "alfa" (in pratica ci fornisce una
condizione
> necessaria ma non sufficiente, perche' la seconda e' piu' restrittiva).
Per tanto
> il flusso logico corretto sarebbe:
>
> Se "redr <= alfa" allora "zero"
> altrimenti Se "redr < (alfa + beta)" allora "redr - alfa"
> altrimenti "beta"
>
> Come detto ora ti faccio notare che il primo controllo logico e'
ridondante,
> in quanto definito gia' nel caso 2; immagina di mettere un minore stretto
al
> primo controllo e che "redr" sia proprio uguale ad "alfa". Cio' che
succede e'
> che il primo controllo fallisce, mentre il secondo e' verificato (per ogni
beta
> maggiore di zero; ma se fosse zero si andrebbe al terzo controllo che
restiruisce
> beta, cioe' zero e cioe' giusto :P), per cui si ritorna "redr - alfa"; ma
"redr"
> e' uguale ad "alfa" per ipotesi, per cui restituisce "zero" :)
> Concludendo il flusso corretto risulta:
>
> Se "redr < alfa" allora "zero"
> altrimenti Se "redr < (alfa + beta)" allora "redr - alfa"
> altrimenti "beta"

quindi avevo capito sopra :)
giusto?


>
> In sistanza il tutto si puo' risolvere con una macro, del tipo:
>
> #define IRPEF_MED(x,y,z,w) ( (x < y) ? 0 : ( (x < ( y + z)) ? ((x - y)* w
/ 100) : (z * w / 100)) )
>
>   Dove passerai, al posto della 'x' il "redr", 'y' ed 'z' i rispettivi
"alfa" e "beta"
> ed al posto di 'w' l'aliquota relativa allo scaglione.
> In sostanza potresti definire una cosa del tipo:
>
> #define ALIQUOTA_1 24
>     #define ALFA_1 10329.14
>     #define BETA_1 5164.56
>
>     #define ALIQUOTA_2 32
>     #define ALFA_2 15493.72
>     #define BETA_2 15493.69
>
>     #define ALIQUOTA_3 39
>     #define ALFA_3 30987.41
>     #define BETA_3 38734.27
>
> Questa macro e' definita per tutti questi scaglioni (e per eventuali
futuri strutturati
> nella stessa maniera).
>

si ci sono fin quio ci sono :)

> Ultimo caso da analizzare e' il calcolo dell'aliquota massima; il tuo
codice recita:
> ---
> ali5=redr-69721.41;
> if (ali5 <= 0) ali5=0;
> if (ali5 >69721.41) ali5 = redr - 69721.41;
> irpef5=ali5*45/100;
> ---

azz che attore :) non sapevo che il mio codice sapesse recitare hihihi :P

> Questo caso e' analogo al calcolo dell'aliquota piu' bassa (ma non uguale
purtroppo).
> Pero' vorrei farti notare una cosa: a che cosa ti serve il secondo "if"?
> Assegni ad un "ali5" un valore; poi dici che se e' maggiore di una data
quantita'
> gli riassegni lo stesso valore; perche' prima che valore c'era? :)
> L'unico "if" che ha senso e' il primo; per tanto potresti risolvere il
problema
> nella seguente maniera:
>
> #define ALIQUOTA_MAX 45
>     #define ALFA_MAX 69721.41
>     #define IRPEF_MAX(x) ( ( (x - ALFA_MAX) < 0) ? 0 : ((x - ALFA_MAX) *
ALIQUOTA_MAX / 100) )
>
> Anche questa mi sembra molto chiara e non necessita di ulteriori commenti.

chiarissima come sempre :)

> 6. Risulta inutile dichiarare 300.000 variabili per i sub-totali, quando
te ne
> bastano, esagerando, 2 per ottenere lo stesso risultato. La variabile che
> contiene il totale, puo' anche contenere i sub-totali, poiche' una
sommatoria
> come la tua e' cosi' fatta:
> x1 + x2 + x3 + ... +xn
> Se io scrivessi che (x1 + x2) = y e dicessi:
> y + x3 + ... + xn
> sei d'accordo che il risultato non cambia?

certamente :)

> Ho detto esagerando 2 perche' se non ti serve printare a video i
sub-totali
> (o ti serve ma non vuoi richiamare 2 volte la stessa macro), utilizzi una
> variabile temporanea che usi per printare a video e per sommarla al
totale.
> Nella fattispecie, per il tuo codice, una cosa del tipo:
> ---
> temp = IRPEF_MIN(redr); tot += temp;
> printf("\nIrpef 18: %.2f", temp);
>
> temp = IRPEF_MED(redr, ALFA_1, BETA_1, ALIQUOTA_1); tot += temp;
> printf("\nIrpef 24: %.2f", temp);
>
> temp = IRPEF_MED(redr, ALFA_2, BETA_2, ALIQUOTA_2); tot += temp;
> printf("\nIrpef 32: %.2f", temp);
>
> temp = IRPEF_MED(redr, ALFA_3, BETA_3, ALIQUOTA_3); tot += temp;
> printf("\nIrpef 39: %.2f", temp);
>
> temp = IRPEF_MAX(redr); tot += temp;
> printf("\nIrpef 45: %.2f", temp);
>
> printf("\nIrpef totale: %.0f\n\n", tot);
> ---
> Ottieni lo stesso risultato con un terzo delle righe che hai scritto tu :)

perfetto :)
tutto chiaro almeno fin qui :)
contionuo a leggere :)


> Se poi addirittura non ti servisse neanche avere i risultati intermedi
> (per fare una cosa cosi', ricordati di inizializzare a zero "tot"), puoi
> tranquillamente eliminare "temp", e sommare tutto direttamente a "tot".


no no mi servono....
solo su file non mi servono ma a video si! :)

>
> 7. Poiche' utilizzi la "conio.h", la chiamata a:
> system("PAUSE");
> La puoi rimpiazzare con una "getch();"
> mentre la:
> system("CLS");
> con una clrscr();

ci ho provato o meglio la prima versione era con cosi'  ma con getch(); non
mi aspettava il return

> Il Borland ti dava dei warning per le chiamate "system" perche' essa e'
> definita in "stdlib.h" che tu NON hai incluso :)

lo so me l'ha fatto notare anche Al sul forum :)

>
> 8. Il devC++ ti da quei problemi, come ti ho gia' detto, perche' la
"conio.h",
> non e' una libreria "standard", per cui un compilatore non e' tenuto ad
> averla e linkarla. Inoltre, da specifica, non deve essere utilizzata per
> applicazioni a 32-bit, per via del fatto che utilizza chiamate a basso
> livello e OS a 32-bit in modalita' protetta non amano cio' (niente
> interrupt... a priori; anche se, ad esempio, Linux ha un interrupt INT80h
> con svariate funzioni da poter essere usato), con risultato il crash del
> programma. Di fatto sospetto, che non sia neanche presente.

si me l'avevi detto via sms :)

>
> Per ovviare a cio' potresti utilizzare la codifica ANSI dei colori, a
patto
> che l'utilizzatore del tuo programma carichi nel suo config.sys il driver
> "ansi.sys".

oppure lo compilo col borland :P

>
> 9. Quando chiami la cprintf("\r"); solo per questo, e' uno spreco;
inserisci
> uno '\r' in piu' nella prossima riga che stampi a video ed ottieni lo
stesso
> risultato con una chiamata a funzione in meno.

chiarissimo :) mi ero accorto anche io di questa inutile chiamata :)


> Questo e' quanto e scusa se ti ho scritto solo ora, ma come sai durante la
> settimana sono molto impegnato.

ma che grazie di tutto come smepre :)

piu' tardi se ho un po' di tempo provo a riscrivere il mio codice
vediamo se ho capito tutto :)

>
> Alla prossima.
> Ciao.


holaz bell0 :P


XXXX
The Official WebSite
http://xxxxwebmaster.altervista.org
www.xxxxwebmaster.cjb.net
Sono il re del Nulla
Mentre il Nulla ruba i migliori



Other related posts: