Associate data with a symbol

Gents, what would be the best way to associate some extra data with a symbol in the AmiBroker UI such that this data is saved and then available to the AFL code?
For some of the products I will be trading the price that is coming from the feed provider is 100 x the IB price, so for these products in the AFL I would have to divide by 100.
I am not sure where I can setup this value on a per product basis.
Thank you!

I think using SWITCH function is one option.

Right, but I don’t want to hardcode the symbols in the AFL. I am looking instead to something similar what the symbol information window offers, where you can specify for example the TickSize, and the value entered there is available in AFL.

@zaxxon have you searched regarding the Symbol Information?

Or in the User’s Guide search for Tick, and then look down for the Symbol menu. The Information Window allows you to display and edit the preferences of the symbol. If you search on Fundamental - and select Using Fundamental data, you can read about importing fundamental data from other sources. Of course if you only have a couple to enter, you can always just do it by hand…

Hope this helps.

Right, but this would be like a new field, and as far as I can see you cannot extend the symbol information window with custom fields.

With tick and point value, you should be able to control how your system works with the data.

I would think it would be like the futures contracts, where you define the tick and point value, then you can determine what each price means for dollars. Sorry, it has been way to long for me to remember when I was trying to work with futures in AB database, but I am sure you can get what you need through these values. Also sure that you can reference them in your AFL directly without issue. Also think you can define and import the values from a .csv file if you have lots to do.

Would suggest looking and searching on Futures contract specifications in the help to see how to deal with it.

Good Luck.

Tick size and point value are already set up correctly for my symbols. The problem is that my data feed provider, Norgate, for a couple of symbols provides prices that are 100 x IB price. Just for a few, for the rest the two prices match. For these few symbols, when placing the order through IB controller, I need to divide the price Norgate provides by 100.
I can hardcode this symbol list in the AFL, but I was hoping that there is a better way, like setting up this value through the AB GUI and getting access to it in the AFL.

Sounds like your best alternative might be to use the AUX1 and/or Aux2 fields and do it in your code. If you default the Aux fields to a value of 1, then you could use what ever factor you need in the few symbols and include the calculation using the Aux field for all your IB orders.

Hope that gets you thinking on the correct path.

Check with Norgate before going down the Aux1/Aux2 path. I think that they already use those fields for other things in some of their data sets. @NorgateData (Richard Dale) could probably offer guidance.

If I understand correctly, the issue is the quoting convention difference between IB and Norgate, while each is self-consistent (thus correct). This is a common issues among different databases or broker platforms. It seems logical to set up a mapping file, in a CSV file for example, that maps a class of symbols and their quoting conventions (presumably futures such as HG) from Norgate to IB and vice versa. You probably need to take care of symbol differences as well. Not every system uses exchange symbol. For example Bloomberg uses “US” and 1-digit expiration year for US Treasury bond futures, whereas IB and many others use the exchange symbol “ZB” and 1 or 2 digit year. You can use this file/table as an exception table – i.e. if a symbol is not in the table, then the systems can pass them through unchanged.

Hacking the database isn’t a robust solution, as pointed by Matt – even if the fields Aux1/Aux2 is not currently used, it may be used in the future.

Whenever you use any sort of data plugin in AmiBroker, the AUX1/2 fields are no longer user-adjustable (same goes for OHLCV OI too).

In future releases of our product we will be populating the AUX1 and AUX2 fields with our own values, depending upon security type. For stocks, AUX1 will have the turnover and AUX2 will contain any dividend not already adjusted for in the price data (and we’ll have a user-definable price-adjustment-for-various-different-groups-of-corporate-actions setting).

For Continuous Futures, AUX1 will be populated with the YYYYMM (year and month) of the delivery from which the contract was generated for that bar.

Some exchanges do strange things with regards to the method of quotation - where they have their contract/trade specifications in in “cents” or “pennies” we do so too. Some brokers choose to quote things differently to the contract specifications.

If you could provide any specifics of the securities/symbols involved I’d be happy to discuss those here.

PS - 1/2 digit years don’t work for long histories.

Thanks for the additional information, Richard. I am looking forward to the new release.

Yeah, the 1-2 digit year for futures is an anachronism. A few years ago, Bloomberg has open-sourced its “once and forever” global security ID system, unlike some other large, acquisitive data vendors which consider their IDs proprietary but cannot provide user a clear dictionary. The granularity and the breadth of this FIGI system is amazing. Perhaps as a result of the feature, it seems to be gaining some traction with non-Bloomberg data and trading system vendors.