<= And> = dovrebbe essere evitato quando si usano numeri interi, come in un ciclo For? [chiuso]

Ho spiegato ai miei studenti che la parità di test non è affidabile per le variabili float, ma va bene per i numeri interi. Il libro di testo che sto usando dice che è più facile da leggere> e <di> = e <=. Sono d'accordo in una certa misura, ma in un ciclo For? Non è più chiaro se il ciclo specifica i valori iniziale e finale?

Mi sto perdendo qualcosa di cui l'autore del libro di testo ha ragione?

Un altro esempio è nei test di intervallo come:

se il punteggio> 89 grado = 'A'
altrimenti se il punteggio> 79 grado = 'B' ...

Perché non dire semplicemente: se il punteggio> = 90?

Nei linguaggi di programmazione a parentesi graffe con array a base zero , è consuetudine scrivere forloop come questo:

for (int i = 0; i < array.Length, i++) { }

Questo attraversa tutti gli elementi dell'array ed è di gran lunga il caso più comune. Evita l'uso di <=o >=.

L'unica volta che questo dovrebbe mai cambiare è quando è necessario saltare il primo o l'ultimo elemento, oppure attraversarlo nella direzione opposta o attraversarlo da un punto iniziale diverso o verso un punto finale diverso.

Per le raccolte, nelle lingue che supportano gli iteratori, è più comune vedere questo:

foreach (var item in list) { }

Ciò evita del tutto i confronti.

Se stai cercando una regola dura e veloce su quando usare <=vs <, non ce n'è una; usa ciò che esprime al meglio il tuo intento. Se il tuo codice deve esprimere il concetto "Minore o uguale a 55 miglia all'ora", allora deve dire di <=no <.

Per rispondere alla tua domanda sulle gamme di voti, >= 90ha più senso, perché 90 è il valore limite effettivo, non 89.

Non importa

Ma per il bene della discussione, analizziamo le due opzioni: a > bvs a >= b.

Un attimo! Quelli non sono equivalenti!
OK, quindi a >= b -1vs a > bo a > bcontro a >= b +1.

Hm, a >bed a >= bentrambi sembrano migliori di a >= b - 1ea >= b +1 . Cosa sono 1comunque tutti questi ? Quindi direi che qualsiasi beneficio derivante dall'avere >invece >=o viceversa è eliminato dovendo aggiungere o sottrarre casuali 1.

E se fosse un numero? È meglio dire a > 7o a >= 6? Aspetta un secondo. Stiamo seriamente discutendo se è meglio usare >vs >=e ignorare le variabili hard coded? Quindi diventa davvero una questione se a > DAYS_OF_WEEKè meglio dia >= DAYS_OF_WEEK_MINUS_ONE ... o è a > NUMBER_OF_LEGS_IN_INSECT_PLUS_ONEvs a >= NUMBER_OF_LEGS_IN_INSECT? E torniamo ad aggiungere / sottrarre 1s, solo questa volta in nomi di variabili. O magari discutendo se è meglio usare soglia, limite, massimo.

E sembra che non ci siano regole generali: dipende da cosa viene confrontato

Ma in realtà, ci sono cose molto più importanti da migliorare nel proprio codice e linee guida molto più obiettive e ragionevoli (ad es. Limite di caratteri X per riga) che hanno ancora delle eccezioni.

Computazionalmente non vi è alcuna differenza nei costi quando si utilizza <o >rispetto a <=o>= . È calcolato altrettanto velocemente.

