Implement as_draws generics in other packages?

オープン
#183 コメント 13 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
r
領域
api

調査の方向性

まず posterior に既存する as_draws/as_draws_XXX ジェネリックと、brms、rstanarm、rstan、cmdstanr の変換 API を比較します。各統合でどのオブジェクトクラスと draw 形式をサポートするべきかを定義し、実装前にメンテナーと提案内容を確認します。完了の定義は、パッケージ横断のインターフェースについて合意されていることです。

索引モデルが issue の本文から書いたものです。

説明

interface

(Note: I'm opening this here for discussion first rather than opening a bunch of essentially duplicate issues in several packages)

Now that posterior is on CRAN, would it make sense to have as_draws() / as_draws_XXX() implementations for objects in brms, rstanarm, rstan, cmdstanr, etc? I think it would help fulfill part of the promise of {posterior}; that is, users don't have to remember what particular function for a given model type gets them draws in what format, they can just chuck the object into as_draws_XXX() for whatever format they want.

E.g. with cmdstanr, rather than doing this:

model$draws(format = "XXX")

People could (optionally) do:

model %>% as_draws_XXX()

The advantage of the latter code is that as more packages also implement these generics it becomes easier for users to move between packages. @paul-buerkner @jgabry thoughts? I dunno if this was already the plan anyway.

主要言語
R
スター
172
フォーク
27
平均マージ
5日 12時間
マージ済み PR(30日)
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

stan-dev/posterior のほかの issue

stan-dev/posterior の issue をすべて見る

似ている issue

R の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。