This new building block is for non-coder power users or for quick prototyping of a trading strategy.
It is a "Condition" building block that combines several of the available conditions like
* Bars since Entry/Exit
* Price Compare to Entry Bar
* Trading Days in Trade
but is more versatile, allows for more conditions and unlimited combinations of these conditions. It works as follows:
The Condition building block accepts an expression like "High - EntryPrice < 0.6".
Possible elements in such an expression are:
Current Prices
Open, High, Low, Close, Volume, Average, etc...
Past end Future Prices
Close[-1], Close[-2], etc...
Properties of LastOpenPosition
DaysInPosition, EntryPrice, BarsHeld, etc...
It is a "Condition" building block that combines several of the available conditions like
* Bars since Entry/Exit
* Price Compare to Entry Bar
* Trading Days in Trade
but is more versatile, allows for more conditions and unlimited combinations of these conditions. It works as follows:
The Condition building block accepts an expression like "High - EntryPrice < 0.6".
Possible elements in such an expression are:
Current Prices
Open, High, Low, Close, Volume, Average, etc...
Past end Future Prices
Close[-1], Close[-2], etc...
Properties of LastOpenPosition
DaysInPosition, EntryPrice, BarsHeld, etc...
Rename
The new condition building block could use a technique similar to the EvalOpt indicator to make things optimizable.
An expession like
could be made optizable by introducing these magic patterns:
An expession like
CODE:
High * (2.0 - BarsHeld/100) > EntryPrice * 1.05
could be made optizable by introducing these magic patterns:
CODE:like the EvalOpt indicator does it.
High * ({f1} - BarsHeld/100) > EntryPrice * {f2}
After rereading mdosey's request in this post:
https://wealth-lab.com/Discussion/Build-4-of-finantic-Eval-available-11482
I came to the conclusion that he needs a building block
"GenericBuyAtLimit", where the limit price comes from an expression as described above.
So this #FeatureRequest is about a family of new building blocks that accept arbitrary expressions containig prices and properties of LastOpenPosition.
https://wealth-lab.com/Discussion/Build-4-of-finantic-Eval-available-11482
I came to the conclusion that he needs a building block
"GenericBuyAtLimit", where the limit price comes from an expression as described above.
So this #FeatureRequest is about a family of new building blocks that accept arbitrary expressions containig prices and properties of LastOpenPosition.
What about adding that building block to your finantic.Eval extension?
Not as an indicator, but another module that adds the block.
Not as an indicator, but another module that adds the block.
Thank you both for considering the request, I appreciate your time. It's a bit unfortunate if it would need to be handled at the building block level, rather than at the Indicator level like EvalOpt. Ideally I would like to be able to reference things like BarsHeld from inside the EvalOpt string, so that I can combine it with other ways that I am already using EvalOpt.
Since EvalOpt already supports insertion/replacement using special strings like {i1} and {f1}, it would feel intuitive to also allow insertion of something like {BarsHeld} into the string. But I understand that there are limitations behind the scenes with the way indicators and time series are handled.
Since EvalOpt already supports insertion/replacement using special strings like {i1} and {f1}, it would feel intuitive to also allow insertion of something like {BarsHeld} into the string. But I understand that there are limitations behind the scenes with the way indicators and time series are handled.
This #FeatureRequest is implemented/realized with build 5 of finantic.Eval extension.
Your Response
Post
Edit Post
Login is required