Чи порівняння рівності чисел з плавкою вводить в оману молодших розробників, навіть якщо в моєму випадку не виникає помилка округлення?

Наприклад, я хочу показати список кнопок від 0,0,5, ... 5, який переходить на кожні 0,5. Для цього я використовую цикл і мають інший колір на кнопці 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';
    }
}

З одного боку, оригінальний код для мене більш простий і передовий. Але є одне, що я розглядаю: чи == STANDARD_LINE вводить в оману молодших товаришів по команді? Чи приховує той факт, що числа з плаваючою комою можуть мати помилки округлення? Прочитавши коментарі до цієї публікації:

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

здається, що багато розробників не знають, які цифри з плаваючою точністю є точними. Чи слід уникати порівнянь рівності чисел з плаваючими числами, навіть якщо це є дійсним у моєму випадку? Або я над цим замислююся?

Я завжди уникав би послідовних операцій з плаваючою комою, якщо модель, яку я обчислюю, не вимагає від них. Арифметика з плаваючою комою для більшості неінтуїтивна і є основним джерелом помилок. А розповідати про випадки, коли це спричиняє помилки, від тих, де цього немає, - це ще більш тонка відмінність!

Тому використання поплавців у якості лічильників циклу - це дефект, який очікує, і це потребує хоча б жирного коментаря, що пояснює, чому тут добре використовувати 0,5, і що це залежить від конкретного числового значення. У цей момент переписування коду, щоб уникнути плаваючих лічильників, ймовірно, буде більш читабельним варіантом. І читабельність - це поруч правильність в ієрархії професійних вимог.

Як правило, петлі слід писати так, щоб думати про те, щоб зробити щось n разів. Якщо ви використовуєте індекси з плаваючою комою, це вже не питання робити щось n разів, а працювати, поки умова не буде виконана. Якщо ця умова дуже схожа на ту, i<nщо очікує так багато програмістів, то, схоже, код виконує одне, коли він насправді робить інше, що може бути легко неправильно трактовано програмістами, які скидають код.

Це дещо суб'єктивно, але, на мою скромну думку, якщо ви можете переписати цикл, щоб використовувати цілий індекс для циклу фіксовану кількість разів, ви повинні зробити це. Тож розглянемо таку альтернативу:

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 до 5,0. Чи слід? Схоже, це рішення інтерфейсу користувача, яке може легко змінитись (наприклад, можливо, ви хочете, щоб розриви між наявними ширинами зростали, як ширини. 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/3, яку ви, мабуть, не хотіли б відображати як 0,33333333333333 чи будь-яку іншу. Або, можливо, ви хочете побачити "1,0" замість "1" для узгодженості з "1,5" .)

Усі вони відчувають мене як прояви єдиної слабкості, яка є свого роду змішуванням шарів. Ці числа з плаваючою комою є частиною внутрішньої логіки програмного забезпечення. Текст, показаний на кнопках, є частиною інтерфейсу користувача. Вони повинні бути більш відокремленими, ніж тут у коді. Поняття на кшталт "який із них є типовим, який слід виділити?" є питаннями інтерфейсу користувача, і вони, ймовірно, не повинні прив'язуватися до цих значень з плаваючою комою. І ваша петля тут справді (або принаймні має бути) петлею над кнопками , а не за шириною рядків . Написане таким чином, спокуса використовувати змінну циклу, що приймає не цілі значення, ви просто зникнете: ви просто використовуєте послідовні цілі числа або для ... в / для ... циклу.

Я відчуваю, що більшість випадків, коли можна спокуситися переходити на не цілі числа, виглядають так: є й інші причини, абсолютно не пов'язані з числовими питаннями, чому код слід організувати інакше. (Не у всіх випадках; я можу уявити, що деякі математичні алгоритми можуть бути найбільш чітко виражені в циклі над не цілими значеннями.)

Один кодовий запах - це використання поплавків у циклі.

Цикли можуть бути зроблені багатьма способами, але в 99,9% випадків ви повинні дотримуватися приросту в 1 або, безумовно, буде плутанина не тільки молодших розробників.

Так, ви хочете цього уникнути.

Числа з плаваючою комою є однією з найбільших пасток для підозрілого програміста (це, на мій досвід, майже всіх). Залежно від тестів на рівність плаваючої крапки, до представлення грошей як плаваючої точки, все це велика трясовина. Додавання одного поплавця на іншого є одним з найбільших порушників. Існують цілі томи наукової літератури про подібні речі.

Використовуйте номери з плаваючою комою саме там, де вони доречні, наприклад, роблячи фактичні математичні розрахунки там, де вони вам потрібні (наприклад, тригонометрія, графіки графіків функцій тощо), і будьте дуже обережні, виконуючи послідовні операції. Рівність є правою. Знання про те, який конкретний набір чисел точно відповідає стандартам IEEE, є дуже прихованим, і я ніколи від цього не залежу.

У вашому випадку, буде , по Murphys закону, настане момент , коли керівництво хоче , щоб ви не маєте 0,0, 0,5, 1,0 ... 0,0 , але, 0,4, 0,8 ... або що - то; ви будете негайно навантажені, і ваш молодший програміст (або ви самі) будете налагоджувати довго і наполегливо, поки не знайдете проблему.

У вашому конкретному коді я б дійсно мала цілу змінну циклу. Він представляє ith кнопку, а не номер, що працює.

І я, мабуть, задля додаткової ясності не писав, 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 ), отже, для таких аргументів ("це більш заплутаною / помилкою, схильною до роботи з цілими чи не цілими числами)) це доцільно близько до того, щоб мати окремий тип "по духу"; при щоденному використанні (циклі, координати екрану, індекси масиву тощо) не буде сюрпризів із цілими числами, представленими 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,455 і 1,55".