Vectorizing fredr_series about fredr HOT 4 CLOSED

Note that to do this in a tidy way the structure of the return value would have to change from:

# A tibble: 846 x 2
   date       UNRATE
   <date>      <dbl>
 1 1948-01-01    3.4
 2 1948-02-01    3.8
 3 1948-03-01    4  
 4 1948-04-01    3.9
 5 1948-05-01    3.5
 6 1948-06-01    3.6
 7 1948-07-01    3.6
 8 1948-08-01    3.9
 9 1948-09-01    3.8
10 1948-10-01    3.7
# ... with 836 more rows

to

# A tibble: 846 x 3
   date       key    value
   <date>     <chr>  <dbl>
 1 1948-01-01 UNRATE   3.4
 2 1948-02-01 UNRATE   3.8
 3 1948-03-01 UNRATE   4  
 4 1948-04-01 UNRATE   3.9
 5 1948-05-01 UNRATE   3.5
 6 1948-06-01 UNRATE   3.6
 7 1948-07-01 UNRATE   3.6
 8 1948-08-01 UNRATE   3.9
 9 1948-09-01 UNRATE   3.8
10 1948-10-01 UNRATE   3.7
# ... with 836 more rows

so we can stack series.

I'd be okay with just doing it for fredr_series_observations(). It makes the most sense there and is easy to understand how you'd add multiple series together. The approach could be:

• fredr_series_observations() changes to fredr_series_observations_single() (it would not be exported)
• The inners of fredr_series_observations_single() changes a little so that it returns in the format like above (an easy change from the looks of it)
• The "new" fredr_series_observations() function does an lapply() across the series_id values, calling the single function each time. Then you do do.call(rbind, lapply_result_list) to get your final product.

Ideally I'd use purrr::map_dfr() but that implicitly introduces a purrr AND a dplyr dependency.

from fredr.

Upon further reflection, I think this is a little beyond the scope of something this package should support.

With the advent of purrr, I'm no longer sure I see the pressing need to vectorize single function I write. We could include the purrr::map_dfr() approach as a recipe in the vignettes. Did you have a use case in which this approach is too cumbersome?

from fredr.

I was just going with the general R theory that things are vectorised. But I totally see your point. It's nice with purrr too because pmap() gives us iteration over both the series_id and, say, the observation_start for free, where otherwise we'd have to do a lot of work to vectorize every arg.

That being said, I do think we may want to change the structure of the return value so they stack nicely. Maybe have a date, series and value column. Do you agree?

from fredr.

Yes I see what you're saying. date, series_id and value as columns is a good compromise for now.

from fredr.