Decimal Math, Floating Point Precision, and Exponents in RatioMath

[0xpatrickdev]

Around 49:50 in yesterday’s office hours, @dckc started talking about BigInts, RatioMath, and floating point precision. Some chatter ensued in Discord, and I’d like to start a discussion here as I was unable to find any for the “exponent”, “logarithm”, or “decimal” keywords.

I am aware that floating point precision is a complex topic and am by no means an expert. But as a consumer of this software, some topics I am interested in learning about are:

1. Can RatioMath support exponents? (i.e., exponentiateRatios(baseRatio, expRatio))

RatioMath has been a pleasure to use, but I ran into a blocker when trying to introduce exponents.

In this snippet here, I am attempting to calculate continuous interest (Pe^rt) with ratios using a fictitious exponentiateRatios() function. Is this something that could be supported, or would overflows be too much of a concern? Perhaps there could also be exponentiateRatioBy(baseRatio, exp) and exponentiateByRatio(base, expRatio) signatures.

2. Will the agoric-sdk ever support arbitrary precision decimals as part of the official sdk (something like BigDecimal)?

This is maybe something that would need to come from the ES community, but I am curious to get thoughts nonetheless. From a DX perspective it seems like BigInt/RatioMath is enough to get you where you need, but it’d be great to have something to reach to when decimals or irrational numbers are needed!

3. What is the recommended way (best practice) for working with decimals in a smart contract?

makeRatio() allows us to express rational numbers and approximations of irrational numbers with precision and seemingly handles a majority of use cases, but has limitations with exponents and trig.

We also have the JS-native Math object (minus .rand()) and number primitive, but I imagine something like this is not recommended for use in a production contract due to loss of precision. (0.1 + 0.2 !== 0.3)

I believe @dckc was exploring libraries like exactnumber and MikeMcl’s family of libraries - big.js, bignumber.js, decimal.js, and decimal.js-light during some weekend skunk works time, so perhaps he may have some more thoughts to share in due course.

[turadg]

The design of Amounts is to use an integer quantity so that the are never ambiguities of precision. The "decimalPlaces" of the brand specifies how many of the countable unit there are in the human-scale unit (ee.g. 6 decimal places) but all the math is done ignoring that scaling parameter. It's just an integer. Specifically a bigint so that it can be arbitrarily large and not subject to overflow problems. (It also wraps access in Nat() to ensure values are never negative).

RatioMath is for working with ratios of Amounts.

1. Can RatioMath support exponents

I'm not sure I understand the question. If you mean can a ratio multiplicand support repeated multiplication by the same multipler, yes. There is no possibility of overflow with ratios because they use bigint. Now, the numerator and denominator could get very large. But you can always quantize down to the precision you need:

agoric-sdk/packages/zoe/src/contractSupport/ratio.js

Lines 332 to 348 in b05c226

	* Make an equivalant ratio with a new denominator
	*
	* @param {Ratio} ratio
	* @param {bigint} newDen
	* @returns {Ratio}
	*/
	export const quantize = (ratio, newDen) => {
	const oldDen = ratio.denominator.value;
	const oldNum = ratio.numerator.value;
	const newNum =
	newDen === oldDen ? oldNum : bankersDivide(oldNum * newDen, oldDen);
	return makeRatio(
	newNum,
	ratio.numerator.brand,
	newDen,
	ratio.denominator.brand,
	);

2. Will the agoric-sdk ever support arbitrary precision decimals as part of the official sdk (something like BigDecimal)?

Not in Amounts or Ratios, no. They are designed to have fixed precision to prevent a class of bugs.

3. What is the recommended way (best practice) for working with decimals in a smart contract?

If your precision is the decimal places of an Amount, use a bare amount. If you need more precision, make a ratio. Quantize it to the precious you need.

You may find Inter Protocol's interest module helpful.

[dckc]

The Inter Protocol, so far, doesn't need to compute continuous interest. It compounds interest by doing simple interest periodically using a timer.

My interest in the exactnumber library was for client-side stuff.

If I needed to do continuous compound interest in a smart contract today, I would probably use that exactnumber library. It seems well-engineered using modern JavaScript without much bloat. But I can't think of a scenario that would require doing continuous compound interest in a smart contract. Is it convenient to tell me more about your use case, @0xpatrickdev ?

[0xpatrickdev]

Thank you both for the quick responses!

I am mainly just exploring and agree TimerService + Simple Interest is a sufficient approach. I am in the camp that contracts should be as “dumb” as possible and complexity moved elsewhere (off-chain actor/computation), but do like to explore the boundary of “what’s feasible in a contract”. You are correct to call out continuous interest is probably not suitable for a financial asset, and is used more in portfolio management and pricing.

A hypothetical scenario is a term loan that acts like an american call option as it approaches the term date. It has a getAccumulatedInterest() facet that uses the current timestamp to determine compounding interest. This could be continuous or n period compounding, with the thinking that this is potentially less resource intensive than a Notifier and users may not require frequent updates (but, this is maybe not favorable for wallets/explorers).

Another scenario is a vault contract that underwrites and trades said term loans, and uses PriceAuthorities and Notifiers (in conjunction with an investment mandate) to make offers/invitations. This contract may want to calculate PV/FV with n period compounding interest. If an oracle network were to provide rolling stdev for assets and T-Bill/risk-free rates, I could imagine folks exploring options pricing models in a contract. I recognize off-chain maybe makes more sense here, but 🤷‍♂️.

In yesterday’s rabbit hole that spun into today, I took a stab at creating exponentiateRatios with two different approaches, binary search & newton's method: master...0xpatrickdev:agoric-sdk:pc/exponentiate-ratios. It’s a WIP, and I just learned these algorithms could be used for this purpose yesterday, but tests are passing so maybe it’s worth a look! Here is a spreadsheet that may help make sense of the test values.

Edit: it seems to hit 'Maximum BigInt size exceeded' or run for too long when I throw more precise time and rate ratios at it