|
PureBytes Links
Trading Reference Links
|
<span
>Hello
Tomasz!
<span
>
<span
>Thank you
very much for your response.
<span
>
<span
>As a
software engineer (yes, you are right), I would like to ask for three more enhancements.
I’m not sure whether they are valuable for the majority of AmiBroker customers –
long-term stock investors, but they would be definitely beneficial for
short-term and commodity traders, especially for those using complicated custom
indicators and/or trading systems.
<span
>
<font
size=2 color=navy face=Arial>1)<span
> <span
class=EmailStyle18>It would be nice if the
functions like ref(), valuewhen(), etc. with an argument of type CONST will
accept a NUMBER, so it will be possible to do:
<font
size=2 color=navy face=Arial>N = MIN (a, b);
<font
size=2 color=navy face=Arial>prevOpen = ref (open, N);
<font
size=2 color=navy face=Arial>
<font
size=2 color=navy face=Arial>2)<span
> <span
class=EmailStyle18> For/while loops and IF-THEN-ELSE constructs would be useful
as well. The last would save complicated multi-level IIF constructs.
<font
size=2 color=navy face=Arial>
<font
size=2 color=navy face=Arial>3)<span
> <span
class=EmailStyle18>Functions (AFL file name
where the function is defined), or simple ‘include’ construction can help to
reduce code size and complexity for sophisticated custom indicators and/or
trading systems.
<span
>
<span
>
<span
>As for my
47Kb formula, I think about 80% of this code is targeted to workaround the current
limitations of AFL listed in the message #859 (<a
href="">http://www.egroups.com/message/amibroker/859).
It’s my system for trading NYBOT Sugar (I’ve not tested it on other commodities
yet), and the indicators showing graphically the account balance and results of
each trade. BTW, it would be very useful if the automatic analysis tool will
graph the account value and trade results.
<span
>I can send
this code directly to you if you are curious to see how a mad software engineer
can write 47K code in 4-th generation scripting language to implement a trading
system based on 2 simple price formations <span
class=EmailStyle18><span
>J<font size=2
color=navy face=Arial>
<span
>
<span
>Thank you,
<span
>Dima
<span
>
<font size=2 color=black
face=Tahoma>-----Original
Message-----
From: AmiBroker Support
[mailto:support@xxxx]
Sent: Saturday, January 20, 2001
6:05 AM
To: amibroker@xxxxxxxxxxx
Subject: Re: [amibroker] AFL
comments
<span
>
<font size=2 color=black
face="Courier New">Hello Dima,<font size=2 color=black
face="Courier New">
You must be a software developer, Dima! Your requests are so detailed!
I am glad and thankful that you point out all these things.
> I'd like to request a few minor enhancements to AFL interpreter.
>
> 1) The AFL buffers (in Guru Comments, indicator builder, etc.) are
> limited to about 32Kb [AFL code for my trading system is currently
47K].
> Once AFL code is larger, it becomes impossible to edit it in the
window (but
> still possible to load file). It'd be great if you can make this
buffer
> *unlimited*
Wow! 47K formula - that sounds truly interesting. Maybe you will uncover
some secrets
about this one?
As for the limit I can enlarge it easily to 64K but then limitation of
Windows 95/98
comes up:
"Windows 95 implements some window management features in 16 bits.The
use of 16 bits imposes some restrictions on parameters in
functions and messages and places limits on internal storage. In some
cases, Windows 95 provides features that can be used to avoid
these restrictions and limitations. For example, the standard edit control
is limited to somewhat less than 64 kilobytes (K) of
text" - taken from Microsoft Developer Network
There are of course no such limitations on Windows NT/2000 so this is not
an issue for these platforms.
Or... I can switch to so-called "Rich-edit" controls that do not
have such limitation (but are slower...)
>
> 2) Subsequent comments are not recognized, i.e. if I have
> /* comment one */
> /* comment two */
> or
> a = b; // comment one
> /* comment two */
> I get an error message pointing to the leading slash of the
> second comment
This one should be fixed long time ago :-(
> 3) result of Boolean (or any other) operation including an array which
> value is {EMPTY} for particular date is {EMPTY}. I think {EMPTY}
should be
> considered as 0. Example:
> sell = exitLongPosition OR enterShortPosition;
> If my first trade for the time period is Long, sell will have
> {EMPTY} value until my first short trade. 1 in exitLongPosition will
be
> ignored because of {EMPTY} value of enterShortPosition.
I guess you are right (but for boolean operations only). Why not for all
operations?
Simply because {EMPTY} is used to mark that there are no valid data
for given bar. For example moving average value is NOT available for the
first
<range> number of bars. So if you base your other calculations onthe
results
of MA you should not include these invalid data. AFL engine detects {EMPTY}
values and skips them so nested functions/operators work only on valid
data.
Best regards,
Tomasz Janeczko
===============
AmiBroker - the comprehensive share manager.
http://www.amibroker.com
|