I have moved this thread to its own topic so that it will not get
mixed up with the other thread going forward. I have added three
replies at the top level here ~Dennis
Peter,
I believe it
should ultimately end up as part of the official docs.
However, creating
a separate one to start with and getting the bugs
worked out of it would
help everyone now. If it is a successful and
useful document, then I am
sure Tomasz will take note and figure out
how to incorporate its
usefulness into the AB docs.
Identifying a need that does not require
the brightest brains in the
AFL world to contribute to it is a
liberating experience. Instead of
begging for someone else to solve it,
ordinary and extraordinary users
alike can make it happen in bite sized
chunks.
I think the way to approach this is for one lead person to
take a
small section, say the first 10 items in alphabetical order from
the
functions list and take a stab at filling them out completely and
post
them here for comments. Then perhaps a few volunteers could follow
the lead and each take the next few in sequence. And do the same
thing. This way there could be parallel efforts and feedback in an
open way that would encourage more participation from anyone who
thinks they could do the same thing to a small set. It would not take
too long to assemble a good size Glossary that way --one section at a
time.
BR,
Dennis
On Aug 29, 2008, at 10:37 PM,
peterjldyke wrote:
> Hi,
> Would it be feasible to work on
the existing manual without re-
> writing another document? The
headings and information, as they
> stand are already there, set out
years ago by TJ and others. What is
> lacking is a keyword search in
newbie plain english. Maybe a start
> could be made on the Function
headings.
> Peter
>
>
Mike,
Thanks. Yes that
is what I meant by extracting everything from the
docs. Those are the
basics, but it does take a bit more detective
work to make sure nothing
is missed. But if a complete list is not
easily available, then we will
just have to compile it the best we can
and fill in the blanks later.
There are a number of single character
tokens used in different
contexts, like in a text field.
BR,
Dennis
On Aug 29, 2008,
at 6:19 PM, Mike wrote:
>> It would sure help to get started if
Tomasz or someone else has a
>> current text list of all keywords
and tokens that AFL recognizes
>> to get started with -- that way
nothing would be missed and it is
>> just adding info to each
one.
>
> The existing documentation offers this.
>
>
http://www.amibroker.com/guide/a_language.html
>
http://www.amibroker.com/guide/a_keywords.html
>
http://www.amibroker.com/guide/afl/afl_index.php?m=1
>
>
Mike
Keith,
You did such a good job explaining your proposal,
would you like to
take the first 10 to get us started?
The functions
list is easy in some respects because it is already half
way there. But
the one line definitions would likely want to be a bit
more descriptive
about its intended use. Search words might also
include a category or
two so the list could return functional groups.
The search words might
be the largest part of the entry.
I would be happy to assemble the
whole list off line and keep it
updated as we work through the total and
publish it in an acceptable
form, and try to keep the momentum going
--unless someone else wants
that role.
I can think of some other
projects that could be handled the same way
that would be of general
help to all if this effort is successful.
Test group:
#include
- preprocessor include command (AFL 2.2)
#include_once - preprocessor
include (once) command (AFL 2.70)
#pragma - sets AFL pre-processor option
(AFL 2.4)
abs - absolute value
AccDist -
accumulation/distribution
acos - arccosine function
AddColumn -
add numeric exploration column (AFL 1.8)
AddTextColumn - add text
exploration column (AFL 1.8)
AddToComposite - add value to composite
ticker (AFL 2.0)
ADLine - advance/decline line (AFL 1.2)
Best
regards,
Dennis
Begin forwarded message:
> From: Dennis
Brown <see3d@xxxxxxxxcom>
> Date: August 29, 2008
6:02:30 PM EDT
> To: amibroker@xxxxxxxxxps.com
> Subject: Re:
[amibroker] Re: The best way to help newbies,
> oldies, ... and
AmiBroker ...
> Reply-To: amibroker@xxxxxxxxxps.com
>
>
Keith,
>
> Thanks for rescuing my post from the oblivion of the
chaos that came
> after it.
>
> I like your more detailed
suggestion and yes we are talking about
> the same thing. From a
practical point, this is not something that
> one person should have
to take on by themselves -- it could be
> overwhelming. This is
perfect for a collaborative effort initially,
> but would require a
Wiki sort of thing to do that in the broadest
> sense. Once it is all
pieced together, it would not be too hard to
> maintain in the UKB or
in another way. Perhaps a text file could be
> uploaded with the
partial document and "checked out" to be worked
> on. Eventually it
would be complete enough to post as a good
> resource, but of course
would have to be updated regularly as AFL
> evolves.
>
>
I think my extension to this is that I would like to see the entries
> link to the place in the documentation tha t defines them, or
> perhaps an auto search for references in the docs. Not clear to me
> yet what would be the most helpful if they are not integrated into
> the official docs.
>
> It would sure help to get
started if Tomasz or someone else has a
> current text list of all
keywords and tokens that AFL recognizes to
> get started with -- that
way nothing would be missed and it is just
> adding info to each
one.
>
> Otherwise, like you said, the first job to piece them
together from
> the various places in the docs.
>
> Any
other ideas about how to make this a reality without killing one
>
person?
>
> Best regards,
> Dennis
>
> On Aug
29, 2008, at 4:34 PM, Keith McCombs wrote:
>
>> Dennis
--
>> Your comments below reminded me of something I've always
wanted for
>> AFL. You called it an "AFL to English Dictionary",
while I was
>> thinking "Glossary". But, I believe, we may be
looking for the
>> same thing.
>>
>> Many times
I knew what I wanted but couldn't find it in the help
>>
documentation just because I didn't know what AB called it. For
>>
example, when I first wanted to plot multiple or different or other
>> equities, all on the same chart, I was pretty sure that it
could be
>> done but had a hard time figuring out how. It was
quite a while
>> ago, so I'm not sure exactly how I tried to solve
the problem. But
>> I probably opened up Help and did a Search for
'multiple',
>> 'different', 'other', or 'many'. Somehow,
eventually, I discovered
>> the 'foreign' function, which, by the
way, took me longer than to
>> write and debug my final
code.
>>
>> Had there been an "AFL to English Dictionary"
or 'Glossary' with an
>> entry like,
>> "foreign( ) --
refers to symbols other primary symbol. Search -
>> different,
many, multiple, other."
>> it would have been of great help at the
time.
>>
>> Another hard one, at least for me, to come up
with on my own,
>> "AddToComposite() -- used to create
composite indicators.
>> Search - different, index, indicator,
many, multiple, other.
>> and
>> "ATC -- abbreviation for
AddToComposite."
>>
>> Note: Making such a glossary
should not be very difficult. It
>> would consist of:
>>
1. Make a list of all the keywords, functions, and other useful
>>
terms in AFL.
>> 2. Add very brief description for each. Best done
by users with
>> 'intermediate' experience.
>> 3. Add
Search words. Best done dynamically by newer users,
>> especially
those who had difficulty finding the particular keyword
>> or
function.
>>
>> This could be a very useful addition to
the UKB.
>>
>> Oh yes,
>> "Users Knowledge Base
-- very helpful "how to" articles by
>> users. http://www.amibroker.org/userkb/glossary
>>
Search - user, more, help, tutorial.
>> and
>> "UKB --
abbreviation for Users Knowledge Base."
>> and
>> "AFL --
abbreviation for AmiBroker Formula Language."
>>
>> BTW,
given such a 'Glossary' or 'AFL to English Dictionary', I see
>>
no need for an "English to AFL Dictionary". Just search for the
>>
English word that you think might lead you in the right
direction.
>>
>> --
Keith
>>
>>
>>
>> Dennis Brown
wrote:
>>>
>>> Ron, and other posters to this
thread,
>>>
>>> This is a good example of where some
of the problems in
>>> understandin g come from. AFL is cryptic
and concise. It takes a
>>> good long while to make the
connection between a natural language
>>> _expression_ of the
desired result and the AFL to say the same
>>> thing. I had ask
for an AFL to English dictionary. You and other
>>> posters are
asking for an English to AFL phrase book. I really
>>> like
that idea. There are a large number of one liners that are
>>>
very useful and are great at teaching how things work in AFL. How
>>> many times have I seen a question for "How do I plot a
vertical
>>> line at x?" or "How do I change the background
color by bar to
>>> indicate some indicator condition?". Almost
the kind of thing
>>> that could make up an AFL FAQ section.
This seems like one of the
>>> things the UKB was created to
handle. However, each item is too
>>> small to warrant a wh ole
UKB article in itself. The TOC
>>> structure is not set up for
that IMO. However, having a dozen one
>>> liners about
plotting, etc., in one subject would be very
>>> helpful. Just
the fact that a number of question would be
>>> answered under
one general heading makes it more likely that a new
>>> user
would find the answer to the thing he wanted
quickly.
>>>
>>> I am hearing so many good ideas on
this and similar threads in the
>>> last couple of days from
new and old hands.
>>>
>>> I am a great fan of
"Cheat Sheets". Condensation of all key
>>> points to a subject
on one page. There are many areas of AFL that
>>> could fit
into this model.
>>>
>>> Of course the problem with
the UKB is that each article has to
>>> have an owner who is
responsible to input and update its content.
>>> There are also
some barriers to becoming a UKB author. Not big
>>> ones, but
just big enough to keep busy people from crossing over.
>>>
&n bsp;One suggestion was made to have AB support help out with
>>> that so there would be an easy as email way to make a
contrib
>>> ution for these snippets. Support already has
offered to post
>>> articles for authors, but I think it is
still a barrier to have to
>>> write a "complete" article to
post anything. Adding to an article
>>> that is already
structured with a small think like people post
>>> hers would
not be so daunting.
>>>
>>> I think it is a great
idea to have a topic related AFL phrase
>>> book. Of course it
would also be appropriate for any UKB author
>>> to put up his
hand and say he will sign up to maintain a
>>> particular topic
UKB entry for the phrase book.
>>>
>>> Perhaps if a
few of us could take a topic and get the ball
>>> rolling,
others would join in. The idea is that instead of
>>> writing a
UKB article, you just email a snippet to the responsible
>>>
person to add it to the article.
>>>
>>> This list
itself could be used to vet things first to reduce the
>>>
editing of completed articles. That way someone would not have to
>>> be an expert to maintain one
topic.
>>>
>>> If several people like this basic
idea, the we could expand the
>>> concept and create an outline
for the subjects.
>>>
>>> Should we start organizing
the topics for a phrase book?
>>>
>>> It is one
thing to complain, another to suggest improvements, and
>>>
still another to be willing to contribute to the
suggestions.
>>>
>>> What do people think of this
idea, and contributing to it?
>>>
>>> Best
regards,
>>>
Dennis
>>>
>>>
>>> On Aug 28, 2008, at
3:13 PM, <professor@xxxxxxxxx1.biz> <professor@xxxxxxxxx1.biz
>>> >
wrote:
>>>
>>>>
Ron,
>>>>
>>>> The examples that you used were
perfect. Even I could understand
>>>> how they worked and
learn how to do things that I wanted to do
>>>> but didn't
know how to do it. I spent a lot of time using
>>>>
barssince and ref trying accomplish
this.
>>>>
>>>> Thanks,
>>>>
Tom
>>>> ----- Original Message -----
>>>>
From: Ronald Davis
>>>> To: amibroker@xxx
oogroups.com
>>>> Sent: Thursday, August 28, 2008 11:36
AM
>>>> Subject: Re: [amibroker] Re: The best way to help
newbies,
>>>> oldies, ... and AmiBroker
...
>>>>
>>>> In the very early days of my
Amibroker learning curve, The best
>>>> help that
I
>>>> received was from this board when an experienced user
was kind
>>>> enough to
>>>> quickly code an
example or what I was asking.
>>>>
>>>> Then,
I would play with what they had given me, and I started to
>>>> understand
>>>> how to use
Amibroker.
>>>>
>>>> For example,
REF(c>ref(c,2),5); says that the close that happened
>>>> five days
>>>> ago has to be higher than
the close that happened on the sixth
>>>> day
ago.
>>>>
>>>> Whereas,
SUM(c>ref(c,2),5); only requires that any one or more of
>>>> the
>>>> closes over the last five days
has to be higher than the previous
>>>>
days
>>>> close.
>>>>
>>>> The
above examples of simple english explanations from this board
>>>> are how I
>>>> started l earning
Amibroker. Ron D
>>>>
>>>> ----- Original
Message -----
>>>> From: "Ken Close" <ken45140@xxxxxxcom>
>>>> To: <amibroker@xxxxxxxxxps.com>
>>>> Sent:
Thursday, August 28, 2008 12:15 PM
>>>> Subject: RE:
[amibroker] Re: The best way to help newbies,
>>>> oldies,
... and
>>>> AmiBroker
...
>>>>
>>>> > Amen. Amen!
AMEN!
>>>> >
>>>> > While Tomasz has
done so much to improve and expand the
>>>>
training/manual
>>>> > since the early days (he really
has!), the fact there is
>>>> continual
>>>>
> questions
>>>> > on the same stuff or "small stuff",
suggests there is still
>>>> room for
and
>>>> > benefit from improvement.
>>>>
>
>>>> > I am constantly reminded (or remind myself)
that Tomasz has to
>>>> say "Read
>>>> >
the
>>>> > Manual". Some questions are almost obvious that
a quick trip to
>>>> help
>>>> >
would
>>>> > answer the question, but o ther "simple"
questions are not.
>>>> Many of us do
>>>>
> attempt to find the answers in help but cannot.
>>>>
>
>>>> > For example, yesterday, I wanted to know how
to make
>>>> subscripted arrays.
>>>> >
I
>>>> > did not remember that VarGet and VarSet was set
up to do this.
>>>> So a trip
>>>> >
to
>>>> > Help and typing in "subscripted arrays" found 9
entries none of
>>>> which led
>>>> >
me
>>>> > to VarSet or VarGet. I think one of the
improvements would be a
>>>> search
>>>> >
system which allowed more complex search logic or strings, or
>>>> some way to
>>>> > zero in on the
specific request. As Tomasz says, it is almost
>>>> always
in
>>>> > there, it just is hard to
find.
>>>> >
>>>> >
Ken
>>>> >
>>>> >
>>>>
>
>>>> > -----Original Message-----
>>>>
> From: amibroker@xxxxxxxxxps.com
>>>>
[mailto:amibroker@xxxxxxxxxps.com] On
>>>> >
Behalf
>>>> > Of Dennis Brown
>>>> >
Sent: T hursday, August 28, 2008 11:58 AM
>>>> > To: amibroker@xxxxxxxxxps.com
>>>> >
Subject: Re: [amibroker] Re: The best way to help newbies,
>>>> oldies, ... and
>>>> > AmiBroker
...
>>>> >
>>>> >
Brian,
>>>> >
>>>> > You are correct. I
switched to AB because I wanted a
>>>> programming
language
>>>> > that was fundamentally tied into the
realtime price arrays and
>>>> the
>>>> >
charting
>>>> > for the same. RT quotes --> Database
--> AFL -->
>>>> > Charts. That was all I wanted,
and that is pretty much all I use.
>>>> > There is a lot
of overhead associated with getting and
>>>> maintaining
the
>>>> > data,
>>>> > interacting with
the user, and outputting the the data in a
>>>> useful
form.
>>>> > I
>>>> > only wanted to be
concerned with the algorithms that decided to
>>>> buy
or
>>>> > sell.
>>>> > Interestingly,
even with all the support functions handled by
>>>> AB, I
still
>>>> > spend 80% of my time coding UI things! I
think it is some kin d
>>>> of
>>>> >
computer
>>>> > programming law.
>>>>
>
>>>> > AFL was my real destination with AmiBroker,
and I had a hard
>>>> time because
>>>> >
it
>>>> > was not well defined. A lot of assumptions were
made about prior
>>>> > knowledge
>>>> >
of specific programming language conventions in C like
languages.
>>>> > Languages
>>>> > I had
no experience with. These are middle level languages. My
>>>>
> experience
>>>> > was with machine level assembler
code, and very high level like
>>>> >
Revolution/SuperCard/HyperCard, and a
>>>> >
smattering of BASIC and APL from the original versions 40 years
>>>> ago.
>>>> > I had no idea that I was
supposed to go learn C syntax before I
>>>> could
use
>>>> > the AFL documentation. IMHO this is a
documentation hole big
>>>> enough to
>>>>
> drive a truck through.
>>>> >
>>>>
> Then what happens when someone has no experience with any
>>>> programming
>>>> > language at all.
Perhaps some Excel experience, or maybe
>>>> experience
using
>>>> > a
>>>> > programmable
calculator. I c an't imagine the bewilderment with
>>>> AFL.
It
>>>> > takes a lot of handholding from support or this
list to get
>>>> over the first
>>>> >
hump.
>>>> >
>>>> > I believe it would
be appropriate to define the AFL language in
>>>>
the
>>>> > documentation as if it were the only language
that exists on
>>>> the planet.
>>>>
>
>>>> > For instance "+" is defined as "Addition".
Whereas, in reality
>>>> the "+"
>>>> >
operator is data type dependent. It will add two numbers, add a
>>>> number to
>>>> > every element in an
array, add two arrays element by element, or
>>>> >
concatenate
>>>> > two strings. It will not add a number
or array to a string.
>>>> >
>>>> > As I
have suggested before, I would have liked to see a
>>>>
"Complete"
>>>> > listing of all operators, functions,
reserved words, syntax
>>>> characters,
>>>>
> directives, etc., in one live list index that points to a page
>>>> that
>>>> >
explains
>>>> > each one in the same way that the
functions are now described.
>>>> Then
>>>>
> additional "see also" pointers on those pages to point to more
>>>> in depth
>>>> > documents when
available. In fact the current functions list
>>>> could
simply
>>>> > be expanded to do this.
>>>>
>
>>>> > This would have saved me many weeks off the
learning curve.
>>>> >
>>>> > I don't
know if Howard is planning on doing this in his new
>>>>
book, but it
>>>> > should be part of the on-line
documentation.
>>>> >
>>>> > Best
regards,
>>>> > Dennis
>>>>
>
>>>> >
>>>> > On Aug 28, 2008, at
10:34 AM, brian_z111 wrote:
>>>> >
>>>>
>> I didn't explain myself very well there.
>>>>
>>
>>>> >> What I am saying is that I think we
are making it harder by not
>>>> >> admitting that it
is a programmers program and just getting on
>>>>
with
>>>> >> teaching AFL.
>>>>
>>
>>>> >> If anyone held told me that at the
start I would have run for
>>>> it but
>>>>
>> the fact is that the help manual is about 'AmiBroker the
>>>> program' but
>>>> >> eventually I
came to realise it is all about programming -
>>>> >>
specifically AFL.
>>>> >>
>>>> >>
So, if I do want to get on with it where do I go?
>>>>
>>
>>>> >> The AFL section of the h elp manual is
condensed.
>>>> >> The first few chapters of Howards
Book are a basic intro to AB
>>>> and
the
>>>> >> rest of the book is orientated around
SystemDesign & Evaluation?
>>>>
>>
>>>> >> Where is the next stop on the AFL
line?
>>>> >>
>>>>
>>
>>>> >> brian_z
>>>>
>>
>>>> >>
>>>>
>>
>>>> >>
>>>> >> --- In amibroker@xxxxxxxxxps.com, "brian_z111"
>>>> <brian_z111@...> wrote:
>>>>
>>>
>>>> >>> Herman,
>>>>
>>>
>>>> >>>> I always figured that
sticking with AFL would have provided
>>>> a
more
>>>> >>>> continuous path for users to
develop their programming
>>>>
expertise.
>>>> >>>
>>>> >>>
This is a new point, not really discussed much before, I
think.
>>>> >>>
>>>> >>> I
really don't know how to put it in words but you are so
>>>>
right.
>>>> >>>
>>>> >>>
Tomasz should be proud of me because if I am a programmer at
>>>> all I
>>>> >>
am
>>>> >>> an array programmer...... but
sometimes I am l eft reaching
>>>> for
AFL?
>>>> >>>
>>>> >>>
Perhaps there are co nventions that people with 2 or
more
>>>> >> programming
>>>>
>>> languages automatically understand?
>>>>
>>>
>>>> >>> Do I have to go and learn C++
as well.
>>>> >>>
>>>> >>>
Should I need too?
>>>> >>>
>>>>
>>> brian_z
>>>> >>>
>>>>
>>
>>>> >>
>>>>
>>
>>>>
>>