Optionally skip vectorization of a policy function

[lars-reimann]

What problem do you want to solve?

Related to #708

Add a new parameter is_vectorized to the policy_info decorator to indicate that a function is already vectorized. In that case, it is not vectorized again.

Todo

• [X] Pick an appropriate title.
• [X] Put Closes #XXXX in the first PR comment to auto-close the relevant issue once the PR is accepted. This is not applicable if there is no corresponding issue.
• [x] Document PR in CHANGES.md.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.46%. Comparing base (263c169) to head (a933a75).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #721 +/- ## ========================================== + Coverage 89.40% 89.46% +0.06% ========================================== Files 51 51 Lines 3615 3618 +3 ========================================== + Hits 3232 3237 +5 + Misses 383 381 -2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[MImmesberger]

I think skip_vectorization is much better than is_vectorized.

However, given that #708 is supposed to add a new (core) functionality to GETTSIM, I wonder whether the purpose of the decorator is sufficiently easy to understand for non-experts. It took me a minute to understand the necessity of the decorator, now I'm wondering how long it would take someone who has never heard of vectorization (e.g. Stata users?).

From this point of view it might make sense to use a term that is less precise from the programmers point of view, but more understandable for the user. I don't have a good name right now, but given that the not vectorized functions return columns instead of scalars function_output=column with default scalar might do the trick. Given the specified function output, we can infer whether the function should be vectorized or not.

[hmgaudecker]

Thanks!

This will only be used in case of things like joins etc. -- so very confined. We will document it there, so it is easy to find when need arises.

I'd say users who have not seen the term "vectorisation" have no business doing anything other than implementing scalar-level functions :wink:. There is a lot of value in technical precision.

Hence, skip_vectorization it shall be! Thanks both!