Bhè come avevo intuito è a livello principiante.
La risposta è: banalmente controlla i costrutti iterativi, ovvero cicli FOR e WHILE (o quello che è).
Se hai solo cicli FOR puoi calcolare esattamente quante operazioni fai.
Esempio scemissimo
for i=1 to N
totale = totale +i
In questo caso sai di fare esattamente 2N operazioni (in realtà ne fai 4N, perchè hai un test e un jump, e in realtà ne fai anche di più, ma sei a livello-base, non complichiamo la vita), che sono
- un assegnamento
- una somma
Quindi se N è 10, farai 10 somme e 10 assegnamenti.
la complessità è ovviamente o(N), o anche (meglio) 2N.
Non hai casi peggiori: il ciclo è sempre quello, quindi sempre tot è il tempo.
Se invece hai cose "strane", tipo
while qualcosa > qualcosa
... boh...
allora devi considerare che il ciclo può essere eseguito
-mai (complessità 0)
-una volta
-tante volte
- un numero variabile di volte, a seconda dei casi.
Ecco quindi che devi indicare sia la complessità PEGGIORE, cioè quando sei proprio sfortunato ed ogni singolo test "va male".
Poi si studia normalmente quella MEDIA (ma penso sia troppo difficile per te, ci vuole calcolo della probabilità, non credo si insegni a ingegneria, potrei sbagliare).
Vado a pranzo, ciao.
PS ovviamente do per scontato che nessuno ti abbia spiegato il calcolo "effettivo" della complessità, dove c'è il doppio problema dell'asintotica, e dei moltiplicatori (cioè i coefficienti) e infine dell'implementazione effettiva.
Paradossalmente, infatti, non tutte le operazioni elementari hanno lo stesso costo (cioè vengono tradotti in istruzioni-macchina più o meno veloci).
Non è immediato stabilire se è meglio un algoritmo che fa 10N(moltiplicazioni)+10000(assegnamenti) vs 3000N (assegnamenti) vs 10N(moltiplicazioni) + 200N (assegnamenti).
Ancor meno è facile capire se è sempre meglio o(n^2) invece di o(n^3) [sottolineo sempre]
Son tutte cose molto, ma molto complicate, se affrontate rigorosamente e non spannometricamente.
Fortunatamente per te, sicuro al 100% per la spannometria