Matthew Kay

Moving my comment here... Ah damn. Could also fall back to the for loop version in that case I suppose... Honestly I'd guess most use cases of the regex version...

Just to potentially uncomplicate our lives: is there a strong use case for 256 byte+ regex here, whether passed by the user or assembled by us internally from a list...

> I tested the single regex pattern with | yesterday but it turns out there is a size limit. Even with perl = TRUE, it starts throwing errors after certain...

Interesting --- if I am reading this correctly, arrow supports dplyr's database-style interface right? i.e. mutate() / select() / etc construct queries that are not executed until collect() is called....

Yes, I think this would still be useful. At some point I'd like to revisit @kgoldfeld's excellent post and assess what pain points remain and which features here we can...

@paul-buerkner I'm not sure I understand the filtering issue with dim in a separate column --- it seems to me it would be easier to filter if dims were not...

This looks like it could be very useful to me! Two quick thoughts if we go down this road: 1. To be consistent with other functions I'd consider a verb-ish...

> The first case is easier, as some function in posterior could be given a set of draws objects and corresponding weights. These could be merged to a draw object...

Awesome! I'll close this and open issues on rstanarm and cmdstanr. `as_draws_XXX()` appears to already work on `rstan::stanfit` from my quick testing, as stanfit objects appear to mimic arrays so...

> 1. Shall we add additional arguments to `as_draws_XXX.somefit` to mimic existing applications people are used to from `as.array` and friends. Specifically: > * Shall we add a `variable` argument...