Please ignore. Sorted. I wasn't clearing the AmiVar Result array upon multiple calls.
--- In [email protected], "Rob" <sidharth...@...> wrote: > > Actually, forgot to mention... one of the little bits of 'polishing' is that > I seem to be getting very broadly the correct results. However I am also > getting some ghost signals on bars that I'm pretty sure relate to the array > sizes & quick AFL... because when I change my SetBarsRequired() call at the > end of my AFL the ghost signals either disappear, or more frequently move to > another place. > > Very strange... any obvious spring to mind...? > > --- In [email protected], "jooleanlogic" <jooleanl@> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
