Apakah mungkin mendapatkan 0 dengan mengurangi dua angka floating point yang tidak sama?

Apakah mungkin mendapatkan pembagian dengan 0 (atau tak terhingga) dalam contoh berikut?

public double calculation(double a, double b)
{
     if (a == b)
     {
         return 0;
     }
     else
     {
         return 2 / (a - b);
     }
}

Dalam kasus normal, tentu saja tidak. Tetapi bagaimana jika adan bsangat dekat, dapat (a-b)menyebabkan 0ketepatan perhitungan?

Perhatikan bahwa pertanyaan ini untuk Java, tapi saya pikir itu akan berlaku untuk sebagian besar bahasa pemrograman.

Di Jawa, a - btidak pernah sama dengan 0jika a != b. Ini karena Java mengamanatkan operasi floating point IEEE 754 yang mendukung angka denormalized. Dari spec :

Secara khusus, bahasa pemrograman Java membutuhkan dukungan nomor floating-point yang didenormalkan IEEE 754 dan underflow bertahap, yang membuatnya lebih mudah untuk membuktikan sifat-sifat yang diinginkan dari algoritma numerik tertentu. Operasi floating-point tidak "flush to zero" jika hasil yang dihitung adalah angka yang dinormalkan.

Jika FPU bekerja dengan angka yang didenormalkan , mengurangi angka yang tidak sama tidak akan pernah menghasilkan nol (tidak seperti penggandaan), lihat juga pertanyaan ini .

Untuk bahasa lain, itu tergantung. Dalam C atau C ++, misalnya, dukungan IEEE 754 adalah opsional.

Yang mengatakan, adalah mungkin untuk ekspresi 2 / (a - b)meluap, misalnya dengan a = 5e-308dan b = 4e-308.

Sebagai solusinya, bagaimana dengan yang berikut ini?

public double calculation(double a, double b) {
     double c = a - b;
     if (c == 0)
     {
         return 0;
     }
     else
     {
         return 2 / c;
     }
}

Dengan begitu Anda tidak bergantung pada dukungan IEEE dalam bahasa apa pun.

Anda tidak akan mendapatkan pembagian dengan nol terlepas dari nilainya a - b, karena pembagian floating point dengan 0 tidak menghasilkan pengecualian. Ia mengembalikan tak terhingga.

Sekarang, satu-satunya cara a == bmengembalikan true adalah jika adan bmengandung bit yang sama persis. Jika mereka berbeda sedikit saja, perbedaan di antara mereka tidak akan menjadi 0.

EDIT:

Seperti yang dikatakan Batsyeba dengan benar, ada beberapa pengecualian:

1. "Bukan angka yang membandingkan" salah dengan dirinya sendiri tetapi akan memiliki pola bit yang identik.

2. -0.0 didefinisikan untuk membandingkan true dengan +0.0, dan pola bit mereka berbeda.

Jadi jika keduanya adan bini Double.NaN, Anda akan mencapai klausa lain, tetapi karena NaN - NaNjuga kembali NaN, Anda tidak akan membaginya dengan nol.

Tidak ada kasus di mana pembagian dengan nol dapat terjadi di sini.

The SMT Solver Z3 mendukung IEEE tepat aritmatika floating point. Mari kita minta Z3 untuk menemukan angka adan bsedemikian rupa sehingga a != b && (a - b) == 0:

(set-info :status unknown)
(set-logic QF_FP)
(declare-fun b () (FloatingPoint 8 24))
(declare-fun a () (FloatingPoint 8 24))
(declare-fun rm () RoundingMode)
(assert
(and (not (fp.eq a b)) (fp.eq (fp.sub rm a b) +zero) true))
(check-sat)

Hasilnya adalah UNSAT. Tidak ada angka seperti itu.

String SMTLIB di atas juga memungkinkan Z3 untuk memilih mode pembulatan sewenang-wenang ( rm). Ini berarti bahwa hasilnya berlaku untuk semua mode pembulatan yang mungkin (yang ada lima). Hasilnya juga mencakup kemungkinan bahwa salah satu variabel dalam permainan mungkin NaNatau tidak terbatas.

a == bdiimplementasikan sebagai fp.eqkualitas sehingga +0fdan -0fmembandingkan sama. Perbandingan dengan nol diimplementasikan menggunakan fp.eqjuga. Karena pertanyaannya ditujukan untuk menghindari pembagian dengan nol, ini adalah perbandingan yang tepat.

Jika tes kesetaraan diimplementasikan menggunakan persamaan bitwise, +0fdan -0fakan menjadi cara untuk membuat a - bnol. Versi sebelumnya yang salah dari jawaban ini berisi detail mode tentang kasus itu untuk yang penasaran.

