Чи слід уникати <= і> = під час використання цілих чисел, наприклад у циклі For? [зачинено]

Я пояснив своїм студентам, що тестування, що відповідає рівним тестуванню, не є надійним для плаваючих змінних, але добре для цілих чисел. У підручнику, який я використовую, сказано, що легше читати> і <, ніж> = і <=. Я певною мірою згоден, але в циклі For? Чи не чіткіше, щоб цикл вказав початкові та кінцеві значення?

Чи пропускаю я щось, на що автор підручника правильний?

Інший приклад - тести Range, такі як:

якщо бал> 89 бал = 'А',
інше, якщо бал> 79 бал = 'В' ...

Чому б просто не сказати: якщо оцінка> = 90?

У мовах програмування з фігурними дужками з масивами , що базуються на нулі , прийнято писати forпетлі так:

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

Це обходить всі елементи масиву, і це, безумовно, найпоширеніший випадок. Це дозволяє уникнути використання <=або >=.

Єдиний час, коли б це колись довелося змінити, це коли вам потрібно пропустити перший або останній елемент, або пройти його в протилежному напрямку, або пройти його від іншої початкової точки або до іншої кінцевої точки.

Для колекцій мовами, які підтримують ітератори, частіше це бачити:

foreach (var item in list) { }

Що цілком уникає порівнянь.

Якщо ви шукаєте жорстке і швидке правило щодо використання <=vs <, не існує жодного; використовуйте те, що найкраще виражає ваші наміри. Якщо ваш код повинен виражати поняття "Менше або рівне 55 миль на годину", то йому потрібно сказати <=, ні <.

Відповідати на ваше запитання щодо діапазонів оцінок >= 90має більше сенсу, оскільки 90 - фактичне граничне значення, а не 89.

Це не має значення.

Але заради аргументу, давайте розглянемо два варіанти: a > bпроти a >= b.

Тримайся! Це не рівнозначно!
OK, потім a >= b -1проти a > bабо a > bпроти a >= b +1.

Гм, a >bі a >= bобидва виглядають краще, ніж a >= b - 1і a >= b +1. Що це все- 1таки? Тому я заперечую, що будь-яка користь від того, >щоб замість цього >=чи навпаки, усувається за рахунок додавання чи віднімання випадкових 1s.

Але що робити, якщо це число? Краще сказати a > 7чи a >= 6? Почекайте секунду. Чи ми серйозно сперечаємось, чи краще використовувати >vs >=і ігнорувати жорстко кодовані змінні? Тож справді стає питанням, чи a > DAYS_OF_WEEKкращий за a >= DAYS_OF_WEEK_MINUS_ONE... чи це a > NUMBER_OF_LEGS_IN_INSECT_PLUS_ONEпроти a >= NUMBER_OF_LEGS_IN_INSECT? І ми повертаємось до додавання / віднімання 1s, лише цього разу в назвах змінних. Або може бути дебатом, якщо найкраще використовувати поріг, ліміт, максимум.

І, схоже, немає загального правила: це залежить від того, що порівнюється

Але насправді в коді є кращі важливіші речі та набагато більш об'єктивні та розумні вказівки (наприклад, обмеження символів X на рядок), які все ще мають винятки.

Обчислювально немає різниці у вартості при використанні <або >порівнянні з <=або >=. Він обчислюється однаково швидко.

Однак більшість циклів буде рахувати від 0 (адже багато мов використовують 0 індексації для своїх масивів). Отже, канонічне для циклу в цих мовах є

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

якщо це зробити з <=символом a , знадобиться, щоб ви десь додали -1, щоб уникнути помилки, що не виходить

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

або

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

Звичайно, якщо мова використовує індексацію на основі 1, ви б використовували <= як обмежувальну умову.

Ключовим є те, що значення, виражені в умові, є значеннями, описаними в описі проблеми. Чистіше читати

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

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

}

на напіввідкритий інтервал, ніж

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

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

}

і треба робити математику, щоб знати, що між 19 і 20 немає можливого значення

Я б сказав, що справа не в тому, чи слід використовувати ви> або> =. Сенс у тому, щоб використовувати все, що дозволяє писати експресивний код.

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

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

Це спосіб більш виразний, ніж

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

В інших випадках кращий інший спосіб:

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

Набагато краще, ніж

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

