Closed christophersanborn closed 2 years ago
Yeah; doing so Math.round(parseFloat(minToReceive) * minToReceivePrecision) would solve this issue but not sure about other scenarios, will be implementing it now at dex.iobanker.com and please check the results.
... it seems to be silently removing the decimal point and using all digits, including the sub-integral digits, to make the integer amount_to_sell value. This suggests a deeper problem in the TransactionBuilder functionality.
I don't exactly know where it went wrong, but it seems the input (E.G. the float 12.999999999999998
) is converted to Long
here:
if (typeof value === "number") {
value = "" + value;
}
return Long.fromString(value, unsigned);
The result is clearly unexpected.
> parseFloat("0.00013")*100000
12.999999999999998
> Long.fromString(""+parseFloat("0.00013")*100000)
Long { low: 1150981118, high: 30, unsigned: false }
> Long.fromString(""+parseFloat("0.00013")*100000).toString()
129999999998
Created issue https://github.com/bitshares/bitsharesjs/issues/99 and pull request https://github.com/bitshares/bitsharesjs/pull/100. Wish it helps.
FWIW rounding the input should work.
> parseFloat("0.00013")*100000
12.999999999999998
> Long.fromString(""+parseFloat("0.00013")*100000)
Long { low: 1150981118, high: 30, unsigned: false }
> Long.fromString(""+parseFloat("0.00013")*100000).toString()
129999999998
> Long.fromString(""+Math.round(parseFloat("0.00013")*100000),true)
Long { low: 13, high: 0, unsigned: true }
> Long.fromString(""+Math.round(parseFloat("0.00013")*100000),true).toString()
13
Describe the bug Some decimal values with imprecise floating point representation are not converting correctly to integer values. Extra digits are produced, with result that a user might sell MORE of their asset than they intend to.
To Reproduce Steps to reproduce the behavior:
Expected behavior
BTWTY has a precision of 5, so the user would expect to be selling 13 units.
Encountered behavior
User is in fact selling 129999999998 units.
Screenshots
Desktop (please complete the following information):
Additional context
Problem may stem from not rounding the result from parseFloat in PoolExchangeModal.jsx, e.g. here:
https://github.com/bitshares/bitshares-ui/blob/24c9e7166ce7258d0ab1b24c104aee91ece3c600/app/components/Modal/PoolExchangeModal.jsx#L81
Case in point, in the Node.js REPL, the following can be observed:
Better may be to simply round the result:
An additional concern:
Although the result of parseFloat in the above example gives digits following the decimal point, it DOES place the decimal point in the correct location. The value passed in to ApplicationApi.liquidityPoolExchange() as the amountToSell parameter, gets passed along from there to TransactionBuilder as, presumably, a floating point value. Somehow or other TransactionBuilder is not detecting this and throwing an error as it should, nor truncating at the decimal point. Worse, it seems to be silently removing the decimal point and using all digits, including the sub-integral digits, to make the integer amount_to_sell value. This suggests a deeper problem in the TransactionBuilder functionality.