Hesap makinesi uygulaması mı? Bunu herkes yapabilir, değil mi?

"Hesap makinesi uygulaması mı? Bunu herkes yapabilir" → Aslında öyle değil

• Hesap makinesi, matematiksel ifadelerin sonucunu doğru göstermelidir ve bu sanıldığından çok daha zordur
• iOS hesap makinesinde (10^100) + 1 − (10^100) ifadesi hatalı biçimde 0 olarak hesaplanır
• Ancak Android doğru şekilde 1 sonucunu verir; bunu nasıl başardıkları ise gerçekten akıl almaz

Google ve Hans-J. Boehm

• Google, ünlü programcı Hans-J. Boehm'u işe aldı
• Boehm, C++'ta paylaşılan değişkenlerin anlam bilimini tanımlayan bir uzmandır
• Ama ona verilen görev beklenmedik biçimde bir hesap makinesi uygulaması geliştirmekti

Kayan noktanın sorunu

• Kayan noktalı sayılar, 0.3 veya 10^100 gibi değerleri tam olarak ifade edemez
• Yani kayan nokta temelli bir hesap makinesine güvenilemez
• Doğru hesaplama için farklı bir yaklaşım gerekir

Bignum ile çözüm

• Tam sayı hesaplama sorunu, Bignum (sınırsız tam sayı) kullanılarak çözülebilir
• Bignum, bellek boyutuna göre dinamik olarak genişleyen bir tam sayı türüdür
• (10^100) + 1 - (10^100) problemi Bignum kullanıldığında çözülür
• Ancak kesirli işlemler hâlâ çözülmüş olmaz

Kesirler ve cebirsel sayılar

• Kesirler (3/4 gibi değerler), pay ve paydayı Bignum ile saklayarak çözülebilir
• Ancak pi (π) veya karekök (√2) gibi irrasyonel sayılar ifade edilemez
• Boehm, polinom tabanlı bir gösterimi denedi
  • Örneğin √2, x² - 2 = 0 denklemiyle ifade edilebilir
  • Ancak π bu yöntemle de ifade edilemez

Yapıcı gerçek sayılar (Constructive Real Numbers)

• Boehm, "özyinelemeli gerçek aritmetiği (RRA)" kavramını araştırdı
• Kullanıcı istenen hassasiyeti girer ve değer bu hassasiyet içinde hesaplanır
• Örneğin π, 0.01 hata payı içinde ifade edilirse 3.14 döndürülür
• Ancak bu yöntem, tam karşılaştırma yapmayı zorlaştırır

Tam olarak 0'ı ifade etme sorunu

• RRA yaklaşımı, 1 - 1 sonucunu 0 yerine 0.0000000001 olarak da ifade edebilir
• Bu, kullanıcı deneyimi (UX) açısından sorun yaratır
• Boehm, çözüm bulmak için başka araştırmacılarla iş birliği yapmaya başladı

Richardson-Fitch algoritması

• 1994'te Dan Richardson ve John Fitch, belirli işlemler içinde sayı karşılaştırma sorununu çözdü
• Ancak bu algoritma o kadar yavaştı ki pratikte kullanılması imkânsızdı
• Örneğin 1 ≠ 1 - e^(-e^1000) ifadesini ayırt etmek için evrendeki atom sayısından fazla işlem gerekir

RRA ile rasyonel sayı işlemlerinin birleşimi

• Boehm, RRA ile rasyonel sayı işlemlerinin güçlü yanlarını birleştirme fikrini geliştirdi
• Basit işlemlerde (ör. 6 × 9 veya 8 / 3) rasyonel sayı işlemleri kullanılır
• Yalnızca irrasyonel sayılar işin içine girdiğinde RRA kullanılır
• Sonuç olarak sayılar rasyonel sayı × gerçek sayı biçiminde temsil edilir

Sembolik gösterim (Symbolic Representation)

• π, √2 gibi özel sayılar için RRA yerine sembolik gösterim kullanılır
• Örneğin π, "π" simgesi olarak saklanır ve yalnızca gerektiğinde sayıya dönüştürülür
• Yalnızca dört işlem değil, trigonometrik fonksiyonlar (sin, cos, tan), logaritma ve üstel fonksiyonlar da sembolik gösterimden yararlanır

Nihai çözüm

• Tüm sayılar rasyonel sayı × gerçek sayı (sembolik gösterim veya RRA) biçiminde saklanır
• Mümkün olduğunda doğruluğu korumak için rasyonel sayı işlemleri kullanılır
• RRA işlemlerini en aza indirmek için sembolik gösterimden azami ölçüde yararlanılır
• Sonuçta hız ve doğruluk arasında denge kuran kusursuz bir hesap makinesi sistemi ortaya çıkar

Sonuç

• Boehm ve ekibinin geliştirdiği Android hesap makinesi basit bir program değildir
• Doğru sonuç verirken aynı zamanda hızlı ve verimli algoritmalar uygular
• Bu, "sıradan bir hesap makinesi uygulaması" değil, matematiksel olarak incelikle tasarlanmış bir sistemdir

"Bir dahaki sefere Android hesap makinesini kullandığınızda, bu emeği hatırlayın!"

[street62]

Bu arada, yapay zeka neo'nun bunu "öyle ya" gibi çevirmiş olması ilginç. Orijinali "Anyone could make that" olduğu için şakacı bir ton yok ama hehe cuk oturmuş.

[gurugio]

Lisans öğrencisiyken 8086 kartını elimle lehimleyerek yapıp sayısal tuş takımı ve metin LCD’sini bağlayarak 8086 assembly ile hesap makinesi (yalnızca dört işlem yapan) yapmaya kadar giden bir dersimiz vardı.
Kartı yapıp tuş takımıyla LCD’yi bağlayıp çalıştırmayı başardım ama hesap makinesini yapamadım.
O zamanlar yazılıma yeteneğim olmadığını düşünüp donanım mühendisi olarak işe girdim ama bir şekilde kendimi yazılım geliştirme yaparken buldum.
Hesap makinesi gerçekten zordu.

[yunsub2]

Olabilir ya -> Olabilir ya değil, "olabilir ya" olmalı. 😃

[carnoxen]

Kayan nokta ayarlaması yapmaya kalkınca başınız ağrıyacaktır herhalde? hahaha

[tribela]

Hesap makinesi denince benim aklıma Windows’un varsayılan hesap makinesi geliyor. 2+2*2 hesabını yapınca 6 yerine 8 çıkıyor. Bunu bilerek böyle yapmışlar gibi görünüyor ama ben hiç anlayamıyorum. Eskiden bir kokteyldeki alkol miktarını hesaplamıştım da alkol, içeceğin toplam miktarından fazla çıkınca afalladığımı hatırlıyorum.

[khrad]

İşleçlere her bastığınızda önceki ifadenin anında hesaplandığı, sıradan elektronik hesap makinelerinin tipik çalışma biçimini izliyor; yoksa siz sadece bilimsel hesap makinesi mi kullandınız?

[ned0909]

Kesinlikle katılıyorum. Sunucu gerektirmediği için iyi olur diye hesap makinesiyle başladım ama ortaya çıkan hesaplama hataları ve bug'ları düzeltmek için çok uğraştım.

[ganadist]

Kaynak kodundaki uygulama genel bakışı

Kaynak kodundaki hesap makinesi işlem mantığının açıklaması

Tamsayı işleme kodu

Gerçel sayı işleme kodu

[aer0700]

"Hesap makinesi uygulaması mı? Onu herkes yapabilir ki" → aslında öyle değil
Bunun uygulanabileceği alanlar sonsuz gibi görünüyor hahaha

"Python mı? Aşırı kolay işte" → aslında öyle değil

[tsboard]

Ben de izlerken aynı şeyi düşündüm. lol

"JavaScript mi? Tam çocuk oyuncağı" → aslında öyle değil

[joyfui]

(10^100)+1−(10^100)
Vay canına, gerçekten iPhone hesap makinesi 0, Android hesap makinesi ise 1 gösteriyor.
Ama Google'da aratınca sonuç 0 çıkıyor...

[GN⁺]

Hacker News görüşü

• İlginç bir hikâye. Sayıları ifade etmenin daha güçlü bir yolu, onları continued fraction olarak ifade etmek. Continued fraction, gerçek sayıları ve rasyonel sayıları verimli biçimde temsil edebiliyor
  • İlginç bir bilgi olarak, çok da eski olmayan matematik ders kitaplarına göre continued fraction için toplama/çarpma algoritmalarının var olmayabileceği söyleniyordu. Ancak 1972'de Bill Gosper, continued fraction'ın aritmetik için tamamen uygun olduğunu kanıtladı
  • Şu anda reals adlı bir Python kütüphanesi üzerinde çalışıyorum. Bu kütüphane, Decimal veya Fraction tiplerinin yerini alabilecek şekilde tasarlandı. Bill Gosper'ın tekniklerini kullanarak continued fraction'ları işliyor
• Bağlantının kısalıp tıklanamaz hâle gelmesi talihsiz olmuş. Makalenin gerçek bağlantısı burada
• Başlığı okur okumaz güldüm. IEEE 754 en kötüsü, ama diğer her şeyden daha iyi. Örnekleri görür görmez bunun Kahan summation ya da tam teşekküllü bir computer algebra system ile ilgili olduğunu düşündüm. Recursive Real Arithmetic'i daha önce duymamıştım
  • Erken dönem C++ kahramanlarından biri hakkında fikir edinmiş oldum. Basit görünen şeylerin ne kadar derin olabileceğini hatırlatıyor
• NYC metro ücreti $2.90. iOS'ta PCalc kullanarak MetroCard'da kalan değeri hesapladığımda, 0 yerine -8.881784197E-16 çıktı. Apple'ın hesap makinesini kullanırken bu olmuyor
  • Geliştiriciye sordum; Apple'ın kendi matematik kütüphanesini kullandığını ve bunun yerine geçecek başka bir kütüphane bulmaları gerektiğini söyledi
• Neredeyse hiç kimse tam özellikli bir hesap makinesi uygulaması yapmadı. Burada TI-89 gibi tam özellikli bir hesap makinesinden söz ediyorum
  • Android'de bir TI-89 hesap makinesi emülatörü kullanıyorum. Android uygulamalarının yarısı kadar bile özellik sunmuyor ve düzgün çalışmıyor
• RRA'ya geçmenin tek dezavantajı kullanıcı deneyimi değil. Sonuç 0.0000000... olduğunda, hesap makinesi bu sayının tersini hesaplayıp hesaplayamayacağına karar veremiyor
  • Örneğin, 1/(atan(1/5)-atan(1/239)-pi/4) ifadesi için "hesaplanamıyor" çıktısı veriyor. 1/(atan(1/5)-atan(1/239)-pi/4+10^(-100000)) denendiğinde de hâlâ "hesaplanamıyor" çıktısı veriyor
• Neredeyse hiçbir sayı IEEE kayan noktalı biçimde temsil edilemez. Rastgele bir sayının teorik olarak açıklanamaz olma olasılığı yaklaşık %100 olabilir
  • Bazı sorunlar bignum'lar kullanılarak önlenebilir. Anlık varoluşsal kaygı giderildi
• TI-92 gibi gelişmiş TI hesap makinelerinin bu sistemi kullanıp kullanmadığını bilen var mı? Bir "rasyonel sayı" modu vardı ve RRA kullanmış olabilir
• "recursive real arithmetic" (RRA) kullanma biçimi, bana Conal Elliot ile yapılmış harika bir tartışmayı hatırlattı. Şeyleri ayrık biçimde temsil etmekten sürekli biçimde temsil etmeye geçişten söz ediliyordu
  • Örneğin, eskiden yazı tipleri piksel blokları olarak ifade edilirdi, şimdi ise çizgi/vektör olarak algılanıyor. Bilgisayar bilimi sadece en yeni ticari araçları öğrenmek değil, gerçeğin peşinden gitmek olmalı
• Android Open Source Project'in hesap makinesi kaynak koduyla biraz oynadım. Google bunu Google Play Services'a taşıdı, ama eski kaynak hâlâ erişilebilir
  • Birkaç gerçek sorunu çözüyor; bir kütüphanede kullanılabilmesini umuyorum. Önceki makalede birkaç kütüphane hakkında tartışma vardı