Numpy: BUG: لا يتم فرز ناتج numpy.percentile

تم إنشاؤها على ١٢ أكتوبر ٢٠١٩  ·  16تعليقات  ·  مصدر: numpy/numpy

ناتج numpy.percentile لا يتم فرزه دائمًا

مثال على إعادة إنتاج الكود:

import numpy as np
q = np.arange(0, 1, 0.01) * 100
percentile = np.percentile(np.array([0, 1, 1, 2, 2, 3, 3 , 4, 5, 5, 1, 1, 9, 9 ,9, 8, 8, 7]) * 0.1, q)
equals_sorted = np.sort(percentile) == percentile
print(equals_sorted)
assert equals_sorted.all()

رسالة خطأ:

[صدق صدق صدق صدق صدق صدق صدق صدق
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح صحيح
صحيح صحيح صحيح صحيح خطأ خطأ صحيح صحيح صحيح صحيح خطأ
صح صحيح صحيح خطأ]
AssertionError Traceback (آخر مكالمة أخيرة)
في
1 q = np. النسبة المئوية ([0 ، 1 ، 1 ، 2 ، 2 ، 3 ، 3 ، 4 ، 5 ، 5 ، 1 ، 1 ، 9 ، 9 ، 9 ، 8 ، 8 ، 7]) * 0.1 ، np.arange (0 ، 1 ، 0.01) * 100)
2 equals_sorted = np.sort (q) == q
----> 3 تأكيد يساوي _sorted.all ()

خطأ التوكيد:

معلومات إصدار Numpy / Python:

1.17.2 3.6.8 (v3.6.8: 3c6b436a57 ، 24 ديسمبر 2018 ، 02:04:31)
[GCC 4.2.1 متوافق Apple LLVM 6.0 (clang-600.0.57)]

00 - Bug numpy.lib good first issue

التعليق الأكثر فائدة

مرحبًا ، يبدو أنه كان هناك تحديث لإحدى إجابات stackexchange المقدمة من @ eric-wieser مع استيفاء بديل جيد.
يتضمن مؤشر الترابط دليلًا على الرتابة ، ويبدو أن الإصلاح المقترح يعالج جميع المشكلات المذكورة.
إذا كان هذا منطقيًا بالنسبة للمشكلة ، فسأكون على استعداد لتنفيذ ذلك كالتزام أول ، أو يمكن لشخص آخر تجربته.
20191209_020250

ال 16 كومينتر

لماذا تتوقع أن يتم فرزها؟ النسبة المئوية هي عنصر - المخرجات بترتيب المدخلات.

مرحبا !
في الواقع ، تعتبر النسبة المئوية حسب المقاس - عند التفكير في q ، وهو في حالتنا
np.arange(0, 1, 0.01) * 100 .
أتوقع أن يتم فرز الناتج لأنه تم فرز q .

توجد بعض الأخطاء العددية داخل ULP واحد ، والتي تختلف بالنسبة لمدخلات مختلفة بنفس قيمة الإخراج. أشك في أن هناك أي شيء يمكن القيام به حيال ذلك.

حالة فشل مخفضة قليلاً:

In [40]: np.percentile(np.array([0, 1, 1, 2, 2, 3, 3 , 4, 5, 5, 1, 1, 9, 9 ,9, 8, 8, 7]) * 0.1, [89, 90, 95, 96, 98, 99])
Out[40]: array([0.9, 0.9, 0.9, 0.9, 0.9, 0.9])

In [41]: np.diff(_)
Out[41]:
array([-1.11022302e-16,  2.22044605e-16, -1.11022302e-16,  1.11022302e-16,
       -1.11022302e-16])

هنا تظهر non-Sorted-ness عبر فرق.

أعتقد أنه من المحتمل أن يكون هناك شيء يمكننا القيام به حيال ذلك. أعتقد أن هذا يرجع إلى استقرار هذه الخطوط ، والتي تؤدي عملية lerp (بشكل أساسي add(v_below*weights_below, v_above*weights_above) ):

https://github.com/numpy/numpy/blob/b9fa88eec62e34e906689408096beb2450830d9a/numpy/lib/function_base.py#L3907 -L3908

https://github.com/numpy/numpy/blob/b9fa88eec62e34e906689408096beb2450830d9a/numpy/lib/function_base.py#L3928 -L3929

https://github.com/numpy/numpy/blob/b9fa88eec62e34e906689408096beb2450830d9a/numpy/lib/function_base.py#L3939 -L3942

هناك مجموعة من المقايضات التي يجب إجراؤها عند الاستيفاء الخطي لقيم الفاصلة العائمة ، لكنني أظن أن هناك خيارًا "صحيحًا" هنا ، ولم نقم به.

بعض المعلومات الأساسية هنا: https://math.stackexchange.com/questions/907327/accurate-floating-point-linear-interpolation

