Support precision inference for integers
- Dominant language
- Elm
- Stars
- 51
- Forks
- 69
- Avg merge
- 25m
- Merged PRs (30d)
- 1
Description
_This is work in progress_
Morphir currently only supports arbitrary precision integers. We decided to do this to avoid the complexity of correctness around numeric operations that can cause an overflow. While this makes things very clean and simple in the IR there are a lot of advantages to fixed precision types in some of our backends. So I decided to create this issue to collect all the thoughts we might have around the possibility of supporting this.
## What makes working with fixed precision difficult
The biggest difficulty is around type inference. When you have fixed precision numbers and you are applying arithmetic on them, how do you know what the precision of the result should be?
Some programming languages chose to define simple rules that work in many cases but allow overflows or exceptions to happen at runtime. We can't allow either of those since our main concern is correctness.
RDBMS usually use more accurate precision inference rules that try to avoid overflows by anticipating larger results and increasing the precision when certain operations are applied but they have to balance that with practicality and sometimes they still opt for allowing overflows. Take aggregations as an example, adding up arbitrary number of rows of even the smallest precision will result in values of arbitrary precision.
## How feasible is it to support fixed precision in Morphir
Our main tool for runtime correctness is type checking so if we want to support fixed precision we will have to be able to infer the precision of arithmetic operations so that we can disallow modelers from trying to store higher precision values in lower precision variables.
Both of the approaches above rely on the fact that the languages limit the set of valid operations on integer values so they can define precision rules for every operation. RDBMS go a step further because they also control relational operations like aggregation so they can define rules for both.
Fortunately both applies to Morphir too: we know about all the integer operations in the SDK and we also know about collection operations. This means that we can theoretically infer precision very accurately.
## How would we go about precision inference
As mentioned earlier there are two pieces to the puzzle: track precision for arithmetic operations, track multiplicity for collection operations. The latter is necessary to be able to deal with aggregations but we are free to choose the accuracy anywhere between tracking exact multiplicity or just assuming every collection is infinite size and always using arbitrary precision when any aggregation is done.
### Inferring precision for arithmetic operations
To infer the precision of the result of an arithmetic expression we need to track the minimum and maximum values that can be returned based on the minimum and maximum values of the inputs.
Contributor guide
Assessment
This issue has not been assessed yet.