Z3 Online belum mendukung teori FPA. Hasil ini diperoleh dengan menggunakan cabang tidak stabil terbaru. Itu dapat direproduksi menggunakan .NET bindings sebagai berikut:

var fpSort = context.MkFPSort32();
var aExpr = (FPExpr)context.MkConst("a", fpSort);
var bExpr = (FPExpr)context.MkConst("b", fpSort);
var rmExpr = (FPRMExpr)context.MkConst("rm", context.MkFPRoundingModeSort());
var fpZero = context.MkFP(0f, fpSort);
var subExpr = context.MkFPSub(rmExpr, aExpr, bExpr);
var constraintExpr = context.MkAnd(
        context.MkNot(context.MkFPEq(aExpr, bExpr)),
        context.MkFPEq(subExpr, fpZero),
        context.MkTrue()
    );

var smtlibString = context.BenchmarkToSMTString(null, "QF_FP", null, null, new BoolExpr[0], constraintExpr);

var solver = context.MkSimpleSolver();
solver.Assert(constraintExpr);

var status = solver.Check();
Console.WriteLine(status);

Menggunakan Z3 untuk menjawab pertanyaan mengambang IEEE bagus karena sulit untuk mengabaikan kasus-kasus (seperti NaN, -0f, +-inf) dan Anda dapat mengajukan pertanyaan yang sewenang-wenang. Tidak perlu menafsirkan dan mengutip spesifikasi. Anda bahkan dapat mengajukan pertanyaan campuran mengambang dan bilangan bulat seperti "apakah int log2(float)algoritma khusus ini benar?".

Fungsi yang disediakan memang dapat mengembalikan tak terhingga:

public class Test {
    public static double calculation(double a, double b)
    {
         if (a == b)
         {
             return 0;
         }
         else
         {
             return 2 / (a - b);
         }
    }    

    /**
     * @param args
     */
    public static void main(String[] args) {
        double d1 = Double.MIN_VALUE;
        double d2 = 2.0 * Double.MIN_VALUE;
        System.out.println("Result: " + calculation(d1, d2)); 
    }
}

Outputnya adalah Result: -Infinity.

Ketika hasil pembagian adalah besar untuk disimpan dalam dobel, infinity dikembalikan bahkan jika penyebutnya bukan nol.

Dalam implementasi floating-point yang sesuai dengan IEEE-754, setiap tipe floating-point dapat menyimpan angka dalam dua format. Satu ("dinormalisasi") digunakan untuk sebagian besar nilai floating-point, tetapi angka terkecil kedua yang dapat diwakilinya hanya sedikit lebih besar dari yang terkecil, sehingga perbedaan di antara keduanya tidak dapat diwakili dalam format yang sama. Format lain ("dinormalkan") hanya digunakan untuk angka yang sangat kecil yang tidak dapat diwakili dalam format pertama.

Sirkuit untuk menangani format floating-point yang didenormalkan secara efisien mahal, dan tidak semua prosesor memasukkannya. Beberapa prosesor menawarkan pilihan antara memiliki operasi pada angka yang sangat kecil jauh lebih lambat daripada operasi pada nilai-nilai lain, atau meminta prosesor menganggap angka yang terlalu kecil untuk format yang dinormalisasi menjadi nol.

Spesifikasi Java menyiratkan bahwa implementasi harus mendukung format denormalized, bahkan pada mesin yang melakukannya akan membuat kode berjalan lebih lambat. Di sisi lain, ada kemungkinan bahwa beberapa implementasi mungkin menawarkan opsi untuk memungkinkan kode berjalan lebih cepat dengan imbalan penanganan nilai yang sedikit ceroboh yang untuk sebagian besar tujuan terlalu kecil untuk diperhitungkan (dalam kasus di mana nilai terlalu kecil untuk diperhitungkan, itu dapat menjengkelkan memiliki perhitungan dengan mereka membutuhkan waktu sepuluh kali selama perhitungan itu penting, sehingga dalam banyak situasi praktis flush-to-zero lebih berguna daripada aritmatika lambat tapi akurat).

Dahulu sebelum IEEE 754, sangat mungkin bahwa a! = B tidak menyiratkan ab! = 0 dan sebaliknya. Itu adalah salah satu alasan untuk membuat IEEE 754 di tempat pertama.

Dengan IEEE 754 hampir dijamin. Kompiler C atau C ++ diizinkan untuk melakukan operasi dengan presisi lebih tinggi dari yang dibutuhkan. Jadi jika a dan b bukan variabel tetapi ekspresi, maka (a + b)! = C tidak menyiratkan (a + b) - c! = 0, karena a + b dapat dihitung sekali dengan presisi lebih tinggi, dan sekali tanpa presisi yang lebih tinggi.

