Enable single-precision LifeCycleModel1#103
Conversation
These changes are enough to test single-precision functionality for LifeCycleModel1 (CPU and GPU). Work is likely needed for Grid Interpolation (and many other things), but it shows how not-terribly-invasive the changes are.
In PolicyInd2Val_FHorz.m we simplify our construction by not explicitly passing `1` as the step argument. This is the default, and saves us a cast operation. All the other parameters not cast are magically already the proper floating point precision for our purposes. Note that we needed to change the defaults for `tolerance` in the computation of LifeCycleProfiles, as the default value is smaller than can be represented in single-precision floating point.
At some point in the future it would be cool to make Policy an `int32`, but definitely don't want to make it a `single` (which loses precision after millions of states in the state space). Also, let AggVars be single precision if we are doing that.
|
These changes assume that users cannot be bothered by typing their parameters as single or double fp, so we let them do what they want, and we cast the parameters into the correct precision when we need them. This leads to relatively little need to do other casting. Based on the models tested (LifeCycleModel 1, 8, 18, 35, and 40), it is obvious that Values can, indeed be 32 bit floating point. Policy, however, must either be Using LifeCycleModel40 I did test out using There's a bit of a conflict between optional index parameters and optional precision parameters in the |
There are places in the code where we do need to do floating point operations on policy values (see around line 408 of `StationaryDist_FHorz_Case1`, but this can be handled in the moment and does not foreclose on maintaining `int32` Policies generally.
Applies these learnings: If all we do is store an index matrix from `max` into Policy, we don't need to cast it to the index type. However, if we need to do any maths, we do. If we do any maths with division within a rem/ceil stanza, we need to take care that we are promoting numerator and denominator to double. This is because in the integer world ceil(1/2) is zero, whereas ceil(1.0/2.0) is 1. You'll know you got it wrong when you find lots of zeros in the Policy matrix. Expanded to cover the Huggett&Ventura 2000 replication.
Need to understand why double is better than single for LifeCycleModel35semi!
1 participant
These changes are enough to test single-precision functionality for LifeCycleModel1 (CPU and GPU).
Work is likely needed for Grid Interpolation (and many other things), but it shows how not-terribly-invasive the changes are.