Formatting and rounding numbers

[uchu]

We need to format all numbers in DEX, so it is more easy to read long numbers. For example: 1,000,000.00 (with 2 decimals precision by default)

We need to implement an ability to use custom decimal precision. In the simplest way it can be just a harcoded map: token: price precision, amount precision. In that way we can correctly display tokens that have typically low price or quantities.

Examples
0.0000012 BTC
30000.56 some token
150.50 USDT

While amounts can be like 1100.00 Usdt when displayed in the interface, the actual values can be like 1100.000091. we have to display the full exact amount on mouse hover (simple html tooltip is enough for now) and in any input fields of the forms. Also in the sections where we make transactions.

Let's discuss the parts of the UI where full or alternative formats can be needed, unless it is obvious.

DOD:

All numbers, prices and amounts should be rounded and formatted correctly.

[AuroraLantean]

@uchu @Warchant @akorchyn
After some research, for financial calculation it is recommended to use integers to do all calculation, then we round up to what we want at division: https://www.pullrequest.com/blog/precision-matters-why-using-cents-instead-of-floating-point-for-transaction-amounts-is-crucial/

Define "dp" as decimal precision... E.g. USD has 2 dp for example $ 2.37

• Addition/Subtraction: a tokenA 2dp balance adds or subtracts a tokenB 3dp balance: Convert them into integers using the bigger dp
  E.g. 0.01+0.001 => (10 + 1)x1000 = 11 and dp of 3 => 0.011, and that is 3 dp
  Result dp = the max dp between them

• Multiplication: a tokenA 2dp balance multiplies a tokenB 3dp balance: Convert them into integers using each of their dp
  E.g. 0.01*0.001 => (1x1)/(100 x1000) => 1 and dp of 5 => 0.00001 and that is 5 dp.
  The result dp = the sum of those dp

• Division: a tokenA 3dp balance is divided by a tokenB 2dp balance: Convert them into integers using the bigger dp
  3dp / 2dp => 2dp( top and bottom both are multiplied by the bigger of 10**dp => 0 dp / 0 dp => dp1-dp2 )
  E.g. 0.001/0.10 => 1/10 => 0.1
  The result dp = 3-2 = 1

2dp / 3dp => 2dp( top and bottom both are multiplied by the bigger of 10**dp => 0 dp / 0 dp => dp1-dp2 )
E.g. 0.01/0.001 => 10/1 = 10
The result dp = 0

E.g. 0.01/100.000 => 10/100000 = 0.0001
The result dp = ?? ... Division in math is always strange... I think we can decide how much dp we want after division

[uchu]

E.g. 0.01/100.000 => 10/100000 = 0.0001
Why it cannot be dp = 4 here?

Lets add max dp as a configurable variable. We can start with something like 6 max, and we can adjust it later in one place

[AuroraLantean]

Yes, 4dp... I was saying the dp from division is not predictable given input of dp1 and dp2

All practical calculations, we can all use BigNumber or similar libraries in JavaScript here and Rust in the GGXNode
Those dp rounding are only for frontend users to view.
Okay I will add a max dp

[AuroraLantean]

@uchu @Warchant @akorchyn
Regarding "harcoded map: token: price precision, amount precision":

• Amount precision has already be determined by each token/currency, except rare cases
  E.g. BTC: 8 dp, ETH: 18 dp, USDT on Ethereum network: 6 dp
  Exception. in Binance and Coinmarketpalce, USDT is quoted in 4 dp like 0.9996 USD, although USD itself has only 2 dp

• Price precision is determined by the base token(like base currency in foreign exchange), and I suggest we round it up to ceiling in displayed view. Ceiling rounding means 0.051 is rounded to 0.06 in 2 dp

E.g. the price of BTC in USDT should be the same as USDT 6dp, because the customers have to pay in USDT, which is in 6dp
61158.69 USD per BTC /0.9996 USD per USDT = 61183.163265306 USDT/BTC ... We round it to ceiling 6dp: 61183.163266

E.g. the price of USDT in BTC should be the same as BTC 8dp
0.9996 USD per USDT/ 61158.69 USD per BTC = 0.9996/61158.69 BTC/USDT = 0.000016344 ... We round it to ceiling 8dp: 0.00001635

For actual exchange calculation when we calculate swap output token amount, we calculate all in integers and in BigNumbers. And we could:

• calculate from the rounded quote price
  OR
• calculate all without rounding during calculation, then round it down(floor rounding at the output token precision) So users may find they occasionally receive slight more than expected tokens after exchange
  please advise. Thanks

[AuroraLantean]

@uchu instructed to follow major cryptoexchange design patterns.
According to Binance design:

• Inputs for BTC/ETH/USDT all accept 8 dp amounts.
  ... Assuming USDT amounts beyond 6dp are omitted automatically
• Outputs or asset balances all display 8 dp balances... this is good enough before BTC reaches 100 Million USD
  ... Assuming USDT balances beyond 6dp are automatically taken away
• set default max dp as 8

[AuroraLantean]

Done: set Modal input max to 8 decimal precision in Wallet, Dex, BridgeBTC pages

[AuroraLantean]

@uchu Regarding price and balance representation, after looking at Binance and Coinmarketcap, most tokens have 2 and 4 decimals, but the others have the following long decimals... However, they all have 4 significant figures(DOGE changes in price a lot so it changes between 4 and 5 significant figures). So 4 significant figures is more important, not fixed decimals. Please advise. Thanks
Binance Price Display:
https://www.binance.com/en/markets/overview
DOGE $0.15273 ... 5 dp
XME $0.03685 ... 5dp
DGB $0.01275 ... 5dp
XVG $0.005628 ... 6dp
Coinmarketcap Price Display:
https://coinmarketcap.com/
DOGE $0.1531 ... 4dp
XEM $0.03696 ... 5 dp
VeChain $0.04085 ... 5 dp
Floki $0.0001425 ... 7 dp
Shiba $0.00002278 ... 8 dp
PEPE $0.000005191 ... 9 dp
BONK $0.00001483 ... 8 dp

[AuroraLantean]

@uchu From the above observation, Price Representation Rules can be deduced:

• DAI price uses 8 dp
• if price >= 1, use default 2 dp. This includes USDT and USDC: 1.00xy => 1.00, OR use 4 dp 0.999x
• if price < 1, use 4 significant figures(except 5 for DOGE, TRX)

[AuroraLantean]

I found another bug so cannot further progress on this item until this is fixed:
DexPage Orderlist Prices show zeros#272
RFQ product (view)

DexPage SellAmount cannot handle some decimal inputs#268
RFQ product (view)