rfftfreq: هل n هو عدد معاملات rfft؟

سمّ العددين قبل إنشاء المحور

إذا استعمل rfft طول تحويل N، يكون طول خرجه floor(N/2)+1. [2] نكتب العدد المنتظر m، ونفصله عن N الذي يحتاجه محور التردد.

نؤلف نافذة بطول N=7 وفاصل d=1/14 ثانية، أي معدل مفترض 14 عينة/ثانية. نحدد الطول فقط؛ لم ننشئ قيم إشارة أو معاملات مركبة، ولم نجمع تسجيلًا من جهاز.

بصيغة العد يكون m=floor(7/2)+1=3+1=4. هذا حساب لعدد المعاملات المتوقع، لا نتيجة تشغيل rfft في فحصنا الجديد. لا نعطي أربع قيم طيفية مفترضة ثم نزعم قياسها.

شغلنا np.fft.rfftfreq(7,d=1/14) على NumPy 2.3.5. أعاد [0,2,4,6] بنوع float64 وشكل (4,). هنا توافق عدد تسميات التردد مع m المحسوب.

عند حفظ بيانات مثال كهذا، نقترح حقولًا منفصلة لطول التحويل N وعدد المعاملات m والفاصل d ووحدته. لا نضع الرقمين 7 و4 تحت اسم «الطول» نفسه ثم نتوقع من القارئ تخمين المقصود.

مرر العدد المختصر لترى الفرق

يحسب تنفيذ الإصدار 2.3.5 عدد الخانات n//2+1، ثم يضرب الفهارس من صفر في 1/(n×d). [3] لذلك يتغير العدد والمقام عند تغيير n.

للسبع، فهارس الخانات [0,1,2,3] والمقام N×d=7×1/14=1/2. قسمة الفهارس على نصف تعطي [0,2,4,6]. كل قيمة عنوان تردد، وليست مقدار معامل.

نجرب الاستدعاء الخاطئ لمقصودنا: np.fft.rfftfreq(4,d=1/14). أعاد [0,3.5,7] وشكلًا (3,). العدد أربعة عومل طول نافذة جديدة، فأصبح عدد التسميات floor(4/2)+1=3.

المقام الجديد 4/14=2/7. الفهارس [0,1,2] بالقسمة عليه تعطي [0,7/2,7]. ليست القائمة الأولى بعد حذف قيمتها الأخيرة: القيمة الثانية نفسها تغيرت من 2 إلى 3.5.

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

الطولان الزوجي والفردي قد يشتركان في m

عند طول فردي لا يوجد في rfft طرف عند نصف معدل العينات؛ الطول الزوجي يتضمن ذلك الطرف. [2] نذكر هذا المعنى دون حساب معاملات طيف في التشغيل الحالي.

إذا صار طول النافذة N=6 مع الفاصل نفسه، فعدد المعاملات المتوقع floor(6/2)+1=4 أيضًا. لكن المقام 6/14=3/7، والشبكة الصحيحة [0,7/3,14/3,7] دورة/ثانية.

أعاد التشغيل للطول 6 نحو [0,2.333333,4.666667,7]. نقرب الكسرين في العرض فقط. شبكة السبع [0,2,4,6] لها العدد نفسه، لكنها تختلف في القيم، ولا تنتهي عند 7.

إذا احتفظنا فقط بـm=4 وd=1/14، فلن يعرف سجلنا هل استعملنا ست قيم أم سبعًا. تمرير m بوصفه n أعاد [0,3.5,7] في الحالتين، لأنه استدعاء بالمعلمات نفسها.

النطاق التعليمي هنا لا يتضمن قصًا أو حشوًا. إذا اختير طول تحويل مختلف في rfft، فاحفظ ذلك الطول المستخدم، لا طول الملف قبل التغيير. [2] لم نختبر مسار الحشو؛ نوضح شرط تسمية الحقل الذي نريد حفظه.

راجع القيم حتى حين يتفق العدد

مع N=3 والفاصل 1/14، يكون m=2. أعاد المسار الصحيح [0,14/3]، وأعاد تمرير m إلى n القائمة [0,7]. كل قائمة تحمل قيمتين؛ فحص العدد وحده يمر رغم اختلاف العنوان الثاني.

ونختار تحكمًا مستقلًا N=2. عنده m=2 أيضًا، فصار رقما المعلمتين متساويين. أعاد المساران [0,7]. هذا اتفاق عددي لحالة محددة، لا دليل أن عدد المعاملات يصلح بدل طول التحويل عمومًا.

فحصنا الأطوال الموجبة من 1 إلى 25 مع الفواصل {1,1/2,1/14} ثانية، أي 75 زوجًا مختلفًا. مررنا لكل زوج الطول الأصلي ثم m المحسوب إلى rfftfreq مع الفاصل نفسه: 150 استدعاءً للدالة المساعدة.

حفظنا 870 عنصر مخرج حقيقي. قارنّا كل قيمة بمرجع مستقل من كسور k/(N×d) أو k/(m×d)، وفحصنا الشكل والنوع. أكبر فرق عن المرجع بعد تمثيله عائمًا كان نحو 8.88×10⁻¹⁶، ضمن حد مطلق 10⁻¹².

اتفق طول الناتجين في تسع حالات، واختلف في 66. اتفق الناتجان بالكامل في ست حالات، كلها تخص N=1 أو N=2 والفواصل الثلاثة. في الحالات الـ69 الأخرى تغير العدد أو القيم أو كلاهما.

لم ننشئ مصفوفة إشارة أو طيف، ولم ننفذ rfft أو irfft أو fft. لم نفحص محاور أو أجهزة أو فواصل غير موجبة أو قيمًا غير محدودة أو أداءً. الفحص يثبت شبكات الحالات المحددة؛ احفظ طول التحويل والفاصل ثم قارن عدد التسميات وقيمها معًا.