|
PureBytes Links
Trading Reference Links
|
<font size=2 color="#993366"
face=Arial>Hello Tomasz,
<font size=2 color="#993366"
face=Arial>
<font size=2 color="#993366"
face=Arial>I was really amazed by AFL speed. Now I understand the reason – thank you.
<font size=2 color="#993366"
face=Arial>
<font size=2 color="#993366"
face=Arial>As for my suggestion #1, just in case I was not clear enough, I meanthe
CONST argument can be NUMBER (not a VECTOR). Probably the better example would
be
<font size=2 color="#993366"
face=Arial>N = -1;
<font size=2 color="#993366"
face=Arial>prevClose = ref (close, N);
<font size=2 color="#993366"
face=Arial>Anyway, this limitation can be workaround (at least in my case), so I do
not thing it is worth any significant effort…
<font size=2 color="#993366"
face=Arial>Regarding the #1 of my prev. message, I think 64K will be enough, especially
after external functions are implemented.
<font size=2 color="#993366"
face=Arial>
<font size=2 color="#993366"
face=Arial>Thank you for listening, and the great level of support which you’ll rarely
find for multi-thousand-dollar tools,
<font size=2 color="#993366"
face=Arial>Dima.
<font size=2 color="#993366"
face=Arial>
<font size=2 color=black
face=Tahoma>-----Original
Message-----
From: Tomasz Janeczko
[mailto:tj@xxxx]
Sent: Sunday, January 21, 2001
5:23 AM
To: amibroker@xxxxxxxxxxx
Subject: Re: [amibroker] AFL
comments
<span
>
<font size=2 color=black
face=Tahoma>Hello
Dima,
<font size=3 color=black
face="Times New Roman"> <font
color=black>
<font size=2 color=black
face=Tahoma>Thank
you for your e-mail. I think that the best news for you is that soon
AmiBroker will support charting/analysis plug-ins (in the form of DLLs)<font
color=black>
<font size=2 color=black
face=Tahoma>that
will enable writing systems/indicators in any programming language. <font
color=black>
<font size=3 color=black
face="Times New Roman"> <font
color=black>
<font size=2 color=black
face=Tahoma>As
for suggestions #1 and #2 - implementing such things is not so easy in AFL
because AFL is vector-based language. This means<font
color=black>
<font size=2 color=black
face=Tahoma>that
when you write " something = close * volume" the engine performs
vector multiplication at once (this is the reason why<font
color=black>
<font size=2 color=black
face=Tahoma>AFL
is 10 or more times faster than other formula languages found in other stock
analysis software).... BUT I will think about it :-)<font
color=black>
<font size=3 color=black
face="Times New Roman"> <font
color=black>
<font size=2 color=black
face=Tahoma>Point
#3 - yes, external functions would be nice :-) <font
color=black>
<font size=3 color=black
face="Times New Roman"> <font
color=black>
<font size=2 color=black
face="Times New Roman">Best regards,
Tomasz Janeczko
===============
AmiBroker - the comprehensive share manager.
<a
href="">http://www.amibroker.com<font
color=black>
<font size=2 color=black
face="arial ce">----- Original Message ----- <font size=2
color=black face="arial ce">
<font size=2 color=black
face="arial ce">
From:<font size=2 color=black
face="arial ce"> Dima
Rasnitsyn
<font size=2 color=black
face="arial ce">To:<font size=2 color=black
face="arial ce"> <a href=""
title="amibroker@xxxxxxxxxxx">amibroker@xxxxxxxxxxx <font
size=2 color=black face="arial ce">
<font size=2 color=black
face="arial ce">Sent:<font size=2 color=black
face="arial ce"> Sunday, January 21, 2001 4:56 AM<font size=2
color=black face="arial ce">
<font size=2 color=black
face="arial ce">Subject:<font size=2
color=black face="arial ce"> RE: [amibroker] AFL comments<font size=2
color=black face="arial ce">
<font size=3 color=black
face="Times New Roman"> <font
color=black>
<span
class=EmailStyle19>Hello Tomasz!
<span
class=EmailStyle19>
<span
class=EmailStyle19>Thank you very much for
your response.
<span
class=EmailStyle19>
<span
class=EmailStyle19>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
class=EmailStyle19>
<span
class=EmailStyle19>1)<font size=1
face="Times New Roman">
<font
size=2 color=navy face=Arial>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:
<span
class=EmailStyle19>N = MIN (a, b);
<span
class=EmailStyle19>prevOpen = ref (open,N);
<span
class=EmailStyle19>
<span
class=EmailStyle19>2)<font size=1
face="Times New Roman">
<font
size=2 color=navy face=Arial> For/while
loops and IF-THEN-ELSE constructs would be useful as well. The last would save
complicated multi-level IIF constructs.
<span
class=EmailStyle19>
<span
class=EmailStyle19>3)<font size=1
face="Times New Roman">
<font
size=2 color=navy face=Arial>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
class=EmailStyle19>
<span
class=EmailStyle19>
<span
class=EmailStyle19>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
class=EmailStyle19>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=EmailStyle19><span
>J<font size=2
color=navy face=Arial>
<span
class=EmailStyle19>
<span
class=EmailStyle19>Thank you,
<span
class=EmailStyle19>Dima
<span
class=EmailStyle19>
<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
<font size=3
color=black face="Times New Roman"> <font
color=black>
<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<font
color=black>
<font size=3 color=black
face="Times New Roman"><br
>
|