The ".t8" just means a dataset file with 8 fields plus the date. It is not always the CONTRACT format. For avoiding confusion, we'll modify that example.

To the other questions: Yes, splitting options data over many datasets by their expiration dates would be less effective I suppose, if not to say crazy. Historical files are either not split, or split by years. Files or datasets are not updated unless you update them. We can not add 4-5 fields to the *.t8 file because it would then be a *.t12-*.t13 file.

When I have an additional dataset loaded containing the greeks, how would you suggest finding the row related to the contract that I would like to trade?

Suppose I have an options chain for that date loaded (from T8 data), and I have a parallel dataset containing additional data.

1. How can I loop thru the various available contracts in the current chain loaded from T8 data? The examples that I found just suggest an option to select a given contract in the chain, given its parameters (strike, CALL/PUT, etc).
2. How can I relate each of those to the appropriate row in my aditional dataset?

The simplest way would be using the ContractRow variable that contains the dataset row of the selected contract. It is available in the latest Zorro beta version.

Jcl,
sorry for insisting, but I do want to get better understanding of things.

1. IB is the only Zorro's integration to trade options (at the moment anyway), and IB streams greeks via API.

- Why would you not want to receive and store them in RT together with prices in a Contract structure?
There does not seem to be extra overhead related to receiving them alongside prices...Is it because you tried them and judged them to be inaccurate?
Is it because calculating them locally would still be faster? (it would definitely not be so for numerous backtests during development).
PLease share your thinking.

2. Why would we prefer to store 4-5 fields (option contract specs) TWICE - once in a Contract struct and once in a related dataset with Greeks, - AND waste time looping through these fields to locate the needed line in a dataset(with a ContractRow)?

What's the tradeoff you are facing that necessitates sticking to an 8-field contract structure rather than an 12-field one?

Thanks for your patience and clarifications.

Best
Z.

For the record, the Ally Invest plugin also trades options. I wrote it as a community contribution.

Historical data is very large. Therefore the size of the used structs is not irrelevant. We had to be carefully to only include fields that are really needed and used. No user so far wanted greek fields in historical data. Some vendors do offer history with greeks, but at twice the price of normal options history. I hope this answers the question.

If someone got the point of backtesting an algorithmic options
strategy and obtained data - the one would "normally" use the greeks, rather sooner then later.
Having to store and process same data twice just magnifies the "size" problem for a typical user.

Some more questions:
1. What should the sequence of fields in a dataset be for the ContractRaw to work?
2.
Will ContractRaw get set to the contract found with this function? If not, then what's the suggested way of setting it upon calling this function?

3. Using "ContractUpdate()":
- to improve efficiency, it would be great to be able to limit retrieved chains to "max N-days" from now and "X-stds" strikes from current price, or do this manually - as per manual.

What should be the sequence of fields in such dataset?

4. What's the principle of sequencing records in a chain - from 1..to NumContracts?

5. What CONTRACT Struct fields are populated by ContractPrice()in RT?
Will the price of underlying get updated?
I am trading spot FX, but would like to implement a strategy with options on futures..

Best
Z.

We've written all sorts of options systems for clients, but never had to "store and process some data twice" - and I would not hire a programmer who does that without need. Yes, contract() sets ContractRow. The sequence of fields in a CONTRACT struct can be found in trading.h. The sequence of options in an options chain is determined by the broker or the historical data. contractPrice() sets the contract ask and bid price. If the underlying is also updated depends on the broker; IB does it, other brokers might not.

I truly seek to understand and would really appreciate your
thinking, experience, best practice, and considerations that seem obvious to you, but might not to us.


It is documented for (type,Expiry,strike) but not for (type,Days,strike).


In what sequence do fields need to be in the 'greeks' dataset?
(for the ContractRaw to work). Same as in CONTRACT?


Ok. IB also streams greeks, and your opinion/experience with this - if any - would be very helpful and save time.
Is this something you worth considering?

From your questions it seems that something was still confused or misunderstood. Your greeks dataset is created and used by you. So I do not know its sequence of fields, which is up to you. How to create and use a dataset is described in the manual. The only number you need is ContractRow, for getting the right row.

I have no experiences with the greeks from IB, so I can not comment on them. They are used for manual trading, so I assume that they are ok.