Il confronto dell'uguaglianza dei numeri float inganna gli sviluppatori junior anche se nel mio caso non si verificano errori di arrotondamento?

Ad esempio, voglio mostrare un elenco di pulsanti da 0,0,5, ... 5, che salta per ogni 0,5. Uso un ciclo for per farlo e ho un colore diverso sul pulsante STANDARD_LINE:

var MAX=5.0;
var DIFF=0.5
var STANDARD_LINE=1.5;

for(var i=0;i<=MAX;i=i+DIFF){
    button.text=i+'';
    if(i==STANDARD_LINE){
      button.color='red';
    }
}

In questo caso non dovrebbero esserci errori di arrotondamento poiché ogni valore è esatto in IEEE 754, ma sto lottando se dovessi cambiarlo per evitare il confronto di uguaglianza in virgola mobile:

var MAX=10;
var STANDARD_LINE=3;

for(var i=0;i<=MAX;i++){
    button.text=i/2.0+'';
    if(i==STANDARD_LINE/2.0){
      button.color='red';
    }
}

Da un lato, il codice originale è più semplice e avanti per me. Ma sto prendendo in considerazione una cosa: i == STANDARD_LINE induce in errore i compagni di squadra junior? Nasconde il fatto che i numeri in virgola mobile potrebbero avere errori di arrotondamento? Dopo aver letto i commenti di questo post:

https://stackoverflow.com/questions/33646148/is-hardcode-float-precise-if-it-can-be-represented-by-binary-format-in-ieee-754

sembra che ci siano molti sviluppatori che non sanno che alcuni numeri float sono esatti. Devo evitare i confronti dell'uguaglianza dei numeri float anche se è valido nel mio caso? O ci sto pensando troppo?

Eviterei sempre le successive operazioni in virgola mobile a meno che il modello che sto calcolando non le richieda. L'aritmetica in virgola mobile non è intuitiva per la maggior parte e costituisce una fonte importante di errori. E raccontare i casi in cui provoca errori da quelli in cui non lo è è una distinzione ancora più sottile!

Pertanto, l'utilizzo di float come contatori di loop è un difetto in attesa di verificarsi e richiederebbe almeno un grosso commento di fondo che spieghi perché qui va bene usare 0,5 e che questo dipende dal valore numerico specifico. A quel punto, riscrivere il codice per evitare i contatori float sarà probabilmente l'opzione più leggibile. E la leggibilità è accanto alla correttezza nella gerarchia dei requisiti professionali.

Come regola generale, i loop dovrebbero essere scritti in modo tale da pensare di fare qualcosa n volte. Se stai usando indici a virgola mobile, non è più una questione di fare qualcosa n volte ma piuttosto di correre fino a quando una condizione è soddisfatta. Se questa condizione sembra essere molto simile a quella i<nche si aspettano così tanti programmatori, allora il codice sembra fare una cosa quando ne sta effettivamente facendo un'altra che può essere facilmente interpretata male dai programmatori che saltano il codice.

È in qualche modo soggettivo, ma secondo la mia modesta opinione, se riesci a riscrivere un ciclo per usare un indice intero per fare il ciclo per un numero fisso di volte, dovresti farlo. Quindi considera la seguente alternativa:

var DIFF=0.5;                           // pixel increment
var MAX=Math.floor(5.0/DIFF);           // 5.0 is max pixel width
var STANDARD_LINE=Math.floor(1.5/DIFF); // 1.5 is pixel width

for(var i=0;i<=MAX;i++){
    button.text=(i*DIFF)+'';
    if(i==STANDARD_LINE){
      button.color='red';
    }
}

Il ciclo funziona in termini di numeri interi. In questo caso iè un numero intero ed STANDARD_LINEè anche forzato a un numero intero. Questo ovviamente cambierebbe la posizione della linea standard se ci fosse un roundoff e allo stesso MAXmodo, quindi dovresti comunque cercare di evitare il roundoff per un rendering accurato. Tuttavia, hai ancora il vantaggio di modificare i parametri in termini di pixel e non di numeri interi senza doverti preoccupare del confronto dei punti fluttuanti.

