私の場合、丸めエラーが発生していなくても、浮動小数点数が等しいかどうかを比較すると、ジュニア開発者を誤解させますか？

たとえば、0、0.5、... 5のボタンのリストを表示し、0.5ごとにジャンプします。私はforループを使用してそれを行い、ボタン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';
    }
}

この場合、IEEE 754では各値が正確であるため、丸めエラーはありませんが、浮動小数点の等価比較を避けるために変更する必要がある場合は苦労しています：

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';
    }
}

一方で、元のコードはよりシンプルで、私にとっては楽しみです。しかし、私が検討していることが1つあります。i== STANDARD_LINEはジュニアチームメイトを誤解させますか？浮動小数点数に丸め誤差がある可能性があるという事実を隠していますか？この投稿のコメントを読んだ後：

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

一部の浮動小数点数が正確であることを知らない開発者が多いようです。私の場合、浮動小数点数の等価比較が有効であっても、避けるべきですか？または、私はこれについて考えすぎていますか？

私が計算しているモデルがそれらを必要としない限り、私は常に連続した浮動小数点演算を避けます。浮動小数点演算は、ほとんどの主要なエラーの原因には直観的ではありません。そして、それがそうでないものからエラーを引き起こすケースを伝えることは、さらに微妙な違いです！

したがって、フロートをループカウンターとして使用することは、発生を待機している欠陥であり、少なくともここで0.5を使用してもよい理由を説明する太い背景コメントが必要です。これは特定の数値に依存します。その時点で、フロートカウンターを回避するためにコードを書き換えることは、おそらくより読みやすいオプションになります。そして、専門的な要件の階層においては、読みやすさが正しいことの次に重要です。

原則として、ループは何かをn回実行することを考えるような方法で記述される必要があります。浮動小数点インデックスを使用している場合、何かをn回実行するのではなく、条件が満たされるまで実行するという問題はなくなりました。この状態がi<n、多くのプログラマーが期待するものと非常によく似ている場合、コードがスキミングしているプログラマーによって簡単に誤解される可能性がある実際に別のことをしているときに、コードは1つのことをしているように見えます。

多少主観的ですが、謙虚な意見では、整数インデックスを使用して一定の回数ループするようにループを書き換えることができる場合は、そうする必要があります。したがって、次の代替案を検討してください。

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';
    }
}

ループは整数で機能します。この場合i、整数でありSTANDARD_LINE、同様に整数に強制されます。もちろん、これにより丸めが発生した場合、標準ラインの位置が変更されるためMAX、正確なレンダリングのために丸めを防止するよう努力する必要があります。ただし、浮動小数点の比較を心配することなく、整数ではなくピクセル単位でパラメーターを変更できるという利点があります。

私は、整数以外のループ変数を使用することは、正しく動作するこのような場合でも、一般的に悪いスタイルであるという他のすべての答えに同意します。しかし、私には、それがここで悪いスタイルである別の理由があるように思われます。

コードは、利用可能な線幅が正確に0から5.0までの0.5の倍数であることを「知っています」。すべきですか？それは簡単に変更できるユーザーインターフェイスの決定のようです（たとえば、幅が大きくなるにつれて利用可能な幅のギャップを大きくしたい場合があります。0.25、0.5、0.75、1.0、1.5、2.0、2.5、3.0、4.0、 5.0または何か）。

あなたのコードは、利用可能な行幅がすべて浮動小数点数と小数の両方として「素敵な」表現を持っていることを「知っています」。それはまた変わるかもしれない何かのように思えます。（0.1、0.2、0.3などが必要になる場合があります。）

コードは、ボタンに配置するテキストが単にJavaScriptがそれらの浮動小数点値に変換するものであることを「知っています」。それはまた変わるかもしれない何かのように思えます。（たとえば、1日のように幅が1/3になり、0.33333333333333などとして表示したくない場合があります。または、 "1.5"との一貫性のために "1"ではなく "1.0"を表示する場合があります。 ）

