Czy należy unikać <= i> = podczas używania liczb całkowitych, na przykład w pętli For? [Zamknięte]

Wyjaśniłem moim uczniom, że testowanie równe nie jest wiarygodne dla zmiennych zmiennoprzecinkowych, ale jest dobre dla liczb całkowitych. W podręczniku, którego używam, jest napisane, że łatwiej jest czytać> oraz <niż> = i <=. Zgadzam się do pewnego stopnia, ale w pętli For? Czy nie jest bardziej jasne, aby pętla określała wartości początkowe i końcowe?

Czy brakuje mi czegoś, co autor podręcznika ma rację?

Innym przykładem są testy zasięgu, takie jak:

jeśli wynik> 89 ocena = „A”
, jeśli wynik> 79 ocena = „B” ...

Dlaczego po prostu nie powiesz: jeśli wynik> = 90?

W kręconych językach programowania z tablicami zerowymi zwykle zapisuje się fortakie pętle:

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

Przechodzi przez wszystkie elementy w tablicy i jest zdecydowanie najczęstszym przypadkiem. Unika używania <=lub >=.

Jedyny moment, który musiałby to zmienić, to konieczność pominięcia pierwszego lub ostatniego elementu, przejścia w przeciwnym kierunku lub przejścia z innego punktu początkowego lub innego punktu końcowego.

W przypadku kolekcji w językach, które obsługują iteratory, częściej można to zobaczyć:

foreach (var item in list) { }

Co całkowicie eliminuje porównania.

Jeśli szukasz twardej i szybkiej reguły, kiedy użyć <=vs <, nie ma takiej; użyj tego, co najlepiej wyraża Twoją intencję. Jeśli twój kod musi wyrażać pojęcie „mniej niż lub równe 55 mil na godzinę”, to znaczy <=, że nie <.

>= 90Bardziej sensowne jest udzielenie odpowiedzi na pytanie dotyczące zakresów ocen , ponieważ 90 to rzeczywista wartość brzegowa, a nie 89.

To nie ma znaczenia

Ale ze względu na argument, przeanalizujmy dwie opcje: a > bvs a >= b.

Wytrzymać! To nie jest równoważne!
OK, a następnie a >= b -1vs a > blub a > bvs a >= b +1.

Hm, a >bi a >= boba wyglądają lepiej niż a >= b - 1i a >= b +1. Co to w ogóle 1jest? Argumentowałbym więc, że wszelkie korzyści z posiadania >zamiast >=lub odwrotnie są eliminowane przez dodawanie lub odejmowanie losowych liczb 1s.

Ale co jeśli to liczba? Czy lepiej powiedzieć a > 7czy a >= 6? Poczekaj sekundę. Czy poważnie spieramy się, czy lepiej używać >vs >=i ignorować zmienne zakodowane na stałe? Tak naprawdę staje się pytanie, czy a > DAYS_OF_WEEKjest lepsze niż a >= DAYS_OF_WEEK_MINUS_ONE... czy to jest a > NUMBER_OF_LEGS_IN_INSECT_PLUS_ONEvs a >= NUMBER_OF_LEGS_IN_INSECT? Wróciliśmy do dodawania / odejmowania 1s, tylko tym razem w nazwach zmiennych. A może debatowanie, czy najlepiej zastosować próg, limit, maksimum.

I wygląda na to, że nie ma ogólnej zasady: zależy od tego, co jest porównywane

Ale tak naprawdę są o wiele ważniejsze rzeczy do poprawienia w kodzie i znacznie bardziej obiektywne i rozsądne wytyczne (np. Limit znaków X na linię), które wciąż mają wyjątki.

Obliczeniowo nie ma różnicy w kosztach przy użyciu <lub w >porównaniu do <=lub >=. Jest obliczany równie szybko.

Jednak większość pętli będzie liczyła od 0 (ponieważ wiele języków używa 0 indeksowania dla swoich tablic). Tak więc kanoniczna pętla for w tych językach jest

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

zrobienie tego za pomocą <=wymagałoby dodania gdzieś -1, aby uniknąć błędu off-by one

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

lub

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

Oczywiście, jeśli język używa indeksowania 1, wówczas użyłbyś <= jako warunku ograniczającego.

Kluczem jest to, że wartości wyrażone w warunku są tymi z opisu problemu. Czytanie jest łatwiejsze

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

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

}

na półotwartą przerwę niż

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

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

}

i muszę wykonać matematykę, aby wiedzieć, że nie ma żadnej możliwej wartości między 19 a 20

Powiedziałbym, że nie chodzi o to, czy powinieneś użyć> czy> =. Chodzi o to, aby użyć czegokolwiek, co pozwala pisać ekspresyjny kod.

Jeśli uznasz, że musisz dodać / odjąć jeden, rozważ użycie drugiego operatora. Uważam, że dobre rzeczy dzieją się, gdy zaczynasz od dobrego modelu swojej domeny. Wtedy logika się pisze.

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

To jest o wiele bardziej wyraziste niż

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

W innych przypadkach preferowany jest inny sposób:

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

O wiele lepszy niż

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

Proszę wybaczyć „prymitywną obsesję”. Oczywiście chciałbyś tutaj użyć odpowiednio typu Velocity i Money, ale pominąłem je dla zwięzłości. Chodzi o to: użyj wersji, która jest bardziej zwięzła i pozwala skupić się na problemie biznesowym, który chcesz rozwiązać.

Jak wskazałeś w swoim pytaniu, testowanie równości zmiennych zmiennoprzecinkowych nie jest wiarygodne.