Concordo con tutte le altre risposte sul fatto che l'utilizzo di una variabile di ciclo non intero è generalmente un cattivo stile anche in casi come questo in cui funzionerà correttamente. Ma mi sembra che ci sia un altro motivo per cui il cattivo stile qui.

Il tuo codice "sa" che le larghezze di linea disponibili sono precisamente i multipli di 0,5 da 0 a 5,0. Dovrebbe? Sembra che sia una decisione dell'interfaccia utente che potrebbe facilmente cambiare (ad esempio, forse si desidera che gli spazi tra le larghezze disponibili aumentino come fanno le larghezze. 0,25, 0,5, 0,75, 1,0, 1,5, 2,0, 2,5, 3,0, 4,0, 5.0 o qualcosa del genere).

Il tuo codice "sa" che le larghezze di linea disponibili hanno tutte "belle" rappresentazioni sia come numeri a virgola mobile che come decimali. Anche quello sembra qualcosa che potrebbe cambiare. (Potresti voler 0,1, 0,2, 0,3, ... ad un certo punto.)

Il tuo codice "sa" che il testo da mettere sui pulsanti è semplicemente ciò in cui Javascript trasforma quei valori in virgola mobile. Anche quello sembra qualcosa che potrebbe cambiare. (Ad esempio, forse un giorno vorrai larghezze come 1/3, che probabilmente non vorresti visualizzare come 0.33333333333333 o altro. O forse vuoi vedere "1.0" invece di "1" per coerenza con "1.5" .)

Mi sembrano tutte manifestazioni di una singola debolezza, che è una sorta di mescolanza di strati. Quei numeri in virgola mobile fanno parte della logica interna del software. Il testo mostrato sui pulsanti fa parte dell'interfaccia utente. Dovrebbero essere più separati di quanto non siano nel codice qui. Nozioni come "quale di queste è l'impostazione predefinita che deve essere evidenziata?" sono questioni relative all'interfaccia utente e probabilmente non dovrebbero essere legate a quei valori in virgola mobile. E il tuo loop qui è davvero (o almeno dovrebbe essere) un loop su pulsanti , non su larghezze di linea . Scritta in questo modo, la tentazione di usare una variabile di ciclo che accetta valori non interi scompare: useresti solo numeri interi successivi o un ciclo for ... in / for ... of.

La mia sensazione è che la maggior parte dei casi in cui si potrebbe essere tentati di passare in rassegna numeri non interi sono così: ci sono altre ragioni, completamente estranee alle questioni numeriche, per cui il codice dovrebbe essere organizzato in modo diverso. (Non tutti i casi; posso immaginare che alcuni algoritmi matematici possano essere espressi in modo più preciso in termini di un ciclo su valori non interi.)

Un odore di codice sta usando float in loop in quel modo.

Il looping può essere fatto in molti modi, ma nel 99,9% dei casi dovresti attenersi a un incremento di 1 o ci sarà sicuramente confusione, non solo dagli sviluppatori junior.

Sì, vuoi evitare questo.

I numeri in virgola mobile sono una delle più grandi trappole per il programmatore ignaro (il che significa, nella mia esperienza, quasi tutti). Dal dipendere dai test di uguaglianza in virgola mobile, alla rappresentazione del denaro come virgola mobile, è tutto un grande pantano. Sommare un galleggiante sull'altro è uno dei più grandi delinquenti. Ci sono interi volumi di letteratura scientifica su cose come questa.

Utilizzare i numeri in virgola mobile esattamente nei punti in cui sono appropriati, ad esempio quando si eseguono calcoli matematici effettivi in ​​cui sono necessari (come trigonometria, rappresentazione grafica di grafici ecc.) E fare molta attenzione quando si eseguono operazioni seriali. L'uguaglianza è giusta. La conoscenza di quale particolare serie di numeri sia esatta per gli standard IEEE è molto arcana e non dipenderei mai da essa.

