3. bt.sizer.PercentSizer behavior
For code/output blocks: Use ``` (aka backtick or grave accent) in a single line before and after the block. See: http://commonmark.org/help/

bt.sizer.PercentSizer behavior

  • E

    Hello,
    I am running Cerebro engine with the following parameters:

    'broker_input': {
            'stdstats': False,
            'opreturn': False,
            'cash': 10000,
            'slippage_perc': 0,
            'comission': StocksPerc,
            'commvalue':0,
            'sizer': bt.sizers.PercentSizer,
            'percents': 100
        }
    }

    The weird thing is that when I run the engine with NZDUSD forex where the price is around 0.6, all of my orders are rejected with margin. However the same data feed makes trades with FixedSizer or with PercentSizer when the percent drops below around 80. PercentSizer also works perfectly fine with a couple other data feeds. My question is that is there some kind of buffer I need to think about when using PercentSizer like comission slippage etc. (even though they are both zero in my cases)?
    Thanks,

    My repo: https://github.com/emindeniz/exterme_bt
    I am running walkforward_test_run.py

    0
  • B
    administrators

    I don't know what kind of input is that for cerebro, but it would seem you are, like many others, hitting the wall that you think you can buy the close price with an All-In strategy.

    There has to be a best-seller somewhere which recommends using an All-In strategy and doesn't explain how the markets work. But I haven't come across that book yet.

    Try your luck with cheat-on-open: Docs - Cheat-On-Open

    0
  • E

    I totally agree with the stupidity of all in strategies, but I feel like there is a bit more to that here. Looking at the following log:

    Order size: 10233.442891368994
Order value: 8500.0
2011-06-29T00:00:00, Order submitted by 1900-01-01 00:00:00 2100-01-01 00:00:00 NZDUSD
2011-06-30T00:00:00, Order Submitted NZDUSD-market
2011-06-30T00:00:00, Order Margin NZDUSD
2011-07-03T00:00:00, Ending Value 10000.0000
Order size: 10362.315306968352
Order value: 8499.999999999998
2011-07-11T00:00:00, Order submitted by 2011-07-04 00:00:00 2017-01-01 00:00:00 NZDUSD
2011-07-12T00:00:00, Order Submitted NZDUSD-market
2011-07-12T00:00:00, Order Margin NZDUSD
Order size: 10333.341437914853
Order value: 8500.0
2011-07-12T00:00:00, Order submitted by 2011-07-04 00:00:00 2017-01-01 00:00:00 NZDUSD
2011-07-13T00:00:00, Order Submitted NZDUSD-market
2011-07-13T00:00:00, Order Margin NZDUSD
Order size: 9957.009148734287
Order value: 8500.0
2011-08-03T00:00:00, Order submitted by 2011-07-04 00:00:00 2017-01-01 00:00:00 NZDUSD
2011-08-04T00:00:00, Order Submitted NZDUSD-market
2011-08-04T00:00:00, Order Accepted NZDUSD-market
2011-08-04T00:00:00, SELL EXECUTED, Price: 0.8537, Size: 9957.0091,

    I am using a percent sizer only at 85%. It seems that my orders are rejected if the order size (not my order value) is bigger than my cash. In other words, the first three orders are rejected because numerical value of my order size is bigger than my cash, the percent sizer starts working as soon as my order size drops below my cash. Very curious indeed.

    0
    B
     1 Reply
  • B
    administrators

    @emin-ozkan said in bt.sizer.PercentSizer behavior:

    but I feel like there is a bit more to that here

    Having feelings is ok, but a code snippet, data and proper logs to show a bug ... much better ...

    Looking at the following log:

    It's a useless log. Sorry to be so direct, but it simply is.

    The basics for a log:

    • Logging proper information, like date and ohlcv values
    • Logging why one date is 1900-01-01 along a the data 2100-01-01 (or 2011-07-04 against 2017-01-01)

    Because if not, someone would immediately feel there is something fundamentally wrong: regardless of the size, the value is always 8500. Higly improbable.

    0

  • In order to make all-in-one sizer I've used both cheat-on-open feature and built-in filter which splits the candle in 2 candles: OOOO and OHLC.

    With the cheat-on-open feature the broker value from the previous day is used. Which left me sometime with the excessive amount of cash after rebalancing of positions. Filter above gives an opportunity to use broker value recalculated for open price.

    0
Log in to reply
 
});