Is this method
In attempting to use this method I am getting an error message that I can't cast a void.
CODE:functional? Are there any examples of usage? If functional, what data type does it return? string?
TradierHistorical.Instance.GetOptionChainWithGreeks(OptContractSymbol, _expiry);
In attempting to use this method I am getting an error message that I can't cast a void.
Rename
It's an undocumented void method used internally. (It should have probably been made a private method.)
If you want the greeks for a symbol, use the documented Historical Provider method GetGreeks(string optionSymbol), which returns an OptionGreek object.
If you want the greeks for a symbol, use the documented Historical Provider method GetGreeks(string optionSymbol), which returns an OptionGreek object.
Shucks. I thought I found an Easter Egg!
If I could d/l the entire Option Chain (OC) for a symbol /date combo, I could use a single Linc / lambda expression to get the option symbol that meets multiple criteria: strike, price, and any combination of Greeks, all optionally within a range on each of those parameters.
Currently, what I have to do to accomplish this is:
1. Get a valid symbol for strike / date (without specifying Greeks or price ranges)
2. Figure out what the increment in the OC is for that date around the strike. (Requires multiple option fetches with "guesses" at the increment until I get a valid one.)
3. Make additional symbol fetches using found increment to get "candidate" option symbols
4. Get Greeks on each candidate symbol to confirm it is within a range of multiple criteria, including price
5. Put valid candidate symbols in a list together with their Greek characteristics
6. Sort the list based on transaction value to select optimal symbol based on price / Greeks criteria
I'm not concerned about the local processing this requires but would like to cut down on the number of pings I make to the data provider to get the symbol I want.
I realize that this capability to d/l the entire OC looks like it might only be available with the Tradier API, but would you entertain a Feature Request for this?
If I could d/l the entire Option Chain (OC) for a symbol /date combo, I could use a single Linc / lambda expression to get the option symbol that meets multiple criteria: strike, price, and any combination of Greeks, all optionally within a range on each of those parameters.
Currently, what I have to do to accomplish this is:
1. Get a valid symbol for strike / date (without specifying Greeks or price ranges)
2. Figure out what the increment in the OC is for that date around the strike. (Requires multiple option fetches with "guesses" at the increment until I get a valid one.)
3. Make additional symbol fetches using found increment to get "candidate" option symbols
4. Get Greeks on each candidate symbol to confirm it is within a range of multiple criteria, including price
5. Put valid candidate symbols in a list together with their Greek characteristics
6. Sort the list based on transaction value to select optimal symbol based on price / Greeks criteria
I'm not concerned about the local processing this requires but would like to cut down on the number of pings I make to the data provider to get the symbol I want.
I realize that this capability to d/l the entire OC looks like it might only be available with the Tradier API, but would you entertain a Feature Request for this?
It seems like a natural idea to me, since brokers and other platforms have calls to get an option chain. For example, Medved Trader has a getOptionChain.
But you'll have to convince Cone that it brings value because he's dead set against it. Admittedly I don't trade options so I'm sure Cone has a logical reason for not wanting to implement it.
But you'll have to convince Cone that it brings value because he's dead set against it. Admittedly I don't trade options so I'm sure Cone has a logical reason for not wanting to implement it.
Every provider has a different way of supplying the chain. For those that we support (currently IQFeed, IB, and Tradier), we do a lot of processing to put it in our OptionChain class that all of the Historical Providers can use.
Now Glitch, I don't know why you say that. I gave everyone a working example months ago to pull the entire chain details from IB. (You can get the chain for Tradier the same way using TradierHistorical.Instance.) But all the strikes in IB's chain are not valid at all expirations, and everyone's welcome to have fun with that.
https://www.wealth-lab.com/Discussion/Option-Chain-access-in-Broker-API-10462
Our implementation of GetOptionsSymbol() will do all the work you need to find the best contract for price and days to expiration for you in one statement.
Now If you're choosing contracts based on Greeks, that could be a reasonable use for having all the chain. But I'd argue that you should let us know what's required and we can build it into GetOptionsSymbol(). You would avoid a lot of repetitive programming. Let's see a feature request.
Now Glitch, I don't know why you say that. I gave everyone a working example months ago to pull the entire chain details from IB. (You can get the chain for Tradier the same way using TradierHistorical.Instance.) But all the strikes in IB's chain are not valid at all expirations, and everyone's welcome to have fun with that.
https://www.wealth-lab.com/Discussion/Option-Chain-access-in-Broker-API-10462
Our implementation of GetOptionsSymbol() will do all the work you need to find the best contract for price and days to expiration for you in one statement.
Now If you're choosing contracts based on Greeks, that could be a reasonable use for having all the chain. But I'd argue that you should let us know what's required and we can build it into GetOptionsSymbol(). You would avoid a lot of repetitive programming. Let's see a feature request.
QUOTE:
I gave everyone a working example months ago to pull the entire chain details from IB.
@Cone I was reviewing some previous posts on this topic (in preparation for completing my action item referenced below) and for the first time I realized that we may have not been on the same page in our usage of the term "Option Chain." The example code referenced above can be useful for identifying available option chains by date and strikes, but it is not what I mean by "option chain." The typical option chains I have seen, and the ones I use every day, are organized by symbol>exp date>put/call>strike. There is a lot of information for each strike, often including last price, bid/ask, and open int, in addition to the most popular Greeks.
I know you know this, and I'm not trying to be pedantic. I would like to share how I use option chains each day to provide a use case that might be helpful. (I don't know that there is anything unique about it.)
The information I require is which strikes on the selected [symbol>exp date] chain fall within an acceptable range of Greek values and price (either the last price, or bid/ask, or midpoint). The price is to confirm that the selected strike won't exceed its allocation. Most option chains provide all this information at a glance. I can look for strikes that fall within a range of one or more Greeks, and prices, and generally pick one within a few seconds.
I started using WL option capabilities (some new or updated) to automate this process. Instinctively, I fell back to thinking about the real-world model of an option chain. I concluded that the most direct and faithful automated reproduction of what I am doing manually would be to load an option chain into a C# class list. I then could use a lambda expression (with its incredible flexibility to code nearly any rule or set of rules) on the list to exactly replicate my rules for picking the ideal strike.
I am not pushing to implement this solution, since that has already been rejected. I also am aware that I still have an action to describe the additional functionality I would require in order to have WL find the ideal strike in a more efficient way than the way I have to it today. This is taking some time as I am challenged to describe what I would require, because the parameters of the call might get very complex and need to accept ranges of potential values (like a lambda expression) to get to the right answer. I'm not sure you will want to consider that direction, but if you're open to it, I can post a feature request outlining the requirements as I see them.
QUOTE:Let's all use the same terminology.
Most option chains provide all this information at a glance.
In broker API terms, an Option Chain consists of expiration dates and strikes for calls and puts. That's it. What you're talking about is the all the STREAMING DATA that you see in an option table for a range of strikes at specific expirations.
Since you're talking about live bid/ask and greeks, let's keep this discussion limited to IB. The title of this thread refers to Tradier, but as you should already know, Tradier doesn't provide live option data through the API - you're limited to a quote once an hour (maybe that's good enough).
Not so with IB. The way we acquuire the greeks from IB is by starting a temporary Streaming request for data. Usually *something* needs to change to get a response or the request will time out after a several seconds.
The problem when running a Strategy is that you expect a run to complete quickly, and we can't necessarily request streams for an entire option chain. But if streams were already running for a range of strikes/expirations that you're interested in, all this data would be instantly available.
One way you could get what you want is to start streams for a list of options using the Quotes tool. If IB is the provider for that, you'll instantly get a response for IBHistorical.Instance.GetGreeks() - for each contract. You can build your own virtual look-up table with that.
On the other hand, I've studied this for recent concierge request from a non-customer (so I'm not certain if that's going anywhere). However, what I've worked out in my head involves creating an options extension (no U.I.) that would create an instance of IBStreaming and launch streams for a range of strikes around some price. If the underlier is active, this should fill with data within a few seconds, which would work fine for a strategy to retrieve data from a snapshot of the "virtual option table".
If you're interested in that, send in a Concierge Request with your specifications.
@Cone Thank you for the extensive description of what is happening behind the scenes with the WL methods. I didn't understand that IB was not providing the content of the option chain, just providing a framework from which a developer can create one. It appears that Tradier's option chain feature is quite different in that it does return a populated XML or JSON formatted option chain (optionally including Greeks).
Thanks for the suggestion. I am trying to move away from IB / TWS for options trading and am attempting to vet Tradier and TDA / Schwab as an alternative. That decision will be informed by the answer to my recent post here.
Thanks for the suggestion. I am trying to move away from IB / TWS for options trading and am attempting to vet Tradier and TDA / Schwab as an alternative. That decision will be informed by the answer to my recent post here.
I'll look in to adding another call return a List<OptionSnapshot> for a range of strikes, where OptionSnapshot would consist of OptionGreek and Bid/Ask.
That's a cinch for Tradier because it's just one call for history data, although the current Bid/Ask wouldn't be available.
For IB and probably others like Schwab and Tradestation, it will be more of a challenge (Post #6).
That's a cinch for Tradier because it's just one call for history data, although the current Bid/Ask wouldn't be available.
For IB and probably others like Schwab and Tradestation, it will be more of a challenge (Post #6).
That sounds great! Yes, bid/ask does not appear to be available w/ Tradier. They provide last price, which is OK if the option is pretty liquid.
Regarding Shwab support, did you follow the link I put in Post #7?
Regarding Shwab support, did you follow the link I put in Post #7?
Your Response
Post
Edit Post
Login is required