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
.
price_r
and useprice
only to display the price to the user.price_r
of the offer always matches the price because that's how prices are represented.price
is a way to displayprice_r
in an human-readable format.100/9
means it takes 9 units of buying to get 100 units of selling asset. That's the price used in the transaction. Theprice
field is an human readable representation of100/9
. You should useprice_r
.100/9 != 11.1111111
, that's the result of truncation. Clearly the price of400000001 / 36000000
is different from100/9
, but they both have the same first 7 decimal digits and so they are both represented as11.1111111
inprice
.