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 [email protected], "jooleanlogic" <joole...@...> 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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "tuzo_wilson" > > > > > > > > <j.tuzo.wilson@> wrote: > > > > > > > > > > > > > > > > > > --- In [email protected], "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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
