قد تحفظ وحدة الزمن ومضاعفها، ثم تستخدمهما لتعريف نوع الحقل. نقارن وصفين مؤلفين في NumPy: تاريخ بدقة ثلاثة أيام ومدة بالوحدة نفسها. نقرأ ناتج الدالة، ثم نسأل ما الذي بقي خارج هذا الناتج.
ماذا يصف الزوج؟
تعيد datetime_data وحدة نوع التاريخ أو المدة وعدد وحداتها الأساسية في الخطوة. [1]
نقرأ العنصرين وفق هذا الدور. لا نضع اسم الحقل أو قيمة تاريخ فعلية أو نتيجة جمع في مكانهما؛ تجربتنا تبدأ بوصف النوع نفسه.
إذا حفظنا الناتج في عمودين نسميهما الوحدة والمضاعف، فقد حفظنا ما اخترنا عرضه فيهما. سنختبر لاحقًا هل يكفيان للإجابة عن سؤال آخر: هل يخص الوصف تاريخًا أم مدة؟
زوج واحد ووصفان
شغّلنا NumPy 2.3.5 على CPython 3.12.14. أنشأنا a=np.dtype('datetime64[3D]') وb=np.dtype('timedelta64[3D]'). الأوصاف مؤلفة؛ لم ننسخ الأرقام من أمثلة المصدر.
أعاد np.datetime_data(a) الزوج ('D', 3)، وأعاد np.datetime_data(b) الزوج نفسه. في كل نتيجة، العنصر الأول str والثاني int، والنتيجة tuple.
عند مقارنة النتيجتين باستعمال == سجلنا True. لكن a==b أعطى False. أمامنا مساواة للعنصرين اللذين استخرجناهما، لا مساواة لكائني النوع الأصليين.
لنفترض سجلًا تعليميًا يحذف a وb ويحتفظ فقط بزوج كل منهما. يصبح السطران متطابقين في الحقول المحتفظ بها. لا تستطيع تلك الحقول وحدها استعادة أي السطرين كان التاريخ وأيهما كان المدة في تجربتنا.
والعدد 3 هنا ليس عدد عناصر مصفوفة قرأناها، ولا مدة خدمة قسناها. لم ننشئ مصفوفة قيم أو موعدًا في هذا المثال؛ قارنّا أوصاف أنواع ونواتج قراءتها.
احتفظ بالعائلة أيضًا
كان dtype.kind للتاريخ 'M' وللمدة 'm'؛ يميز التوثيق بهما عائلتي البيانات. [2]
في تشغيلنا، a.kind أعطى 'M' وb.kind أعطى 'm'. الحرف الكبير مختلف عن الصغير؛ إذا جعلناهما متطابقين في بطاقة القراءة فقد حذفنا الفرق الذي نسجله هنا.
للتدريب نكوّن بطاقتين: ('M', 'D', 3) و('m', 'D', 3). تختلف الخانة الأولى وحدها بينهما في مثالنا، وتبقى الوحدة والمضاعف متساويين. البطاقة تصميمنا لعرض الحقول؛ ليست ناتجًا إضافيًا تعيده datetime_data.
لا نخلط أيضًا بين الحرف 'M' حين قرأناه من kind، وبين الرمز 'M' حين نضعه في خانة وحدة مؤلفة في الشبكة. عنوان الحقل جزء من قراءة القيمة؛ تطابق المحرف لا يثبت أن العمودين يؤديان الدور نفسه.
إذا كانت المهمة تصنيف أحد الوصفين، نستعمل العائلة مع معلومات الوحدة. وإذا كانت المهمة مقارنة الزوجين فقط، نستطيع تسجيل تساويهما دون استنتاج أن الوصفين متساويان. لم نجر تحويلًا أو جمعًا كي نستنتج جوازه من هذه القراءة.
فحوص وحدود
كتبنا الوحدة والمضاعف المتوقعين قبل نداء الدالة. لكل اختيار أنشأنا وصف datetime64 ووصف timedelta64 بالحقول نفسها. لم نستعمل datetime_data لتوليد المتوقع ثم نقارنه بنداء آخر منها.
اخترنا للشبكة عشر وحدات: Y وM وW وD وh وm وs وms وus وns. مع كل وحدة استعملنا المضاعفات 1 و2 و4 و7. العدد 10×4=40 زوجًا؛ أضفنا زوج 3D المؤلف خارج الشبكة فصار المجموع 41.
لكل زوج ثلاث مجموعات: بيانات وصف التاريخ أمام الحقول المكتوبة ونوعي عنصري الزوج؛ وبيانات وصف المدة أمامها؛ ثم تساوي الزوجين مع اختلاف رمزي العائلة وعدم مساواة كائني النوع.
مرت 41×3=123 مجموعة. استدعينا datetime_data مرتين لكل زوج، أي 82 نداءً. لا نسمي عدد المجموعات عددًا للأزواج أو للنداءات.
النطاق أوصاف الأنواع الصريحة والوحدات والمضاعفات المذكورة. لم نختبر قيم تواريخ أو حسابًا أو تحويلًا أو مناطق زمنية أو أطوال شهور وسنوات، أو NaT أو وحدة عامة أو مدخلات غير زمنية أو ترتيب بايتات أو أنواعًا مركبة أو أداء. لم نشغّل إصدارًا أقدم.
حين تحفظ وصفًا مختصرًا، اكتب السؤال الذي يستطيع وصفك الإجابة عنه. في تجربتنا كان الزوج كافيًا لحفظ الوحدة والمضاعف اللذين قرأناهما؛ وحذف خانة العائلة جعل التاريخ والمدة متطابقين في السجل المختصر.
| الوصف | datetime_data | kind |
|---|---|---|
| datetime64[3D] | ('D', 3) | M |
| timedelta64[3D] | ('D', 3) | m |
للتوسع: هوية العملة والوحدة.
المراجع
أُعدّ هذا المقال بمساعدة الذكاء الاصطناعي، وخضع لمراجعة ذاتية بالأداة نفسها. لا يُنسب إلى مراجع بشري أو خبير مستقل. منهجية المحتوى.