[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [amibroker] Re: AFL 101 --resend (sorry if it gets duplicated)



PureBytes Links

Trading Reference Links

Brian,

You seem to be spouting a lot about things you know little about as if  
you were an authority.  Please, a little more humility in such  
matters.  A true general purpose "Matrix" language with true matrix  
operations would be found in the language "APL" (A Programming  
Language) or "J".  Read about this, right down to the operator  
definitions, and you will understand.  BTW, APL was the first "true"  
programming language I learned in 1969 (I don't count a programmable  
calculator I first used at my work).

http://www.sigapl.org/
http://www.jsoftware.com/

Arrays in most languages are simple indexing of data cells like in a  
spreadsheet.  The types of simple operations in a spreadsheet formula  
are easily done with loops in a general purpose language by indexing  
1, 2, or more indexes.  True matrix operations are a completely  
different bag.

AFL arrays are specific implementations for processing time series  
data associated with equities.  They are not general purpose and were  
never intended to be, though it is possible to hijack them for some  
general purpose things (which I do) if you understand the limitations  
--like automatic sizing.

I fully support your general intensions of wanting to see more general  
and special purpose operations in AFL, that make it easier to  
implement a variety of solutions associated with equity evaluation and  
trading.  Tomasz has added these things over time as their value  
becomes clear.  I feel that AFL is one of AmiBroker's most valuable  
competitive advantages in the marketplace.   IMHO, enhancing AFL to  
provide more control of a variety of low and high level functions  
should be a high priority.  And in keeping with current themes,  
finding a way to teach non-programmers how to become AFL programmers  
should be a very high priority.  It seems there is more desire to  
learn AFL than understanding of how to proceed with that education.   
AFL is actually a good language to learn programming for the first  
time.  It hides many low level operation and syntax requirements so  
that the user can concentrate more on the problem rather than the  
process of programming.

There have been books written as an introduction to programming using  
simple languages like BASIC.  Following the general progression of  
such a book, but substituting AFL as the language, is what is perhaps  
missing.

For a non-programmer.  Learning several languages to be able to  
program their systems is too much to ask.  Having all the needed  
elements for even advanced system development contained within an AFL  
"wrapper" is in my opinion a superior approach for the benefit of AB  
users coming up the AFL learning curve.

Best regards,
Dennis


On Mar 24, 2009, at 9:27 AM, brian_z111 wrote:

> Hello Tomasz,
>
> Thanks for your educational post, I thoroughly enjoyed it.
>
> Quirky != bad;
>
> (some people like quirkiness ... like Bob Dylan in his song "Simple  
> Twist of Fate")
>
> Of course I am just giving an opinion from my perspective (personal).
>
> Re your points:
>
> C language - I was just quoting from one of your posts .... I should  
> have given the link because you did include some context
>
> http://finance.groups.yahoo.com/group/amibroker/message/135059
>
>> As for "matrix" operations - that this does not belong to the  
>> >definition of any general purpose language.
>
> I did a little bit of reading on 'languages that have array  
> functions' when we had a short discussion on array programming  
> before and found this link:
>
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)
>
> (it comes from the Wikipedia array page)
>
> http://en.wikipedia.org/wiki/Array
>
> As I said, there is no point in comparing AFL to a GP language ....  
> it is quirky to me that AFL is an array language and doesn't have a  
> full suite of array functions .... perhaps other languages that are  
> intended to handle price arrays etc would be a better comparison.
>
>> Having said that, for anyone needing multiple dimensional arrays in  
>> AFL there are several options:
>
>> a) use VarGet/VarSet (the 2-dim array is simply array of the array,  
>> so for N:M 2-dim array you need N AFL arrays)
>> b) using embedded JScript parts with AFL
>> c) using free open source Osaka plugin (you can extend it to your  
>> needs since all sources are available)
>> d) using any external COM object (written in VB for example if you  
>> need that)
>
> Except for a) none of these meet the criteria of "Native" to the  
> language (AFL)
>
> VarGet/VarSet can hardly be described as a suite of array functions.
>
>
> Neither a, b, c or d achieve your own stated objective:
>
>> SIMPLICITY OF USE plus compactness of code is the paramount design  
>> >decision.
>
>> The database is exposed in two ways:
>> First (more general)
>> full OLE read/write direct access to the database - see Stocks/ 
>> Stock/Quotations/Quotation objects:
>> http://www.amibroker.com/guide/objects.html
>> - and this OLE interface is DIRECTLY available from AFL level.
>
>
> That is very good for developers/instutions and the handful of  
> traders who want to write their own trading program built around AB.
>
> Hardly what the average trader wants to have to do before they can  
> start trading.
>
> Anyway, all of this could be done much easier from within AFL using  
> AFL functions .... there is no need at all to use OLE for this type  
> of thing .... it seems like overkill to me for a simple array  
> processing language.
>
>
>
>> Second (easier)
>> AddToComposite/Foreign - gives you easy to use way to STORE and  
>> >READ from the AmiBroker database.
>
> ATC is time dependent ... when timeframe compression is used it  
> starts to become quirky and that is just the beginning.
>
> Once again hardly a substitute for a full suite of native database  
> functions.
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx>  
> wrote:
>>
>> Hello,
>>
>> There are several misconceptions in what was written here.
>> AFL is specifically designed to protect the newbie and people  
>> without coding experience
>> from programming stuff like memory allocation/deallocation, pointer  
>> manipulation,
>> declarations, type casting, etc.
>>
>> So although it looks like C it is way more easy than C.
>>
>> What is single operator in AFL (like array addition) involves many  
>> line of code in C
>> plus memory allocation/deallocation (and keeping track on all that).
>>
>> SIMPLICITY OF USE plus compactness of code is the paramount design  
>> decision.
>> That's why arrays in AFL are automatically managed, have size that  
>> automatically
>> refers to "visible" area, so you can simply add arrays with single  
>> + operator.
>>
>> With general purpose C language with "normal" arrays you would need  
>> to manage memory for arrays by yourself,
>> alignment (if size differs which elements to add), looping (you  
>> need to perform calculations
>> on individual elements of array).
>> (maybe you don't know but in C and there are no built-in dynamic  
>> arrays, only fixed compile-time size is supported,
>> and dynamic array is implemented via pointers and explicit memory  
>> allocation malloc/free)
>>
>> As for "matrix" operations - that this does not belong to the  
>> definition of any general purpose language.
>>
>> There are no "matrix" operations in any popular general purpose  
>> language C/C++/Java/JScript/Basic/Pascal.
>>
>> In C/C++ even scalar trigonometric operations like sin( x) or  
>> string concatenation are NOT part of the language.
>>
>> The language itself defines:
>> a) syntax
>> b) basic arithmetic operators + precedence working on primitive  
>> types only (scalar integer and/or float)
>> c) flow control (conditional execution, loops)
>> d) structural concepts (variables/functions/procedures/structures/ 
>> objects)
>> e) some miscellaneous stuff like run-time type info, exception  
>> handling etc.
>>
>> And that's it.
>>
>> Anything more is supplied by LIBRARIES. In C there is a library for  
>> basic string manipulation (such as concatenation
>> - strcat) or floating point. The same with any high-level stuff  
>> like matrices - this is the area which
>> is implemented by EXTERNAL libraries (not part of the language).
>> Libraries in AFL can be provided by:
>> a) #include - the AFL code implementing features via functions
>> b) AmiBroker Development Kit - allowing to write extensions  
>> (functions) as a DLL in any compiled language.
>> c) JScript/VBScript
>> d) any external COM object http://www.amibroker.com/guide/a_aflcom.html
>>
>> This covers any imaginable application and any imaginable need you  
>> may have.
>>
>> Having said that, for anyone needing multiple dimensional arrays in  
>> AFL there are several options:
>> a) use VarGet/VarSet (the 2-dim array is simply array of the array,  
>> so for N:M 2-dim array you need N AFL arrays)
>> b) using embedded JScript parts with AFL
>> c) using free open source Osaka plugin (you can extend it to your  
>> needs since all sources are available)
>> d) using any external COM object (written in VB for example if you  
>> need that)
>>
>> If anyone is "advanced enough" to need multiple dimensional arrays,  
>> it is also "advanced enough" to use these options
>> without any trouble.
>>
>>
>> Also with regards to:
>>> - some of the architecture of AB is quirky also e.g. essentially  
>>> it is a database, at the binary level, but you can't write
>>> directly to the native database
>> That is entirely not true.
>> The database is exposed in two ways:
>> First (more general)
>> full OLE read/write direct access to the database - see Stocks/ 
>> Stock/Quotations/Quotation objects:
>> http://www.amibroker.com/guide/objects.html
>> - and this OLE interface is DIRECTLY available from AFL level.
>>
>> Second (easier)
>> AddToComposite/Foreign - gives you easy to use way to STORE and  
>> READ from the AmiBroker database.
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "brian_z111" <brian_z111@xxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Tuesday, March 24, 2009 1:46 AM
>> Subject: [amibroker] Re: AFL 101
>>
>>
>>> My perspective as a newcomer to programming when I started into AB/ 
>>> AFL around 2-3 years ago:
>>>
>>> - Tomasz says that AB is most like C
>>> - primarily one has to learn AFL fullstop
>>> - experienced programmers sometimes have to unlearn somethings and  
>>> find this hard to do for a while
>>> - in some ways programming naivity paid off for me as I am at home  
>>> with array programming
>>> - in other places I am lost because nothing can fill the missing  
>>> link of not being familiar with syntax that is common to other
>>> languages (called experience)
>>> - AFL is quirky ..... some things that intuitively and logically  
>>> seem needed are 'missing' and then you have to work around that
>>> e.g. IMO it is bizarre that AFL has been around for many years but  
>>> doesn't have dynamic arrays or matrix functions ... the quirky
>>> aspects of AFL make it extremely difficult for lay people ...  
>>> every time you get on a roll you find an exception
>>> - some of the architecture of AB is quirky also e.g. essentially  
>>> it is a database, at the binary level, but you can't write
>>> directly to the native database
>>> - to save you future distress....many in the past have asked for  
>>> an AFL book...the logic seems compelling to me
>>> - everyone starts from a different place so some need an 'Intro to  
>>> AB', book
>>> - I like Howards contributions overall but IMO it is rather old  
>>> world to publish in hard copy ... an ebook would be much better
>>> ... we have to consider that AB/AFL is way beyond the 500 pages  
>>> allocated to it ib Howard's 2 books.
>>> - the AFL library is not the place to learn code ... good for  
>>> sharing code between experienced AFL'ers
>>> - this forum is a book and contains at least 1000* the code, help,  
>>> code and trading tips available anywhere else .....
>>> unfortunately it lacks sections, an index and topics etc .... once  
>>> again the logic for a better forum (from an educational
>>> perspective) seems compelling.
>>>
>>> (Sorry Rik but Google searching Yahoo doesn't reference threads  
>>> does it?)
>>>
>>> - AB/AFL is huge ... I don't think any layperson will ever cover  
>>> it all without a big effort to become a programming expert,
>>> albeit one who specialises in AFL
>>>
>>> - AB is not a democracy or an open project
>>>
>>> BTW all of the advice given in this thread so far is spot on.
>>>
>>>
>>>
>>>
>>>
>>> --- In amibroker@xxxxxxxxxxxxxxx, "louies88" <Louies88@> wrote:
>>>>
>>>> I think Amibroker is great, especially its AFL. Although I don't  
>>>> know enough about it to claim that it's superior than most other
>>>> scripting languages out there, I know for a fact that this is one  
>>>> of the best. That also begs the question of how a person w/
>>>> virtually no programming background can get started w/ AFL. I  
>>>> followed this forum long enough to note that some of you in here
>>>> are excellent coders. The codes that I often see are flawless and  
>>>> eloquent, which then makes me think how long does it take a
>>>> coding newbie such as myself to attain that coding level.
>>>>
>>>> I look at it this way. Coding a computer language is pretty  
>>>> similar to learning a foreign language. I remember how my first
>>>> English class went. I started out by learning a few basic  
>>>> vocabulary words, then use some of it in the form of a noun, then a
>>>> verb, finally an object. Sentence structures, or in computer  
>>>> language better known as syntax, govern if a sentence is
>>>> grammatically correct or if it's not. With that in mind, I also  
>>>> started out by looking at the AFL Library in Amibroker. I
>>>> downloaded all of the functions in the hope of building myself an  
>>>> Amibroker vocabulary and started to put some of the basic
>>>> vocabulary words together to make a "sentence."
>>>>
>>>> However, since there isn't any kind of document FORMALLY teaching  
>>>> the ABC of coding in Amibroker, I'm left w/ a question how does
>>>> Amibroker syntax work? Some of the experienced coders here often  
>>>> compare AFL syntax to that of C++. But for a person w/ neither
>>>> background in AFL or C++ or any other computer langugae, the  
>>>> question remains: How do I get start? Where's the square one?
>>>>
>>>> Anybody w/ such experience is highly appreciated if he/she's  
>>>> willing to shed a light on this.
>>>>
>>>>
>>>> Thanks
>>>>
>>>


------------------------------------

**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.

TO GET TECHNICAL SUPPORT send an e-mail directly to 
SUPPORT {at} amibroker.com

TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)

For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/amibroker/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/amibroker/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:amibroker-digest@xxxxxxxxxxxxxxx 
    mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx

<*> To unsubscribe from this group, send an email to:
    amibroker-unsubscribe@xxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/