Data.table: fungsi rolling, agregat bergulir, jendela geser, rata-rata bergerak

Usulan implementasi rollmean , disederhanakan.

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

ya, dan banyak lagi fungsi yang digulung mengikuti ide dasar yang sama (termasuk
deviasi standar bergulir / momen berbasis harapan apa pun, dan fungsi apa pun
seperti rollproduct yang menggunakan * yang dapat dibalik alih-alih + untuk digabungkan di dalam
jendela

Saya selalu membayangkan fungsionalitas rolling window sebagai pengelompokan dataset menjadi beberapa grup yang tumpang tindih (windows). Maka API akan terlihat seperti ini:

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

Kemudian jika j berisi, katakanlah, mean(A) , kita dapat menggantinya secara internal dengan rollmean(A) -- persis seperti yang kita lakukan dengan gmean() sekarang. Atau j dapat berisi fungsionalitas yang rumit (misalnya, jalankan regresi untuk setiap jendela), dalam hal ini kami akan menyediakan .SD data.table untuk itu -- persis seperti yang kami lakukan dengan grup sekarang.

Dengan cara ini tidak perlu memperkenalkan 10+ fungsi baru, cukup satu. Dan rasanya data.table-y dalam semangat juga.

ya setuju

Pada Sabtu, 21 Apr 2018, 15:38 Pasha Stetsenko [email protected]
menulis:

Saya selalu membayangkan fungsionalitas jendela bergulir sebagai pengelompokan
kumpulan data menjadi beberapa kelompok yang tumpang tindih (jendela). Maka API akan terlihat
sesuatu seperti ini:

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

Kemudian jika j berisi, katakanlah, mean(A), kita dapat menggantinya secara internal dengan
rollmean(A) -- persis seperti yang kita lakukan dengan gmean() sekarang. Atau j bisa
berisi fungsionalitas yang rumit secara sewenang-wenang (katakanlah, jalankan regresi untuk
setiap jendela), dalam hal ini kami akan menyediakan .SD data.table untuk itu -- tepatnya
seperti yang kita lakukan dengan kelompok sekarang.

Dengan cara ini tidak perlu memperkenalkan 10+ fungsi baru, cukup satu. Dan itu
merasakan semangat data.table-y juga.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Rdatatable/data.table/issues/2778#issuecomment-383275134 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AHQQQdbADiE4aAI1qPxPnFXUM5gR-0w2Tks5tquH8gaJpZM4TeTQf
.

@st-pasha ide yang menarik, terlihat seperti semangat data.table-y, tetapi akan memaksakan banyak batasan, dan tidak terlalu sesuai untuk kategori fungsi ini.

• cara melakukan rollmean berdasarkan grup

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

• cara menghitung ukuran jendela yang berbeda untuk kolom yang berbeda

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

• bagaimana menghitung rollmean di luar [.data.table seperti yang sekarang kita izinkan untuk shift

rollmean(rnorm(10), 3)

• bagaimana mendukung pertanyaan seperti

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

• cara memanggil mean dan rollmean dalam panggilan j

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

Biasanya saat menggunakan by kami menggabungkan data ke jumlah baris yang lebih sedikit, sementara fungsi rolling selalu mengembalikan vektor dengan panjang yang sama dengan input. Jenis fungsi dalam SQL ini memiliki API dengan gaya berikut:

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

Anda masih dapat menggabungkannya dengan GROUP BY sebagai berikut:

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

Jadi di SQL fungsi-fungsi itu tetap di SELECT yang merujuk ke j di DT.
Di DT kita bisa mencapai hal yang sama dengan:

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

Fungsi bergulir cocok dengan kategori fungsi yang sama dengan shift yang juga mengembalikan jumlah baris yang sama seperti yang didapat pada input.
Pergeseran dalam SQL terlihat seperti:

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

mean dan rollmean bukan hanya fungsi yang berbeda, mereka adalah kategori fungsi yang berbeda. Yang satu dimaksudkan untuk berkumpul menurut kelompok, yang lain tidak berkumpul sama sekali. Ini mudah terlihat di SQL di mana kita tidak menggunakan GROUP BY untuk jenis fungsi bergulir tetapi kita perlu menggunakan GROUP BY untuk agregat seperti mean (akhirnya mendapatkan total hibah saat mengelompokkan klausa tidak ada).
Saya tidak melihat alasan yang kuat untuk mencoba menerapkan aturan pengoptimalan yang sama seperti yang kami lakukan untuk mean , terutama ketika itu tidak benar-benar cocok untuk use case, dan semua itu hanya demi data.table-y Roh. Proposal saat ini adalah data.table-y spirit juga, dapat dengan mudah digabungkan dengan := , sama seperti shift . Itu hanya menambahkan serangkaian fungsi baru, saat ini tidak tersedia di data.table.

@jangorecki Terima kasih, ini semua pertimbangan yang valid. Tentu saja orang yang berbeda memiliki pengalaman yang berbeda, dan pandangan yang berbeda tentang apa yang harus dianggap "alami".

Dimungkinkan untuk melakukan rollmean berdasarkan grup: ini hanya pengelompokan 2 tingkat: DT[, mean(V1), by=.(V2, roll(3))] . Namun saya tidak melihat cara membuat ukuran jendela yang berbeda pada kolom yang berbeda dengan sintaks saya ...

Saya harus mengakui bahwa saya belum pernah melihat sintaks SQL untuk rolling join sebelumnya. Sangat menarik bahwa mereka menggunakan agregator standar seperti AVG namun menerapkan spesifikasi windowing untuk itu. Melihat dokumentasi Transact-SQL ada beberapa ide menarik di sana, misalnya perbedaan antara pemilihan baris logis/fisik. Mereka mengizinkan operator "OVER" yang berbeda pada kolom yang berbeda, namun dalam semua contoh yang mereka berikan, klausa OVER yang sama diulang beberapa kali. Jadi ini menunjukkan bahwa kasus penggunaan ini jauh lebih umum, dan karenanya menggunakan satu grup roll() akan menghasilkan lebih sedikit pengulangan.

Juga, pertanyaan SO ini memberikan wawasan yang menarik mengapa sintaks OVER diperkenalkan dalam SQL sama sekali:

Anda dapat menggunakan GROUP BY SalesOrderID. Perbedaannya adalah, dengan GROUP BY Anda hanya dapat memiliki nilai agregat untuk kolom yang tidak termasuk dalam GROUP BY. Sebaliknya, menggunakan fungsi agregat berjendela alih-alih GROUP BY, Anda dapat mengambil nilai agregat dan non-agregat. Artinya, meskipun Anda tidak melakukan itu dalam kueri contoh Anda, Anda dapat mengambil nilai OrderQty individual dan jumlah, hitungan, rata-rata, dll. melalui grup SalesOrderID yang sama.

Jadi tampaknya sintaks dirancang untuk menghindari batasan SQL standar di mana hasil kelompok-berdasarkan tidak dapat digabungkan dengan nilai yang tidak diagregasi (yaitu memilih A dan mean(A) dalam ekspresi yang sama). Namun data.table tidak memiliki batasan seperti itu, sehingga ia memiliki lebih banyak kebebasan dalam memilih sintaks.

Sekarang, jika kita ingin benar-benar maju, kita perlu berpikir dalam perspektif yang lebih luas: apa fungsi "bergulir", untuk apa fungsinya, bagaimana bisa diperpanjang, dll. dari sudut pandang ahli statistik:

Fungsi "Rolling mean" digunakan untuk menghaluskan beberapa input yang bising. Katakanlah, jika Anda memiliki pengamatan dari waktu ke waktu dan Anda ingin memiliki beberapa gagasan tentang "kuantitas rata-rata", yang bagaimanapun akan bervariasi dari waktu ke waktu meskipun sangat lambat. Dalam hal ini "rata-rata bergulir selama 100 pengamatan terakhir" atau "berputar rata-rata atas semua pengamatan sebelumnya" dapat dipertimbangkan. Demikian pula, jika Anda mengamati kuantitas tertentu pada rentang input, Anda dapat menghaluskannya dengan menerapkan "rata-rata bergulir lebih dari ±50 pengamatan".

• Jadi, ekstensi pertama adalah melihat "jendela halus": bayangkan mean atas pengamatan masa lalu di mana semakin jauh pengamatan di masa lalu, semakin sedikit kontribusinya. Atau rata-rata pengamatan terdekat pada kernel Gaussian.
• Kedua adalah jendela adaptif. Misalnya, jika Anda memiliki input derau yang ditentukan pada interval [0, 1], maka menghaluskannya menggunakan jendela ±N menghasilkan hasil yang bias di dekat tepi. Penduga tak bias akan mengadaptasi bentuk jendela berdasarkan jarak dari tepi.
• Resample smoothing: pembatasan untuk menghasilkan pengamatan yang sama persis seperti pada data sumber terlalu membatasi. Jika Anda menganggap data Anda sebagai pengamatan bising dari beberapa fungsi yang mendasarinya, maka sangat masuk akal untuk meminta menghitung nilai yang dihaluskan dari fungsi tersebut pada mesh yang lebih kasar / lebih halus daripada input aslinya. Atau mungkin data asli ditempatkan tidak teratur dan Anda ingin mengambil sampel ulang ke kisi biasa.
• Jackknife: untuk setiap pengamatan Anda ingin menghitung rata-rata/regresi atas semua pengamatan kecuali arus.
• K-fold split: melihat data sebagai beberapa grup di mana setiap grup hanya mengecualikan sebagian kecil dari pengamatan.

Semua ini dapat diimplementasikan sebagai operator pengelompokan yang diperluas, dengan jendela bergulir menjadi salah satu elemen dalam daftar ini. Yang sedang berkata, saya tidak mengapa kita tidak bisa memiliki keduanya.

Saya harus mengakui bahwa saya belum pernah melihat sintaks SQL untuk rolling join sebelumnya.

Saya berasumsi maksud Anda fungsi rolling, masalah tidak ada hubungannya dengan rolling join.

Mereka mengizinkan operator "OVER" yang berbeda pada kolom yang berbeda, namun dalam semua contoh yang mereka berikan, klausa OVER yang sama diulang beberapa kali. Jadi ini menunjukkan bahwa kasus penggunaan ini jauh lebih umum, dan karenanya menggunakan grup roll() tunggal akan menghasilkan lebih sedikit pengulangan.

Ini hanya masalah kasus penggunaan, jika Anda memanggil OVER() yang sama berkali-kali, Anda mungkin merasa lebih berkinerja untuk menggunakan GROUP BY , membangun tabel pencarian dan menggunakan kembali dalam kueri lain. Apa pun contoh yang ada, pengulangan OVER() diperlukan untuk mempertahankan fitur lokalitas untuk setiap ukuran yang disediakan. Kasus penggunaan saya dari Gudang Data tidak sesederhana yang berasal dari Microsoft docs.

Sebaliknya, menggunakan fungsi agregat berjendela alih-alih GROUP BY, Anda dapat mengambil nilai agregat dan non-agregat.

Di data.table kita melakukan := dan by dalam satu query untuk mencapainya.

Jadi tampaknya sintaks dirancang untuk menghindari batasan SQL standar di mana hasil kelompok-berdasarkan tidak dapat digabungkan dengan nilai yang tidak diagregasi (yaitu memilih A dan mean(A) dalam ekspresi yang sama). Namun data.table tidak memiliki batasan seperti itu, sehingga memiliki lebih banyak kebebasan dalam memilih sintaks.

Ini tidak banyak membatasi SQL tetapi hanya desain GROUP BY, yang akan diagregasi, dengan cara yang sama seperti by agregat kita. API baru diperlukan untuk mencakup fungsionalitas jendela baru. Pengelompokan untuk fungsi jendela SQL dapat disediakan untuk setiap panggilan fungsi menggunakan FUN() OVER (PARTITION BY ...) mana _partition by_ seperti pengelompokan lokal untuk ukuran tunggal. Jadi untuk mencapai fleksibilitas SQL kita perlu menggunakan j = mean(V1, roll=5) atau j = over(mean(V1), roll=5) menjaga API itu di j . Tetap saja pendekatan ini tidak akan memungkinkan untuk mendukung semua kasus penggunaan yang disebutkan di atas.

Anda dapat memuluskannya dengan menerapkan "rata-rata bergulir lebih dari ±50 pengamatan".

Inilah yang digunakan untuk argumen align .

Jadi, ekstensi pertama adalah melihat "jendela halus": bayangkan mean atas pengamatan masa lalu di mana semakin jauh pengamatan di masa lalu, semakin sedikit kontribusinya. Atau rata-rata pengamatan terdekat pada kernel Gaussian.

Ada banyak varian (jumlah yang hampir tidak terbatas) dari rata-rata bergerak, fungsi jendela pemulusan yang paling umum (selain rollmean/SMA) adalah rata-rata bergerak eksponensial (EMA). Mana yang harus disertakan, dan mana yang tidak, bukanlah hal yang sepele untuk diputuskan, dan sebenarnya yang terbaik untuk membuat keputusan itu sesuai dengan permintaan fitur yang akan datang dari pengguna, sejauh ini tidak ada yang seperti ini yang diminta.

Semua ini dapat diimplementasikan sebagai operator pengelompokan yang diperluas, dengan jendela bergulir menjadi salah satu elemen dalam daftar ini.

Tentunya mereka bisa, tetapi jika Anda melihat SO, dan masalah yang dibuat di repo kami, Anda akan melihat bahwa beberapa fungsi bergulir di sini bertanggung jawab atas 95+% permintaan dari pengguna. Saya senang bekerja di EMA dan MA lainnya (walaupun saya tidak yakin apakah data.table adalah tempat terbaik untuk itu), tetapi sebagai masalah terpisah. Beberapa pengguna, termasuk saya, sedang menunggu rata-rata pergerakan sederhana di data.table selama 4 tahun.

Inilah pendapat saya, berasal dari sudut pandang ahli statistik

Sudut pandang saya berasal dari Data Warehousing (di mana saya menggunakan fungsi jendela, setidaknya seminggu sekali) dan analisis tren harga (di mana saya menggunakan puluhan moving average yang berbeda).

rollmean draft didorong ke cabang roll . Saya menemukan sebagian besar paket lain yang mengimplementasikan rolling mean tidak dapat ditangani dengan baik dengan na.rm=FALSE dan NA yang ada di input. Implementasi ini menangani NA secara konsisten ke mean , yang membebankan beberapa overhead tambahan karena panggilan ISNAN . Kami dapat mengizinkan API ke versi yang lebih cepat tetapi kurang aman jika pengguna yakin tidak ada NA dalam input.
PR ada di #2795

@mattdowle menjawab pertanyaan dari PR

Mengapa kita melakukan ini di dalam data.table? Mengapa kami mengintegrasikannya alih-alih berkontribusi ke paket yang ada dan menggunakannya dari data.table?

1. Ada 3 masalah berbeda yang dibuat meminta fungsionalitas itu di data.table. Juga beberapa pertanyaan SO ditandai data.table. Pengguna mengharapkan itu berada dalam cakupan data.table.
2. data.table sangat cocok untuk data deret waktu dan agregat bergulir adalah statistik yang cukup berguna di sana.

tebakan saya adalah sintaks (fitur hanya mungkin atau nyaman jika dibangun ke dalam data.table; misalnya di dalam [...] dan dioptimalkan) dan membangun internal data.table ke dalam fungsi bergulir di level C; misalnya froll* harus mengetahui dan menggunakan indeks dan kunci data.table. Jika demikian, lebih spesifik tentang itu diperlukan; misalnya contoh singkat sederhana.

Bagi saya pribadi ini tentang kecepatan dan kurangnya rantai ketergantungan, saat ini tidak mudah untuk dicapai.
Kunci/indeks dapat berguna untuk frollmin/frollmax, tetapi kecil kemungkinannya pengguna akan membuat indeks pada variabel ukuran. Kecil kemungkinan pengguna akan membuat indeks pada variabel ukuran, juga kami belum melakukan pengoptimalan ini untuk min/maks. Saya tidak melihat banyak hal untuk optimasi GForce karena memori yang dialokasikan tidak dilepaskan setelah panggilan roll* tetapi dikembalikan sebagai jawaban (sebagai lawan dari rata-rata non-rolling, jumlah, dll.).

Jika tidak ada argumen yang meyakinkan untuk pengintegrasian, maka kita harus berkontribusi pada paket lain sebagai gantinya.

Saya mencantumkan beberapa di atas, jika Anda tidak yakin saya sarankan Anda untuk mengisi pertanyaan kepada pengguna data.table, bertanya di twitter, dll untuk memeriksa respons. Fitur ini sudah lama diminta dan oleh banyak pengguna. Jika tanggapan tidak meyakinkan Anda, Anda dapat menutup masalah ini.

Saya menemukan sparklyr dapat mendukung fungsi rolling dengan sangat baik dalam dataset skala yang sangat besar.

@harryprince dapat memberi sedikit lebih banyak cahaya dengan memberikan kode contoh bagaimana Anda melakukannya di sparklyr?
Menurut sketsa dplyr "Fungsi jendela"

Agregat bergulir beroperasi di jendela lebar tetap. Anda tidak akan menemukannya di base R atau di dplyr, tetapi ada banyak implementasi di paket lain, seperti RcppRoll.

AFAIU Anda menggunakan API percikan khusus melalui sparklyr yang antarmuka dplyrnya tidak diimplementasikan, benar?

Masalah ini adalah tentang agregat bergulir, "jenis" fungsi jendela lainnya sudah ada di data.table untuk waktu yang lama.

Memberikan beberapa contoh sehingga kami dapat membandingkan kinerja (dalam memori) vs sparklyr / SparkR juga akan membantu.

Baru terpikir oleh saya bahwa pertanyaan ini:

bagaimana cara menghitung ukuran jendela yang berbeda untuk kolom yang berbeda?

sebenarnya memiliki cakupan yang lebih luas, dan tidak berlaku untuk fungsi rolling saja.

Misalnya, tampaknya sangat masuk akal untuk menanyakan cara memilih harga produk rata-rata menurut tanggal, lalu menurut minggu, dan mungkin menurut minggu+kategori -- semuanya dalam kueri yang sama. Jika kita pernah mengimplementasikan fungsionalitas seperti itu, sintaks alami untuk itu bisa menjadi

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

Sekarang, jika fungsi ini sudah diterapkan, maka itu akan menjadi lompatan sederhana dari sana ke sarana bergulir:

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

Tidak mengatakan bahwa ini jelas lebih baik daripada rollmean(price, 5) -- hanya memberikan beberapa alternatif untuk dipertimbangkan...

@st-pasha

cara memilih harga produk rata-rata menurut tanggal, lalu menurut minggu, dan mungkin menurut minggu+kategori -- semuanya dalam kueri yang sama.

AFAIU ini sudah dimungkinkan menggunakan ?groupingsets , tetapi belum terhubung ke [.data.table .

@jangorecki , @st-pasha , dan Co. -- Terima kasih atas semua pekerjaan Anda dalam hal ini! Saya ingin tahu mengapa dukungan sebagian jendela dihapus dari ruang lingkup, apakah ada potensi fungsi itu untuk membuatnya kembali ke peta jalan? Akan berguna bagi saya kadang-kadang, dan mengisi celah fungsionalitas yang setahu saya belum diisi zoo atau RcppRoll .

Pertanyaan Stack Overflow ini adalah contoh yang baik dari aplikasi bergulir yang dapat mengambil manfaat dari argumen partial = TRUE .

@msummersgill Terima kasih atas umpan baliknya. Di posting pertama saya secara eksplisit menautkan komit sha di mana kode fitur sebagian jendela dapat ditemukan. Implementasi yang ada kemudian dihapus untuk mengurangi kompleksitas kode. Itu juga membebankan biaya kinerja yang kecil bahkan ketika tidak menggunakan fitur itu. Fitur ini dapat (dan mungkin harus) diimplementasikan dengan cara lain, pertama selesai apa adanya, dan kemudian hanya mengisi sebagian jendela yang hilang menggunakan loop tambahan 1:window_size . Jadi overhead fitur itu hanya terlihat saat Anda menggunakannya. Namun demikian, kami menyediakan fungsionalitas tersebut melalui argumen adaptive , di mana fitur partial hanyalah kasus khusus dari rata-rata bergulir adaptive . Ada contoh bagaimana mencapai partial menggunakan adaptive di ?froll manual . Tempelkan di sini:

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)

Tentu saja tidak akan seefisien fungsi rolling non-adaptif menggunakan loop ekstra untuk mengisi hanya sebagian jendela.
AFAIK zoo memiliki fitur partial .

Apakah kalian punya rencana untuk menambahkan fungsi regresi bergulir ke data.table?

@waynelapierre jika akan ada permintaan untuk itu, maka ya. Anda memiliki +1 saya

terima kasih ini bagus. Padahal hanya satu pertanyaan. Saya hanya melihat agregat gelinding sederhana, seperti rata-rata gelinding atau median gelinding. Apakah Anda juga menerapkan fungsi rolling yang lebih halus seperti rolling dataframe DT? Katakanlah, buat DT bergulir menggunakan 10 obs terakhir dan jalankan regresi lm di atasnya.

Terima kasih!

@randomgambit saya akan mengatakan itu di luar jangkauan, kecuali akan ada permintaan tinggi untuk itu. Tidak akan terlalu sulit untuk melakukannya lebih cepat dari basis R/zoo hanya dengan menangani loop bersarang di C. Tetapi kita harus mencoba mengimplementasikannya menggunakan algoritma "online", untuk menghindari loop bersarang. Ini lebih rumit, dan kami akhirnya bisa melakukannya untuk statistik apa pun, jadi kami harus memotong statistik itu di beberapa titik.

@jangorecki menarik terima kasih. Itu berarti saya akan terus menggunakan tsibble untuk menyematkan... DATA.TABLES dalam tibble ! pusing :D

Mencoba menggunakan frollmean untuk menghitung "kurva logistik" nonparametrik yang menunjukkan P[y | x] untuk biner y menggunakan tetangga terdekat x . Terkejut y disimpan sebagai logical tidak dilemparkan secara otomatis ke integer :

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

Kesalahan dalam froll(fun = "mean", x = x, n = n, fill = fill, algo = algo, align = align, :
x harus bertipe numerik

Contoh bagaimana argumen vektor x / n dapat memengaruhi kinerja.
https://github.com/AdrianAntico/RemixAutoML/commit/d8370712591323be01d0c66f34a70040e2867636#r34784427
lebih sedikit loop, kode lebih mudah dibaca, jauh lebih cepat (percepatan 10x-36x).

frollapply siap: 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

hai teman-teman, akankah FUN (ditentukan pengguna) yang diteruskan ke frollapply diubah untuk mengembalikan objek R atau data.frame(data.table), x yang diteruskan ke frollapply bisa berupa data.tabel karakter tidak dipaksa ke numerik, maka FUN bisa dilakukan di label dan frollapply mengembalikan daftar? kemudian kita dapat melakukan regresi bergulir atau pengujian bergulir seperti melakukan pengujian Benford atau ringkasan pada label.

Itu selalu berguna untuk memberikan contoh yang dapat direproduksi. Untuk memperjelas... dalam skenario seperti itu Anda ingin frollapply(dt, 3, FUN) mengembalikan daftar panjang nrow(dt) mana setiap elemen daftar akan data.table dikembalikan oleh FUN(dt[window]) ?
frollapply(x=dt, n=3, fun=FUN)[[3]] sama dengan FUN(dt[1:3])
frollapply(x=dt, n=3, FUN=FUN)[[4]] sama dengan FUN(dt[2:4])
Apakah itu benar? @jerryfuyu0104

Saat ini kami mendukung beberapa kolom yang diteruskan ke argumen pertama tetapi kami memprosesnya secara terpisah, perulangan. Kita mungkin memerlukan beberapa argumen tambahan multi.var=FALSE , ketika disetel ke true itu tidak akan mengulang x (seperti sekarang: list(FUN(x[[1]]),FUN(x[[2]])) ) tetapi meneruskan semua kolom FUN(x) .

ada pembaruan untuk ini?

Saya mendukung permintaan sebelumnya.

Lebih jauh, apakah mungkin untuk mendukung argumen "sebagian" untuk memungkinkan jendela sebagian?

@eliocamp dapatkah Anda menguraikan apa itu jendela partial ?

@eliocamp dimungkinkan untuk mendukung argumen "sebagian". Anda mungkin sudah mengetahuinya tetapi dukungan untuk fungsi ini sudah ada, menggunakan argumen adaptive=TRUE , lihat contoh untuk detailnya.

Ini berarti menghitung fungsi dari awal hingga akhir alih-alih membentuk titik setengah jendela.
Misalnya untuk rata-rata bergulir 11 lebar, elemen pertama yang dikembalikan akan menjadi rata-rata elemen 1 sampai 6. Yang kedua, rata-rata dari 1 sampai 7, dan seterusnya.

@jangorecki oh, terima kasih, saya tidak tahu itu! Saya akan mengeceknya.

Setuju, kita perlu argumen parsial, tidak hanya untuk kenyamanan tetapi juga untuk kecepatan. adaptive=TRUE menambahkan overhead.
Dan ya, kita juga perlu regresi bergulir, jadi menyediakan banyak variabel dan menggulirkannya sekaligus, tidak masing-masing secara terpisah.
Tidak ada pembaruan tentang status mereka.

Saya ingin membantu tetapi keterampilan C++ saya sama sekali tidak ada. :keringat: Apakah menurut Anda ini cocok untuk pemula?

Kami tidak membuat kode dalam C++ tetapi dalam C. Ya, ini adalah tempat yang baik untuk memulai. Saya melakukan hal itu di frollmean.

Saya melihat kodenya dan sepertinya menakutkan. Tapi saya akan memperbarui Anda dalam hal apapun.

Tapi sekarang, untuk permintaan lain: frollmean(.SD) harus mempertahankan nama. Secara lebih umum, froll* harus mempertahankan nama jika inputnya seperti daftar dengan nama.

Sebagai pengguna data.table yang sering, saya merasa sangat berguna untuk memiliki fitur "sadar waktu", seperti yang saat ini ditawarkan dalam paket tsibble . Sayangnya paket ini dikembangkan sekitar dplyr . Saya ingin tahu apakah implementasi data.table bisa dilakukan. Fungsi jendela yang diusulkan dalam masalah ini adalah bagian dari fitur tersebut.

@ywhcuhk Terima kasih atas umpan baliknya, saya sebenarnya berpikir masalah ini sudah meminta terlalu banyak. Sebagian besar tercakup dengan baik oleh gulungan paket yang masih ringan yang sangat cepat. Untuk fitur lainnya, saya sarankan untuk membuat masalah baru untuk setiap fitur yang Anda minati, jadi diskusi apakah kami ingin menerapkan/mempertahankan dapat diputuskan untuk masing-masing secara terpisah. Hanya dari melihat readme of tstibble saya tidak melihat sesuatu yang baru yang ditawarkannya ...
Judulnya adalah "Bingkai Data Temporal Rapi" tetapi tampaknya tidak menawarkan penggabungan temporal.

Terima kasih @jangorecki atas tanggapannya. Mungkin ini adalah masalah yang bergantung pada konteks. Struktur data yang paling sering saya tangani dikenal sebagai "data panel", dengan ID dan waktu. Jika program "mengetahui" fitur data ini, banyak operasi, terutama operasi deret waktu, akan menjadi sangat mudah. Untuk seseorang yang mengetahui STATA, ini adalah operasi berdasarkan tsset dan xtset , seperti lead, lag, fill gap, dll. Saya pikir "indeks" di data.table dapat ditingkatkan entah bagaimana untuk mengaktifkan operasi tersebut.

Tentu saja, operasi ini dapat dilakukan dalam fungsi data.table seperti shift dan by . Saya hanya berpikir index di data.table memiliki banyak potensi untuk dieksplorasi. Saya setuju ini harus milik masalah yang berbeda. Tapi saya tidak tahu bagaimana cara memindahkannya tanpa kehilangan diskusi di atas ...