Nel tuo caso, non ci sarà , con la legge Murphys, arrivato al punto in cui gestione vuole che non si dispone di 0.0, 0.5, 1.0 ... ma 0.0, 0.4, 0.8 ... o qualsiasi altra cosa; verrai immediatamente borked e il tuo programmatore junior (o te stesso) eseguirà il debug a lungo e duramente fino a quando non trovi il problema.

Nel tuo particolare codice, avrei effettivamente una variabile di ciclo intero. Rappresenta il ipulsante th, non il numero corrente.

E probabilmente, per maggiore chiarezza, probabilmente non scriverò, i/2ma i*0.5ciò chiarirà abbondantemente cosa sta succedendo.

var BUTTONS=11;
var STANDARD_LINE=3;

for(var i=0; i<BUTTONS; i++) {
    button.text = (i*0.5)+'';
    if (i==STANDARD_LINE) {
      button.color='red';
    }
}

Nota: come sottolineato nei commenti, JavaScript non ha effettivamente un tipo separato per gli interi. Ma i numeri interi fino a 15 cifre sono garantiti come precisi / sicuri (vedi https://www.ecma-international.org/ecma-262/6.0/#sec-number.max_safe_integer ), quindi per argomenti come questo ("è più confuso / soggetto a errori nel lavorare con numeri interi o non ") questo è appropriatamente vicino ad avere un tipo separato" nello spirito "; nell'uso quotidiano (loop, coordinate dello schermo, indici di array ecc.) non ci saranno sorprese con numeri interi rappresentati Numbercome JavaScript.

Non credo che nessuno dei tuoi suggerimenti sia buono. Invece, vorrei introdurre una variabile per il numero di pulsanti in base al valore massimo e alla spaziatura. Quindi, è abbastanza semplice passare in rassegna gli indici del pulsante stesso.

function precisionRound(number, precision) {
  let factor = Math.pow(10, precision);
  return Math.round(number * factor) / factor;
}

var maxButtonValue = 5.0;
var buttonSpacing = 0.5;

let countEstimate = precisionRound(maxButtonValue / buttonSpacing, 5);
var buttonCount = Math.floor(countEstimate) + 1;

var highlightPosition = 3;
var highlightColor = 'red';

for (let i=0; i < buttonCount; i++) {
    let buttonValue = i / buttonSpacing;
    button.text = buttonValue.toString();
    if (i == highlightPosition) {
        button.color = highlightColor;
    }
}

Potrebbe essere più codice, ma è anche più leggibile e più robusto.

Puoi evitare il tutto calcolando il valore che stai mostrando piuttosto che usare il contatore di loop come valore:

var MAX=5.0;
var DIFF=0.5
var STANDARD_LINE=1.5;

for(var i=0; (i*DIFF) < MAX ; i=i+1){
    var val = i * DIFF

    button.text=val+'';

    if(val==STANDARD_LINE){
      button.color='red';
    }
}

L'aritmetica in virgola mobile è lenta e l'aritmetica di numeri interi è veloce, quindi quando uso il virgola mobile, non lo userei inutilmente laddove è possibile utilizzare numeri interi. È utile pensare sempre ai numeri in virgola mobile, anche alle costanti, come approssimativi, con qualche piccolo errore. Durante il debug è molto utile sostituire i numeri in virgola mobile nativi con oggetti in virgola mobile più / meno in cui si considera ogni numero come un intervallo anziché un punto. In questo modo si scoprono inesattezze progressivamente crescenti dopo ogni operazione aritmetica. Quindi "1,5" dovrebbe essere considerato come "un numero compreso tra 1,45 e 1,55", e "1,50" dovrebbe essere considerato come "un numero compreso tra 1,495 e 1,505".