Вибачте, будь ласка, "примітивну одержимість". Очевидно, ви б хотіли використовувати тут швидкість і гроші, відповідно, але я їх опустив для стислості. Сенс у тому: Використовуйте більш коротку версію, яка дозволяє зосередитись на бізнес-проблемі, яку ви хочете вирішити.

Як ви зазначали у своєму запитанні, тестування рівності на змінних float не є надійним.

Те саме стосується і <=та >=.

Однак не існує такої проблеми надійності для цілих типів. На мою думку, автор висловлював свою думку щодо того, що можна читати.

Погоджуєтесь ви з ним чи ні, звичайно, ваша думка.

Кожен з відносин <, <=, >=, >а також == і !=мають приклади використання для порівняння двох значень з плаваючою точкою. Кожен має конкретне значення і слід вибрати відповідний.

Я наведу приклади для тих випадків, коли ви хочете саме цього оператора для кожного з них. (Однак пам’ятайте про NaNs.)

• У вас є дорога чиста функція, fяка приймає вхідне значення з плаваючою комою. Для того , щоб прискорити обчислення, ви вирішили додати кеш найостанніших обчислених значень, тобто, відображення таблиці пошуку xв f(x). Ви дійсно хочете використовувати ==для порівняння аргументів.
• Ви хочете знати, чи можете ви осмислено розділити на якесь число x? Ви, мабуть, хочете використовувати x != 0.0.
• Ви хочете знати, чи є значення xв одиничному інтервалі? (x >= 0.0) && (x < 1.0)- правильна умова.
• Ви обчислили детермінант dматриці і хочете сказати, чи є вона позитивною? Немає жодної причини використовувати інше, окрім d > 0.0.
• Ви хочете знати, чи _{n = 1,…, ∞} n ^−α розходиться? Я б тестував на alpha <= 1.0.

Математика з плаваючою комою (загалом) не є точною. Але це не означає, що ви повинні боятися цього, ставитися до цього як до магії, і, звичайно, не завжди трактуйте дві величини з плаваючою комою, рівними, якщо вони знаходяться в межах 1.0E-10. Це дійсно порушить вашу математику і спричинить все дивні речі.

• Наприклад, якщо ви використовуєте нечітке порівняння з вищезазначеним кешем, ви введете веселі помилки. Але ще гірше, що функція більше не буде чистою, а помилка залежить від раніше обчислених результатів!
• Так, навіть якщо x != 0.0і yє кінцевим значенням з плаваючою комою, воно y / xне повинно бути кінцевим. Але може бути доречним знати, чи y / xне є це кінцевим через переповнення або через те, що операція не була математично чітко визначена для початку.
• Якщо у вас є функція, яка є передумовою того, що вхідний параметр xповинен знаходитися в одиничному інтервалі [0, 1), я був би дуже засмучений, якби він викликав збій у твердженні при виклику з x == 0.0або x == 1.0 - 1.0E-14.
• Детермінант, який ви обчислили, може бути неточним. Але якщо ви збираєтесь робити вигляд, що матриця не є позитивно визначеною, коли обчислена детермінанта 1.0E-30, нічого не виходить. Все, що ви робили, збільшувало ймовірність дати неправильну відповідь.
• Так, на ваш аргумент alphaможуть вплинути помилки округлення, а тому alpha <= 1.0може бути істинним, навіть якщо справжнє математичне значення для виразу, яке alphaбуло обчислено, може бути справді більшим за 1. Але в цьому моменті ви нічого не могли б зробити з цього приводу.

Як завжди в інженерії програмного забезпечення, обробляйте помилки на відповідному рівні та обробляйте їх лише один раз. Якщо ви додасте помилки округлення на порядок 1.0E-10(це, мабуть, є магічним значенням більшості людей, я не знаю чому) щоразу, коли ви порівнюєте величини з плаваючою комою, незабаром ви будете мати помилки на порядок 1.0E+10…

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

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

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

Якщо цикл замість цього був записаний як:

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

тоді компілятор міг би припустити, що цикл ніколи не потребуватиме виконання більше n разів, і, таким чином, він зможе генерувати більш ефективний код.

Зауважте, що будь-яке переповнення підписаними типами може мати неприємні наслідки. Подано:

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

Компілятор може переписати це як:

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;

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