|
PureBytes Links
Trading Reference Links
|
Short summary:
1. Optional feature to require all variables to be declared and
AFL parser to check if all identifier (var and function) is declared.
2. Fixed error position info in include files or "Syntax checking"
for include files.
Hi Dennis,
you are right. Script languages are the easiest.
I think that AB's greatest advantages are the fast backtester and
its "special" array processing script language. So I don't mind that it
is a script. For a "quick idea check/strategy development" it is great.
For real time trading on a one minute chart it is an "adventure". The
programming model and the runtime environment are not designed for this
purpose.
Back to finding bugs. If we talk about typos the most annoying errors
for me are the missing/extra {, (, ), } in an include file (I use ~ 10-
15 includes. I developed a framework with testable include modules).
Then comes the variable name mistypes. Then comes the missing function
argument where the function is in an include. Finding them is "not real
debugging", it is typo error hunting in a script. If my suggestion is
implemented in AB the variable name mistypes and resulting
initialization issues of a typo are caught with no "typo hunting"
effort. They can be caught at parse time (at first parse) even in code
sections (functions also) that are not executed on each chart refresh
(e.g. real time trading functions).
I agree with you on include file problem. Anything is better than the
useless character position info. The "quick and dirty" solution to
includes could be a special "Verify syntax" feature for include files.
Syntax validation is now useless for an include file as includes
usually use other includes where functions are defined. All the syntax
errors of missing function declarations make is hard to find real
syntax errors (like a missing ;) in an include file. And the not
resizable error list at the bottom of the script windows makes it
impossible anyway.
If we talk about "real" debugging to find program logic errors we have
to distinguish trading strategy development and real time trading logic
code. They are quite different in the way you write code and how you
debug them.
In trading strategy development we mostly use AFL in its "intended
way". We have to think in sets/vectors/matrixes. The programming model
is static. We mostly work on static data (past), the result is static.
So its not a big deal. We simple display the static results of
set/vector/matrix operations on a chart (these are indicators, filters,
explorations). Code path is usually "straight" without branching. To
debug this logic we have to write debugging code (Plot/PlotShapes
calls, displaying bar data in tooltip and interpretation window). We
change the code, run it then we stare at the chart. It is static and we
have time... :)
AB does not provide any handy tool for this type of debugging. There is
no way to step through the code and display an array variable on the
chart ad-hoc. You have to change the code. (And version it ... )
If there would be a "mouse click shortcut" to generate code to plot a
variable or to "mark" a single variable to be displayed with some
distinctive style on the chart with its own scale? This type of
debugging could be easy and fast.
Real time trading system development is quite different. There we need
an "event driven like" run time environment. The programming model is
quite dynamic, the data to process changes continuously (e.g. when the
status of an order changes the code has to react. The indicators on the
actual bar change values continuously and orders have to be send
according to the changing indicator values). Here we do not use arrays
but "STATIC variables" to store current state of a system. Code path is
quite fragmented. There are a lot of branching and function calls. I do
not intend to hurt TJ or anyone but AFL and it's runtime environment is
not designed for this.
To develop a "reliable" system of this type we would need at least a
code debugger and an exchange simulator. With them we could step
through the code and see how the state of the system (static variable
values and code path) changes and to check if all code paths work as
intended.
AB does not have a step through debugger so we have to put trace code
everywhere and print out all interesting variable values to debug
output and to log files.
The real catch with this type of programming in AFL is that errors
(syntax and logical) show up unexpectedly and then they disappear at
next refresh. AB 5.20's log window is a great deal of help in this. But
that is after the event... If you have a position and it should be
closed you do not want to bother with mysterious bugs.
These errors appear and disappear as different code paths are executed.
Stricter language syntax ("option explicit" like required variable
declaration and stricter parse time checking) does not solve program
logic bugs but a lot of these sudden syntax errors could be eliminated.
Regards
Y
------------------------------------
**** IMPORTANT ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
*********************
TO GET TECHNICAL 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/
|