Numpy: سلوك الفهرسة مع علامات الحذف غير بديهي.

تبدو هذه حالة زاوية سيئة بشكل خاص - أعتقد أننا نعتبر أن ... يفرض على المؤشرين المتقدمين ، 0 و [0] ، اعتبارهما غير متجاورين - على الرغم من المحاور التي يفهرسونها _ هي متجاورة.

واجهتنا هذه المشكلة عند محاولة نسخ الفهرسة غير المعقدة. أعتقد أن هذا تفاعل غريب بين قاعدتين:

• تتوسع Ellipsis إلى مجموعة من الشرائح الكاملة ، كل منها تعتبر فهرسًا أساسيًا
• تؤدي المؤشرات الأساسية والمتقدمة من النظام المختلط إلى تشغيل عملية تبديل.

يتم تشغيل هذه الحالة الخاصة لأن المجموعة 0-d (عند ... مع وجود جميع المؤشرات) لا تزال تعتبر كتلة فهرس أساسية ، في حين يجب أن تكون غير مرئية حقًا.

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

لماذا يجب أن تكون "غير مرئية" حقًا؟ يجب أن يتصرف ... بشكل متطابق مع أي عدد من الأبعاد. للقيام بذلك ، يجب أن يتم تشغيل التبديل في جميع الحالات. أتخيل شيئًا منظمًا مثل series, ..., color حيث ... معرف من قبل المستخدم ويمكن أن يكون 0-d. لو كنت لكتابة برنامج لمعالجة تلك البيانات، هل تحتاج إلى فهرسة ليمكن نقل متوقعا عدم النظر عما ... توسع (أو لا توسيع) ل.

في النهاية ، هذا محير ببساطة ، وسيتعين علينا الحصول على .oindex ، و .vindex وما إلى ذلك بشكل أكثر جدية لحلها: https://numpy.org/neps/nep- 0021-Advanced-indexing.html

أنا مع حجة seberg بأن السلوك الحالي هو أفضل تعميم. يمكننا بالتأكيد التأكد من أن المستندات أكثر وضوحًا.

لم أكن أعرف شيئًا عن هذا الاقتراح ، شكرًا للإشارةseberg!

اسمحوا لي أن أعيد الصياغة فقط للتأكد من أنني أفهم حجتك. لنفترض أننا قمنا بتسمية المؤشرات المتقدمة A والمؤشرات الأساسية B وكما ورد أعلاه ، فإنني أستدعي إعادة الترتيب op a (معمم). في مثالك ، لدينا أربع حالات:

• [A1, ..., A2] و [B1, ... A1] : تؤدي هذه الحالات إلى الانتقال إلى [A1, A2, ....] و [A1, B1, ...] بغض النظر عن كيفية توسع ... .
• [A1, ..., B1] و [B1, ..., B2] : هذه الحالات لا تفعل ذلك.

هذه القواعد متسقة بمجرد معرفة الفئة (أ أو ب) series و color تنتمي ، بغض النظر عن كيفية توسع ... . هذا يعادل معاملة ... ككتلة (يحتمل أن تكون 0-d) من المؤشرات الأساسية. إن معاملة 0-d ... كحالة خاصة سيكون أمرًا سيئًا لأن التحويل سيكون مشروطًا بما إذا كان المستخدم قد مر في صفيف ثنائي الأبعاد أو ثلاثي الأبعاد أو أكثر. أوافق ، هذا مكان سيء ليكون فيه.

حدسي أن الكتل 0-d يجب أن تكون no-op كان مدفوعًا بكيفية تصرف tuples ، حيث بالنسبة لأي i ،

i: int
M: Tuple[int, ...]
N = ()
assert M[:i] + N + M[i:] == M

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

أثناء التطوير ، كنا نغير طريقة عملنا للفهرسة وسنقوم بإدخال ... لإثبات الكود في المستقبل ونشعر بالارتباك عندما يتم نقل الأشكال بطريقة سحرية. لقد تفاقمت بسبب الحالة الفارغة ... التي كانت غير منطقية بشكل خاص.

شكرا لإلقاء نظرة! يمكنني إرسال مستند PR إذا كنت ترغب في ذلك.

antonl a doc PR مرحب به دائمًا ، هناك العديد من التحسينات الممكنة هنا.