SO: unwanted orders price shifts due to incrementing price

[bitphage]

From bitshares/python-bitshares#227 (comment)

In dexbot we're incrementing prices to place staggered orders, this is a test which shows actual order price and initially calculated price are different:

        closer_order = worker.place_closer_order(asset, order, place_order=True)
    
        # Test for correct price
>       assert closer_order['price'] == order['price'] * (1 + worker.increment)
E       assert 99.01980296969697 == 99.0099009894
E         -99.01980296969697
E         +99.0099009894

So, we should switch from incrementing prices to incrementing amount only (base or quote) to place staggered orders, and as a consequence we need a method to place orders specifying both base and quote amounts (see the first message)

Another example: test setup failed to place initial orders to close the target spread, see that 1% error:

_______________________________________________________ test_maintain_strategy[mountain-config0] ________________________________________________________

initial_allocation = {}

    def test_maintain_strategy(initial_allocation):
        """ Check if intial orders placement is correct
        """
        worker = initial_allocation
    
        # Check target spread is reached
>       assert worker.actual_spread < worker.target_spread + worker.increment
E       assert 0.030186976828429968 < (0.02 + 0.01)
E        +  where 0.030186976828429968 = {}.actual_spread
E        +  and   0.02 = {}.target_spread
E        +  and   0.01 = {}.increment

[bitphage]

The less asset precision, the bigger price increment error is.

[MarkoPaasila]

The problem is that we assume that we get the price we specify. When calculating prices we must do so taking into account the available resolution, and use an actually possible price going forward. See my pr for reference. I'm working on an improved version, but it seems pretty specific to Staggered Orders (with it's order size limits), and maybe not so suitable as a generic function.

[bitphage]

Further workaround improvement was 00a920f

[bitphage]

I think this could be closed now as applied workaround eliminated (almost?) all consequences.

For later, I would refactor SO to use Decimal amounts on orders calculations and precise prices based on such amounts. Price correction method was proposed in #512, but it's usage requires SO refactor anyway. Also, could be implemented more clean used Decimal and custom mul() div() as recommended in https://docs.python.org/3/library/decimal.html#decimal-faq