Data.table: وظائف الدرفلة ، الركام المتداول ، النافذة المنزلقة ، المتوسط ​​المتحرك

التنفيذ المقترح rollmean ، مبسط.

x = data.table(v1=1:5, v2=1:5)
k = c(2, 3)

i - single column
j - single window
m - int referring to single row
w - current row's sum of rolling window
r - answer for each i, j



md5-be70673ef4a3bb883d4f334bd8fadec9



for i in x
  for j in k
  r = NA_real_
  w = 0
    for m in 1:length(i)
      w = w + i[m]
      w = w - i[m-j]
      r[m] = w / j

نعم ، والعديد من الوظائف المتدحرجة تتبع نفس الفكرة الأساسية (بما في ذلك
الانحراف المعياري المتداول / أي لحظة قائمة على التوقع وأي وظيفة
مثل rollproduct الذي يستخدم العكس * بدلاً من + للتجميع داخل
النافذة

كنت أتخيل دائمًا وظيفة النافذة المتدحرجة كتجميع مجموعة البيانات في مجموعات متداخلة متعددة (النوافذ). ثم ستبدو واجهة برمجة التطبيقات على النحو التالي:

DT[i, j,
   by = roll(width=5, align="center")]

ثم إذا كان j يحتوي ، على سبيل المثال ، mean(A) ، فيمكننا استبداله داخليًا بـ rollmean(A) - تمامًا كما نفعل مع gmean() الآن. أو يمكن أن يحتوي j على وظيفة معقدة بشكل تعسفي (على سبيل المثال ، قم بتشغيل انحدار لكل نافذة) ، وفي هذه الحالة سنوفر بيانات .SD data.table لها - تمامًا كما نفعل مع المجموعات فى الحال.

بهذه الطريقة ليست هناك حاجة لتقديم أكثر من 10 وظائف جديدة ، واحدة فقط. ويشعر بالبيانات.الجدول في الروح أيضًا.

نعم أوافق

يوم السبت ، 21 أبريل 2018 ، الساعة 3:38 مساءً Pasha Stetsenko [email protected]
كتب:

كنت أتخيل دائمًا وظيفة النافذة المتدحرجة كتجميع
مجموعة البيانات في مجموعات متعددة متداخلة (النوافذ). ثم ستبدو واجهة برمجة التطبيقات
شيء من هذا القبيل:

DT [i، j،
بواسطة = لفة (العرض = 5 ، محاذاة = "المركز")]

ثم إذا احتوت j ، على سبيل المثال ، على المتوسط ​​(A) ، فيمكننا استبدالها داخليًا
rollmean (A) - تمامًا كما نفعل مع gmean () الآن. أو يمكن j
تحتوي على وظيفة معقدة بشكل تعسفي (على سبيل المثال ، قم بتشغيل انحدار لـ
كل نافذة) ، وفي هذه الحالة سنقوم بتزويد .SD data.table لها - بالضبط
مثلما نفعل مع المجموعات الآن.

بهذه الطريقة ليست هناك حاجة لتقديم أكثر من 10 وظائف جديدة ، واحدة فقط. وها
يشعر بالبيانات.الجدول في الروح أيضًا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/2778#issuecomment-383275134 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AHQQdbADiE4aAI1qPxPnFXUM5gR-0w2Tks5tquH8gaJpZM4TeTQf
.

@ st-pasha فكرة مثيرة للاهتمام ، تشبه روح data.table-y ، لكنها ستفرض قيودًا كثيرة ، وليست مناسبة حقًا لهذه الفئة من الوظائف.

• كيفية أداء rollmean حسب المجموعة

DT[, rollmean(V1, 3), by=V2]

• كيفية حساب أحجام النوافذ المختلفة لأعمدة مختلفة

DT[, .(rollmean(V1, 3), rollmean(V2, 100))]

• كيفية حساب rollmean خارج [.data.table كما نسمح الآن لـ shift

rollmean(rnorm(10), 3)

• كيفية دعم استعلامات مثل

DT[, .(rollmean(list(V1, V2), c(5, 20)), rollmean(list(V2, V3), c(10, 30)))]

• كيفية استدعاء mean و rollmean بنفس j المكالمة

DT[, .(rollmean(V1, 3), mean(V1)), by=V2]

عادةً عند استخدام by نقوم بتجميع البيانات إلى عدد أصغر من الصفوف ، بينما تقوم الدوال المتغيرة دائمًا بإرجاع متجه بنفس طول الإدخال. هذه الأنواع من الوظائف في SQL لها واجهة برمجة تطبيقات بالأسلوب التالي:

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename;

لا يزال بإمكانك دمجه مع GROUP BY على النحو التالي:

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename
GROUP BY group_columns;

لذلك في SQL ، تظل هذه الوظائف في SELECT والتي تشير إلى j في DT.
في DT يمكننا تحقيق الشيء نفسه من خلال:

DT[, rollmean(value, 100)]
DT[, rollmean(value, 100), group_columns]

تتناسب وظائف التدوير مع نفس فئة الوظائف مثل shift والتي تُرجع أيضًا نفس عدد الصفوف عند إدخالها.
يبدو التحول في SQL كما يلي:

SELECT LAG(value, 1) OVER ()
FROM tablename;

mean و rollmean ليسا مجرد وظائف مختلفة ، إنهما فئات مختلفة من الوظائف. أحدهما يعني التجميع وفقًا للمجموعة ، والآخر ليس التجميع على الإطلاق. هذا مرئي بسهولة في SQL حيث لا نستخدم GROUP BY لنوع وظائف التدوير ولكننا نحتاج إلى استخدام GROUP BY للتجمعات مثل mean (في النهاية نحصل على إجمالي المنحة عند التجميع شرط غير موجود).
لا أرى سببًا قويًا لمحاولة تطبيق نفس قواعد التحسين كما نفعل مقابل mean ، خاصةً عندما لا يكون مناسبًا حقًا لاستخدام الحالة ، وكل ذلك من أجل البيانات فقط. روح. العرض الحالي عبارة عن روح data.table أيضًا ، ويمكن دمجها بسهولة مع := ، مثل shift . إنه يضيف فقط مجموعة من الوظائف الجديدة ، غير متوفرة حاليًا في جدول البيانات.

jangorecki شكرًا ، هذه كلها اعتبارات صالحة. بالطبع لدى الأشخاص المختلفين تجارب مختلفة ، ووجهات نظر مختلفة حول ما يجب اعتباره "طبيعيًا".

من الممكن تنفيذ rollmean حسب المجموعة: هذا مجرد تجميع من مستويين: DT[, mean(V1), by=.(V2, roll(3))] . ومع ذلك ، لا أرى كيفية إنشاء أحجام نوافذ مختلفة على أعمدة مختلفة باستخدام بناء الجملة الخاص بي ...

يجب أن أعترف أنني لم أر قط بناء جملة SQL لتداول الصلات من قبل. من المثير للاهتمام أنهم يستخدمون مجمِّعًا قياسيًا مثل AVG مع تطبيق مواصفات النافذة عليه. بالنظر إلى وثائق Transact-SQL ، هناك بعض الأفكار المثيرة للاهتمام هناك ، على سبيل المثال التمييز بين اختيار الصف المنطقي / المادي. أنها تسمح بالفعل بعوامل "OVER" مختلفة في أعمدة مختلفة ، ولكن في جميع الأمثلة التي يقدمونها ، يتم تكرار نفس جملة OVER عدة مرات. لذا فهو يشير إلى أن حالة الاستخدام هذه أكثر شيوعًا ، وبالتالي فإن استخدام مجموعة واحدة roll() سيؤدي إلى تكرار أقل.

أيضًا ، يوفر سؤال SO هذا نظرة ثاقبة مثيرة للاهتمام حول سبب تقديم صيغة OVER في SQL على الإطلاق:

يمكنك استخدام GROUP BY SalesOrderID. الفرق هو أنه مع GROUP BY ، يمكنك فقط الحصول على القيم المجمعة للأعمدة التي لم يتم تضمينها في GROUP BY. في المقابل ، باستخدام الدالات التجميعية ذات الإطارات بدلاً من GROUP BY ، يمكنك استرداد كل من القيم المجمعة وغير المجمعة. وهذا يعني ، على الرغم من أنك لا تفعل ذلك في استعلام المثال الخاص بك ، يمكنك استرداد قيم OrderQty الفردية ومجاميعها وأعدادها ومتوسطاتها وما إلى ذلك عبر مجموعات من معرفات SalesOrderID نفسها.

لذا يبدو أن بناء الجملة مصمم للتحايل على قيود SQL القياسية حيث لا يمكن دمج نتائج التجميع مع القيم غير المجمعة (على سبيل المثال ، تحديد كل من A و mean(A) في نفس التعبير). ومع ذلك ، لا يحتوي data.table على مثل هذا القيد ، لذا فهو يتمتع بحرية أكبر في اختيار بناء الجملة.

الآن ، إذا أردنا حقًا المضي قدمًا في المنحنى ، فنحن بحاجة إلى التفكير من منظور أوسع: ما هي الوظائف "المتدرجة" ، وما الذي يتم استخدامه من أجله ، وكيف يمكن تمديدها ، وما إلى ذلك. من وجهة نظر الإحصائي:

يتم استخدام وظيفة "المتداول المتوسط" لتسهيل بعض المدخلات الصاخبة. لنفترض ، إذا كانت لديك ملاحظات بمرور الوقت وتريد الحصول على فكرة عن "متوسط ​​الكمية" ، والتي قد تختلف مع ذلك بمرور الوقت على الرغم من أنها بطيئة جدًا. في هذه الحالة ، يمكن اعتبار "التدحرج على آخر 100 ملاحظة" أو "التدحرج على جميع الملاحظات السابقة". وبالمثل ، إذا لاحظت كمية معينة عبر نطاق من المدخلات ، فيمكنك تخفيفها عن طريق تطبيق "متوسط ​​التدحرج على أكثر من 50 ملاحظة".

• لذا ، فإن الامتداد الأول هو النظر إلى "النوافذ الملساء": تخيل متوسطًا على الملاحظات السابقة حيث كلما زادت الملاحظة في الماضي ، قلت مساهمتها. أو متوسط ​​المشاهدات القريبة على نواة غاوسي.
• الثانية هي النوافذ التكيفية. على سبيل المثال ، إذا كان لديك إدخال صاخب محدد خلال فاصل زمني [0 ، 1] ، فإن تجانسه باستخدام نافذة ± N ينتج نتيجة متحيزة بالقرب من الحواف. يمكن للمقدر غير المتحيز تكييف شكل النافذة بناءً على المسافة من الحافة.
• إعادة تشكيل التجانس: تقييد إنتاج العديد من الملاحظات بالضبط كما هو الحال في بيانات المصدر مقيد للغاية. إذا كنت تفكر في بياناتك على أنها ملاحظات صاخبة لبعض الوظائف الأساسية ، فمن المعقول تمامًا أن تطلب حساب القيم المتجانسة لهذه الوظيفة على شبكة أكثر خشونة / أدق من الإدخال الأصلي. أو ربما تكون البيانات الأصلية متباعدة بشكل غير منتظم وتريد إعادة تشكيلها على شبكة عادية.
• Jackknife: لكل ملاحظة تريد حساب المتوسط ​​/ الانحدار على جميع الملاحظات باستثناء التيار.
• تقسيم K-fold: اعرض البيانات كمجموعات متعددة حيث تستبعد كل مجموعة سوى جزء صغير من الملاحظات.

يمكن تنفيذ كل هذه العوامل كمشغلات تجميع ممتدة ، مع كون النوافذ المتدحرجة أحد العناصر الموجودة في هذه القائمة. بعد قولي هذا ، لا أفعل لماذا لا يمكننا الحصول عليه في كلا الاتجاهين.

يجب أن أعترف أنني لم أر قط بناء جملة SQL لتداول الصلات من قبل.

أفترض أنك تقصد وظائف متدرجة ، فالمسألة لا علاقة لها بتدوير الصلات.

أنها تسمح بالفعل بعوامل "OVER" مختلفة في أعمدة مختلفة ، ولكن في جميع الأمثلة التي يقدمونها ، يتم تكرار نفس جملة OVER عدة مرات. لذا فهو يشير إلى أن حالة الاستخدام هذه أكثر شيوعًا ، وبالتالي فإن استخدام مجموعة () لفة واحدة سيؤدي إلى تكرار أقل.

إنها مجرد حالة استخدام ، إذا كنت تتصل بنفس OVER () مرات عديدة ، فقد تجد أنه من الأفضل استخدام GROUP BY ، وإنشاء جدول بحث وإعادة استخدامه في استعلامات أخرى. مهما كانت الأمثلة الموجودة ، فإن تكرار OVER () مطلوب للاحتفاظ بميزة المنطقة لكل مقياس يتم توفيره. يستخدم بلدي الحالات من مستودعات البيانات حيث لا تكون بهذه البساطة مثل تلك الموجودة في مستندات Microsoft.

في المقابل ، باستخدام الدالات التجميعية ذات الإطارات بدلاً من GROUP BY ، يمكنك استرداد كل من القيم المجمعة وغير المجمعة.

في data.table نقوم بعمل := و by في استعلام واحد لتحقيق ذلك.

لذلك يبدو أن بناء الجملة مصمم للتحايل على قيود SQL القياسية حيث لا يمكن دمج نتائج التجميع حسب القيم غير المجمعة (أي تحديد كل من A والمتوسط ​​(A) في نفس التعبير). ومع ذلك ، لا يحتوي data.table على مثل هذا القيد ، لذا فهو يتمتع بحرية أكبر في اختيار بناء الجملة.

لا يقتصر الأمر على تحديد SQL ولكن مجرد تصميم GROUP BY ، بحيث يتم تجميعها ، بنفس الطريقة التي يتم بها تجميع by . مطلوب واجهة برمجة تطبيقات جديدة لتغطية وظائف النافذة الجديدة. يمكن توفير التجميع لوظيفة نافذة SQL لكل استدعاء دالة باستخدام FUN() OVER (PARTITION BY ...) حيث يشبه _partition by_ التجميع المحلي لمقياس واحد. لذلك لتحقيق مرونة SQL ، سنحتاج إلى استخدام j = mean(V1, roll=5) أو j = over(mean(V1), roll=5) مع الاحتفاظ بواجهة برمجة التطبيقات هذه بـ j . لا يزال هذا النهج لن يسمح بدعم جميع حالات الاستخدام المذكورة أعلاه.

يمكنك تخفيفها عن طريق تطبيق "متوسط ​​التدحرج على أكثر من 50 ملاحظة".

هذا هو سبب استخدام الوسيطة align .

لذا ، فإن الامتداد الأول هو النظر إلى "النوافذ الملساء": تخيل متوسطًا على الملاحظات السابقة حيث كلما زادت الملاحظة في الماضي ، قلت مساهمتها. أو متوسط ​​المشاهدات القريبة على نواة غاوسي.

هناك العديد من المتغيرات (عدد غير محدود تقريبًا) للمتوسطات المتحركة ، وأكثر وظائف نافذة التنعيم شيوعًا (بخلاف rollmean / SMA) هي المتوسط ​​المتحرك الأسي (EMA). ما يجب تضمينه ، وما لا يجب تضمينه ، ليس تافهاً لاتخاذ قرار ، وفي الواقع من الأفضل اتخاذ هذا القرار وفقًا لطلبات الميزات التي ستأتي من المستخدمين ، حتى الآن لم يتم طلب أي شيء مثل هذا.

يمكن تنفيذ كل هذه العوامل كمشغلات تجميع ممتدة ، مع كون النوافذ المتدحرجة أحد العناصر الموجودة في هذه القائمة.

بالتأكيد يمكنهم ذلك ، ولكن إذا نظرت إلى SO ، والمشكلات التي تم إنشاؤها في الريبو الخاص بنا ، فسترى أن تلك الوظائف المتدحرجة القليلة هنا مسؤولة عن 95 +٪ من الطلبات المقدمة من المستخدمين. يسعدني العمل على EMA والمتوسطات المتحركة الأخرى (على الرغم من أنني لست متأكدًا مما إذا كان data.table هو أفضل مكان لهؤلاء) ، ولكن كمسألة منفصلة. بعض المستخدمين ، بمن فيهم أنا ، ينتظرون مجرد متوسط ​​متحرك بسيط في البيانات.جدول لمدة 4 سنوات بالفعل.

هذا هو رأيي ، قادم من وجهة نظر إحصائي

تأتي وجهة نظري من تخزين البيانات (حيث استخدمت وظيفة النافذة ، مرة واحدة على الأقل في الأسبوع) وتحليل اتجاه السعر (حيث استخدمت عشرات من المتوسطات المتحركة المختلفة).

rollmean يتم دفع مشروع ل roll فرع. لقد وجدت أن معظم الحزم الأخرى التي تنفذ يعني التدحرج غير قادرة على التعامل بشكل جيد مع na.rm=FALSE و NAs الموجودة في المدخلات. يعالج هذا التطبيق NA باستمرار إلى mean ، مما يفرض بعض النفقات الإضافية بسبب ISNAN للمكالمات. يمكننا السماح لواجهة برمجة التطبيقات بإصدار أسرع ولكن أقل أمانًا إذا كان المستخدم متأكدًا من عدم وجود NAs في الإدخال.
العلاقات العامة في # 2795

mattdowle يجيب على أسئلة العلاقات العامة

لماذا نفعل هذا داخل data.table؟ لماذا نقوم بدمجها بدلاً من المساهمة في الحزم الحالية واستخدامها من data.table؟

1. كانت هناك 3 مشكلات مختلفة تم إنشاؤها للمطالبة بهذه الوظيفة في جدول البيانات. كما تم وضع علامة على أسئلة SO متعددة data.table. يتوقع المستخدمون أن يكون ذلك في نطاق data.table.
2. يناسب data.table بشكل مثالي بيانات السلاسل الزمنية ، وتعد المجاميع المتدحرجة إحصائية مفيدة جدًا هناك.

تخميني هو أنه يعود إلى بناء الجملة (الميزات ممكنة أو ملائمة فقط إذا كانت مضمنة في data.table ؛ على سبيل المثال داخل [...] ومحسّن) وبناء البيانات الداخلية للجدول في وظيفة التدوير على المستوى C ؛ على سبيل المثال ، froll * يجب أن تكون على علم واستخدام مؤشرات ومفتاح data.table. إذا كان الأمر كذلك ، هناك حاجة إلى مزيد من التفاصيل حول ذلك ؛ مثال قصير بسيط.

بالنسبة لي شخصيًا ، يتعلق الأمر بالسرعة ونقص سلسلة التبعيات ، في الوقت الحاضر ليس من السهل تحقيقها.
يمكن أن تكون المفاتيح / المؤشرات مفيدة لـ frollmin / frollmax ، ولكن من غير المحتمل أن يقوم المستخدم بإنشاء فهرس لمتغير القياس. من غير المحتمل أن يقوم المستخدم بعمل فهرس لمتغير القياس ، كما أننا لم نقم بهذا التحسين لـ min / max حتى الآن. لا أرى فائدة كبيرة في تحسين GForce لأن الذاكرة المخصصة لا يتم تحريرها بعد استدعاء roll * ولكن يتم إرجاعها كإجابة (على عكس المتوسط ​​غير المتداول ، المجموع ، إلخ).

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

لقد ذكرت بعضها أعلاه ، إذا لم تكن مقتنعًا ، أوصيك بملء سؤال لمستخدمي data.table ، أو طرحه على Twitter ، وما إلى ذلك للتحقق من الرد. هذه الميزة كانت مطلوبة منذ وقت طويل ومن قبل العديد من المستخدمين. إذا لم يقنعك الرد ، فيمكنك إغلاق هذه المشكلة.

لقد وجدت أن sparklyr يمكنه دعم وظائف التدوير بشكل جيد جدًا في مجموعة بيانات كبيرة الحجم.

harryprince يمكن أن يعطي القليل من الضوء من خلال تقديم مثال على رمز كيف تفعل ذلك في سباركلير؟
وفقا ل "وظائف النافذة" المصغر dplyr

الركام المتداول يعمل في نافذة بعرض ثابت. لن تجدها في القاعدة R أو في dplyr ، ولكن هناك العديد من التطبيقات في الحزم الأخرى ، مثل RcppRoll.

AFAIU يمكنك استخدام واجهة برمجة تطبيقات شرارة مخصصة عبر sparklyr لم يتم تنفيذ واجهة dplyr ، أليس كذلك؟

تدور هذه المشكلة حول التجميعات المتدحرجة ، وهناك "أنواع" أخرى من وظائف النافذة موجودة بالفعل في data.table لفترة طويلة.

تقديم بعض الأمثلة حتى نتمكن من مقارنة الأداء (في الذاكرة) مقابل sparklyr / SparkR سيكون مفيدًا أيضًا.

لقد خطر لي أن هذا السؤال:

كيف تحسب أحجام النوافذ المختلفة لأعمدة مختلفة؟

له في الواقع نطاق أوسع ، ولا ينطبق على وظائف التدوير فقط.

على سبيل المثال ، يبدو أنه من المعقول تمامًا أن نسأل عن كيفية تحديد متوسط ​​سعر المنتج حسب التاريخ ، ثم بالأسبوع ، ثم ربما حسب الأسبوع + الفئة - كل ذلك في نفس الاستعلام. إذا قمنا في أي وقت بتنفيذ مثل هذه الوظيفة ، فيمكن أن تكون البنية الطبيعية لها

DT[, .( mean(price, by=date), 
        mean(price, by=week), 
        mean(price, by=c(week, category)) )]

الآن ، إذا تم تنفيذ هذه الوظيفة بالفعل ، فستكون قفزة بسيطة من هناك إلى الوسائل المتغيرة:

DT[, .( mean(price, roll=5), 
        mean(price, roll=20), 
        mean(price, roll=100) )]

لا نقول أن هذا أفضل بشكل لا لبس فيه من rollmean(price, 5) - مجرد طرح بعض البدائل للنظر فيها ...

@ st-pasha

كيفية تحديد متوسط ​​سعر المنتج حسب التاريخ ، ثم بالأسبوع ، ثم ربما حسب الأسبوع + الفئة - كل ذلك في نفس الاستعلام.

AFAIU هذا ممكن بالفعل باستخدام ?groupingsets ، لكن لم يتم ربطه بـ [.data.table حتى الآن.

jangorecki ، @ st-pasha ، وشركاهم - شكرًا على كل ما zoo أو RcppRoll .

يعد سؤال Stack Overflow هذا مثالًا جيدًا على تطبيق متجدد يمكن أن يستفيد من وسيطة partial = TRUE .

msummersgill شكرا على ردود الفعل. في المنشور الأول ، قمت بربط sha صراحة حيث يمكن العثور على رمز ميزة النافذة الجزئية. تمت إزالة التطبيق الموجود لاحقًا لتقليل تعقيد التعليمات البرمجية. كان أيضًا يفرض تكلفة أداء صغيرة حتى عند عدم استخدام هذه الميزة. يمكن (وربما ينبغي) تنفيذ هذه الميزة بالطريقة الأخرى ، اكتمل أولاً كما هي ، ثم قم فقط بملء النافذة الجزئية المفقودة باستخدام حلقة إضافية 1:window_size . لذلك لا يمكن ملاحظة الحمل الزائد لهذه الميزة إلا عند استخدامها. على الرغم من ذلك ، فإننا نقدم هذه الوظيفة عبر وسيطة adaptive ، حيث تكون ميزة partial مجرد حالة خاصة من adaptive يعني المتداول. هناك مثال على كيفية تحقيق partial باستخدام adaptive في ?froll يدويًا . لصقه هنا:

d = as.data.table(list(1:6/2, 3:8/4))
an = function(n, len) c(seq.int(n), rep(n, len-n))
n = an(3, nrow(d))
frollmean(d, n, adaptive=TRUE)

بالطبع لن تكون فعالة مثل وظيفة الدرفلة غير التكيفية باستخدام حلقة إضافية لملء نافذة جزئية فقط.
AFAIK zoo لديه ميزة partial .

هل لديكم أي خطة لإضافة وظائف الانحدار المتداول إلى data.table؟

waynelapierre إذا كان هناك طلب على ذلك ، إذن نعم. لديك +1 الخاص بي

شكرا هذا عظيم. على الرغم من سؤال واحد فقط. لا أرى سوى المجاميع المتدحرجة البسيطة ، مثل الوسيط المتداول أو الوسيط المتداول. هل تقوم أيضًا بتنفيذ وظائف دائرية أكثر دقة مثل إطارات بيانات DT المتداول؟ لنفترض ، إنشاء DT متداول باستخدام آخر 10 ساعات وتشغيل انحدار lm عليه.

شكرا!

randomgambit أود أن أقول أنه خارج النطاق ، ما لم يكن هناك طلب كبير على ذلك. لن يكون من الصعب جدًا القيام بذلك لتكون أسرع من قاعدة R / zoo فقط عن طريق التعامل مع حلقة متداخلة في C. ولكن يجب أن نحاول تنفيذها باستخدام خوارزمية "عبر الإنترنت" ، لتجنب التكرار المتداخل. هذا أكثر تعقيدًا ، ويمكننا في النهاية القيام به لأي إحصائية ، لذلك علينا قطع هذه الإحصائيات في مرحلة ما.

jangorecki شكرا مثيرة للاهتمام. هذا يعني أنني سأستمر في استخدام tsibble للتضمين ... DATA.TABLES في tibble ! في مهب العقل: د

حاولت استخدام frollmean لحساب "منحنى لوجستي" غير معلمي والذي يظهر P[y | x] للثنائي y باستخدام الجيران الأقرب x . فوجئت بتخزين y حيث تم تخزين logical تلقائيًا إلى integer :

DT = data.table(x = rnorm(1000), y = runif(1000) > .5)
DT[order(x), .(x, p_y = frollmean(y, 50L))]

خطأ في froll (fun = "mean" ، x = x ، n = n ، fill = fill ، algo = algo ، align = align ،:
يجب أن يكون x من النوع الرقمي

مثال على كيفية تأثير وسيطات المتجه x / n على الأداء.
https://github.com/AdrianAntico/RemixAutoML/commit/d8370712591323be01d0c66f34a70040e2867636#r34784427
حلقات أقل ، رمز أسهل في القراءة ، أسرع بكثير (تسريع 10x-36x).

frollapply جاهز: https://github.com/Rdatatable/data.table/pull/3600

    ### fun             mean     sum  median
    # rollfun          8.815   5.151  60.175
    # zoo::rollapply  34.373  27.837  88.552
    # zoo::roll[fun]   0.215   0.185      NA
    # frollapply       5.404   1.419  56.475
    # froll[fun]       0.003   0.002      NA

مرحبًا ، هل سيتم تغيير FUN (المعرفة من قبل المستخدم) إلى frollapply لإرجاع كائن R أو بيانات. تسميات وعودة frollapply قائمة؟ ثم يمكننا إجراء اختبار الانحدار المتداول أو اختبار التدحرج مثل إجراء اختبار Benford أو الملخص على الملصقات.

من المفيد دائمًا تقديم مثال قابل للتكرار. للتوضيح ... في مثل هذا السيناريو ، قد ترغب في إعادة frollapply(dt, 3, FUN) قائمة بطول nrow(dt) حيث سيكون كل عنصر قائمة data.table إرجاعه بواسطة FUN(dt[window]) ؟
frollapply(x=dt, n=3, fun=FUN)[[3]] يساوي FUN(dt[1:3])
frollapply(x=dt, n=3, FUN=FUN)[[4]] يساوي FUN(dt[2:4])
هل هذا صحيح؟ تضمين التغريدة

ندعم حاليًا العديد من الأعمدة التي تم تمريرها إلى الوسيطة الأولى ولكننا نعالجها بشكل منفصل ، مع تكرار التكرار. ربما نحتاج إلى بعض الوسيطات الإضافية multi.var=FALSE ، عند التعيين على "صحيح" ، لن يتكرر أكثر من x (كما هو الحال الآن: list(FUN(x[[1]]),FUN(x[[2]])) ) ولكن مرر جميع الأعمدة FUN(x) .

أي تحديث لهذا؟

أنا أؤيد هذا الطلب السابق.

علاوة على ذلك ، هل يمكن دعم حجة "جزئية" للسماح بنوافذ جزئية؟

eliocamp هل يمكنك توضيح ما هي نافذة partial ؟

eliocamp سيكون من الممكن دعم الحجة "الجزئية". قد تعلم أنه يوجد بالفعل دعم لهذه الوظيفة ، باستخدام الوسيطة adaptive=TRUE ، انظر الأمثلة للحصول على التفاصيل.

قد يعني حساب الوظيفة من البداية حتى النهاية بدلاً من تشكيل نقطة نصف النافذة.
على سبيل المثال ، بالنسبة لمتوسط ​​التدوير 11 عرضًا ، سيكون العنصر الأول الذي يتم إرجاعه هو متوسط ​​العناصر من 1 إلى 6. والعنصر الثاني ، متوسط ​​العناصر من الأول إلى السابع ، وهكذا.

jangorecki أوه ، شكرًا ، لم أكن أعرف ذلك! سوف تحقق من ذلك.

موافق ، نحن بحاجة إلى حجة جزئية ، ليس فقط للراحة ولكن أيضًا للسرعة. يضيف adaptive=TRUE النفقات العامة.
ونعم ، نحتاج أيضًا إلى الانحدار المتدحرج ، لذلك توفير متغيرات متعددة والتداول عليها في وقت واحد ، وليس كل واحد على حدة.
لا يوجد تحديث عن حالة هؤلاء.

أرغب في المساعدة ولكن مهاراتي في C ++ غير موجودة تمامًا. : sweat: هل تعتقد أنه قد يكون مناسبًا للمبتدئين الكاملين؟

نحن لا نبرمج في C ++ ولكن في C. نعم ، إنه مكان جيد للبدء به. لقد فعلت ذلك بالضبط على مرح.

ألقي نظرة على الكود ويبدو أنه شاق. لكنني سأقوم بتحديثك على أي حال.

ولكن الآن ، لطلب آخر: يجب أن يحتفظ frollmean (.SD) بالأسماء. بشكل عام ، يجب أن تحتفظ froll * بالأسماء إذا كان الإدخال يشبه القائمة بأسماء.

بصفتي مستخدمًا متكررًا لـ data.table ، أجد أنه من المفيد للغاية أن يكون لديك ميزات "مدركة للوقت" ، مثل تلك المعروضة حاليًا في الحزمة tsibble . للأسف تم تطوير هذه الحزمة بحوالي dplyr . أتساءل عما إذا كان تنفيذ جدول البيانات ممكنًا. وظائف النافذة المقترحة في هذه المشكلة هي مجموعة فرعية من تلك الميزات.

ywhcuhk شكرًا على التعليقات ، كنت أفكر في الواقع أن هذه المشكلة كانت تطلب الكثير بالفعل. يتم تغطية معظم ذلك جيدًا بواسطة لفة حزمة لا تزال خفيفة الوزن سريعة جدًا. بالنسبة إلى الميزات الأخرى ، أقترح إنشاء عدد جديد لكل ميزة تهتم بها ، لذا يمكن تحديد مناقشة ما إذا كنا نريد التنفيذ / الصيانة لكل منها على حدة. فقط من إلقاء نظرة على الملف التمهيدي لـ tstibble ، لا أرى أي شيء جديد يقدمه ...
عنوانها هو "Tidy Temporal Data Frames" ولكن لا يبدو أنها تقدم صلات زمنية.

شكرا لك jangorecki على الرد. ربما يتعلق الأمر بالسياق. تُعرف بنية البيانات التي أتعامل معها في أغلب الأحيان باسم "بيانات اللوحة" ، مع معرف ووقت. إذا كان البرنامج "على علم" بميزة البيانات هذه ، فسيتم تسهيل الكثير من العمليات ، وخاصة عمليات السلاسل الزمنية. بالنسبة لشخص يعرف STATA ، فهذه العمليات تعتمد على tsset و xtset ، مثل العميل المتوقع ، والتأخر ، وسد الفجوة ، وما إلى ذلك ، أعتقد أن "الفهرس" في جدول البيانات يمكن تحسينه بطريقة ما لتمكين مثل هذه العمليات.

بالطبع ، يمكن إجراء هذه العمليات في وظائف data.table مثل shift و by . لقد اعتقدت للتو أن جدول البيانات index لديه الكثير من الإمكانات التي يمكن استكشافها. أوافق على أن هذا يجب أن ينتمي إلى قضية مختلفة. لكني لا أعرف كيف أنقلها دون أن أفقد المناقشات أعلاه ...