|
PureBytes Links
Trading Reference Links
|
Brian,
My apologies for being brusk. I was in an frustrated mood this morning.
I hope you found the other information useful.
Best regards,
Dennis
On Mar 24, 2009, at 6:01 PM, brian_z111 wrote:
>> You seem to be spouting a lot about things you know little about as
>> >if
>> you were an authority.
>
>
> I don't appreciate being spoken to like that.
>
> I understand perfectly well thanks but if you want to 'play the man'
> to win the day?
>
>> Please, a little more humility in such
>> matters.
>
> I don't find any use for false humility.
>
> If I go away and get a masters degree in IT and learn several
> languages will I be allowed to have an opinion then?
>
> I don't think you read my posts carefully.
>
> BTW Tomasz ..... it doesn't follow that because I am discussing
> something in the forum that I am campaining for a feature i.e. that
> I want something .... I may just enjoying some discussion or sharing
> a point of view with others.
>
>
> I don't find VarSet compact and the easiest possible way or == a
> suite of array functions but I might be wrong!
>
> I don't find that it is explained fully in the manual either ...
> which is when it becomes quirky ... but I might be wrong on that
> point too!
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>>
>> 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@>
>>> 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@>
>>>> 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
>
>
>
------------------------------------
**** 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/
|