Pytanie 1
W przedstawionych funkcjonalnie równoważnych kodach źródłowych po przeprowadzeniu operacji w zmiennej b zostanie zapisany wynik:
| Python: | C++/C#/Java: |
x = 5.96; b = int(x); | double x = 5.96; int b = (int)x; |
A. 5.96
B. 596
C. 5
D. 6
W zadaniu można łatwo się pomylić, bo sposób działania rzutowania (czyli konwersji typu float/double na int) nie zawsze jest intuicyjny. Często spotykam się z błędnym przekonaniem, że taka operacja powinna albo zostawić część ułamkową, albo zaokrąglić liczbę, albo nawet przesunąć przecinek, jak w odpowiedzi 596 – co jest typowe przy interpretacji liczb całkowitych i dziesiętnych w innych kontekstach, ale nie tutaj. W rzeczywistości, podczas rzutowania liczby zmiennoprzecinkowej na typ całkowity, program po prostu odcina wszystko, co jest po przecinku, i zostawia tylko część całkowitą. To wynika bezpośrednio ze specyfikacji tych języków oraz z architektury komputerów (operacje na typach prostych). Przykład z 5.96: po rzutowaniu zostaje tylko 5, bo 0.96 nas nie interesuje – to jest eliminowane. Zaokrąglanie do 6, jak można by się spodziewać, jeśli ktoś myśli kategoriami matematycznymi, nie zachodzi – odcinanie nie bierze pod uwagę wartości po przecinku, tylko po prostu ją kasuje. Z kolei zapisanie 5.96 jako wyniku jest niemożliwe, bo typ int może przechowywać tylko liczby całkowite. Uważam, że najczęstszy błąd wynika właśnie z automatycznego założenia, że komputer zachowa się tak jak człowiek podczas zaokrąglania czy czytania liczb. W praktyce, kiedy potrzebujemy zaokrąglić liczbę w górę lub w dół, trzeba użyć funkcji takich jak round(), floor() czy ceil() (w Pythonie lub odpowiednich w innych językach). Rzutowanie na int to jedno z podstawowych, ale zdradliwych zachowań – z mojego punktu widzenia znajomość tego mechanizmu jest kluczowa, zwłaszcza przy pracy z indeksami, pętlami czy konwersją danych wejściowych z typów tekstowych na liczby. Podsumowując – rzutowanie float/double na int zawsze po prostu ucina część ułamkową, nie zaokrągla jej, nie interpretacją dziesiętną. To jest zgodne z dokumentacją języków programowania i standardami przemysłowymi.