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
In the system parameters we keep track of the total amount of kit needed to close all currently open burrows via field outstanding_kit. However, this is only an approximation of the real amount. Not only we update the burrow.outstanding_kit field individually (per burrow) when touching burrows, but also burrows or checker might remain untouched for a while, which could introduce further rounding errors.
Errors of a few percents per year are NOT acceptable. Errors of 0.1% or so per year would be tolerable.
In order to test this meaningfully we should be able to create scenaria with many burrows, a lot of activity, and let a lot of time pass, which can be quite complicated to manufacture. Furthermore, one must keep track of all the burrows ever created to be able to inspect the storage and aggregate the total amount of outstanding kit for all burrows so that it can be compared to parameters.oustanding_kit.
The text was updated successfully, but these errors were encountered:
After some investigation I found out that underapproximations of the
total outstanding kit are not all that uncommon, which justifies the
need for #218. Here is a high-level example / regression test
illustrating this.
Other items:
* Add `compute_outstanding_dissonance` to help identify
underapproximations (useful for investigating #156 too).
* Remove the warnings on underapproximations in `checker.ml`;
they are more common than I expected.
* Type signature fixes in `Ligo.Map` definitions.
In the system parameters we keep track of the total amount of kit needed to close all currently open burrows via field
outstanding_kit
. However, this is only an approximation of the real amount. Not only we update theburrow.outstanding_kit
field individually (per burrow) when touching burrows, but also burrows or checker might remain untouched for a while, which could introduce further rounding errors.Errors of a few percents per year are NOT acceptable. Errors of 0.1% or so per year would be tolerable.
In order to test this meaningfully we should be able to create scenaria with many burrows, a lot of activity, and let a lot of time pass, which can be quite complicated to manufacture. Furthermore, one must keep track of all the burrows ever created to be able to inspect the storage and aggregate the total amount of outstanding kit for all burrows so that it can be compared to
parameters.oustanding_kit
.The text was updated successfully, but these errors were encountered: