BigNumber.div(divisor) doesn't return the good result

[iboxgithub]

Hi,
when I use BigNumber.div(divisor) I have some results I can't explain, can you please take a look at TEST2 and let me know if I did something wrong?

  const t1 = ethers.utils.parseUnits("32446080116944622871630", "wei");
  const t2 = ethers.utils.parseUnits("52240126807063116261284835", "wei");
  const t3 = ethers.utils.parseUnits("1694987324029278321362138552169957830169752283860", "wei");

  //below should something like 161005972428026... (please ignore round up, I mean more accurate)
  console.log("TEST1: " + t2.div(t1)); // = 1610 [WRONG]  
  // below is correct
  console.log("TEST2: " + t3.div(t1)); // = 52240126324045198977206551 [OK]

thanks for your help!

[ricmoo]

What is wrong with that values? I just used python to compute these (I often use Python for testing, since it uses arbitrary precision).

These are my results (which match):

>>> 52240126807063116261284835 / 32446080116944622871630
1610L
>>> 1694987324029278321362138552169957830169752283860 / 32446080116944622871630
52240126324045198977206551L

which match ethers BigNumber:

homestead> BigNumber.from("52240126807063116261284835").div("32446080116944622871630").toString()
'1610'
homestead> BigNumber.from("1694987324029278321362138552169957830169752283860").div("32446080116944622871630").toString()
'52240126324045198977206551'

[iboxgithub]

I agree for Python, nevertheless you will see that even if you change 52240126807063116261284835 with 52240126807063116261284942 for example, it is still 1610, the result is truncated/rounded up and I don't know why :(

[ricmoo]

BigNumber only operates on integers. Values are rounded toward zero.

If you are trying to perform fixed-point maths, you must use the FixedNumber object. They are much more complex to work with though, as you must consider the field in which they are operating.

E.g.

homestead> FixedNumber.from("52240126807063116261284835", "fixed80x18").divUnsafe(FixedNumber.from("32446080116944622871630", "fixed80x18")).toString()
'1610.059724280260943834'

Is that what you were looking for? If so, check out the docs. You should also familiarize yourself with the various caveats of using fixed-point math. There is a lot of complexity when dealing with decimal components...

Let me know if that helps. :)

[ricmoo]

(moving to discussions)

[iboxgithub]

First of all thanks for your time, truly appreciated!
so I think I understand what you say, and I indeed managed to do the operation and the result is now not a round up number BUT I don't get why it's so cumbersome...
I'm only trying to calculate a price of a swap on a DEX based on current reserves (regardless of the fees). So, my input params are reserveX = 32446080116944622871630, reserveY = 52240126807063116261284835, swapX is 0.0997... so priceX = reserveY / reserveX and valueSwapX = swapX * priceX
Isn't there a simple way to calculate that?
I tried with BigNumber only but now I need to consider FixedNumber...all of this to basically replicate the Smart Contract behavior...
Is it because I'm a newbie or doesn't it seem overkill just to do 2 math ops?

[iboxgithub]

First of all thanks for your time, truly appreciated!
so I think I understand what you say, and I indeed managed to do the operation and the result is now not a round up number BUT I don't get why it's so cumbersome...
I'm only trying to calculate a price of a swap on a DEX based on current reserves (regardless of the fees). So, my input params are reserveX = 32446080116944622871630, reserveY = 52240126807063116261284835, swapX is 0.0997... so priceX = reserveY / reserveX and valueSwapX = swapX * priceX
Isn't there a simple way to calculate that?
I tried with BigNumber only but now I need to consider FixedNumber...all of this to basically replicate the Smart Contract behavior...
Is it because I'm a newbie or doesn't it seem overkill just to do 2 math ops?

[ricmoo]

If you look at line 626 here you will see the Solidity makes a call to a library which Uniswap wrote, which is where all the maths are done.

You will likely want to use the maths here. I honestly don't know why they are doing that approximation to rounding, as they add 997 and then divide by 1000.

I would expect them to add 999 and divide by 1000, but the end result is that the values will be rounded up at 3 decimals places (with some small margin of error they seem to have included for some reason).

But basically, when in doubt, check the Solidity. :)

[iboxgithub]

thanks a lot, I was checking the Solidity code too but still can't find the same result, I will keep on digging.
I really appreciate the time you spent on this!

[CodeForcer]

You will likely want to use the maths here. I honestly don't know why they are doing that approximation to rounding, as they add 997 and then divide by 1000.

@ricmoo that's them taking a fee of 0.3%, not a rounding approximation

[ricmoo]

Ohhh! Huge thanks for the clarification. That makes way more sense. ;)

[iboxgithub]

forgot to answer that haha, thanks @CodeForcer (for the help here and on Discord!)
@ricmoo my apologies I used the good reserves amount and now all good, thanks again for your time and support!