|
PureBytes Links
Trading Reference Links
|
When you use static variables note that if you use the same name in
multiple indicators they can clash. These are system global variables
I think so be careful how you use them.
To prevent this from happening I use a VarPfx variable to make the
variable mane unique. I use the indicator file name plus the version
of the indicator. Follows is the code I use:
_N(SectionName = "Your file name goes here");
_N(Ver = "Ver1_0"); // indicator version number
_SECTION_BEGIN(SectionName);
EnableTextOutput(False); // prevents incidental text from being
displayed in the interpretation window
VarPfx = Filename + Ver; // it does not seem to matter if you use
spaces or special characters in the file name or version. But I don't
just in case. Also if you are hancling multiple symbol names you can
add the name to VarPfx, VarPfx = Filename + Ver + Name();, and so
on.
Then in the static var I add this as a prefix:
StaticVarSet(VarPfx + "var name goes here", assignment value here);
Barry
--- In amibroker@xxxxxxxxxxxxxxx, "J. Biran" <jbiran@xxx> wrote:
>
> This is an interesting discussion.
>
>
>
> Re 11) is there a disadvantage in using
> StaticVarSet("varname"+Name()+Interval(2),Var);
>
>
>
> Joseph Biran
> ____________________________________________
>
>
>
> From: amibroker@xxxxxxxxxxxxxxx
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
> Sent: Monday, August 04, 2008 1:42 PM
> To: Herman vandenBergen
> Subject: Re: [amibroker] AFL programming style questions
>
>
>
> Thanks Herman,
>
>
>
> re 6) That is an amazing trick. If I did not rely on the
> Parameter Window for my parameters, I would likely use this
> idea. You might get away without using the Parameter
> Window, but I still find it very useful --short of writing a
> complete replacement. In any case, I will keep it in mind
> for future consideration because it is such a great trick.
>
>
>
> It would be interesting to see what the difference in time
> is between static and natural variables under different
> circumstances.
>
>
>
> re 11) Since I only run in indicator mode and don't use AA
> at all, ChartID works for me. However, I have made it a
> global variable ChartID = NumToStr(GetChartID());
>
> I could easily change it to any unique string I wanted to in
> a few seconds --or even a manually entered identifier. I
> just added a global type parameters now so that I can share
> those between different setups. I also added symbol global
> parameters. I already had the ability to add symbol
> specific parameters within a setup. I think that will cover
> all the bases. With my current scheme, I can have one chart
> controlling the parameters for another chart (without it
> even knowing it) by swapping the ChartID string. This is
> how I plan on doing my home built optimizer chart.
>
>
>
> Great fun!
>
>
>
> Best regards,
>
> Dennis
>
>
>
> On Aug 2, 2008, at 2:36 PM, Herman wrote:
>
>
>
>
>
> re 6) yes just calculate the values and write them to an
> include file like. This would be done conditional so it only
> updates the variables when needed, not at each execution of
> course.
>
>
>
> a=3;
>
> b=6;
>
> s1 = "AAPL";
>
> etc;
>
>
>
>
>
> I have hundreds of variables declared that way. Common sense
> tells me this is faster than either staticvar or persistent
> variables.
>
>
>
> re 11)
>
>
>
> If you share staticvar between Indicators and the AA using
> ChartID is a problem because it is not available in the AA.
>
>
>
> have fun!
>
> herman
>
>
>
> Saturday, August 2, 2008, 12:40:40 PM, you wrote:
>
>
>
> > Herman,
>
>
>
> > Wow! What a list. A lot of good ideas in here. Thanks!
>
> > I have gone down the checklist to see where I stand on
> these (embedded below).
>
>
>
> > BR,
>
> > Dennis
>
>
>
> > On Aug 2, 2008, at 3:58 AM, Herman vandenBergen wrote:
>
>
>
> > I have tried many styles but was never able to stick to
> anyone.
>
> > Here are some of my preferences however i am afraid I
> don't have a specific style! .
>
>
>
> > I like compact listings to see the maximum number of lines
> at once.
>
>
>
>
>
> > 1. Ditto.
>
> > I rarely use multiple statements in one line.
>
>
>
>
>
> > 2. I do this sometimes when it expresses one thought like:
> if( Condition ){ X=This; Y=That; }
>
> > I use empty lines to space functional blocks, not to space
> code for visual effect.
>
>
>
>
>
> > 3. Ditto.
>
> > I like to indent the curly brackets, to make function and
> other blocks of code stand out better
>
>
>
>
>
> > 4. I do this type of code block indenting now:
>
>
>
> > if(condition){ // simple comment about what we are doing
>
> > indented block of code
>
> > is put here
>
> > }
>
> > else{ // another simple comment
>
> > the else part
>
> > }
>
>
>
> > I use include files when I can to shorten listings. i
> frequently
>
> > paste the code temporarily back in for debugging.
>
>
>
>
>
> > 5. Ditto. I have thought it would be cool if include
> files could
>
> > be edited and applied with the syntax check in context
> with the active chart --dream on.
>
> > If I need to store a lot of calculated variables I may
> write them
>
> > to an include file instead of using StaticVariables or
>
> > persistentvariables. I use #Pragma NoCache to get it read
> each time.
>
>
>
>
>
> > 6. This is a real out of the box idea that never occurred
> to me.
>
> > So you overwrite a file with lines of text like "var =
> number; "
>
> > then pull them in at the beginning of your formula as a
> way of
>
> > saving parameters. I approached the problem differently
> with
>
> > Flexible Parameters, but I like your idea to let the AFL
> parse the
>
> > names and default values in this way.
>
> > I use long descriptive variable names; its usually less
> typing and
>
> > easier to read than adding long comments.
>
>
>
>
>
> > 7. I am trying to do more of this.
>
> > I break up lengthy calculations to give me debugging
> points.
>
>
>
>
>
> > 8. Ditto.
>
> > I use DebugView a lot, every day.
>
>
>
>
>
> > 9. Never use it other than once long ago. I have now
> written
>
> > special debug statements that display variables (in an
> information
>
> > "button" array) as they appear at any selected bar in a
> loop, or
>
> > anytime option. This has made debugging hard problems a
> lot easier
>
> > now. However, I can see that for things like an auto
> trade audit
>
> > trail, the DebugView method is the way to go.
>
> > I use three //////// rows to separate major func! tional s
> ections to
>
> > allow spotting them when scrolling through thousands of
> lines of code.
>
>
>
>
>
> > 10. Ditto, but I use //==============
>
>
>
>
>
> > I key most static variables to prevent them from being
> common to multiple applications
>
>
>
>
>
> > 11. Ditto, but I only use ChartID because I only have one
> chart per ID.
>
> > I use persistent variables to facilitate easy start up
> sequences
>
> > and to keep trading (IB/TWS) records
>
>
>
>
>
> > 12 . Ditto, but I use Flexible Parameters method for
> this.
>
> > I like to see initialization blocks because conditions
> often change
>
>
>
>
>
> > 13. Ditto.
>
> > I have folders in my Charts workspace that contain
> frequent used
>
> > code snippets, segments, templates, etc. I edit-copy-paste
> from these
>
>
>
>
>
> > 14. Good idea.
>
> > I often work with two editor windows, one to copy from,
> one current work
>
>
>
>
>
> > 15. Ditto, but one is often a Mac window and one a PC
> window.
>
> > I Apply my include files to a separate pane/tab so I can
> easily
>
> > open/modify include files. i use 20 tabs.
>
>
>
>
>
> > 16. Interesting idea. Some of my include files will not
> compile without each other.
>
> > I use Chart tabs to organize work in progress and create
> Layouts
>
> > for major code changes, or new systems.
>
>
>
>
>
> > 17. I only do a little of this.
>
> > I use revision numbers for all programs, like
> ProgramName-001. This
>
> > creates lots of files and requires me to run Program
> maintenance once a week.
>
>
>
>
>
> > 18. I could improve in this area. I usually just keep
> the last
>
> > one -- though I have an automatic backup system that keeps
> versions by time, date and month.
>
> > Once a week I search my computer for all afl files and
> import them into dated-folders in InfoSelect.
>
>
>
>
>
> > 19. Luckily, I only have a few programs and only only one
> main AFL
>
> > I work on, so it is not hard for me to track my stuff.
>
> > When assigning many variables I like to tab all the "="
> signs to
>
> > the same level for easier reading.
>
>
>
>
>
> > 20. That is an interesting idea.
>
> > ...
>
>
>
> > best r! egards,< /span>
>
> > herman
>
>
>
>
>
>
>
>
>
> > Friday, August 1, 2008, 9:07:31 PM, you wrote:
>
>
>
> >> Hello veteran AFL programmers,
>
>
>
> >> I am still working on developing a consistent AFL style.
>
>
>
> >> I am writing a lot of AFL functions. I try to make as
> many things
>
> >> functions as I can so that I can reuse a lot of code. It
> also makes
>
> >> it easier for the editor to find syntax errors since my
> main code is
>
> >> indicator only and the syntax check pass does not see
> that code since
>
> >> it runs without the Chart ID.
>
>
>
> >> My trading platform is over 5000 lines of AFL (I keep
> adding more, and
>
> >> it keeps getting smaller...LOL). About half of that is
> functions. I
>
> >> pass a lot of data through global variables and arrays
> between
>
> >> functions for the state of the system. It was the only
> efficient way
>
> >> that I knew how to make code modular was to have the data
> common. AFL
>
> >> is largely based on that premise already with special
> state variables
>
> >> and price/trade arrays.
>
>
>
> >> Right now, I have a mix of variable initializations and
> just global
>
> >> declarations at the top of the formula ! so that I don't
> have to declare
>
> >> the globals in each function. I still have a lot of
> global
>
> >> declarations in some functions, but I want to finish
> getting rid of
>
> >> them and just have them declared at the top with a good
> description of
>
> >> how they are used.
>
>
>
> >> I had it in my head that a bunch of global declarations
> in a
>
> >> frequently called function would slow down the execution
> of the
>
> >> function. Am I right about that?
>
> >> I thought I could just mention the names of the input and
> output
>
> >> variables in the header comments if needed for
> documentation.
>
>
>
> >> I am also slowly changing my comments from // to /* */
> so that they
>
> >> are not in the execution path.
>
>
>
> >> I am starting to make my variable names longer so that
> they are more
>
> >> descriptive of the data they hold.
>
>
>
> >> I have some naming conventions like FP_Name for variables
> that are
>
> >> part of my Flexible Parameters system and exist outside
> of t! hat modu le.
>
>
>
> >> I am now planning on adding GP_Name for global parameter
> names and
>
> >> SP_Name for symbol specific parameter names. In Flexible
> Parameters,
>
> >> I give my parameters distinct names independent of their
> displayed
>
> >> labels. Those will be more than mere convention in that
> they will
>
> >> cause the parameters to be saved in a different file
> folder.
>
>
>
> >> What kind of naming conventions do you use that you are
> proud of?
>
>
>
> >> Any other unique features of your program style that you
> think are
>
> >> worth copying?
>
>
>
> >> Thanks for sharing your style ideas.
>
>
>
> >> Best regards,
>
> >> Dennis
>
------------------------------------
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
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/
|