iroha icon indicating copy to clipboard operation
iroha copied to clipboard

Arbitrary precision arithmetic by default

Open appetrosyan opened this issue 2 years ago • 4 comments

Feature request

In lieu of providing multiple fixed-width integer types for all assets, we instead should provide a variable width, fixed precision storage system (with re-allocation) that acts like an arbitrary precision number.

So, all numbers are represented as a Fixed, where the precision is either unspecified and arbitrary (in metadata) or specified at the asset definition creation time and fixed for the duration of the asset's existence.

We differentiate between BinaryFixedPoint as it is used today and DecimalFixedPoint. This allows us to bridge the gap between different blockchains.

Rules

  • Any operation that involves BinaryFixedPoint and DecimalFixedPoint must use arbitrary precision to find the precise answer and use lossy conversions.
  • Any operation that involves numbers of the same kind, may optionally use specialised faster instructions, but fall back to arbitrary precision in cases of overflow, changing the backing storage but not panicking.
  • Operation totals get accumulated into a temporary floating point buffer with no precision loss until being added to the metrics total.

appetrosyan avatar Jun 29 '23 09:06 appetrosyan

I think the inspiration here is something like NUMBER in Oracle

mversic avatar Jan 23 '24 13:01 mversic

Just like 10^18 wei for ETH, what if the resolution of the base unit for the named unit is determined on the asset definition creation and only the number of base units is calculated internally? There may be a reason why the current design did not adopt it though

s8sato avatar Feb 14 '24 10:02 s8sato

@Erigara I think you should write what we've decided to do about this since the description of the ticket no longer matches what is being implemented

mversic avatar Feb 14 '24 10:02 mversic

@mversic sure.

After some dissuasion we decided to provide numeric type for Assets similar to commonly encountered NUMERIC type in relational databases (Postgre, MySql, Oracle).

This type is decimal point number which provides 2 parameters:

  • precision: amount of significant decimal digits in number
  • scale: amount of decimal places after point

From the user point of view it would look like this:

  1. When registering AssetDefinition user will provide NumericSpec with desired precision and scale for the given asset
  2. When sending instruction to Iroha: mint, transfer, burn. Values of asset will be checked to satisfy given spec.

Encoding:

  • for json string representation will be used: "10", "10.3"
  • for scale Numeric will be encoded by two numbers: mantissa and scale, so 10 will be encoded as 10;0, 10.42 as 1042;2

Erigara avatar Feb 14 '24 11:02 Erigara