They don't work because they are incorrect.
But all this is too much burden when there is very convenient
'easy shortcut to AFL function reference" available:
Use "easy" shortcuts f?<AFLFUNCTION HERE>
or
Best regards, Tomasz Janeczko amibroker.com
----- Original Message -----
Sent: Tuesday, September 02, 2008 2:09
PM
Subject: Re: [amibroker] Re: AmiBroker
AFL Glossary project
Tomasz,
I see that my links to the AmiBroker online pages did not work. I
am not sure what the problem is, but that should be resolved before trying to
specify them. What would be the best approach to referencing back to
useful AmiBroker documentation pages from a Glossary in the UKB?
Best regards,
Dennis
On Sep 1, 2008, at 11:30 PM, Dennis Brown wrote:
Keith
you are inspiring my thinking,
I am going to formally propose a two pronged approach to move forward
from here.
1. We create a simple text only template to gather information
initially for the glossary project -- more than one person can work in
parallel gathering data.
2. We write a simple AFL program that reads in this text
file, and generates an output text file in whatever format we want.
As ridiculous at it sounded when I first wrote it, I am not
so sure it is a bad idea anymore. We all have AB running on our
machines and we all know (or are learning) how to make AFL programs.
So even though a VB or JS or C++ or EMACS or whatever language might be the
best choice for one of us, AFL is a common denominator. And it will
make a great example too of using it for something useful other than
trading.
T he output file could be just like what you generated or it could an
HTML file complete with links inserted that could sit in the UKB.
This approach would keep us from having to define and fiddle with
formatting issues on a finished document that could slow us down or limit
the ultimate uses of the data. Instead we could concentrate
on gathering the data as one phase and formatting the output in another
phase. The two phases can be independent and actually proceed in
parallel. The skills needed are different for each. We could
even have two different AFL programs. One to generate text documents
and another for HTML docs. It takes a different skill set to know how
to generate HTML vs just a text document. We can use parameters to
define the formatting we want. Also anyone would be free to write any
other formatting program in any other language they want to generate other
outputs.
New data can be added at any time without messing with formats later,
because it is auto generated from the raw data. Since formatting is
not an issue we could take a integrated or distributed approach to the
initial data phase. People can take a section and work on it as
a separate text doc and merge them later, or we could use a
collaborative doc editing setup on the web. Either way or both way
would work to start with. The collaborative way might be better for
the long term, but I am no expert on these setups --I usually work alone at
home on local data.
Suggested template filled out for abs and CCIa examples:
Notes: a n t for data type, 'for text of arg (see
examples),
unused
fields can be deleted without harm, only Entry: is required.
Entry: abs()
Retur ns: a n
Args: a n
UKBLink:
VideoLink:
Name: Absolute value
Use: Returns absolute value of a number or array
ABVer:
1.0
Hierarchy:
Functions, Math
Tags: absolute, sign, positive
Related:
sign()
Entry: CCIa()
Returns: a
Args: a, n 'period=14
UKBLink:
VideoLink:
Name: ;Commodity Channel Index
Use: Returns Commodity Channel Index of an array
ABVer:
4.2
Hierarchy:
Functions, Indicators
Tags: CCI,
Woodie, overbought, oversold
Related:
CCI()
Comments?
Best regards,
Dennis
On Sep 1, 2008, at 6:14 PM, Dennis Brown wrote:
Keith,
Thanks, Nice work. &nb
sp;You put some good thought into this.
I like the way you added the
full calling form and array vs number and I suppose a t for text
results.
An extract of a couple of
simple ones from your doc for everyone to see:
The 'a' and 'n' at the
beginning of each function below indicates that the function returns an
'array' or a 'number' respectively. Some functions return neither,
while some can return either.
AB -- AmiBroker
Search:
amibroker.com, TJ, Tomasz Janeczko
a n abs(a|n) -- absolute value.
Search: math,
sign
I could see this also as a good *generated* output format from the
basic data set. Could we have our cake and eat it too? Meaning
have an input format that captures potentially more information, and
automatically generate this or similar documents that can be downloaded or
uploaded to the UKB.
Comments?
BR,
Dennis
On Sep 1, 2008, at 5:23 PM, Keith McCombs wrote:
Dennis and others -- I've
started a very simple version of a glossary, just plain text and no
columns or links. As simple is it is, I believe that it satisfies
the primary need -- helping the user find what to look for in the
already existing documentation.
If I include it in this
Yahoogroups form, it gets all reformatted and is difficult to
read. Therefore, I've uploaded it to: http://finance.groups.yahoo.com/group/amibroker/files/
Look for: "Preliminary AB Glossary km080901-1.doc"
BTW, I tried
to put it in Googledocs in both .odt and .doc formats, bu t Googledocs
wouldn't include the leading spaces in sentences. And I'm not very
good at using 'cryptic' indentation techniques. If we were to do
shared documents on Googledocs, would I have to learn the 'cryptic'
secrets?
-- Keith
Dennis Brown wrote:
Keith,
Great! I can't wait to see what you come up with. 20
sounds like a lot to tackle first round though.
I have been trying to think about what KIND of information (not
th e actual format) would be useful to include also. We don't
have to have everything first pass.
I was just making a list here. It still feels like I am
groping in the dark, but a little light at the end of the
tunnel.
Glossary Entry: "Only one entry per form"
Doc Link: Link to the best AB doc place to
learn about this entry --by clicking on the entry
UKB Link:
Optional link to a UKB page --could be a substitute
manual
Other Link:
Optional link to another doc page --could be a tutorial
video
Description: "Short descr iption of the
entry"
AFL version:
First AB version number to support this
Hierarchy:
"TopLevel", "Level2",... "LastLevel" --used for creating a
sorted list and as search terms
Search Tags: "SearchTerm1", "SearchTermN"
Related Entries: "Glossary Entry1", "Glossary EntryN"
--the see also kind of thing
~Dennis
On Sep 1, 2008, at 2:41 PM, Keith McCombs wrote:
Dennis -- I'm still
here. I've been working on a sample. Very sim ple, plain
text, no columns, or tags. I'm trying to supply only enough
information so someone can get an idea of what to look for in
the documentation. Presently, I am avoiding making any
specific reference to section or page in the manual or anywhere else
(too much work and would change with every major AB
revision.
I should be posting to the group with the first
twenty or so entries, this afternoon, US EDT.
I don't expect
the format that I am using will be the final one --- its just a
starting point.
Thanks for your support and comments, past,
present, and future. -- Keith
Dennis Brown wrote:
Keith,
You still with us?
I figured you would have a few things to say about the
formatting issues (unless you are away right now).
I consider you a critical partner in making this happen since
it was primarily your proposal that got it moving.
The startup is a bit messy until we get our feet planted
firmly on the ground.
What do you think about the idea of a spreadsheet as the ini
tial form to hold the raw data during the creation phase?
We can kick things around in text on the list, then add to
the spreadsheet doc as we go.
Answer on list if appropriate for all.
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 Br own 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 chunk s.
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 assembl e 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
y ears 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 >> j ust 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 - prep rocessor 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 (A FL
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@xxx
oogroups.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
cou ld 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 lis t 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 symb ol. 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 helpfu l "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 i t 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 ar e 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 stil l 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 severa
l 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 AmiBr oker ... >>>> >>>> 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 qu ick 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 be cause 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 wit h 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 w ell 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 lik
e >>>> >
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 bewildermen t 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. >>>> >< br> >>>>
> 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 a re 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
__,_._,___
|