Numpy: DOC: docstring لـ numpy.finfo.eps غير صحيح
يحدد docstring لـ numpy.finfo eps السمة
أصغر رقم موجب يمكن تمثيله مثل 1.0 + eps! = 1.0. [...]
هذا التعريف غير صحيح ، على الأقل في الحالة الشائعة لتنسيقات IEEE 754 الثنائية. على سبيل المثال ، مع تنسيق IEEE 754 binary64 في ظل وضع التقريب المعتاد من العلاقات المستديرة إلى الزوج ، يعطي التعريف المذكور قيمة 2**-53 + 2**-105 (تقريبًا 1.1102230246251568e-16 ) ، وهو قليل أكثر من نصف القيمة الصحيحة لـ 2**-52 (تقريبًا 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
بعض عمليات إعادة الصياغة الممكنة:
أصغر رقم موجب مثل 1.0 + eps يمكن تمثيله.
أو:
الفرق بين 1.0 وأصغر عدد عائم قابل للتمثيل أكبر من 1.0.
أو يمكن تعريفه من حيث nextafter النحو التالي:
قيمة
np.nextafter(1.0, np.inf) - 1.0.
للمقارنة ، يحدد القسم 5.2.4.2.2 ، الفقرة 11 من معيار C99 ، وحدات ماكرو *_EPSILON ( DBL_EPSILON ، FLT_EPSILON ، ...) على النحو التالي:
الفرق بين 1 وأقل قيمة أكبر من 1 يمكن تمثيلها في نوع النقطة العائمة المعطى ، b 1p
وبالمثل فإن docstring لـ epsneg غير صحيح.
mdickinson
ال 5 كومينتر
آه ، بالنظر إلى المصدر ، أرى أن eps محسوب في الواقع على أنه أصغر _ قوة من 2_ مثل 1 + eps != eps . هذا ليس هو نفس الفرق بين 1.0 والتعويم التالي الذي يمكن تمثيله من 1.0 ، على الرغم من أن الأمرين يتطابقان مع IEEE 754 والتقريب الدائري إلى الزوج. وضع. لذا فإن إعادة الصياغة المقترحة أعلاه غير صالحة. ربما شيء مثل:
أصغر قوة 2 بحيث يمكن تمثيل 1.0 + eps.
سيكون أفضل؟ من الناحية الفنية ، يجب استبدال هذا 2 بجذر النقطة العائمة ، ولكن ربما يكون هذا متحذلقًا بشكل غير ضروري. هل يحتوي NumPy حاليًا على أي دعم لعوامات الجذر 10 أو الجذر 16؟
[جانبا ، أنا أفضل تعريف epsilon على غرار C99 ، لأنه يتضمن التنسيق فقط ولا يعتمد على دلالات إضافة النقطة العائمة. على وجه الخصوص ، لا يعتمد تعريف C99 على وضع التقريب الساري حاليًا ، بينما تعريف 1 + eps != 1 يفعل ذلك.]
mdickinson
في ٥ يناير ٢٠١٦
من المحتمل أيضًا أن يكون المؤشر إلى np.spacing و np.nextafter في قسم "انظر أيضًا" مفيدًا.
joferkington
في ٥ يناير ٢٠١٦
نحن هنا بعد 4 سنوات تقريبًا ولم يتم إصلاح ذلك. لا أعتقد أن https://github.com/numpy/numpy/pull/14618 سيكون كافيًا لإغلاق هذه المشكلة.
لتوضيح تقرير الخطأ ، يتم إيقاف التعريف الحالي لـ eps في docstring بحوالي عامل 2 من قيمة eps التي يتم إرجاعها بواسطة np.finfo. (الأرقام التي أوردها أدناه مخصصة لعمليات التنفيذ مع معيار النقطة العائمة IEEE-754 64 بت.) أي ،
np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16
ومع ذلك ، فإن docstring يعرّف eps على أنه
"أصغر رقم موجب يمكن تمثيله مثل 1.0 + eps! = 1.0."
القيمة الفعلية لـ eps التي تفي بالتعريف 1.0 + eps_min! = 1.0 هي:
eps_min = 2-53 + 2-105 = 1.1102230246251568e-16
وهو ما يقرب من نصف القيمة الحالية لـ np.finfo (1.0) .eps. ربما لا نريد تغيير قيمة np.finfo (1.0) .eps ، للحفاظ على التوافق مع الإصدارات السابقة ، لكن تعريف docstring لـ eps يحتاج إلى التصحيح لمطابقة ما تم حسابه. يستخدم الكود المصدري لـ np.finfo (1.0) eps numpy.MachAr ، وبالنظر إلى التوثيق هناك ، والذي يسمح بقواعد أخرى إلى جانب 2 ، أعتقد أن أفضل تعريف لـ eps هو أحد الخيارات المبكرة التي اقترحهاmdickinson سابقًا. أود أيضًا إضافة مثال على القيمة إلى الوصف:
"الفرق بين 1.0 وأصغر عدد عائم قابل للتمثيل أكبر من 1.0. (بالنسبة للعوامات الثنائية 64 بت في معيار IEEE-754 ، eps = 2 ** - 52 2.22e-16.)"
وبالمثل فإن docstring لـ epsneg غير صحيح.
gwhammett
في ٨ ديسمبر ٢٠١٩
أنا أيضًا عثرت على هذا الخطأ. يجب إصلاح هذا.
كمرجع ، توثق Matlab eps (الذي له نفس القيمة) على النحو التالي: "المسافة من 1.0 إلى رقم الدقة المزدوجة الأكبر التالي ، أي 2 ^ -52."
c-f-h
في ١٢ فبراير ٢٠٢٠
التعريف الحالي غير صحيح ومربك بسبب مشاكل التقريب. gwhammett ، التعريف المقترح صحيح وأكثر وصفيًا ويشجع العلاقات العامة لإغلاق هذه المشكلة.
rossbar
في ٢٦ فبراير ٢٠٢٠
القضايا ذات الصلة
navytux
·
4تعليقات
Foadsf
·
3تعليقات
qualiaa
·
3تعليقات
ghost
·
4تعليقات
amuresan
·
4تعليقات
التعليق الأكثر فائدة
نحن هنا بعد 4 سنوات تقريبًا ولم يتم إصلاح ذلك. لا أعتقد أن https://github.com/numpy/numpy/pull/14618 سيكون كافيًا لإغلاق هذه المشكلة.
لتوضيح تقرير الخطأ ، يتم إيقاف التعريف الحالي لـ eps في docstring بحوالي عامل 2 من قيمة eps التي يتم إرجاعها بواسطة np.finfo. (الأرقام التي أوردها أدناه مخصصة لعمليات التنفيذ مع معيار النقطة العائمة IEEE-754 64 بت.) أي ،
np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16
ومع ذلك ، فإن docstring يعرّف eps على أنه
القيمة الفعلية لـ eps التي تفي بالتعريف 1.0 + eps_min! = 1.0 هي:
eps_min = 2-53 + 2-105 = 1.1102230246251568e-16
وهو ما يقرب من نصف القيمة الحالية لـ np.finfo (1.0) .eps. ربما لا نريد تغيير قيمة np.finfo (1.0) .eps ، للحفاظ على التوافق مع الإصدارات السابقة ، لكن تعريف docstring لـ eps يحتاج إلى التصحيح لمطابقة ما تم حسابه. يستخدم الكود المصدري لـ np.finfo (1.0) eps numpy.MachAr ، وبالنظر إلى التوثيق هناك ، والذي يسمح بقواعد أخرى إلى جانب 2 ، أعتقد أن أفضل تعريف لـ eps هو أحد الخيارات المبكرة التي اقترحهاmdickinson سابقًا. أود أيضًا إضافة مثال على القيمة إلى الوصف:
وبالمثل فإن docstring لـ epsneg غير صحيح.