これらはすべて、レイヤーの混合の一種である単一の弱点の現れのように感じます。これらの浮動小数点数は、ソフトウェアの内部ロジックの一部です。ボタンに表示されるテキストは、ユーザーインターフェイスの一部です。これらは、ここのコードにあるものよりも分離する必要があります。「これらのうち、強調表示されるデフォルトはどれですか？」などの概念 ユーザーインターフェイスの問題であり、おそらくこれらの浮動小数点値に結び付けられるべきではありません。そして、ここでのループは実際には（または少なくともそうでなければならない）ボタン上のループであり、行幅ではありません。そのように書かれると、整数以外の値を取るループ変数を使用する誘惑はなくなります。連続する整数またはfor ... in / for ... ofループを使用するだけです。

私の考えでは、整数以外の数値をループしようとするほとんどの場合は次のようになります。数値の問題とはまったく関係のない他の理由、コードの編成方法が異なる理由があります。（すべての場合ではありません。いくつかの数学アルゴリズムは、非整数値のループに関して最もきれいに表現されると想像できます。）

1つのコードの匂いは、そのようなループでフロートを使用しています。

ループはさまざまな方法で実行できますが、99.9％のケースでは、1を増やす必要があります。そうしないと、ジュニア開発者だけでなく、間違いなく混乱が生じます。

はい、あなたはこれを避けたいです。

浮動小数点数は、疑うことを知らないプログラマーにとって最大のtrapの1つです（私の経験では、ほぼ全員を意味します）。浮動小数点の等価性テストに依存することから、お金を浮動小数点として表現することまで、それはすべて大きな泥沼です。1つのフロートを他のフロートに加算することは、最大の違反者の1つです。このようなことについての科学文献の全巻があります。

必要な場所で実際の数学的計算を行うとき（三角法、関数グラフのプロットなど）、浮動小数点数を適切な場所で正確に使用し、シリアル操作を行うときは十分に注意してください。平等はすぐに実現します。IEEE規格でどの特定の数値セットが正確であるかについての知識は非常に不可解であり、私はそれに頼ることはありません。

あなたのケースでは、そこになり、マーフィーズ法により、経営陣はあなたが0.0、0.5、1.0 ...しかし、0.0、0.4、0.8 ...または何を持っていたいポイントを来ります。あなたはすぐに退屈し、あなたのジュニアプログラマー（またはあなた自身）は、問題が見つかるまで長時間、ハードにデバッグします。

あなたの特定のコードでは、実際に整数ループ変数があります。i連続番号ではなく、thボタンを表します。

そして、私はおそらく、余分な明確化のために、書きませんi/2が、i*0.5それは豊富で何が起こっているのかを明確にしています。

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';
    }
}

注：コメントで指摘されているように、JavaScriptには実際には整数用の個別の型はありません。ただし、最大15桁の整数は正確/安全であることが保証されています（https://www.ecma-international.org/ecma-262/6.0/#sec-number.max_safe_integerを参照）。したがって、このような引数については（ "is it整数または非整数で動作するより混乱しやすい/エラーが発生する可能性があります」）毎日の使用（ループ、画面座​​標、配列インデックスなど）ではNumber、JavaScriptとして表される整数値に驚くことはありません。

どちらの提案も良いとは思いません。代わりに、最大値と間隔に基づいてボタンの数に変数を導入します。次に、ボタン自体のインデックスをループするのに十分簡単です。

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;
    }
}

コードは増えるかもしれませんが、読みやすく堅牢です。

ループカウンターを値として使用するのではなく、表示している値を計算することにより、全体を回避できます。

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';
    }
}

浮動小数点演算は遅く、整数演算は速いため、浮動小数点を使用する場合、整数を使用できる場所で不必要に使用することはありません。多少の誤差はありますが、浮動小数点数、定数であっても近似値であると常に考えると便利です。デバッグ中に、ネイティブの浮動小数点数を、各数値をポイントではなく範囲として扱うプラス/マイナスの浮動小数点オブジェクトに置き換えると非常に便利です。そうすれば、各算術演算の後に進行する不正確さを発見できます。したがって、「1.5」は「1.45から1.55の間の数字」と見なされ、「1.50」は「1.495から1.505の間の数字」と見なされます。