Nilai NaN (Not a Number) dalam standar floating-point IEEE-754 kerap menjadi sumber keanehan dalam desain bahasa pemrograman. Dua studi kasus terbaru menunjukkan bagaimana asumsi dasar yang melanggar sifat NaN dapat menyebabkan perilaku tak terduga pada Python dan Lua, dua bahasa yang sangat populer di kalangan pengembang perangkat lunak global.
Standar IEEE-754 mendefinisikan NaN sebagai nilai khusus yang muncul ketika sebuah operasi matematika tidak menghasilkan angka yang valid, seperti pembagian nol dengan nol (0/0). Karena sifatnya yang unik, NaN memiliki aturan perbandingan yang berbeda: ia tidak akan pernah sama dengan dirinya sendiri maupun dengan NaN lainnya. Asumsi bahwa sebuah objek selalu setara dengan dirinya sendiri (refleksivitas) adalah fondasi logika yang digunakan oleh hampir semua bahasa pemrograman modern.
Kasus pertama ditemukan dalam mekanisme perbandingan daftar (list) di Python. Secara teori, ekspresi nan == nan akan mengembalikan nilai False. Namun, ketika dua daftar yang berisi NaN dibandingkan, hasilnya justru True. Hal ini terjadi karena Python menerapkan optimasi dengan memeriksa identitas objek terlebih dahulu sebelum mengecek nilai kesetaraannya.
Jika identitasnya sama, interpreter menganggap nilainya juga sama tanpa melakukan pengecekan lebih lanjut. Manual referensi Python sebenarnya mencatat bahwa objek yang memiliki perilaku perbandingan kustom harus mengikuti aturan konsistensi, di mana x is y harus menyiratkan x == y. NaN secara eksplisit memecahkan aturan tersebut. Pengamat menyatakan bahwa ini bukan berarti desain Python salah, melainkan contoh nyata bagaimana optimasi yang aman untuk mayoritas kasus bisa memberikan perilaku aneh ketika bertemu dengan pengecualian seperti NaN.
Di sisi lain, kasus kedua muncul dari Lua, bahasa skrip yang kerap digunakan untuk pengembangan game dan sistem tertanam. Perulangan angka (numerical for-loop) di Lua dirancang dengan format for i = awal, batas, langkah. Ketika NaN dimasukkan sebagai nilai awal atau batas, interpreter Lua (versi implementasi referensi PUC-Rio) menunjukkan hasil yang sangat kontraintuitif.
Percobaan menunjukkan bahwa perintah for i = 0/0, 10 hanya dieksekusi sekali dan mencetak NaN. Begitu pula dengan for i = 0/0, 0/0. Sebaliknya, for i = 1, 10, 0/0 tidak pernah dieksekusi, sementara for i = 10, 1, 0/0 justru berjalan sekali dan mencetak angka 10.0. Semua hasil ini bertentangan dengan intuisi logika pemrograman standar yang diajarkan kepada mahasiswa ilmu komputer.
Penelusuran lebih dalam mengungkap bahwa mekanisme perulangan Lua memeriksa kondisi awal dengan operator batas < awal, namun iterasi selanjutnya menggunakan indeks <= batas. Karena NaN gagal dalam semua bentuk perbandingan, ia lulus pada tes awal tertentu namun langsung gagal pada pengecekan berikutnya. Selain itu, NaN selalu diperlakukan sebagai nilai negatif ketika dipakai sebagai langkah (step), karena pengecekan 0 < langkah akan selalu bernilai False untuk NaN, meski pengembang menggunakan fungsi absolut.
Observasi terhadap kode sumber Lua (PUC-Rio) membuktikan bahwa perilaku aneh ini tidak didokumentasikan, yang merupakan kelalaian dalam desain interpreter. Menggunakan NaN menyebabkan operator perbandingan spesifik yang dipakai oleh implementasi bocor ke dalam perilaku interpreter. Lua sebenarnya sudah menampilkan error ketika angka nol digunakan sebagai langkah perulangan, sehingga wajar jika pengembang mengharapkan perlakuan serupa untuk NaN.
Di Indonesia, fenomena ini memiliki relevansi praktis yang tinggi. Python merupakan tulang punggung ekosistem kecerdasan buatan dan analitik data di berbagai perusahaan rintisan (startup) lokal, sedangkan Lua mendominasi pembuatan game mobile buatan studio domestik. Bug yang bersumber dari NaN sering kali luput dari pengujian otomatis karena sifatnya yang tidak konsisten, yang pada akhirnya dapat merusak algoritma rekomendasi atau menyebabkan aplikasi berhenti mendadak di perangkat pengguna.
Chris Siebenmann sebelumnya pernah mencatat keanehan serupa saat NaN dipakai sebagai kunci pemetaan (map keys) pada bahasa Go. Jika digabungkan, setidaknya terdapat tiga studi kasus besar yang membuktikan betapa sulitnya mengakomodasi NaN dalam paradigma pemrograman konvensional. Bahasa pemrograman dirancang dengan asumsi logika matematika yang stabil, dan kehadiran NaN meruntuhkan asumsi tersebut secara tersembunyi.
Penyelesaian teknis yang paling rasional adalah dengan secara tegas memeriksa dan menolak NaN dalam struktur alur kendali tertentu, seperti perulangan. Tanpa intervensi pada tingkat interpreter, pengembang perangkat lunak dituntut untuk membangun lapisan validasi manual yang lebih ketat di setiap fungsi matematika. Komunitas inti bahasa pemrograman juga perlu merilis tambalan (patch) keamanan agar perilaku tak terduga ini tidak dieksploitasi sebagai celah kerentanan.
Ke depannya, komunitas pengembang di Tanah Air perlu meningkatkan literasi mengenai batasan standar IEEE-754 agar kualitas perangkat lunak yang dihasilkan lebih tangguh terhadap anomali data. Pendidikan pemrograman di universitas-universitas Indonesia juga harus mulai menekankan penanganan kasus batas (edge cases) seperti NaN, bukan sekadar mengajarkan sintaks dasar. Kesadaran ini akan meminimalisir kerugian operasional yang disebabkan oleh kegagalan sistem tak terduga.