ناتج 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 ()
خطأ التوكيد:
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)]
لماذا تتوقع أن يتم فرزها؟ النسبة المئوية هي عنصر - المخرجات بترتيب المدخلات.
مرحبا !
في الواقع ، تعتبر النسبة المئوية حسب المقاس - عند التفكير في 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://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 مع استيفاء بديل جيد.
يتضمن مؤشر الترابط دليلًا على الرتابة ، ويبدو أن الإصلاح المقترح يعالج جميع المشكلات المذكورة.
إذا كان هذا منطقيًا بالنسبة للمشكلة ، فسأكون على استعداد لتنفيذ ذلك كالتزام أول ، أو يمكن لشخص آخر تجربته.
لاحظ أن هناك مشكلة أخرى مع lerp في quantile()
: لم يتم التعامل مع قيم inf بشكل صحيح ، راجع # 12282.
التعليق الأكثر فائدة
مرحبًا ، يبدو أنه كان هناك تحديث لإحدى إجابات stackexchange المقدمة من @ eric-wieser مع استيفاء بديل جيد.
يتضمن مؤشر الترابط دليلًا على الرتابة ، ويبدو أن الإصلاح المقترح يعالج جميع المشكلات المذكورة.
إذا كان هذا منطقيًا بالنسبة للمشكلة ، فسأكون على استعداد لتنفيذ ذلك كالتزام أول ، أو يمكن لشخص آخر تجربته.