Banyak FPU dapat dialihkan ke mode di mana mereka tidak mengembalikan angka dinormalkan tetapi ganti dengan 0. Dalam mode itu, jika a dan b adalah angka normal kecil di mana perbedaannya lebih kecil dari angka normalisasi terkecil tetapi lebih besar dari 0, a ! = b juga tidak menjamin a == b.

"Jangan pernah membandingkan angka titik apung" adalah pemrograman pemujaan kargo. Di antara orang-orang yang memiliki mantra "Anda membutuhkan epsilon", sebagian besar tidak tahu bagaimana memilih epsilon dengan benar.

Saya dapat memikirkan sebuah kasus di mana Anda mungkin dapat menyebabkan ini terjadi. Berikut adalah sampel analog pada basis 10 - sungguh, ini akan terjadi pada basis 2, tentu saja.

Angka titik apung disimpan lebih atau kurang dalam notasi ilmiah - yaitu, alih-alih melihat 35.2, angka yang disimpan akan lebih seperti 3.52e2.

Bayangkan demi kenyamanan bahwa kita memiliki unit floating point yang beroperasi di basis 10 dan memiliki 3 digit akurasi. Apa yang terjadi ketika Anda mengurangi 9,99 dari 10,0?

1,00e2-9,99e1

Shift untuk memberi masing-masing nilai eksponen yang sama

1,00e2-0,999e2

Membulatkan menjadi 3 digit

1,00e2-1,00e2

Uh oh!

Apakah ini bisa terjadi pada akhirnya tergantung pada desain FPU. Karena kisaran eksponen untuk double sangat besar, perangkat keras harus membulatkannya secara internal pada beberapa titik, tetapi dalam kasus di atas, hanya 1 digit tambahan secara internal akan mencegah masalah.

Anda seharusnya tidak pernah membandingkan pelampung atau dobel untuk kesetaraan; karena, Anda tidak dapat benar-benar menjamin bahwa nomor yang Anda tetapkan untuk float atau dobel adalah tepat.

Untuk membandingkan mengapung untuk persamaan, Anda perlu memeriksa apakah nilainya "cukup dekat" dengan nilai yang sama:

if ((first >= second - error) || (first <= second + error)

Pembagian dengan nol tidak ditentukan, karena batas dari bilangan positif cenderung hingga tak terbatas, terbatas dari bilangan negatif cenderung tak hingga negatif.

Tidak yakin apakah ini C ++ atau Java karena tidak ada tag bahasa.

double calculation(double a, double b)
{
     if (a == b)
     {
         return nan(""); // C++

         return Double.NaN; // Java
     }
     else
     {
         return 2 / (a - b);
     }
}

Masalah intinya adalah bahwa representasi komputer dari ganda (alias float, atau bilangan real dalam bahasa matematika) salah ketika Anda memiliki "terlalu banyak" desimal, misalnya ketika Anda berurusan dengan ganda yang tidak dapat ditulis sebagai nilai numerik ( pi atau hasil 1/3).

Jadi a == b tidak dapat dilakukan dengan nilai ganda a dan b, bagaimana Anda berurusan dengan a == b ketika a = 0,333 dan b = 1/3? Bergantung pada OS Anda vs FPU vs angka vs bahasa versus hitungan 3 setelah 0, Anda akan memiliki benar atau salah.

Pokoknya jika Anda melakukan "perhitungan nilai ganda" pada komputer, Anda harus berurusan dengan akurasi, jadi alih-alih melakukan a==b, Anda harus melakukannya absolute_value(a-b)<epsilon, dan epsilon relatif terhadap apa yang Anda modelkan pada waktu itu dalam algoritma Anda. Anda tidak dapat memiliki nilai epsilon untuk semua perbandingan ganda Anda.

Singkatnya, ketika Anda mengetik a == b, Anda memiliki ekspresi matematika yang tidak dapat diterjemahkan pada komputer (untuk setiap angka floating point).

PS: hum, semua yang saya jawab di sini kurang lebih dalam tanggapan dan komentar orang lain.

Berdasarkan tanggapan @malarres dan komentar @Taemyr, inilah kontribusi kecil saya:

public double calculation(double a, double b)
{
     double c = 2 / (a - b);

     // Should not have a big cost.
     if (isnan(c) || isinf(c))
     {
         return 0; // A 'whatever' value.
     }
     else
     {
         return c;
     }
}

Maksud saya adalah mengatakan: cara termudah untuk mengetahui apakah hasil pembagian adalah nan atau inf sebenarnya untuk melakukan pembagian.