0

An order book shows a bid entry, for example:

12:
amount: "758.2907668"
price: "11.1111111"
price_r: {n: 100, d: 9}

I submit a manageBuyOffer with buyAmount ".01" and price at "11.1111111". I expected the bid entry to increase by .01, and thus to 758.3007668. But instead, the order book returns a new entry at the same price:

13:
amount: "0.3333312"
price: "11.1111111"
price_r: {n: 111111111, d: 10000000}

with the prior entry remaining the same. The order book thus ends up with two bid entries with the same 11.1111111 price.

I would like to know how do I manipulate the buyAmount and price parameters so that the new offer gets consolidated with the first one.

I do not encounter this issue when submitting sell offers.

I reckon it has to do with the price_r, as indeed I do not encounter the problem when I submit the price parameter as a ratio with the same values as those of the first offer, i.e., price: {n: 100, d: 9}. This issue could thus be stated otherwise as: given only the buyAmount and the price parameter in a string format, how does one arrive at the numerator and the denominator of the price so that the new offer gets incorporated with the old offer that has the same price string.

Improve this question
9
  • 1
    In my experience, you should work with price_r and use price only to display the price to the user.
    – Francesco
    Sep 20, 2019 at 20:27
  • I would want to. But if I use the price_r parameter I still produce a different entry if I do not match the price_r of the old offer I wish my new offer to be incorporated. The problem is to get the price_r of the old offer given the price. I am beginning to think its impossible to work backwards. The price_r of the offer do not always match the price.
    – J R
    Sep 21, 2019 at 2:28
  • The price_r of the offer always matches the price because that's how prices are represented. price is a way to display price_r in an human-readable format.
    – Francesco
    Sep 21, 2019 at 10:18
  • 1
    A price of 100/9 means it takes 9 units of buying to get 100 units of selling asset. That's the price used in the transaction. The price field is an human readable representation of 100/9. You should use price_r.
    – Francesco
    Sep 21, 2019 at 19:10
  • 1
    The underlying problem is that 100/9 != 11.1111111, that's the result of truncation. Clearly the price of 400000001 / 36000000 is different from 100/9, but they both have the same first 7 decimal digits and so they are both represented as 11.1111111 in price.
    – Francesco
    Sep 22, 2019 at 10:37

1 Answer 1

Reset to default
1

I think the underlying problem is that the number 100/9 has infinite decimal digits and cannot be represented as string. The price you see, 11.1111111 is a truncation of 11.11111111.... = 100/9. When you enter the number 11.1111111 the SDK correctly converts it to its fractional representation 111111111/10000000.

The only way to get around this is to always use fractional prices.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.