dtype.char: هل يكشف الرمز حجم العنصر؟

اقرأ الرمز إلى جانب الحجم

char رمز حرفي للنوع المدمج في كائن dtype. [1]

ننشئ أوصاف أنواع مرنة، ونقرأ ثلاث خصائص لكل وصف: char وstr وitemsize. نريد معرفة هل يكفي الرمز المفرد لتحديد حجم العنصر، دون إنشاء مصفوفة أو تخزين نص داخلها.

نتابع وصفين لهما الرمز نفسه، لكنهما يختلفان في العرض الذي كتبناه عند البناء. الأرقام أوصاف مؤلفة؛ ليست أحجام ملفات أو قراءات لاستهلاك ذاكرة برنامج.

نسجل نص المدخل والخصائص بأسمائها. لا ندمج الرمز والوصف الكامل والحجم في خانة اسم واحدة، لأن هذا قد يخفي اختلافًا ظاهرًا بين كائنين في سجلنا.

قارن U31 وU81 في التشغيل

شغّلنا NumPy2.3.5 على CPython3.12.14 في حاسوب ذي ترتيب بايتات أصلي little-endian. نفذنا dt=np.dtype("U31")، ثم قرأنا dt.char وdt.str وdt.itemsize مرة واحدة لكل خاصية.

رجعت char بالنص"U"، وstr بالنص"<U31"، وitemsize بالعدد124. إنشاء dtype أعاد كائن نوع؛ هذه النصوص والعدد نتائج قراءات الخصائص، وليست ثلاثة نداءات بناء إضافية.

أنشأنا كائنًا آخر بواسطة np.dtype("U81")، وقرأنا الخصائص الثلاث بالطريقة نفسها. رجع الرمز"U" أيضًا، بينما أصبح الوصف"<U81" والحجم324.

إذن الرمز نفسه ظهر مع حجمين مختلفين في المثال:124 و324 بايتًا للعنصر في وصفي النوع. لا نستخرج أحد الحجمين من الحرفU وحده؛ نقرأ العرض المعلن والحجم الفعلي.

لم نضع سلسلة نصية داخل أي وصف. لا نعرف من هذا السجل طول نص واقعي أو عدد المحارف التي ستظهر بصريًا أو أثر تعيين سلسلة طويلة؛ هذه أسئلة خارج قراءاتنا.

الرسم الأول يحفظ الحرف نفسه أمام السطرين، ويضع الوصف والحجم في عمودين مستقلين. العلامة< جزء من النص الوصفي الذي قرأناه على هذا الحاسوب؛ لم نبدل ترتيب بايتات بيانات.

ميز العرض من وحدته

itemsize حجم العنصر في كائن النوع؛ ويمكن أن يختلف في الأنواع المرنة. [2] نضيف تحكمين لقراءة الرمز والحجم بدل نقل أعدادUnicode إلى كل نوع.

في أوصاف U يحدد العدد عرضUnicode بالمحارف، بينما يحدد العرض بالبايتات في أوصاف S وV المختارة. [3] نقرأ وحدة الوصف قبل إجراء المقارنة العددية.

أعطت np.dtype("S31") الرمز"S" والوصف"|S31" والحجم31؛ وأعطت np.dtype("S81") الرمز"S" والوصف"|S81" والحجم81. بقي الرمز ثابتًا بينهما، واختلف الحجم.

وأعطت np.dtype("V31") الرمز"V" والوصف"|V31" والحجم31؛ وأعطت np.dtype("V81") الرمز"V" والوصف"|V81" والحجم81. هذه أوصاف void الخام في تحكمنا؛ لم ننشئ حقولًا أو محتوى بايتيًا لها.

في مرجعنا لهذا المجال، أحجام U تساوي أربعة أمثال العرض:4×31=124 و4×81=324. أما أحجام S وV فتوافق العدد31 أو81. هذه قاعدة التوقع المحددة للأوصاف المختارة، وليست حسابًا لحجم ملف أو برنامج.

نفرق أيضًا بين عرضUnicode في وصف نوع وبين المحرف المرئي في نص مشكّل. لم نفحص محتوى أو تشكيلًا أو اتجاه عرض أو ترميز ملف؛ لا نحول العدد31 إلى وعد بعدد حروف عربية مرئية.

عد البناء وقراءات الخصائص منفصلين

اخترنا n من31 إلى47، أي17 قيمة. لكل n استعملنا العرضين n وn+50، وبنينا U وS وV عند كل عرض. عدد الكتابات17×2×3=102، وكل كتابة مختلفة في هذا السجل.

نفذنا102 نداء بناء dtype ناجحًا، فحفظنا102 سجل عودة لكائن نوع. لا يعني هذا102 تخصيصًا جديدًا أو102 مصفوفة؛ لم نفحص هوية الكائنات أو نختبر تخصيصها.

قرأنا char وstr وitemsize مرة واحدة لكل كائن، فصارت القراءات102×3=306. بينها102 نص رمز و102 نص وصف، أي204 قيم نصية للخصائص، و102 عدد صحيح لحجم العنصر.

كانت قيم char وstr من builtins.str، وقيم itemsize من builtins.int في السجل الفعلي. نفصل هذه القيم عن كائنات dtype المعادة من البناء؛ لا نسمي نداءات البناء102 عودة نصية أو عددية.

بنى مرجع Python قائمة الكتابات والرموز والأوصاف والأحجام المتوقعة قبل استيراد NumPy. اختارU أوS أوV، وأدخل العرض في الوصف، وحسب4×العرض لـU والعرض نفسه لـS وV؛ لم يستعمل بناء dtype أو خصائصه لصنع التوقع.

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

اقتصرنا على الأوصاف المرنة المذكورة والعروض31 إلى47 و81 إلى97، وعلى إصدار التشغيل والحاسوب المعلنين. لم نفحص مصفوفات أو تعيين نصوص أو اقتطاعًا أو محتوى أو ترميزًا أو حقولًا مركبة أو أنواعًا عددية أو تحويلًا أو ترتيب بايتات آخر أو الأداء أو إصدارًا آخر.