Updating and systematising NDArray typing

[davidorme]

Description

This PR makes the NDArray typing across the project systematic:

• Changes NDArray[np.float32] to NDArray[np.float64]
• Changes bare NDArray to the appropriate type (99% NDArray[np.float64], 1% NDArray[np.datetime64])
• Updates a couple of .astype(np.float32)
• Imports numpy in a couple of modules as needed

Fixes #334

Type of change

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist

• Make sure you've run the pre-commit checks: $ pre-commit run -a
• All tests pass: $ poetry run pytest

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.91%. Comparing base (1f315ba) to head (c0ec295).
Report is 294 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #335      +/-   ##
===========================================
- Coverage    95.29%   94.91%   -0.38%     
===========================================
  Files           28       34       +6     
  Lines         1720     2556     +836     
===========================================
+ Hits          1639     2426     +787     
- Misses          81      130      +49     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[j-emberton]

Are we happy with the idea that people now will be instructed not to pass ints into functions doing ordinary arithmetic or array ops? For most functions, integers will work fine.

[davidorme]

I think that depends on what we mean by people? Since the typing is static, this change doesn't actually stop users from passing in integer arrays to those arguments (or indeed anything that isn't explicitly blocked by downstream input checking!), but it does indicate to developers that something is expecting to work with floats. We could expand the typing to make it explicit that these are "numeric" rather than implicitly allowing integers but I think that only affects developers.

[j-emberton]

This is incredibly pernickety.

Do we care if we pass values as ints into a function that requires a float. Examples of this in the code are at line 92 in pmodel_environment.py where we call bounds_checker and pass in -25 and 80 as ints, when the function args are type hinted as floats.

[j-emberton]

I think that depends on what we mean by people? Since the typing is static, this change doesn't actually stop users from passing in integer arrays to those arguments (or indeed anything that isn't explicitly blocked by downstream input checking!), but it does indicate to developers that something is expecting to work with floats. We could expand the typing to make it explicit that these are "numeric" rather than implicitly allowing integers but I think that only affects developers.

It might make sense to just have np.number rather than float64. This is tidy for developers and docs, plus allows use of decimal, fractions etc.

[davidorme]

I don't think we do care if int gets passed in. We don't test for it and they'll get converted (unless I guess someone passes in really long integers that can't be represented in np.float64?). I guess I'm inclined to leave it as is for now.

[j-emberton]

ok cool, in that case I'm happy to approve

[j-emberton]

lgtm