Deleting Tickers and Composites

Creating composites is a lot of fun and can provide useful information about market and sector movements. However, when creating many composites, you will sooner or later find that your database is bloated with obsolete composites. The first requirement is to create a function to delete composites. Dingo kindly provided the following example code, which will be used to provide a variety of other useful functions. Note that the functions below can be used to delete both tickers and composites; the procedure is the same. The formula is designed to be run as an indicator but can be adapted to run in a scan, etc.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

3 Responses to “Deleting Tickers and Composites”

  1. January 6th, 2008 | 2:09 pm

    These are very useful examples to have. Kudos to dingo and Herman for posting them!

    IMO, some of this is working-around yet-to-be implemented features of the AB UI.

    In particular, I’d suggest that it would be very helpful if we could right-click on any symbol or composite and either

    a) copy it’s name (to be pasted into code such as the lists used above), or
    b) delete it from the database directly (why jump thru hoops?)

  2. Herman
    January 6th, 2008 | 2:36 pm

    Thanks for the feedback Progster. The functions in this post allow non-OLE programmers to add them to an Include file and call them without leaving the familiar AFL environment. Eventually we will be able to set a default Include file that will automatically add many such functions to the AmiBroker list of AFL functions. Perhaps, but this might be wishful thinking, the AmiBroker Help could be extended to include custom-Help for custom functions found in the default include file.

    AmiBroker’s design philosophy is that functions that can easily be implemented in OLE will not be implemented in AFL. In this context the above functions may not be temporary “work-arounds”.

    “Jumping through hoops” is a common practice when you design real-time automated trading systems. In real-time trading you may create/delete 100s, or even 1000s, of composites during the day that would be impossible to delete manually. Remember that at this point in time Composites are the only way to implement Static Arrays.

  3. January 6th, 2008 | 3:19 pm

    Thanks for your additional comments – very insightful! Certainly I’m all for programmatic access, and I realize that there are scenarios where manual deletion would be highly burdensome. I suppose what I meant is that there are some scenarios where a little bit of easily applied manual deletion would be ideal, and I’d like to see the UI (rather than AFL) support these to make day-to-day life as simple as possible.

    I think the goal of a big-honkin’ default include file(s) is a good one. This is exactly the sort of thing AB seems very well-designed to accommodate.

    The kind of approach to docs taken by Doxygen and other similar packages seems like it could be adopted to achieve the “included Help” that you mention (if TJ thinks enough of the idea to help it along). The Help system could parse designated include file(s) for specially formatted comments and incorporate them into the Help index and Help presentation. I think that would be very useful as part of the open-ended expansion of AB into the future.