round(1234, -2)<\/td> zaokr\u0105glenie do setek<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nW wielu j\u0119zykach programowania parametr ujemny oznacza w\u0142a\u015bnie zaokr\u0105glanie \u201ew lewo\u201d, czyli do dziesi\u0105tek, setek lub tysi\u0119cy.<\/p>\n\n\n\n
To rozr\u00f3\u017cnienie jest cz\u0119sto pomijane, a p\u00f3\u017aniej prowadzi do b\u0142\u0119d\u00f3w trudnych do znalezienia.<\/p>\n\n\n\n
Zaokr\u0105glenie zmienia warto\u015b\u0107 u\u017cywan\u0105 dalej w programie.<\/p>\n\n\n\n
Formatowanie zmienia tylko spos\u00f3b prezentacji.<\/p>\n\n\n\n
Je\u017celi w Pythonie zapisze si\u0119 liczb\u0119:<\/p>\n\n\n\nKod<\/th> Efekt<\/th><\/tr><\/thead> x = 12.3456<\/code><\/td>warto\u015b\u0107 pe\u0142na<\/td><\/tr> print(f\"{x:.2f}\")<\/code><\/td>na ekranie: 12.35<\/td><\/tr> print(x)<\/code><\/td>nadal: 12.3456<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nProgramista mo\u017ce b\u0142\u0119dnie uzna\u0107, \u017ce warto\u015b\u0107 zosta\u0142a zmieniona, podczas gdy jedynie jej wy\u015bwietlenie zosta\u0142o skr\u00f3cone.<\/p>\n\n\n\n
W systemach finansowych to bardzo niebezpieczne. Raport mo\u017ce pokazywa\u0107 12,35, ale dalsze obliczenia wykonywane s\u0105 na 12,3456 i suma ko\u0144cowa przestaje si\u0119 zgadza\u0107.<\/p>\n\n\n\n
Dlatego trzeba \u015bwiadomie rozdziela\u0107:<\/p>\n\n\n\n
\nlogik\u0119 oblicze\u0144<\/li>\n\n\n\n spos\u00f3b prezentacji danych<\/li>\n<\/ul>\n\n\n\nTo nie jest detal stylistyczny, tylko kwestia poprawno\u015bci systemu.<\/p>\n\n\n\n
Round \u2013 zaokr\u0105gla liczb\u0119 do okre\u015blonej liczby miejsc po przecinku w C, C++ i Python w troch\u0119 inny spos\u00f3b<\/h2>\n\n\n\n R\u00f3\u017cne j\u0119zyki maj\u0105 podobn\u0105 ide\u0119, ale szczeg\u00f3\u0142y implementacji nie s\u0105 identyczne. Szczeg\u00f3lnie wa\u017cne s\u0105 liczby graniczne oraz spos\u00f3b traktowania warto\u015bci ko\u0144cz\u0105cych si\u0119 na .5.<\/p>\n\n\n\n
Python<\/h3>\n\n\n\n Funkcja round()<\/code> jest wbudowana i bardzo cz\u0119sto u\u017cywana.<\/p>\n\n\n\nPrzyk\u0142ad<\/th> Kod<\/th><\/tr><\/thead> do liczby ca\u0142kowitej<\/td> print(round(7.8))<\/code><\/td><\/tr>do 2 miejsc<\/td> print(round(3.14159, 2))<\/code><\/td><\/tr>do setek<\/td> print(round(1548, -2))<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWynik<\/h3>\n\n\n\nWyra\u017cenie<\/th> Wynik<\/th><\/tr><\/thead> round(7.8)<\/code><\/td>8<\/td><\/tr> round(3.14159, 2)<\/code><\/td>3.14<\/td><\/tr> round(1548, -2)<\/code><\/td>1500<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nPython stosuje tzw. banker’s rounding w niekt\u00f3rych przypadkach:<\/p>\n\n\n\nKod<\/th> Wynik<\/th><\/tr><\/thead> round(2.5)<\/code><\/td>2<\/td><\/tr> round(3.5)<\/code><\/td>4<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTo zaskakuje pocz\u0105tkuj\u0105cych, ale ma sens statystyczny przy du\u017cej liczbie operacji finansowych.<\/p>\n\n\n\n
C<\/h3>\n\n\n\n W j\u0119zyku C najcz\u0119\u015bciej u\u017cywa si\u0119 funkcji round()<\/code> z biblioteki math.h<\/code>.<\/p>\n\n\n\nPrzyk\u0142ad<\/th> Kod<\/th><\/tr><\/thead> zaokr\u0105glenie<\/td> double x = 3.76;<\/code>printf(\"%.0f\", round(x));<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nC++<\/h3>\n\n\n\n W C++ sytuacja jest podobna, zwykle z u\u017cyciem <cmath><\/code>.<\/p>\n\n\n\nPrzyk\u0142ad<\/th> Kod<\/th><\/tr><\/thead> zaokr\u0105glenie<\/td> double x = 8.49;<\/code>cout << round(x);<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nR\u0119czne zaokr\u0105glenie przez mno\u017cenie i dzielenie<\/h3>\n\n\n\n Cz\u0119sto spotykany szkolny zapis:<\/p>\n\n\n\nKod C++<\/th> Dzia\u0142anie<\/th><\/tr><\/thead> double x = 3.14159;<\/code>x = round(x * 100) \/ 100;<\/code><\/td>2 miejsca po przecinku<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nMechanizm:<\/p>\n\n\n\n
\nmno\u017cenie przez 100<\/li>\n\n\n\n zaokr\u0105glenie do ca\u0142kowitej<\/li>\n\n\n\n podzia\u0142 przez 100<\/li>\n<\/ol>\n\n\n\nTo rozwi\u0105zanie jest proste i czytelne, ale przy bardzo du\u017cych liczbach mo\u017ce generowa\u0107 b\u0142\u0119dy precyzji.<\/p>\n\n\n\n
Problem liczb zmiennoprzecinkowych i sytuacje, w kt\u00f3rych wynik wygl\u0105da na b\u0142\u0119dny<\/h2>\n\n\n\n Komputer nie przechowuje wi\u0119kszo\u015bci liczb dziesi\u0119tnych dok\u0142adnie. Dzia\u0142a na reprezentacji binarnej, podobnie jak u\u0142amek 1\/3 w systemie dziesi\u0119tnym nie ma sko\u0144czonego rozwini\u0119cia.<\/p>\n\n\n\n
Przyk\u0142ad:<\/p>\n\n\n\nKod Python<\/th> Wynik<\/th><\/tr><\/thead> print(0.1 + 0.2)<\/code><\/td>0.30000000000000004<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTo nie jest b\u0142\u0105d funkcji, tylko spos\u00f3b reprezentacji.<\/p>\n\n\n\n
Tak samo:<\/p>\n\n\n\nKod Python<\/th> Wynik<\/th><\/tr><\/thead> print(round(2.675, 2))<\/code><\/td>2.67<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nU\u017cytkownik oczekuje 2.68, ale komputer operuje na warto\u015bci nieco mniejszej ni\u017c 2.675.<\/p>\n\n\n\n
W ksi\u0119gowo\u015bci i systemach p\u0142atno\u015bci cz\u0119sto stosuje si\u0119 typy dziesi\u0119tne zamiast zwyk\u0142ych float<\/code> lub double<\/code>, w\u0142a\u015bnie po to, \u017ceby unikn\u0105\u0107 takich sytuacji.<\/p>\n\n\n\nW Pythonie u\u017cywa si\u0119 wtedy modu\u0142u decimal<\/code>.<\/p>\n\n\n\nPrzyk\u0142ad<\/th> Kod<\/th><\/tr><\/thead> dok\u0142adniejsze obliczenia<\/td> from decimal import Decimal<\/code>x = Decimal(\"2.675\")<\/code>print(x)<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWarto\u015b\u0107 zapisana jako tekst daje wi\u0119ksz\u0105 kontrol\u0119 nad precyzj\u0105.<\/p>\n\n\n\n
Round \u2013 zaokr\u0105gla liczb\u0119 do okre\u015blonej liczby miejsc po przecinku ale w finansach obowi\u0105zuj\u0105 dodatkowe zasady<\/h2>\n\n\n\n W systemach sprzeda\u017cy i ksi\u0119gowo\u015bci nie wystarczy u\u017cy\u0107 funkcji i uzna\u0107 temat za zamkni\u0119ty.<\/p>\n\n\n\n
Trzeba odpowiedzie\u0107 na kilka pyta\u0144:<\/p>\n\n\n\n
\nczy zaokr\u0105glamy ka\u017cd\u0105 pozycj\u0119 osobno<\/li>\n\n\n\n czy najpierw sumujemy, a potem zaokr\u0105glamy<\/li>\n\n\n\n czy VAT liczymy od pozycji czy od ca\u0142o\u015bci<\/li>\n\n\n\n czy stosujemy standard handlowy czy bankowy<\/li>\n<\/ul>\n\n\n\nDwie poprawne implementacje mog\u0105 da\u0107 r\u00f3\u017cne wyniki ko\u0144cowe.<\/p>\n\n\n\n
Przyk\u0142ad:<\/p>\n\n\n\nPozycje<\/th> Wariant A<\/th> Wariant B<\/th><\/tr><\/thead> 3 \u00d7 3,335<\/td> ka\u017cda pozycja \u2192 3,34<\/td> suma \u2192 10,005<\/td><\/tr> wynik ko\u0144cowy<\/td> 10,02<\/td> 10,01<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nR\u00f3\u017cnica jednego grosza w pojedynczym dokumencie wydaje si\u0119 ma\u0142a, ale przy 50 000 transakcji miesi\u0119cznie oznacza realny problem rozliczeniowy.<\/p>\n\n\n\n
Dlatego system powinien mie\u0107 jasno opisan\u0105 polityk\u0119 zaokr\u0105gle\u0144, a nie \u201edomy\u015blne round()\u201d.<\/p>\n\n\n\n
To jeden z tych obszar\u00f3w, gdzie programista traci najwi\u0119cej czasu na poprawki po wdro\u017ceniu.<\/p>\n\n\n\n
Najcz\u0119stsze b\u0142\u0119dy praktyczne i miejsca, gdzie zaokr\u0105glanie psuje wynik ko\u0144cowy<\/h2>\n\n\n\n Pierwszy b\u0142\u0105d to zbyt wczesne zaokr\u0105glanie.<\/p>\n\n\n\n
Je\u017celi po ka\u017cdym kroku oblicze\u0144 obcinamy wynik do dw\u00f3ch miejsc po przecinku, b\u0142\u0105d narasta.<\/p>\n\n\n\n
Lepsza praktyka:<\/p>\n\n\n\n
\nliczy\u0107 na pe\u0142nej precyzji<\/li>\n\n\n\n zaokr\u0105gla\u0107 dopiero na ko\u0144cu<\/li>\n<\/ul>\n\n\n\nDrugi b\u0142\u0105d to por\u00f3wnywanie liczb zmiennoprzecinkowych operatorem ==<\/code>.<\/p>\n\n\n\nZ\u0142y zapis<\/th> Lepszy zapis<\/th><\/tr><\/thead> if x == 0.3<\/code><\/td>if abs(x - 0.3) < 0.0001<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTrzeci b\u0142\u0105d to mieszanie prezentacji z logik\u0105.<\/p>\n\n\n\n
Formatowanie tekstowe nie powinno decydowa\u0107 o poprawno\u015bci oblicze\u0144.<\/p>\n\n\n\n
Czwarty b\u0142\u0105d to brak test\u00f3w granicznych:<\/p>\n\n\n\n