ElectroYou

Un programma non funziona e dovrei capire perché.
Se definisco così delle variabili:
int aux1, aux2, aux3;
queste sono capaci di ospitare valori interi a 32 bit cioè circa due miliardi.
Se poi adopero queste variabili in una normale espressione aritmetica, contenente delle moltiplicazioni:
aux3=aux1*aux2*99;
sfrutto effettivamente questa capacità? Dovrei provvedere a casting o altro?
E' vero che potrei fare delle prove col debug, ma per il momento ho le idee troppo confuse e conosco pochissimo il C.
Il compilatore è XC32 di Microchip student free e il chip è pic32 MX110F016B.

POST SCRIPTUM Ho fatto la prova col debug e il C risulta assolto. Penso comunque che l'argomento possa rimanere.

Si aux3 può contenere fino a 2 miliardi e rotti se l'int è a 32 bit, prova a stampare il valore di sizeof(int) così ne avrai la certezza.
Tieni presente che se il risultato del prodotto è superiore a 2 miliardi e rotti il sistema non ti dice niente.
Ma che problema ti da?

nel caso leggi
https://ww1.microchip.com/downloads/en/ ... 01686J.pdf
paragrafo 2.4.6
si tende sempre ad usare i tipi definiti in stdint.h

Si, in tal modo si è sicuri del nr di bit usati dal compilatore per le variabili.
Per esempio:
"Int16_t " è un intero a 16 bit.
Mentre dichiarando solo un "int" non sai se il compilatore decide di utilizzare 16 o 32 bit.

OK grazie.

gianc2020 ha scritto:Ma che problema ti da?

E' sempre il ricevitore che sto studiando e su cui ho postato un articolo.
Al posto del passa basso del primo ordine ne ho messo uno del secondo ordine la cui formula iterativa è:
cf=123*dic-6881*cpp+14959*cp;
cf=cf>>13;
cpp=cp; cp=cf;

Così funziona.
Se ricalcolo i coefficienti, sempre col metodo delle differenze all'indietro, per una frequenza di taglio più bassa, smette di funzionare.
Pertanto ritengo che si tratti di un problema numerico ma non è detto.

EcoTan ha scritto:cf=cf>>13;

Stai usando i numeri in fixed point, devi essere assolutamente sicuro che nessun valore provochi un overflow sul bit di segno (i tipi che usi sono interi segnati).

gianc2020 ha scritto:Tieni presente che se il risultato del prodotto è superiore a 2 miliardi e rotti il sistema non ti dice niente.

C'è modo per fare sì che il debug dia un avviso o si fermi ?

EcoTan ha scritto:OK grazie.

gianc2020 ha scritto:Ma che problema ti da?

E' sempre il ricevitore che sto studiando e su cui ho postato un articolo.
Al posto del passa basso del primo ordine ne ho messo uno del secondo ordine la cui formula iterativa è:
cf=123*dic-6881*cpp+14959*cp;
cf=cf>>13;
cpp=cp; cp=cf;

1) suddividi l'operazione in + step e verifica se funziona oppure no.
cf1 = dic-6881
cf2 = 123 * cf1
etc.

2) Prendi il codice e provalo su un compilatore x x86, se non ce l'hai ce ne sono online

Ho verificato che eccezioni numeriche non ce ne sono. Il filtro in realtà funziona in ambedue le versioni, ma nella versione più stretta fa saturare lo stadio rivelatore seguente quindi impedisce il riconoscimento dei caratteri.
Questo veramente non ha senso, perché un filtro più stretto dovrebbe catturare meno rumore e non di più (sbaglio?).
Forse è un problema di tolleranze numeriche "benigne" e in tal caso basterebbe assumere una soglia di rivelazione più alta.