A new official version 6.90.5 already has two of the suggested features implemented (plus five more that were planned earlier):
2 Likes
A feature I saw in another application that I find useful is the creation of additional "optimize" functions:
period = OptimizeList("period", 63, "10, 21, 63, 126, 252"); // default, comma-separated values in a list
period = OptimizeMultiply("period", 40, 10, 320, 2); // default, will try 10, 20, 40, 80, 160, 320 - with automatic round() if multiplier is a float
In particular, I like the use of a list of comma-separated values list.
2 Likes
You can have it right now:
function OptimizeList( _name, _list )
{
local m, x;
m = MxFromString( "{{ " + _list + " }}");
x = Optimize( _name, 0, 0, MxGetSize( m, 1 ) - 1, 1 );
return m[ 0 ][ x ];
}
p = OptimizeList("test", "10, 21, 63, 126, 252");
11 Likes
Hi @Tomasz,
Thank you for the opportunity to clarify my request and for your examples. I take your point about the ambiguity.
Let's focus on your example of three strategies A, B, and C.
Your example with different but fixed percent allocations is a good start, with suitable settings to have each portfolio rebalanced every say 12 (n) months. My main request is around usability and having a simple to use interface similar to the current backtester, but with this additional functionality for multiple strategies or portfolios that are being held simultaneously.
The main attraction of the third party solutions is the ease of use and integration with the backtester menu and settings /parameters. I'm sure many things are possible for expert programmers but most of us here aren't at that level yet, hence the request for your assistance and AB updates.
@Tomasz, thank you for asking for input! Hereâs my wish list:
-
AFL should be able to read all the various settings in Preferences as well as the Analysis Settings in the case of a scan/exploration.
-
AFL should be able to read the Data Source settings, e.g. current intraday filtering settings (24/day/night/etc) and data source name (âDTN IQFeedâŚâ, âNorgateâŚâ).
-
AFL should be able to create, modify, and delete hand-drawn studies.
-
AFL should be able to read/write Account Manager data.
-
The Currencies tab which is currently in Preferences should be local to each database and not application-wide, because the symbols can be different for each data provider and database.
-
All the symbol information fields should be editable as a table, similar to editing a spreadsheet, so that we can make bulk edits more easily.
-
For a repeating exploration, it would be great to have an option for the exploration to act like a dashboard panel that always stays updated, instead of clearing the results list with every iteration.
-
Easy Alerts should be enhanced so that they can be added, modified, and deleted within a chart, e.g. they should be accessible in the chart right-click menu. The alert dialog should get prices from the chart as well as display in the chart, allowing the user to drag a line on the chart to modify the alert. The dialog should be optimized to reduce the number of mouse clicks and number entries to the minimum.
-
There should be an option to copy a database, but exclude the prices and hand-drawn studies from the new DB, so that the user can create a new DB using a different time interval, while preserving the existing symbol information and categories, download new data, and start with un-marked up charts.
-
When a layout is saved, there should be an option to include or exclude the symbol from each chart. There are some charts in my layouts where I want the symbol to be whatever symbol I was using a moment ago, not necessarily the symbol that was saved as part of the layout.
-
The Account Manager should allow prior transactions to be edited or deleted for error corrections or to add missing information.
-
The Account Manager should allow user-defined fields to be used, e.g. to contain user-desired information such as initial risk, OrderIDs, execution IDs, comments, current stop price, etc.
-
Dark mode should be enabled in Symbols, Interpretation, Layouts, Information, Layers, Notepad, Charts, Time & Sales windows, and file dialogs.
-
A repeating exploration that runs while a file dialog is open should still be able to access the file that it needs while the user is using the dialog.
-
In the code editor, it would be intuitive to use Ctrl-PgUp and Ctrl-PgDown to switch between tabs, like how tabbed browsers and Excel work.
-
It would be great to have the option of using VSCode as a code editor in the IDE.
-
Now that Maps exist in AB, it would be great if odbcGetValueSQL() could populate a Map instead of just returning the first record.
Although I understand it's probably impractical to implement everything I proposed above, I'm already looking forward to the new version. Thank you again for asking what we would like to see.
--Peter
@Tomasz although AmiBroker is a powerful program, a great deal of its flexibility comes via the Custom Backtest Interface. The problem is that using the CBI requires significant programing expertise. And working from the high level to the mid-level and down to the low-level CBI requires greater and greater programming knowledge.
I doubt it is possible without a major re-writing of the program, but if the functionality of the CBI was available through regular functions, variables and indicators (i.e. no CBI) then I think the program might be easier for non-programmers to use. So I guess my request is eliminate the need for the CBI.
4 Likes
@portfoliobuilder @Tomasz This I believe would be one of the greatest enhancements for Amibroker which will allow it to compete better with some popular emerging competitors like Realtest (that seems to be gaining popularity among traditional Amibroker users).
I love Amibroker but one of the current limitations of Amibroker is that you donât have access to portfolio level figures (equity, number/names-of-positions/profits/drawdownsâŚ) in the first phase and
cannot do portfolio/equity based entry/exit/decisions without the CBT
Moderator comment: It is false statement. AmiBroker CAN do portfolio based entry and exits without CBT (see below)
Would it be possible to have some simple functions that can be used in the first phase which the amibroker pre-processor essentially converts to a CBT before running the backtest? I am assuming something like that wouldnât involve a major re-write but would make writing portfolio based conditions much easier for the average user.
In AFL Formula Editor when you use 'AFL check' it highlights miscoded items in pink among much other useful information. If you 'X' out of the message box, all pink highlights are cleared.
However if you run AFL check again or Apply some highlights remain. It seems to me that running check again or Appling it would also clear the previous highlights for correct code.
Hopefully this helps.
Congratulations on the upcoming 30th anniversary, that's is a serious milestone!!! Thank you for all that you do.
First I wanted to say that what you wrote is incorrect. AmiBroker makes portfolio based entry / exit decisions without CBT. SetPositionSize allows you to perform position sizing based on PORTFOLIO EQUITY in first phase without CBT. It includes risk-based portfolio-level position sizing schemes like VanTharp position sizing
Proof:
The current architecture gives AmiBroker SPEED and FLEXIBILITY at the same time. RealTest is so limited in what it can do it just can't compare. Realtest is like "fixed function" integrated circuit (you can do only whatever was hardwired in the circuit).
AmiBroker is like CPU (fully programmable can do anything there are NO LIMITS).
AmiBroker is like top-of-the-line Swiss army knife, Realtest is specialized one-purpose screwdriver.
Doing things the way AmiBroker does gives tremendous processing speed (thanks to first phase that runs in PARALLEL - multithreaded) and power (CBT).
Actually competitors copied AmiBroker, not the other way round. Multicharts people copied our ideas (still they run slow), Realtest also copied some ideas from us, yet does not come close in terms of flexibility.
There is absolutely nothing wrong with Custom Backtester. Just the opposite, over 18 years since it was envisioned and created by me, it has proven to be powerful and flexible, allowing to combine maximum speed provided by multithreaded execution from first phase with flexibility of fully programmable backtest procedure that handles even the most esoteric edge cases user can imagine.
2 Likes
1] Will it be possible to add a "go to/ jump to" option through a drop up menu next to the scroll bar or a widget on the chart or an option on right clicking the mouse on the chart?
The basic purpose would be to :
a] Go to particular bar, say bar # 'x' or 'y' bars from latest or to particular date & time etc. depending on the time frame selected.
or
b] Jump to the bar with a particular parameter value in the chart. As an example HHV in some time range (say 52 weeks). Or if we have coded a custom parameter where we split the chart into 4 equal parts where 52 week LLV and 52 week HHV represent the 0 and 100 Levels and we want to jump directly to the bar which is below say 25% level etc. These are just examples. It could be any coded parameter.
2] Would it be possible to assign comments (or notes) to specific bars in the chart which will either act as pop up, which will be hidden when the cursor is not hovering above it or if it has not been clicked?
Something similar to adding comments to excel cells.
As of now, when the cursor hovers over the bar we can see the custom parameter values which have been coded (which is of immense help!). If we could also add comments to these set of visible values, it will be very convenient.
I understand that most users of AmiBroker would use the software for Backtesting or Charting or Real Time Alerts.
I believe that, while the wish lists I have suggested would be seem mostly useful to chartists, it will nevertheless be useful for those who use the software for backtesting by visually seeing the charts after backtesting and also those who use the software for real time alerts if they want to have a quick review of the chart after an alert.
Thank You.
2 Likes
This would be nice....I agree completely.
Love this! This would be very helpful!
Hi Tomasz, sorry for being away these days.
My Proposal seems to be similar to Sergei´s. It´s easy to implement. Just add a Color attribute to every Ticket. This color can be shown on Watchlists or Groups, so on every container of the Ticket.
About using a Color Attribute for Groups i think can be also OK but is not the same. Color by Ticket is more granular, versatile and useful. When i run Explorers, for categorizing trade opportunities, like Earnings, i don't use groups just i get a watchlist when i would like to categorize the contents based on my discretionary analysis. This can be used in many different ways..
2 Likes
Thanks @Tomasz. Yes, I realize that in setpositionsize, one can specify the size as a percent of portfolio equity. However, one cannot target a position to be a specific percentage of portfolio equity. Hence, even many seemingly routine tasks encountered in many trading systems like re-balancing positions (to be a fixed fraction of the portfolio), scaling back positions if they become too large percentage of portfolio equity, reducing total portfolio exposure (by scaling out current positions) or reducing/increasing position size based on trailing portfolio drawdown/performance/metrics etc., need CBT. I totally appreciate your point about the excellent Amibroker architecture you have invented, that gives both speed and flexibility, and support having continued access to the power of CBT. My point was that maybe its possible to further extend Amibroker's usability while still retaining the current paradigm, by having a pre-processor step which auto generates CBT code ("Auto-CBT") in the regular (non-CBT) mode to implement portfolio-level logic. Ideally, the user can just specifies entry/exit/logic conditions based on treating portfolio-level metrics as vectors/arrays just like other AFL arrays, and the Amibroker pre-processor generates CBT code to implement the logic without the user having to mess with CBT. E.g. enable statements to implement rebalancing like:
scaleOutCondition = autoCBTPositionEquity()>0.5*autoCBTPortfolioEquity();
//both "autoCBTPositionEquity()" and "autoCBTPorfolioEquity()" are reserved array names/functions
Buy = IIf( scaleOutCondition, sigScaleOut, someBuyCondition);
SetPositionSize(scaleOutCondition * abs( autoCBTPositionEquity()-0.3*autoCBTPortfolioEquity()), spsValue );
//If position size becomes greater than 50% of total equity, scale the position back to become 30% of equity.
Amibroker's Auto-CBT generator then parses the above statement and generates the appropriate CBT code (since it has access to both portfolio equity and position equity in the bar-by-bar CBT loop) before starting the backtest.
That way, we are still working within the current architecture, while doing a lot of the work for the user behind the scenes. My suspicion is that something like this would address the vast majority (80%+) use cases that one uses CBT for, and enable implementing many of the routine portfolio-level logic seen in real-world trading systems, without most users having to mess with the CBT. Of course, the remaining 20% of users who want to implement complex logic can still use their own CBT using SetCustomBacktestProc() (but wouldn't then have access to Auto-CBT functions).
In the regular/Auto-CBT mode, the user would have access to arrays for portfolio cash, number of positions, arrays for all trailing portfolio/position statistics (just like other regular AFL first-phase arrays) and the Auto-CBT pre-processor generates the required CBT code in the backgroud to implement the logic prior to the backtest).
Apologize if I am fundamentally misunderstanding or missing something here, but wanted to know if an approach like the above is possible, since it seems like it would make Amibroker even more user-friendly while still retaining the speed and power.
1 Like
Backtest report sizing.
Currently the report window default size is smaller than the content. It does not remember its window resizing. It is always the same small size and position.
It seems that the report window could have the default size remembered when it was manual resized. Amibroker is much better at window sizing and positioning than most programs but here it seems missing.
Hope this helps.
Note: This is now implemented in the 6.91.0 (development version)
1 Like
There are two different things:
- size
- position
With regards to size, report window opens with fixed pixel size. Now when you use it on high-dpi screen, it might indeed be too small. This will be addressed in version 6.91.0
Now the position.
The problem with report window keeping its recent position is that, that you might want to open multiple reports to compare them side by side. Or 3 or 4 reports. If report window opened in the last position, newly open report would be stacked on top of each other and casual user might report a "bug" because he can't see other window open (because it is obscured by another).
Currently the position is automatically "increased" so windows are stacked slightly off so it is clear that there are multiple windows open.
So this suggestion will be implemented in 6.91.0 as follows:
- default size will be calculated based on screen DPI so window get larger on highDPI screens
- recent window size (after user has resized the window) will be stored on exit and restored on next run
- the position (left/top) corner will be automatic (i.e. stacked when multiple windows are open so it is clear that there are multiple windows behind)
- application manifest will include "highdpi-aware" flags, so Windows does not blur the viewer on hi-res screens
2 Likes
@singanuk - I understand what you are saying but I don't understand the "fear" about CBT. CBT provides elegant object-oriented interface to the backtest process. It is clean and logical. Trying to implement this functionality in old procedural way is not elegant.
I strongly disagree with that sentiment. Adding some cryptic, ugly functions is not "better" alternative to CBT. CBT is clean. It is as far as it can be from the "mess". What would be messy is a set of of cryptic functions that are somehow transformed but some bizarre black box to CBT by some yet another translation layer adding complexity and doubt.
Adding "function like" interface to the problem that must act upon objects (trades & signals) anyway is NOT going to make thing clearer. Just the reverse. It would cause the mess. The "functions" would need to have receive "object handles" anyway to be able to operate on individual trades and signals. Instead of calling obj.Method(...) you would be calling LongFunctionName( objhandle, ....) .
What can be done instead, is adding some kind of "standard" (pre-defined) rules for built-in rebalancing schemes, in a similar way how ApplyStop implements stops. This could implement well-defined set of "common schemes" in "easy-to-use" interface and all of that without being translated to CBT at all. That would work for those who don't want to learn CBT. (And by the way CBT is NOT hard to learn, it is actually very very simple object interface with just 5 classes, it is utterly simple). Don't be afraid. It is simpler than functions!
Rebalancing in CBT is truly very simple, there is an example in the Knowledge Base:
Actual "meat" where rebalancing happens is 6-8 lines of code. And it is universal, not some one fixed thing.
2 Likes
Here is my whish list for v7:
- Be able to select database from the command line.
- Support external editor for AFL editing. Currently when files are edited externally it is not recognized until the script is reloaded. Monitoring for file change and update the script in the editor and in charts would be wonderful.
1 Like