New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] VersusEnterAndHoldCriterion misleading for "+/-"-criteria #1073
Comments
Correct calculation is: (Strategy Account Balance)/(Buy and Hold Account Balance) - 100%. |
@phong-phuong good idea. I am currently working on a PR to fix this bug. The formula
can only be used if For example, look at the Given:
So we must differ if the criterion is a percentage value or not and then provide two distinct formulas:
Am I right? |
Not quite, the formula will depend on what is being compared, and whether "returns" come into the picture. Consider a portfolio with a start capital of $100. In this context of returns, the In Absolute values: In percentages: Absolute difference between Strategy A and Strategy B: But what if we wanted to compare the profits generated by Strategy A compared to Strategy B? If we wanted to compare returns (the final account balance) from strategy A over strategy B as a ratio? If we wanted to compare returns (the final account balance) from strategy A over strategy B but exclude the initial cost of investment? In the number of winnings example you gave: The formula: Hope that clears any confusion. |
To abstract your last phrase: "..because we are not talking about percentage values (e.g. Returns, etc.) but absolute values (e.g. NumberOfWinningPositions, etc.)". That's what I want to find out and what I asked for. The formula Either we find a formula which can be used for both, percentage and absolute values, or the For example:
I think, that's the proper way, or? |
No, the formula you are referring to can be used with both percent and absolute values. The formula measures the difference in change compared to a base value. Going back to the winnings example: Applying the formula: Or the other version of the formula: Which is interpreted as strategy B is 67% worse than the result obtained using strategy A. |
I was referring this formula (which you introduced in #1073 (comment))
using this with the example:
I already explained that in #1073 (comment). |
Or going back to the winnings example where we compare the users strategy vs enter and hold: User strategy: 9 wins Apply the formula: Which is interpreted as the user's strategy when compared to enter and hold is 2x more than the results of Enter and hold. |
The thing is, sometimes we want to include the base and sometimes we don't |
I know, this is common sense:) I only got irritated because you bring the formula with the base (=
Yes, this is the primary question. When and why do I need to include the base. |
That's not the actual formula to be used every time, but I used that + 1 as a substitute of the initial balance because we don't know the starting balance of the user. It is only there to compare the ending capital of the two strategies when we only have the profit or percent to start with. Compare account balances and directly comparing profits are two separate comparisons. |
Ok, I think there are misunderstandings due to a lack of information: When we compare |
Example for
|
Describe the bug
Some criteria values can have positive and negative values (e.g. PnlCriterion): For such criteria, the
VersusEnterAndHoldCriterion
comparesX
with itsEnterAndHold
, but it does not handle the sign (+/-) in favour ofX
.1. Example: Given:
myPnl +4%
enterAndHoldPnl: - 4%
=> actual calculation = myPnl / enterAndHoldPnl = 4 / -4 = -1 (it should be +1, because -1 would mean
X
is not better than itsEnterAndHold
)2. Example: Given:
myPnl -4%
enterAndHoldPnl: +4%
=> actual calculation = myPnl / enterAndHoldPnl = -4 / +4 = -1 (correct, because -1 means
X
is not better than itsEnterAndHold
)3. Example: Given:
myPnl -8%
enterAndHoldPnl: -4%
=> actual calculation = myPnl / enterAndHoldPnl = -8 / -4 = 0.5 (ok?)
Expected behavior
If a criterion can have both positive and negative values, then
VersusEnterAndHoldCriterion
should handle it in a special way so that the result of theVersusEnterAndHoldCriterion
can be interpreted unequivocally.Maybe we could use another comparision method (instead of
x.dividedBy(enterAndHold)
, we could use "euclidian distance" (but then we have no sign) or any other representative distance calculation, maybe from packagecriterion/statistics
).The text was updated successfully, but these errors were encountered: