|
PureBytes Links
Trading Reference Links
|
Hello,
AFL is basically the same as C (simple, old plain C, not C++),
but without declarations, pointers, memory allocation and all complex stuff that
people find difficult.
Instead it adds native array operators so you write
MyAverage = ( High + Low ) / 2;
and it internally knows that it needs to process every element of array.
In plain C you would always need to write a loop
int i; // declaration required in C but not in AFL
float MyAverage[ BarCount ] ; // declaration required in C but not in AFL
for( i = 0; i < BarCount; i++ )
{
MyAverage[ i ] = ( High[ i ] + Low[ i ] )/2;
}
Of course the same loop works in AFL too, but array statement
is simpler, clearer or even more "elegant" as you need only one line instead of 6.
That single addition (ability to use arrays without loops) plus
automatic memory management is the whole story, there is nothing more to
AFL as compared to C.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "brian_z111" <brian_z111@xxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Friday, February 13, 2009 11:39 AM
Subject: [amibroker] Re: Run time debugging for includes
>> If you understand the simple elegance of the AFL
>> execution process, you would see that this is just wrong.
>
> That is a view that I would like to see; "the simple elegance of AFL
> execution process".
>
> What is the path to that vantage point?
>
> 1) I presume a prior knowledge of how computers work is required
> (machine language, compiler, what a processor does etc)?
>
> 2) Within AB ... go to the developers kit?
>
> I am up to the part where Wiki told me arrays are contiguous in
> memory and that sounds like a good thing .... now I need to know
> where I can find out how AFL execution works (specifically array
> processing).
>
> Anyone care to show me the starting line?
>
> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>>
>> John,
>>
>> You are only making the case that proper organization is the
>> responsibility of the programmer. Programming is a sharp sword.
> You
>> can slice up your problems with it, or you can cut yourself. It
> is
>> all in the technique. And yes, I also need to be reminded of what
> I
>> wrote last month and why.
>>
>> My include statements in the main program are not one-liners.
> There
>> is a comment block at the start of each include file that
> documents
>> what is in there -- like a table of contents. I paste that whole
>> block into my main program. That way I have the top level
>> documentation of what is included -- usually a list of functions
> with
>> parameter names and a short description of why to call it. If I
>> search for a function, it will come across the definition in the
>> include comments. Each function in a file has its own comment
> block.
>> Though I don't make a point of documenting every little change or
> bug
>> fix, I do note the last change date on each one.
>>
>> Outside of a major block of inline code, blocks of functions are
> what
>> I think of as AFL language extensions. So I might have one
> include
>> called FP_UtilityFunctions.afl that adds a dozen useful general
>> purpose stand alone functions to AFL independent of trading
> program
>> specifics.
>>
>> On the other hand, I have FlexibleParam_Buttons.afl that adds many
> new
>> functions that specifically support on-chart button arrays. It has
> a
>> lot of functions and many of them call each other and must be
>> compatible as a set. It would be pure insanity to figure out how
> the
>> whole set worked without being able to see all the code and
> comments
>> together in the same file.
>>
>> Then I have an include called FP_BtnBarInfo.afl that implements a
>> specific button/table of bar information -- a bar inspector. It
> is
>> not a function, but inline code that includes parameter
> definitions,
>> layer mouse click claim code, and a procedure called DrawBarInfo()
>> that draws the buttons on the screen with Gfx commands. That has
> to
>> be called later in reverse order of of all the buttons because
> there
>> are no Z layers for Gfx commands, or else it would be part of the
>> inline code.
>>
>> I would suggest that your proposal would actually make things more
>> obscure from my point of view if I tried to use it as you are
>> suggesting. Then there is the problem of the compiler. It is not
>> really a compiler to any greater sense than most interpreters
> have.
>> It is not multi-pass for resolving references. The preprocessor is
> as
>> close to a compiler pass as it has, and it only looks at a few
>> specific commands like #include. It would have to be able to
> parse
>> the whole syntax to look for functions that are undefined, try to
> find
>> them in a file, add them to a special buffer that is always
> executed
>> initially as part of the AFL pass. This would be a lot of pain
> for
>> little gain. If you understand the simple elegance of the AFL
>> execution process, you would see that this is just wrong.
>>
>> I am quite happy with the general concept of include files as
> opposed
>> to external functions. As I have pointed out, I lends the perfect
>> level of modularity to my programming. It also helps with
> revision
>> control that I only have one AFL trading program -- with a
> thousand
>> parameters. If I had many different trading programs, then I
> would
>> likely add a version number to the include file names for non-
> backward
>> compatible revisions, and leave the old ones alone.
>>
>> Keep the blade away from you own arms and legs. ;-)
>>
>> Best regards,
>> Dennis
>>
>>
>> On Feb 12, 2009, at 6:18 PM, Listsub wrote:
>>
>> > Dennis,
>> >
>> > Interestingly I started out with same view as yourself regarding
>> > grouping related functions into one include file. Although it
> went
>> > against my past experience it was appealing because it seemed a
>> > quicker path to the business of developing and testing trading
>> > systems. Over time I found this approach did not work well for
> me
>> > and I switched to one per file. Reasons it didn't work?
>> >
>> > I found tracking code changes awkward. For example I knew a
> function
>> > group had been changed but which function within it and why?
>> > Keeping track of dependencies.
>> > Forgetting which functions were in which files - my age;-)
>> > Putting the wrong includes in programs - often redundant - age
>> > again ;-)
>> > Silly stuff like what group shall I put this function in - I
> ended
>> > up with 3 big files called Misc1, Misc2, Misc3!
>> >
>> > As you say working with large numbers of files is a challenge. A
>> > good Editor, version control and well organised folders help.
>> >
>> > Thanks for your ideas.
>> > John
>> >
>> >
>> > ----- Original Message -----
>> > From: "Dennis Brown" <see3d@xxx>
>> > To: <amibroker@xxxxxxxxxxxxxxx>
>> > Sent: Thursday, February 12, 2009 2:58 AM
>> > Subject: Re: [amibroker] Re: Run time debugging for includes
>> >
>> >
>> >> John,
>> >>
>> >> Although I would not take advantage of some of what you are
>> >> suggesting, still you make some good points, and you got me
> thinking
>> >> about things that I could use.
>> >>
>> >> I would prefer to have a group of related functions in an include
>> >> file, rather than just one function per file. That way with one
>> >> include file I get a whole new functional set that are edited
>> >> together
>> >> to stay compatible version wise. Otherwise my 40 files would
>> >> become a
>> >> confusing 200+ files. Too much for me! There is a fine line
> between
>> >> not enough modularity and too much modularity. If I do want the
>> >> modularity, then the include can be written to follow the rules
> of a
>> >> function that you describe for scope.
>> >>
>> >> Right now, the include path names are constants because they are
>> >> preprocessed. I would like to have preprocess commands to set an
>> >> override default path for includes folder. That way one
> definition
>> >> in
>> >> the main code before the include could override the default
> include
>> >> folder path. One easy edit to get a new set, or reorganized to a
>> >> subfolder.
>> >>
>> >> #IncludeFolderPathOverride = "path" or <path> to relocate to a
>> >> relative subfolder
>> >> #Include <FilePath>
>> >> #IncludeFolderPathRestore
>> >>
>> >> The override is really a push, and the restore is a pop for
> multiple
>> >> levels. That way you could substitute a new path for just a
> portion
>> >> of the includes that you are testing without hard coding a fixed
> path
>> >> for each one.
>> >>
>> >> Your point #4 below is also an interesting one and could be
> applied
>> >> to
>> >> the include file path.
>> >>
>> >> Best regards,
>> >> Dennis
>> >>
>> >>
>> >> On Feb 11, 2009, at 8:38 PM, Listsub wrote:
>> >>
>> >>> As noted debugging AB with includes is not easy . The nature of
> AFL
>> >>> makes it quick and easy to write/test simple stuff but as
> complexity
>> >>> grows debugging any sizeable AFL project can be quite tricky,
>> >>> particularly if running RT as there is a lot going on.
>> >>>
>> >>> "Modular" programming is only catered for in AB by Includes
> (which
>> >>> is just a soure code copy preprocessor). The AB program
> structure
>> >>> model is therefore basically just one big chunck of code -
> which is
>> >>> why (unless you are very careful what you code inside Inlcudes)
> you
>> >>> can get some very hard to find problems (the problems can even
>> >>> change or disappear depending on the roder of Includes).
>> >>>
>> >>> IMO improving AFL to support procedure/function calls to
> external
>> >>> files would be a big plus to enabling better modular program
> design.
>> >>> Specifically:-
>> >>>
>> >>> a =xyx(p1,p2) would call the external proc/func "xyz" (unless
> xyz
>> >>> is defined in current source file).
>> >>>
>> >>> The benefits as I see them:-
>> >>>
>> >>> 1. #Inlcudes are no longer required for procs/fucntions.Compiler
>> >>> would pull them from library specified via preferences. No more
>> >>> searching for which Include file is that function in, which
> version
>> >>> of that was I using .. etc.
>> >>>
>> >>> 2. External functions matched by filename. i.e one function
> name =
>> >>> one filename, no ambiguity, easily portable.
>> >>>
>> >>> 3. External files are closed boxes - can only receive/pass data
> via
>> >>> parameters, return value or global variables. Everything else
> inside
>> >>> file is local. No interference bewteen files.
>> >>>
>> >>> 4. Faster code development/maint. For example if we have the
>> >>> facility in Preferences to define multiple paths to external
> proc/
>> >>> func library it becomes easy to test out changes without having
> to
>> >>> resort to all the usual suffixing fillenames, changing calls
> etc.
>> >>> i.e.
>> >>>
>> >>> path1=AB_Function_Library_Test
>> >>> path2=AB_Function_LIbrary_Live
>> >>>
>> >>> So to test out a mod just copy the function file to the Test
>> >>> library, make the changes and test. Compiler searches paths in
> order
>> >>> specified so anything with matching name in Test takes
> precedence
>> >>> over same name in Live.
>> >>>
>> >>> 5. Easier debugging? ;-)
>> >>>
>> >>> John
>> >>>
>> >>>
>> >>> ----- Original Message -----
>> >>> From: "jtoth100" <jtoth100@xxx>
>> >>> To: <amibroker@xxxxxxxxxxxxxxx>
>> >>> Sent: Wednesday, February 11, 2009 2:26 PM
>> >>> Subject: [amibroker] Re: Run time debugging for includes
>> >>>
>> >>>
>> >>>> Hi all,
>> >>>>
>> >>>> debugging includes is not easy and handy in any script
> language. So
>> >>>> instead of making the GUI to reduce clicks my suggestion would
> be
>> >>>> to
>> >>>> reduce possible error cases.
>> >>>>
>> >>>> Most errors come from undefined/uninitialized variables. If AFL
>> >>>> language would have an "OPTION" to require definition of all
>> >>>> variables then most common errors could be vanished.
>> >>>> Visual Basic 6.0 never was my favorite language and
> environment. It
>> >>>> was for average Joe to do basic level programming. It did not
>> >>>> require
>> >>>> declaring variable just like AFL or any script language. But
> I
>> >>>> had to
>> >>>> use it years ago. At that time all serious developer started
> each
>> >>>> module in VB with "Option Explicit On". This caused an error at
>> >>>> parse/compile time if a variable was not defined explicitly
> but was
>> >>>> referenced anywhere in the code.
>> >>>>
>> >>>> How would it help?
>> >>>> Most probles come from just creating variables by assigning a
> value
>> >>>> to an "identifier". However if you misstype an "identifier" or
> code
>> >>>> execute in a code path where variable does not get
>> >>>> defined/initialized you get an error. The worst thing is that
> these
>> >>>> errors are hidden until the rearly executed code path is
> executed
>> >>>> (typical runtime error). If definition of variables are
> required
>> >>>> even
>> >>>> these code paths are checked for proper variable usage.
>> >>>>
>> >>>> This should be an option for advanced users which is turned on
> on
>> >>>> purpose. So all code out there could run with no change.
>> >>>>
>> >>>> Variable assignment and definition could be merged to one
> statement
>> >>>> like in any modern language (e.g.: var x = 0.5;) This way
>> >>>> declaration
>> >>>> is required and initialization can be done as well.
>> >>>>
>> >>>> I know it does not guaranty that all runtime error are gone.
> But
>> >>>> with
>> >>>> disciplined coding most can be avoided and the need for
> debugging
>> >>>> is
>> >>>> vastly reduced.
>> >>>>
>> >>>> So I would not go for GUI change request but to improve AFL as
> a
>> >>>> script language.
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Y
>> >>>>
>> >>>>
>> >>
>>
>
>
>
>
> ------------------------------------
>
> **** 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
>
>
>
------------------------------------
**** 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/
|