To samo dotyczy <=i >=.

Jednak nie ma takiego problemu z niezawodnością dla typów całkowitych. Moim zdaniem autorka wyraziła swoją opinię na temat tego, co jest bardziej czytelne.

To, czy się z nim zgadzasz, jest oczywiście Twoją opinią.

Każdy z relacji <, <=, >=, >a także == i !=mają swoje przypadków użycia do porównywania dwóch wartości zmiennoprzecinkowych. Każdy ma określone znaczenie i należy wybrać odpowiedni.

Podam przykłady przypadków, w których chcesz dokładnie tego operatora dla każdego z nich. (Pamiętaj jednak o NaN).

• Masz drogą czystą funkcję, fktóra przyjmuje zmiennoprzecinkową wartość jako dane wejściowe. Aby przyspieszyć obliczenia, zdecydujesz się dodać cache ostatnio obliczonych wartości, czyli odwzorowanie tabeli odnośników xdo f(x). Naprawdę będziesz chciał użyć ==do porównania argumentów.
• Chcesz wiedzieć, czy możesz znacznie podzielić przez liczbę x? Prawdopodobnie chcesz użyć x != 0.0.
• Chcesz wiedzieć, czy wartość xmieści się w przedziale jednostkowym? (x >= 0.0) && (x < 1.0)jest prawidłowy warunek.
• Obliczyłeś wyznacznik dmacierzy i chcesz powiedzieć, czy jest ona pozytywnie określona? Nie ma powodu, aby używać niczego innego d > 0.0.
• Chcesz wiedzieć, czy Σ _{n = 1,…, ∞} n ^{−α jest} rozbieżna? Przetestowałbym alpha <= 1.0.

Matematyka zmiennoprzecinkowa (ogólnie) nie jest dokładna. Ale to nie znaczy, że powinieneś się go bać, traktować go jak magię, a na pewno nie zawsze traktować dwie zmiennoprzecinkowe wielkości, jeśli są w środku 1.0E-10. Takie postępowanie naprawdę złamie Twoją matematykę i spowoduje, że wydarzy się wiele dziwnych rzeczy.

• Na przykład, jeśli użyjesz rozmytego porównania ze wspomnianą wyżej pamięcią podręczną, wprowadzisz zabawne błędy. Co gorsza, funkcja nie będzie już czysta, a błąd zależy od wcześniej obliczonych wyników!
• Tak, nawet jeśli x != 0.0i yjest skończoną wartością zmiennoprzecinkową, y / xnie musi być skończony. Warto jednak wiedzieć, czy y / xnie jest ona skończona z powodu przepełnienia, czy dlatego, że operacja nie była matematycznie dobrze zdefiniowana na początek.
• Jeśli masz funkcję, która ma warunek wstępny, że parametr wejściowy xmusi znajdować się w przedziale jednostkowym [0, 1), byłbym naprawdę zdenerwowany, gdyby wywołał błąd potwierdzenia podczas wywołania za pomocą x == 0.0lub x == 1.0 - 1.0E-14.
• Wyznaczone przez ciebie wyznaczniki mogą być niedokładne. Ale jeśli zamierzasz udawać, że macierz nie jest pozytywnie określona, ​​gdy obliczona jest wyznacznik 1.0E-30, nic nie zyskuje. Wszystko, co zrobiłeś, to zwiększyło prawdopodobieństwo udzielenia złej odpowiedzi.
• Tak, twój argument alphamoże być obciążony błędami zaokrąglania i dlatego alpha <= 1.0może być prawdziwy, nawet jeśli prawdziwa wartość matematyczna wyrażenia alphazostała obliczona, może być naprawdę większa niż 1. Ale w tym momencie nie możesz nic na to poradzić.

Jak zawsze w inżynierii oprogramowania, obsługuj błędy na odpowiednim poziomie i usuwaj je tylko raz. Jeśli dodasz błędy zaokrąglania w kolejności 1.0E-10(wydaje się, że jest to magiczna wartość, której większość ludzi używa, nie wiem dlaczego) za każdym razem, gdy porównujesz liczby zmiennoprzecinkowe, wkrótce wystąpią błędy w kolejności 1.0E+10…

Rodzaj warunkowy stosowany w pętli może ograniczać rodzaje optymalizacji, które kompilator może wykonać, na lepsze lub na gorsze. Na przykład biorąc pod uwagę:

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

kompilator mógłby założyć, że powyższy warunek powinien spowodować zakończenie pętli po pętli n -tego przejścia, chyba że n może 65535, a pętla może wyjść w inny sposób niż przez przekroczenie n. Jeśli te warunki mają zastosowanie, kompilator musi wygenerować kod, który spowodowałby uruchomienie pętli, dopóki coś innego niż powyższy warunek nie spowoduje jej wyjścia.

Jeśli zamiast tego pętla została zapisana jako:

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

wtedy kompilator mógłby bezpiecznie założyć, że pętla nigdy nie będzie musiała wykonywać więcej niż n razy, a zatem może być w stanie wygenerować bardziej wydajny kod.

Pamiętaj, że każde przepełnienie podpisanymi typami może mieć paskudne konsekwencje. Dany:

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

Kompilator może przepisać to jako:

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;

Taka pętla zachowywałaby się identycznie jak oryginał, gdyby w obliczeniach nie wystąpiło przepełnienie, ale mogłaby działać wiecznie, nawet na platformach sprzętowych, gdzie przepełnienie liczb całkowitych normalnie miałoby spójną semantykę zawijania.