|
Hello,
As long as it gets published in UKB at some (final)
stage, I am OK with that project.
Best regards,
Tomasz
Janeczko
amibroker.com
----- Original Message -----
Sent: Saturday, August 30, 2008 10:23
PM
Subject: Re: [amibroker] AmiBroker AFL
Glossary project
Tom,
I don't think I quite have the full understanding of your vision. I
believe Tomasz would need to support the idea (at least not object to it)
because of the amount of proprietary material that would have to be
referenced. I think it should be discussed in its own thread. I
could support it personally if it fills a need and does not fracture the
community.
I am not considering the AFL Glossary project which was not just my idea
to be an end in itself. I also do not see it being that large of a
project if many hands help out a little. Its primary value (other than a
handy listing all the language terms --which is a small task) is to be a
repository for search terms associated with an entry. This was primarily
Keith's idea, but it fit well with my previous idea of how to search for
something when you do not know what its called.
So the direct outcome of this will be a bunch of search terms that a lot
of people have helped create.
The next step is to integrate the data as an index to get to more
information. This step could be taken by a UKB entry, TJ using it in
some way, or another project integrating it. That has not been defined
yet and I think it should not have to be defined yet.
Contrary to some opinions, it does not take extraordinary efforts of just
a couple of people to help with this. It is better served by being open
and in your face. That is because, I don't know what you would have
thought to call something when looking to solve a problem. It will be
the new users who might offer some valuable additions to this project.
By being open, you and everyone else stands to gain by participating in
this project. One way you can help, is to look at it from the point of
how it would be used later on. That could help guide some of the
formatting and details of information that we use.
Best regards,
Dennis
Please see my post about the help manual.
I suggested a membership site that contained a manual. Now I am
thinking that the site could be an AmiBroker Help site. It could contain an
AFL Glossary, an AmiBroker manual, maybe a help forum, and other items to
help AmiBroker users.
Instead of working in individual groups, you could join as one
group to produce the site and at least get some compensation for your
efforts.
Tom
----- Original Message -----
Sent: Saturday, August 30, 2008 10:01
AM
Subject: Re: [amibroker] AmiBroker
AFL Glossary project
Keith,
Here is what I would suggest. We only work on the first 10
items collaboratively on-line here to start. We need to
get good exposure for this initially to get lots of good ideas from the
list.
I will be happy to keep a text file of all the changes and upload it
to the files section if needed and attach it to the post at each logical
round of changes. Of course anyone can attach a text file to the
email version of this post which I and anyone who uses the email option
will get.
Lets leave the formatting out until we get a round of feedback on
that. The first 10 should stimulate ideas for how we should format
the entries to make them most useful.
Some initial discussion will help solidify the overall specs of the
final format.
Tuzo and Mike,
You suggested using Google docs to make a collaborative effort
more efficient. I like the idea if this was an independent
project with a dedicated team. However, there are some things beyond
just the end result to accomplish here.
1. I would like to have this collaborative effort done in full
view of the community and the watchful eye of Tomasz. This is
somewhat of an experiment and it can serve as a model to inspire future
community wide collaboration on other projects with a wide benefit.
If there is awkwardness, let's see if we can work around it, or
demonstrate a need for additional ways for the community to interact
productively. Of course it would work better in a PHP Forum environment,
but lets work with what we have now.
2. Suggestions should come from anyone. Even if they only
want to participate for just a single entry on the whole project.
Having too much hidden away (out of site, out of mind) would deprive
the project of good input.
3. EVERYONE will benefit from seeing each and every AFL or
general AmiBroker term defined in front of them again. Think of it
as an opportunity for new and old to review all the things available and
what they are good for.
I am not the worlds greatest organizer, and I may have a tendency to
have my eye on the moon while seeing how high I can jump. I you
think I am wrong about this approach (I acknowledge it is a bit
awkward) speak up and let's find a better way. :)
Best regards,
Dennis
On Aug 30, 2008, at 12:07 AM, Keith McCombs wrote:
Sounds good to me.
However, is there somewhere we could have a document that we
could all collaborate on without the text getting all garbled up by
Yahoogroups, adding carriage returns, line feeds, and >? I
believe there is some way to do this -- just don't know what that way
is.Dennis Brown wrote:
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
>>>> >>>
>>>>
>>
>>>> >>
>>>>
>>
>>>> >>
__._,_.___
Please note that this group is for discussion between users only.
To get 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
![]()
__,_._,___
|