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
High level is that we run into the limits of 18 decimal fixed point math as we currently use it in two key areas:
Precision loss when operating across multiple OOMs, e.g. a halflife as 0.5^x loses 1 bit of precision for every increment of x
Don't have negative numbers
We can get signed math from PRB but all operations like pow top out quite quickly in terms of what they can represent with overflows/precision loss.
A real world example is a dutch auction that is scanning the market value of N tokens where we don't know the real market value of any pair of them. We want to scan a very large range, which could go into the 18 digits of precision sub 1 but could also be OOMs above 1 as well, e.g. we might want the auction to cover a full 20-50 OOMs. The precision starts to drop a lot if we do this with a halflife, resulting in hacks #245
Problem
This is broadly the issue:
https://hackmd.io/I7Z20eObQhu6dT9F2Z4Wgg
High level is that we run into the limits of 18 decimal fixed point math as we currently use it in two key areas:
0.5^x
loses 1 bit of precision for every increment ofx
We can get signed math from PRB but all operations like
pow
top out quite quickly in terms of what they can represent with overflows/precision loss.A real world example is a dutch auction that is scanning the market value of N tokens where we don't know the real market value of any pair of them. We want to scan a very large range, which could go into the 18 digits of precision sub 1 but could also be OOMs above 1 as well, e.g. we might want the auction to cover a full 20-50 OOMs. The precision starts to drop a lot if we do this with a halflife, resulting in hacks #245
That doc was written before doing any POCing, the latest state of things is at https://github.com/rainlanguage/rain.math.float
Solution
Create something like a 128 decimal float but with some key differences/notes:
The text was updated successfully, but these errors were encountered: