|
PureBytes Links
Trading Reference Links
|
Hi Robert.
The power of the Z is on the rise!
Your experience, knowledge, insight and prediliction for open communication are welcome additions to the community.
All your points are good ... I have addressed some of them in other posts and will move the discussion of the core issues over to Howard's topic (Howard is an author, academic, financial consultant, community orientated, tolerant of contrary opinion and his efforts are integrated with AB development so all in all it would better to hold the discussion under his chairmanship).
--- In amibroker@xxxxxxxxxxxxxxx, i cs <ics4mer@xxx> wrote:
>
> Hi all,
>
> Here I am, only had AB for 24 hours, and already
> offering my 2c worth!
>
> Thank you for making that file available Angelo.
>
> I'm not sure if I am understanding this thread correctly.
> If it's just a matter or running a list of tests against
> a list of instruments - would that not be a reasonably
> simple AFL/Batch run of some sort? ( Remember
> I am a newbie! )
>
> I think the beauty and power of running a
> mulit system/multi instrument BT would be to optimise
> the use of cash (and leverage ) in your account. If this
> is the case, then I don't think that the pseudo code
> you provided would do the job. I do appreciate that
> it is a simplified version of the final product, but
> looking at it I ask myself the following questions:
> - Does the Unit Size script "know" how much each
> other system/instrument strategy has allocated?
> - Is the account "infinite" ? If it isn't an
> infinite account, then the first systems in the loop
> get the most of the allocation because all the fills
> are checked before the next system is tested.
>
> If the allocations are done via optimisation ie
> running the above psuedo code for all possible
> values returned from UnitSize, then
> that becomes a huge task, but not one out of
> the scope of the evolutionary optimisations
> built into AB. This would give you a solution,
> but I get the feel it would be a brute force
> empirical one, and I think ( while it's all still
> it the talking stages ), that we should perhaps
> be discussing a more elegant parametrically
> based solution. Go For Gold!
>
> If you are trying to optimise account allocations
> on a finite account then you would have to
> prevent some good systems from trading simply
> because they are either not as good or too
> correlated to other systems. In some optimisations
> you would have to include sub-optimal
> systems because they are capable of smoothing
> out the equity curve - like buying OTM puts. They
> would lose most of the time, but when they won
> they would do the equity curve a world of good.
>
> This is definitely an area worth discussing at
> length.
>
> Regards
>
> RZ
>
>
>
>
>
>
> ________________________________
> From: ang_60 <ima_cons@xxx>
> To: amibroker@xxxxxxxxxxxxxxx
> Sent: Friday, 8 May, 2009 11:44:17 PM
> Subject: [amibroker] Re: testing multiple systems simultaneously
>
>
>
>
>
> --- In amibroker@xxxxxxxxx ps.com, "Paolo Cavatore" <pcavatore@ ..> wrote:
> >
> > the same logic used in portfolio backtesting should be used in >multi-systems portfolio backtesting.
> >
> >
> >I should assign a proper positionsize of the equity line every time >I get a signal whatever system it comes from - for instance I can >always take a 2% position on every signal no matter if it comes from >system A or B if I'm not supposed to potentially get more than 50 >signals at the
> >
> >
> >
>
> Hi all,
>
> here
>
> http://www.filedrop per.com/loopform ultisystemmultim arket
>
> you will find an almost- too-much simplified loop showing (*) how another software has been programmed in order to get to the target (wellâ?¦. not at 100% but reasonably nearâ?¦. I leave aside the details).
>
> Just translate "instrument" with tickers of a portfolio, and "unit size" with position sizing rules.
>
> For the rest, I concur with most of what Paolo is saying (especially important to me are his two sentences above).... I'm sure there's some misunderstanding among the people in this thread, created because Internet is a wonderful mean to talk to people everywhere in the world but sometimes it's really impossible to reproduce the same efficacy on an eye-on-eye discussion.
>
> PS Thanks to Paul and Benoitek for your precious inputs. They have not been lost.
> I've saved them on my PC and will be looking at their "ways to do" with great attention.
> Onlyâ?¦. this discussion has evolved on the possibility to get Tomasz think if it's possible/economical ly efficient for him to get a "built in solution" â?¦.. also because I know "low level CBT solutions" are not accessible to my present knowledge â?¦. and will not be in a not too distant future neither.
> If it's not possible for nowâ?¦. never mind â?¦.. at the very least we have had a really interesting discussion and some worthwhile suggestions.
>
> Greetings,
>
> Angelo.
>
> (*) This flow chart is publicly available on the web, even by non-purchasers of that product, so I'm confident I'm not violating any copyrights.
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|