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
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >>