You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we built the first release of the ITR tool, we didn't have any 2021 data. Now that we are most of the way through 2022, there's lots of 2021 data (but not all 2021 data is reported yet). When we transform our target data projections (base_providers.py:get_company_projected_targets) into a DataFrame, data's that's projected from 2021 to 2050 (because we have no actual data) gets a full row of data. Data that was projected from 2022 to 2050 (because we have actual 2021 data) gets np.nan as a target projection. This one element in the array dis-anchors our CAGR computation and returns a row of np.nan values, instead of a proper calculation of the projection.
One way to fix this is to compute the CAGR only upon finding the first valid index of each row, and trust that we'd never ask for a target value when we have factual data instead. Another way is to punch our actual data into the left side of the target projection. Either way, we need to fix this so users are not forced to ignore intermediate data updates throughout the year.
The text was updated successfully, but these errors were encountered:
When we built the first release of the ITR tool, we didn't have any 2021 data. Now that we are most of the way through 2022, there's lots of 2021 data (but not all 2021 data is reported yet). When we transform our target data projections (base_providers.py:get_company_projected_targets) into a DataFrame, data's that's projected from 2021 to 2050 (because we have no actual data) gets a full row of data. Data that was projected from 2022 to 2050 (because we have actual 2021 data) gets np.nan as a target projection. This one element in the array dis-anchors our CAGR computation and returns a row of np.nan values, instead of a proper calculation of the projection.
One way to fix this is to compute the CAGR only upon finding the first valid index of each row, and trust that we'd never ask for a target value when we have factual data instead. Another way is to punch our actual data into the left side of the target projection. Either way, we need to fix this so users are not forced to ignore intermediate data updates throughout the year.
The text was updated successfully, but these errors were encountered: