|
PureBytes Links
Trading Reference Links
|
Ahh. Of course. That's what was throwing me. Thought I was going mad.
All done bar a little polishing... for reference, the same piece of looping code in a C++ DLL is approx 25-35 times quicker than the equivalent in AFL in this case... of course that only applies to looping code and not normal AFL array instructions.
--- In amibroker@xxxxxxxxxxxxxxx, "jooleanlogic" <jooleanl@xxx> wrote:
>
> Don't forget that the first time your script is executed, Amibroker runs it once with all bars required before the QuickAFL kicks in. So it is normal that your first debug run may show 5000 bars if that is how many there are, and subsequent runs only 150.
>
> How you structure code is very implementation specific. In the beginning, just go with whatever is easiest. You will be naturally forced into finding better ways of doing things as your code increases in complexity, which it inevitably will.
>
> As a basic guiding rule though, you want to create functions with as few dependencies on external objects as possible.
> In this case, if you use gSite.GetStockArray() inside your custom function, then your function is dependent on the SiteInterface structure. If you pass arrays into the custom function instead, then it isn't. The less dependencies, the better.
>
> > Does anyone use that group...?
> Ha, no not really. But you will find already solved answers to the common problems you're no doubt going to run into.
>
> Jules.
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Rob" <sidhartha70@> wrote:
> >
> > Jules,
> >
> > Thanks. Sorry.. that was weird. At one stage I seemed to viewing arrays passed as parameters via the custom DLL call in AFL as having only 150 elements (correctly as defined by quick AFL) yet the internal stock arrays via gSite.GetStockArray() seemed to have over 5,000 elements (the total array size in that interval). However, all seems to be well now... no idea why.
> >
> > One quick thing... If I'm going to accessing the internal stock arrays, am I better passing them to the custom function as array parameters or via the gSite.GetStockArray()...? I guess they amount to the same thing...?
> >
> > Does anyone use that group...?
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "jooleanlogic" <jooleanl@> wrote:
> > >
> > > Do you mean that the first value in BarIndex() is always 0?
> > > This will be the case if you are running the latest version of Amibroker. The implementation of BarIndex has changed in version 5.29.6
> > >
> > > http://www.amibroker.com/devlog/
> > > Point 13 on the above page notes -
> > > "BarIndex() now returns values always starting from zero (even if QuickAFL is turned on)."
> > >
> > > Plugins have no effect on the way Amibroker handles data. You have access to exactly the same amount of data as you would in the afl script that you're running from.
> > >
> > > You can use gSite.GetArraySize() to get the number of bars available. I.e. BarCount.
> > >
> > > By the way Sid, in case you're not aware, there's an Amibroker dll forum here:
> > > http://finance.groups.yahoo.com/group/amibroker-dll/
> > >
> > > Jules.
> > >
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, "Rob" <sidhartha70@> wrote:
> > > >
> > > > Actually Jules, while I've got you, one further question... when you load the AB stock arrays using gSite.GetStockArray() it seems to load the entire array from a BarIndex() value of zero...
> > > >
> > > > I'm a touch surprised by that. Why doesn't quick AFL apply...? Because it seems to when you pass arrays as parameters to the C++ function from AFL.
> > > >
> > > > --- In amibroker@xxxxxxxxxxxxxxx, "jooleanlogic" <jooleanl@> wrote:
> > > > >
> > > > > As far as I know Sid, the ftol2 is the assembler code for converting a float to an int.
> > > > > Are you trying to step into that line of code (F11) during debugging or does it give you that error no matter what?
> > > > > There's not much point stepping into the assembler file for that, just step over it with F10.
> > > > >
> > > > > Mp stuff's coming along fine. Visually, I've been using it for a few months but work under the hood will be ongoing for a while.
> > > > >
> > > > > Jules.
> > > > >
> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Rob" <sidhartha70@> wrote:
> > > > > >
> > > > > > TJ or anyone else,
> > > > > >
> > > > > > I'm just playing around with the Visual Studio debugger looking at TJ's 'ExampleMA' function... when I get to the following line,
> > > > > >
> > > > > > int nRange = (int) ArgsTable[ 1 ].val;
> > > > > >
> > > > > > I consistently get told that the 'source code is not available'... it seems to be looking for a file "ftol2.asm"...
> > > > > >
> > > > > > I have been googling all morning and seem have enabled the automatic downloading of all the Microsoft symbol's at http://msdl.microsoft.com/download/symbols
> > > > > >
> > > > > > Any ideas what's going on here...?
> > > > > >
> > > > > > TIA
> > > > > >
> > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "jooleanlogic" <jooleanl@> wrote:
> > > > > > >
> > > > > > > Yes you can attach to the Broker.exe process and step through your dll code.
> > > > > > > The Visual C++ Debugger is excellent.
> > > > > > >
> > > > > > > As DNSFAB noted, the C code equivalent is not as straight forward as afl as there is glue code needed, but Tomasz has made the plugin as easy as possible to get started with and there's clear code examples. If you're new to C, then that's going to be your biggest headache initially.
> > > > > > >
> > > > > > > Jules.
> > > > > > >
> > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Rob" <sidhartha70@> wrote:
> > > > > > > >
> > > > > > > > Tuzo,
> > > > > > > >
> > > > > > > > Thanks. But I'm pretty much where you described. I have a very efficient piece of AFL code that HAS to use loops. There is simply no other way to do it... and I've spoken to some very good AFL coders in the process.
> > > > > > > >
> > > > > > > > That routine takes up about 70% of my AFL execution time... I'm running 12 charts and have to spilt them across 2 separate instances of AmiBroker to keep my speed at day trading levels. (i.e. I'm overloading the CPU on one instance)
> > > > > > > >
> > > > > > > > I think I'm definitely at the point where optimization of speed via a C++ dll would be beneficial!!! I'd just be interested to see how much speed it actually adds.
> > > > > > > >
> > > > > > > > While I'm here, can I ask a question about debugging AB dll's... what's the best way...? Can I attach to the AB process or can I simulate an AB call within Visual Studio...?
> > > > > > > > Sorry if that's a silly question... but I'm brand new to Visual Studio...
> > > > > > > >
> > > > > > > >
> > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "tuzo_wilson" <j.tuzo.wilson@> wrote:
> > > > > > > > >
> > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Rob" <sidhartha70@> wrote:
> > > > > > > > > >
> > > > > > > > > > Thanks Jules. Very informative.
> > > > > > > > > >
> > > > > > > > > > "This is why you should always try and use the built in functions and array arithmetic operators where possible."
> > > > > > > > >
> > > > > > > > > That makes sense. Not only are they fast but they've been tested by thousands of users.
> > > > > > > > >
> > > > > > > > > > Or indeed code any looping structures that can't be avoided in AFL and are called regularly in C++ as a DLL.
> > > > > > > > >
> > > > > > > > > Not to start a religious war, but as the saying goes, "premature optimization is the root of all evil".
> > > > > > > > >
> > > > > > > > > http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
> > > > > > > > >
> > > > > > > > > Why not keep it simple and code in AFL, then see how that performance meets with the requirements? If there actually is an issue, then some design changes can be made to increase performance.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tuzo
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
------------------------------------
**** 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:
amibroker-digest@xxxxxxxxxxxxxxx
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/
|