نعم ، أوافق ، +1 على إعادة تنظيم العمليات بحيث تكون رتيبة تمامًا (عدديًا). سيكون جيدًا إذا لم يكن أسوأ أيضًا ، أو على الأقل متطابقًا تقريبًا من حيث الدقة. أنا متأكد من أنه لا داعي للقلق بشأن بعض العمليات / السرعة الإضافية هنا.

تحرير: تم وضع علامة على أن الإصدار الأول جيد. ولكن بعد ذلك ، من المحتمل أن تكون هذه إعادة تنظيم مباشرة إلى حد ما داخل كود بايثون.

سأكون مهتمًا بتناول هذه المسألة. كنت أبحث في بعض الحالات الفاشلة ولاحظت أنها كلها تنطوي على استيفاء خطي بين نفس الرقم. على سبيل المثال ، في مثال إريك ، تقع جميع النسب المئوية التي أدرجها بين تسعيتين. لذلك أعتقد أن الاستيفاء الخطي بينهما يجب أن يكون 9 صحيحًا تمامًا؟ يبدو أن إصلاح مشكلة الاستيفاء الخطي بين رقمين متماثلين سيتعامل مع المشكلات المعروضة في هذا الخطأ ولن يتسبب في حدوث نتيجة ملحوظة في الأداء. ومع ذلك ، إذا أردنا التأكد من أن الاستيفاء الخطي سيكون رتيبًا دائمًا ، فيمكننا القيام بذلك ولكن سيتطلب وظيفة متعددة التعريف أعتقد أنها ستقلل من الأداء.

@ ngonzo95 يجب أن تكون هناك طريقة لتهجئة

لا يلزم إجراء حساب متعدد التعريفات.

يعتمد ذلك على متطلباتك على lerp . بعض ما قد نهتم به أو لا نهتم به:

  • رتيب ( (lerp(a, b, t1) - lerp(a, b, t0)) * (b - a) * (t1 - t0) >= 0 )
  • محدود ( a <= lerp(a, b, t) <= b )
  • متماثل ( lerp(a, b, t) == lerp(b, a, 1-t) )

( 0 <= t <= 1 )

حسنًا ، لم أكن أتوقع أن تكون القطعة متعددة الجوانب ضرورية ، لكني لا أعرف ماهية هذا الأمر جيدًا بما يكفي على ما أعتقد.

بالنظر إليها أكثر ، اكتشفت أن الوظيفة a + (ba) * t لها خاصية كونها رتيبة (التعريف المذكور أعلاه) ومتسقة (lerp (a ، a ، t) = a). أعتقد أن هذا يجب أن يكون كافيا لمتطلبات الوظائف. يبدو أن أحد عوامل الجذب الرئيسية لهذه الوظيفة هو أن lerp (أ ، ب ، 1)! = ب. ومع ذلك ، أعتقد أن الطريقة التي نحسب بها الأوزان تضمن أن 0 <= t <1.

يبدو أن أحد عوامل الجذب الرئيسية لهذه الوظيفة هو أن lerp (أ ، ب ، 1)! = ب. ومع ذلك ، أعتقد أن الطريقة التي نحسب بها الأوزان تضمن أن 0 <= t <1.

لاحظ أنه للأسف lerp(a, b. 1-eps) > b) ممكن بهذه الصيغة.

جديد في المصدر المفتوح.
أردت حل هذا باعتباره مشكلتي الأولى الجيدة. كيف يمكنني المساهمة؟ هل هناك شروط مسبقة؟

كنت أبحث في بعض حالات الفشل ولاحظت أنها تضمنت جميعها إقحامًا خطيًا بين نفس الرقم

في scikit-Learn ، واجهنا مؤخرًا هذه المشكلة: https://github.com/scikit-learn/scikit-learn/issues/15733

نظرًا لأننا نتوقع زيادة q بشكل صارم ، يمكننا تطبيق np.maximum.accumulate لإعادة ترتيب المصفوفة. ومع ذلك ، إذا تمكنا من حل المشكلة في NumPy مباشرةً ، فسيكون هذا رائعًا. هل هناك أي مكان يمكننا البحث فيه للحصول على حل جيد؟

glemaitre : جميع الأسطر ذات الصلة في numpy مرتبطة في تعليقي أعلاه ، https://github.com/numpy/numpy/issues/14685#issuecomment -541467915

مرحبًا ، يبدو أنه كان هناك تحديث لإحدى إجابات stackexchange المقدمة من @ eric-wieser مع استيفاء بديل جيد.
يتضمن مؤشر الترابط دليلًا على الرتابة ، ويبدو أن الإصلاح المقترح يعالج جميع المشكلات المذكورة.
إذا كان هذا منطقيًا بالنسبة للمشكلة ، فسأكون على استعداد لتنفيذ ذلك كالتزام أول ، أو يمكن لشخص آخر تجربته.
20191209_020250

لاحظ أن هناك مشكلة أخرى مع lerp في quantile() : لم يتم التعامل مع قيم inf بشكل صحيح ، راجع # 12282.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات