fetch_series_by_api_link.m

• document better in header (what goes in varargin)
• line 21: if series_list is empty, set df={}; then return. Otherwise the rest of the code is indented as you have it now...
• line 30: length(dataset_codes)
• example in header doesn't work: fetch_series_by_api_link("https://api.db.nomics.world/v22/series?provider_code=AMECO&dataset_code=ZUTN")
• this function is very slow. It took 10 seconds to run fetch_series_by_api_link("https://api.db.nomics.world/v22/series/BIS/long_pp?limit=1000&offset=0&q=&observations=1&align_periods=1&dimensions=%7B%7D") on my computer. It seems like the bulk of the time is spent in the loop starting on line 109. On first look, you don't need to go through this cell by cell, rather column by column, avoiding the inner loop. You should also be able to assign the first row in one line as ordered_columns_names will be a cell array of strings once #8 (closed) is done, removing the loop on lines 56-60. You may want to initialize df to NaN as well.... anyway, we'll review all of this once #8 (closed) is done.

changed title from {-fetch_series_by_api_link.m-} to fetch_series_by_api_link.m

changed the description

Per your last bullet point, you are right, refactoring the code that way would make the function somewhat cleaner. However, I made some further diagnostics and the most time consuming part is the operation done by normalize_period. Here, I'm performing a datetime conversion. I'm not sure if there is any unexploited efficiency gain regarding this operation.

I am not familiar enough with the code or with the DBnomics data to comment specificially, but just some ideas:

• On the first loop of the test case, it seems as though series.series.period_start_day and series.period are the same, so the normalization can be skipped there and you could simply assign series.period=series.period_start_day; perhaps you can check one cell of series.period_start_day and if it's in the right format simply change the name of the field instead of applying the cellfun.
• In fact, perhaps there is something I am missing. Looking at the cellfun, it seems that you're expecting an input string of type 'yyyy-MM-dd' and converting it to a string of type 29 which is 'yyyy-mm-dd'; these are always functionally the same, no? In what situation is this command needed?
• It's still a good idea to write clean code, so if you can avoid the nested for loops in MATLAB, go for it.

closed via commit 32f2e537