Tuttavia, la maggior parte dei loop conterà da 0 (poiché molte lingue usano l'indicizzazione 0 per i loro array). Quindi il canonico per loop in quelle lingue è

for(int i = 0; i < length; i++){
   array[i] = //...
   //...
}

farlo con un <=richiederebbe di aggiungere un -1 da qualche parte per evitare l'off-by di un errore

for(int i = 1; i <= length; i++){
   array[i-1] = //...
   //...
}

o

for(int i = 0; i <= length-1; i++){
   array[i] = //...
   //...
}

Ovviamente se la lingua utilizza l'indicizzazione basata su 1, allora useresti <= come condizione limite.

La chiave è che i valori espressi nella condizione sono quelli della descrizione del problema. È più pulito da leggere

if(x >= 10 && x < 20){

} else if(x >= 20 && x < 30){

}

per un intervallo semiaperto di

if(x >= 10 && x <= 19){

} else if(x >= 20 && x <= 29){

}

e devo fare i conti con la matematica per sapere che non esiste un valore possibile tra 19 e 20

Direi che il punto non è se dovresti usare> o> =. Il punto è usare qualunque cosa ti permetta di scrivere codice espressivo.

Se ritieni di dover aggiungere / sottrarre uno, considera l'utilizzo dell'altro operatore. Trovo che accadano cose buone quando inizi con un buon modello del tuo dominio. Quindi la logica si scrive da sola.

bool IsSpeeding(int kilometersPerHour)
{
    const int speedLimit = 90;
    return kilometersPerHour > speedLimit;
}

Questo è molto più espressivo di

bool IsSpeeding(int kilometersPerHour)
{
    const int speedLimit = 90;
    return kilometersPerHour >= (speedLimit + 1);
}

In altri casi, è preferibile l'altro modo:

bool CanAfford(decimal price, decimal balance)
{
    return balance >= price;
}

Molto meglio di

bool CanAfford(decimal price, decimal balance)
{
    const decimal epsilon = 0e-10m;
    return balance > (price - epsilon);
}

Per favore, scusa l'ossessione primitiva. Ovviamente vorresti usare un tipo Velocity e Money qui, rispettivamente, ma li ho omessi per brevità. Il punto è: utilizzare la versione più concisa e che consente di concentrarsi sul problema aziendale che si desidera risolvere.

Come hai sottolineato nella tua domanda, il test per l'uguaglianza sulle variabili float non è affidabile.

Lo stesso vale per <=e >=.

Tuttavia, non esiste tale problema di affidabilità per i tipi interi. A mio avviso, l'autore ha espresso la sua opinione su quale sia più leggibile.

Indipendentemente dal fatto che tu sia d'accordo o meno con lui, ovviamente è la tua opinione.

Ciascuno dei rapporti <, <=, >=, >e anche == e !=hanno i casi di utilizzo per il confronto di due valori in virgola mobile. Ognuno ha un significato specifico e dovrebbe essere scelto quello appropriato.

Fornirò esempi per casi in cui si desidera esattamente questo operatore per ciascuno di essi. (Attenzione ai NaN, però.)

• Hai una costosa funzione pura fche accetta come input un valore in virgola mobile. Per velocizzare i tuoi calcoli, decidi di aggiungere una cache degli ultimi valori calcolati, ovvero una tabella di ricerca mappata xa f(x). Ti consigliamo di usarlo ==per confrontare gli argomenti.
• Vuoi sapere se puoi dividere in modo significativo per un numero x? Probabilmente vuoi usare x != 0.0.
• Vuoi sapere se un valore xè nell'intervallo unitario? (x >= 0.0) && (x < 1.0)è la condizione corretta.
• Hai calcolato il determinante ddi una matrice e vuoi dire se è definito positivo? Non c'è motivo di usare nient'altro che d > 0.0.
• Vuoi sapere se Σ _{n = 1, ..., ∞} n ^−α diverge? Proverei per alpha <= 1.0.

La matematica in virgola mobile (in generale) non è esatta. Ma ciò non significa che dovresti temerlo, trattarlo come magico e certamente non sempre trattare due quantità in virgola mobile uguali se sono dentro 1.0E-10. Farlo romperà davvero la tua matematica e farà accadere tutte le cose strane.

• Ad esempio, se si utilizza il confronto fuzzy con la cache di cui sopra, si introdurranno errori esilaranti. Ma peggio ancora, la funzione non sarà più pura e l'errore dipenderà dai risultati precedentemente calcolati!
• Sì, anche se x != 0.0ed yè un valore a virgola mobile finito, y / xnon è necessario che sia finito. Ma potrebbe essere rilevante sapere se y / xnon è finito a causa dell'overflow o perché l'operazione non era matematicamente ben definita per cominciare.
• Se si dispone di una funzione che ha come prerequisito che un parametro di input xdeve trovarsi nell'intervallo di unità [0, 1), sarei davvero sconvolto se generasse un errore di asserzione quando chiamato con x == 0.0o x == 1.0 - 1.0E-14.
• Il determinante che hai calcolato potrebbe non essere accurato. Ma se farai finta che la matrice non sia definita positiva quando lo è il determinante calcolato 1.0E-30, non si ottiene nulla. Tutto quello che hai fatto è stato aumentare la probabilità di dare la risposta sbagliata.
• Sì, il tuo argomento alphapotrebbe essere influenzato da errori di arrotondamento e quindi alpha <= 1.0potrebbe essere vero anche se il vero valore matematico per l'espressione da cui è alphastato calcolato potrebbe essere stato davvero maggiore di 1. Ma non c'è nulla che tu possa fare al riguardo a questo punto.

Come sempre nell'ingegneria del software, gestire gli errori al livello appropriato e gestirli una sola volta. Se aggiungi errori di arrotondamento nell'ordine di 1.0E-10(questo sembra essere il valore magico che la maggior parte delle persone usa, non so perché) ogni volta che confronti quantità in virgola mobile, ti imbatterai presto in errori nell'ordine di 1.0E+10...

Il tipo di condizionale utilizzato in un ciclo può limitare i tipi di ottimizzazioni che un compilatore può eseguire, nel bene e nel male. Ad esempio, dato:

uint16_t n = ...;
for (uint16_t i=1; i<=n; i++)
  ...  [loop doesn't modify i]

un compilatore potrebbe presumere che la condizione di cui sopra dovrebbe causare l'uscita del loop dopo l'ennesimo loop di passaggio a meno che n non possa 65535 e il loop potrebbe uscire in qualche modo diverso da quelli che superano n. Se si applicano tali condizioni, il compilatore deve generare un codice che provocherebbe l'esecuzione del ciclo fino a quando qualcosa di diverso dalla condizione precedente lo fa uscire.

Se il ciclo fosse invece stato scritto come:

uint16_t n = ...;
for (uint16_t ctr=0; ctr<n; ctr++)
{
  uint16_t i = ctr+1;
  ... [loop doesn't modify ctr]
}

quindi un compilatore potrebbe tranquillamente supporre che il ciclo non debba mai essere eseguito più di n volte e potrebbe quindi essere in grado di generare codice più efficiente.

Si noti che qualsiasi overflow con tipi firmati può avere conseguenze spiacevoli. Dato:

int total=0;
int start,lim,mult; // Initialize values somehow...
for (int i=start; i<=lim; i++)
  total+=i*mult;

Un compilatore potrebbe riscriverlo come:

int total=0;
int start,lim,mult; // Initialize values somehow...
int loop_top = lim*mult;
for (int i=start; i<=loop_top; i+=mult)
  total+=i;

Un ciclo di questo tipo si comporterebbe in modo identico all'originale se non si verifica alcun overflow nei calcoli, ma potrebbe funzionare per sempre anche su piattaforme hardware in cui l'overflow di numeri interi avrebbe normalmente una semantica di wrapping coerente.