SetPositionSize - results

Hi guys,
I am having trouble understanding the results of my setPositionSize statement,
I am expecting the posSize to be set to 4100.....it is becoming -6100?

    
_TRACE("setMethod " + setMethod);
_TRACE( "confirmedBuy " + confirmedBuy );
_TRACE( "1 PositionSize " + PositionSize );
_TRACE( "setSize " + setSize );
    SetPositionSize( setSize, setMethod * (confirmedBuy == True) );
_TRACE( "2 PositionSize " + PositionSize );

image

See SetPositionSize for correct use.

1 Like

Thanks for your answer.
I totally understand your comment on how to ask a question.
However, in some cases, the question won't need multiple lines of code to explain.
As in this case, a single function call doesn't appear to achieve what you would expect from it's name "SetPositionSize". The result is not obvious, although possibly correct, and just needs further explanation. I was hoping anyone with a good understanding of the function could share some light on the reason for the value in positionsize given the parameters used.

Sorry but you don't because it states to post your code, you have only posted part of your code. Which means others have to play guessing games to try and help you out.

See how-do-i-debug-my-formula, especially about using 'Detailed Log'.

Your interpretation of the guidelines appears to be faulty. Certainly, it says "Post the code that you wrote". Most people would take that to mean the part of the code that is in question. If my code is several hundred lines long and I only want an explanation of the results of a function call (to a function not written by me but a built-in AFL function) on 1 line then the inclusion of any extraneous code, irrelevant to the problem, will only obscure the request and lead to many of the good people trying to offer assistance being unnecessarily distracted from the central query.

As in this case, a single function call doesn't appear to achieve what you would expect from it's name "SetPositionSize". The result is not obvious, although possibly correct, and just needs further explanation. I was hoping anyone with a good understanding of the function could share some light on the reason for the value in positionsize given the parameters used.

You don't understand.
Your posted code should be reproducible code (snippet) that shows your results without resulting in error about missing variables. Is that so hard to understand?
It is does not have to be your entire formula but just part of it and that runs without error reporting undefined variables. So reduce the code in such way that it shows the issue you have with it.

It is clearly mentioned in same thread:

So what is a reproducible code that shows your output of your picture?
It is code like this below one not resulting in Error 29 message(s):

setMethod = spsShares;
confirmedBuy = 1;
setSize = 4100;
PositionSize = -45;

_TRACE("setMethod " + setMethod);
_TRACE( "confirmedBuy " + confirmedBuy );
_TRACE( "1 PositionSize " + PositionSize );
_TRACE( "setSize " + setSize );
    SetPositionSize( setSize, setMethod * (confirmedBuy == True) );
_TRACE( "2 PositionSize " + PositionSize );

I do not think it is that hard to add just four additional lines as I did to repeat the output of your picture, is it?

Now as for your question...
It shows -6100 but not 4100 because it is mentioned in function guide:

First setMethod returns 4 in _Trace log which is in line with manual (see bold text):

AFL Function Reference - SETPOSITIONSIZE

method (ARRAY) defines how 'size' is interpreted

  • spsValue (=1) - dollar value of size (as in previous versions)
  • spsPercentOfEquity (=2) - size expressed as percent of portfolio-level equity (size must be from ..100 (for regular accounts) or .1000 for margin accounts)
  • spsShares (=4) - size expressed in shares/contracts (size must be > 0 )
  • spsPercentOfPosition (=3) - size expressed as percent of currently open position (for SCALING IN and SCALING OUT ONLY)
  • spsNoChange (=0) - don't change previously set size for given bar

Now second one... the size again explained in manual how it works and how it is encoded (again see bold text):

AFL Function Reference - SETPOSITIONSIZE

New SetPositionSize function automatically encodes new methods of expressing position size into old "positionsize" variable as follows:

  • values below -2000 encode share count,
  • values between -2000 and -1000 encode % of current position
  • values between -1000 and 0 encode % of portfolio equity
  • values above 0 encode dollar value

Your chosen method is spsShares so position size returned via trace line

_TRACE( "2 PositionSize " + PositionSize );

is -2000-4100 which results in -6100. Simple elementary school math. It is encoded value telling that number of shares has been set as position size method (not percent of equity and not percent of position value and not dollar value which are all encoded differently to method spsShares).

So if you want to show shares in trace log decode the output to shares via elementary school math again:

_TRACE( "2 PositionSize " + (-2000-PositionSize) );
2 Likes

Thanks for the detailed response, I had missed how the encoding works. I had read it but hadn't understood it properly.
In the future, I will try to make any code snippets able to reproduce the problem as they are.

Luckily for me, you were able to understand what I needed.

Cheers,
Gary.

Once again, thanks for your answer. I understand how it works now.
As a follow up, is there a reason to use code/decode rather than just have a second array indicating what the positionSize value represents?
I am in no way suggesting it is wrong, just curious as to the rationale behind it.

Cheers,
Gary.

To conserve RAM.

Despite usual thinking "I have powerful computer with plenty of RAM", things quickly add up when it comes to memory usage.
Imagine you test on 10K symbols, each having 1 million bars. The array element is 4 bytes each bar and it is separate for each symbol. This gives you 4 * 10K * 1M = 40GB of RAM1 required for JUST ONE ARRAY for 10K symbols
That's why it is important not to use "extra array" for no reason.

1 Note AmiBroker conserves RAM even more and does not need 40GB of RAM in described scenario. But it is my trade secret and I won't reveal it. Anyway AmiBroker is written in super compact way and conserves RAM as much as it can, to such extent that when we can use single bit, we use single bit (not byte) to store information in some memory-critical places.

1 Like

Thanks for the explanation.Makes sense to me.

I'll keep that in mind if I am considering extra arrays in my code.

Cheers,
Gary.

Arrays in your code don't matter, as long as they are NOT static.
Arrays in AFL formula "live" only for duration of execution on SINGLE symbol, so it does not matter how many symbols you test on. Once Analysis goes from one symbol to another it destroys (frees) all memory, except static variables. What counts are arrays/data that have to be KEPT for ALL symbols during backtest. PositionSize, PositionScore, trade signals, entry/exit prices and so on. They have to be kept till final stage (portfolio backtest).

Thanks for the extra info, I believe I now have a better understanding.

Cheers,
Gary.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.