Numpy: DOC: docstring untuk numpy.finfo.eps salah

Dibuat pada 5 Jan 2016 · 5Komentar · Sumber: numpy/numpy

Docstring untuk numpy.finfo saat ini mendefinisikan atribut eps sebagai:

Bilangan positif terkecil yang dapat direpresentasikan sehingga 1,0 + eps! = 1,0. [...]

Definisi tersebut tidak benar, setidaknya dalam kasus umum format biner IEEE 754. Misalnya, dengan format biner64 IEEE 754 di bawah mode pembulatan round-tie-to-even biasa, definisi yang dinyatakan memberikan nilai 2**-53 + 2**-105 (sekitar 1.1102230246251568e-16 ), yang merupakan sedikit lebih dari setengah nilai yang benar dari 2**-52 (sekitar 2.220446049250313e-16 ).

In [36]: eps = 2**-53 + 2**-105

In [37]: eps
Out[37]: 1.1102230246251568e-16

In [38]: 1.0 + eps != 1.0
Out[38]: True

In [39]: 1.0 + np.nextafter(eps, -np.inf) != 1.0
Out[39]: False

In [40]: np.finfo(float).eps
Out[40]: 2.2204460492503131e-16

Beberapa kemungkinan pengubahan urutan:

Angka positif terkecil sehingga 1,0 + eps dapat diwakili.

Atau:

Perbedaan antara 1.0 dan float terwakili terkecil yang lebih besar dari 1.0.

Atau bisa juga didefinisikan dalam nextafter sebagai:

Nilai np.nextafter(1.0, np.inf) - 1.0 .

Sebagai perbandingan, bagian 5.2.4.2.2, paragraf 11 dari standar C99 mendefinisikan berbagai makro *_EPSILON ( DBL_EPSILON , FLT_EPSILON , ...) sebagai:

perbedaan antara 1 dan nilai terkecil yang lebih besar dari 1 yang dapat direpresentasikan dalam tipe floating point yang diberikan, b ^{1− p}

Docstring untuk epsneg juga salah.

00 - Bug Triaged Documentation

Sumber

mdickinson

👍1

Komentar yang paling membantu

Di sini kita hampir 4 tahun kemudian dan ini belum diperbaiki. Menurut saya https://github.com/numpy/numpy/pull/14618 tidak akan cukup untuk menutup masalah ini.

Untuk memperjelas laporan bug, definisi eps saat ini di docstring mati sekitar faktor 2 dari nilai eps yang dikembalikan oleh np.finfo. (Angka yang saya berikan di bawah ini adalah untuk implementasi dengan standar floating point IEEE-754 64 bit.) Yaitu,

np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16

Namun, docstring mendefinisikan eps sebagai

"Angka positif terkecil yang dapat direpresentasikan sehingga 1,0 + eps! = 1,0."

Nilai aktual dari eps yang memenuhi definisi 1.0 + eps_min! = 1.0 adalah:

eps_min = 2 -53 + 2 -105 = 1,1102230246251568e-16

yang hampir 1/2 dari nilai sekarang dari np.finfo (1.0) .eps. Kami mungkin tidak ingin mengubah nilai np.finfo (1.0) .eps, untuk menjaga kompatibilitas ke belakang, tetapi definisi docstring dari eps perlu dikoreksi agar sesuai dengan yang dihitung. Kode sumber untuk np.finfo (1.0) eps menggunakan numpy.MachAr, dan melihat dokumentasi di sana, yang memungkinkan pangkalan lain selain 2, saya pikir definisi terbaik dari eps adalah salah satu opsi awal yang sebelumnya disarankan @mdickinson . Saya juga akan menambahkan nilai contoh ke deskripsi:

"Perbedaan antara 1.0 dan float terwakili terkecil yang lebih besar dari 1.0. (Untuk float biner 64 bit dalam standar IEEE-754, eps = 2 ** - 52 ≅ 2.22e-16.)"

Docstring untuk epsneg juga salah.

gwhammett pada 8 Des 2019

👍2

Semua 5 komentar

Ah, melihat sumbernya , saya melihat bahwa eps sebenarnya dihitung sebagai _kekuatan 2_ terkecil sehingga 1 + eps != eps . Itu tidak sama dengan perbedaan antara 1.0 dan representasi mengambang berikutnya naik dari 1.0 , meskipun dua hal itu kebetulan bertepatan untuk IEEE 754 dan pembulatan round-ties-to-even mode. Jadi penataan ulang yang saya sarankan di atas tidak valid. Mungkin sesuatu seperti:

Pangkat terkecil dari 2 sehingga 1,0 + eps dapat diwakili.

akan lebih baik? Secara teknis, 2 harus diganti dengan radix floating-point, tapi itu mungkin terlalu berlebihan. Apakah NumPy saat ini memiliki dukungan untuk float radix 10 atau radix 16?

[Sebagai tambahan, saya lebih suka definisi epsilon gaya C99, karena ini hanya melibatkan format dan tidak bergantung pada semantik penambahan floating-point. Secara khusus, definisi C99 tidak bergantung pada mode pembulatan yang saat ini berlaku, sedangkan definisi 1 + eps != 1 bergantung pada mode pembulatan.]

mdickinson pada 5 Jan 2016

Sebuah pointer ke np.spacing dan np.nextafter di bagian "Lihat Juga" juga berpotensi berguna.

joferkington pada 5 Jan 2016

Di sini kita hampir 4 tahun kemudian dan ini belum diperbaiki. Menurut saya https://github.com/numpy/numpy/pull/14618 tidak akan cukup untuk menutup masalah ini.

np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16

Namun, docstring mendefinisikan eps sebagai

"Angka positif terkecil yang dapat direpresentasikan sehingga 1,0 + eps! = 1,0."

Nilai aktual dari eps yang memenuhi definisi 1.0 + eps_min! = 1.0 adalah:

eps_min = 2 -53 + 2 -105 = 1,1102230246251568e-16

"Perbedaan antara 1.0 dan float terwakili terkecil yang lebih besar dari 1.0. (Untuk float biner 64 bit dalam standar IEEE-754, eps = 2 ** - 52 ≅ 2.22e-16.)"

Docstring untuk epsneg juga salah.

gwhammett pada 8 Des 2019

👍2

Saya juga baru saja menemukan ketidakakuratan ini. Ini harus diperbaiki.

Sebagai referensi, Matlab mendokumentasikan eps (yang memiliki nilai yang sama) sebagai: "jarak dari 1.0 ke angka presisi ganda berikutnya yang lebih besar, yaitu, 2 ^ -52."

c-f-h pada 12 Feb 2020

Definisi saat ini salah dan membingungkan karena masalah pembulatan. @gwhammett definisi yang diajukan benar dan lebih deskriptif dan mendorong PR untuk menutup masalah ini.