Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I meant archiving the data behind the chart. Will you store it in your program or in some other dbase? A number of options analysis programs contain what you've displayed, but once expiration occurs, it's quite often gone. The really expensive programs - $1000 or more per month - might archive it for you, but I've never tested them.
Since archiving options data can quickly consume a lot of space, you might consider excluding the nickle strikes that rarely have very much volume. They exist in silver, natural gas, grains and a few others.
Re your question about seasonal decay, I think it's there in weather-influenced physical commodities but I haven't quantified it. Examples: Assuming we've had a seasonal run-up in IV, it usually declines rapidly in the grains once we get to Jun/Jul; in coffee once the frost scare has passed; and in natural gas once we realize we're not going to freeze to death in late Feb.
Finally, I didn't mean to overlook Ron99 who came up with the idea, DudeTooth who did a ton of work converting the archaic !@#$% PC-SPAN into a very useful tool for beginners and pros alike, and those who provided ideas and feedback to DudeTooth when he was grinding it out in late 2013/early 2014 - they've all been big contributors.
Can you help answer these questions from other members on NexusFi?
Yes, I have draft code to export the data for both the snapshot Option Chain Chart and for the time series Decay chart, that will allow the data to be saved as csv. Small data sets and small files so a few megabits of space will allow 1000's to be saved. It is understanding the behaviour that I am interested in and this can not be done by a single chart. Need a larger sample to make informed observations. But this is a start and already informs more general concepts for best DTE entry and exit for max daily ROI. My view is it has to be observed before it can be done.
Dudetooth as a copy of my messy code version of the span file now. Maybe some of this will find its way into a new version.
I have picked up from other posts you have done that you are view aware of how commodities can behave and be influenced. E.G. Just your comments about grain, coffee and gas. I find insightful. Maybe we can do some work in this area over time.
The new time series decay chart code is almost identical to that for the option chain chart in the file I sent you.
Yes, I had though about archiving snapshots in csv files. But if you have the psa files then there is not need. The only issue is the psa files seem to be very large, s a few years of data will equal approximately 12 gigabytes of space.
Yes, data collection. I have not tried to understand how you do this at this point in calcMargin or how the data is draw or transformed from the psa files. It must have been a huge task to do what you have done.
I have questions about the data. Should I ask you here or through futures.io (formerly BMT)?
Here is a quick list of the things I want to do.
1. Make the tracker sheet interactive with double click cell code. For example, I would like to be able to insert a header row. This will require reworking track all to accommodate header rows and blank rows. Second, I would like to be able to highlight and un-highlight a spread.
2. I would then like to be able to build a HV and IV Dashboard for all commodities for front and back months. This code would ideally run when a new psa file is downloaded.
3. Scanner criteria development. You will see I get the full option chain by simply changing the delta to 50 and minprice to $10. But I would like to be able to simply type in a option series code to get the full option chain. Then the second method of scanning I would like to explore is IV for options outside of a nominated 1 or 2 standard deviations. This is where I would need your help. I have looked at how I might deconstruct the calMargin into small routines and then be able to route the code based on a filter choice variable but I do not have clue where to start. Can you let me know if you are interested or willing to help.
4. I then want to consolidate all the code and forms with correct module assigned between front end and back end code.
This will then have a tool that I will use everyday and not have me going elsewhere for processing and monitoring and gathering.
4. Last, I am interested in finding the best trades. My approach is through study but I can see where you are going with the back testing and this code approach interests me.
I don't think there is any way around holding pa2 files right now, not unless we can find a way to access a compressed file programmatically (the closest I would have right now would be to unzip a pa2, read it, and delete the uncompressed when done). The pa2 files hold most of what you are looking for without any calculation necessary ... delta, IV, option price, futures price, and HV. Conversions are necessary to get $ amount and the decimal in the right place, but the only real calculation is for margin. If that is not needed for some of the data collection, that part may be able to be skipped.
1) I've never played with double-clicking to execute VBA, but it looks doable. I believe I have an idea of how to have the code find the proper columns/rows dynamically to fill data, so the user can customize the layout.
2) HV and futures prices would be able to be grabbed easily, IV would require the entire option chain. It is possible that the same code used to scan could be used to extract the IV to create volatility charts.
3) These adjustments would be fairly straight forward. I'm sure that the calcMargin can be broken into pieces, I have made some adjustments in those regards, but it can definitely use more.
4) I'm all for streamlining the code, my biggest problem is that I sometimes don't fully understand the code I'm using ... I just know it does what I want it to do.
5) I think the back-testing that I was looking at is akin to your idea of looking at all of the options to see their behaviors. My way was just a little more like looking through a straw.
6) The delta numbering can be modified. In a pa2 file there is no decimals, so you just change what you divide/multiply by to get want you want. I thought seeing a delta of 2 rather than 0.02 was easier for folks to understand in the spreadsheet. Price quotes are a little different because the pa2 files have a mechanism built in to tell you where to put the decimal for the prices. It is done automatically, so to speak, within the code. This could be modified, but it adds a layer of complexity. I left it as is because I wanted to keep the code as simple as I could and if the info was in the pa2 files I wanted to use that. The spreadsheet should be showing the same prices that you would see if you were running it through the PC-SPAN program (notable exception, JY).
7) A big weakness with the pa2 files is that there is no volume or OI reported. I currently use another spreadsheet to strip data from Barchart for futures charts and option data, namely volume and OI.
They way forward may be to determine what to focus on and in what priority. It would seem that visualizing historic data would top the list, at least from my point of view. Scanners and trade ideas will likely flow after we have found those behaviors to exploit. I'll try to create a mock-up of a way to visualize some of what you are looking for and we can go from there.
Here is a screen shot of the popup box you get when you right click on anywhere in the tracker spread sheet. This work by left click a row you wish to modify and then right clicking. You can then insert a header row, remove a header row, insert a blank row, and, copy and paste a row (used to move a position to a different header group).
I am looking for any suggestions for improvements.
A couple of months ago I tried to get a better understanding of the historical volatility (HV) column in DudeTooth's application. I messed around for a little while but I couldn't match it with common HV periods such as 21, 42 or 63 trading days. Some times it was close but other times it was way off.
Since that time, I've ignored the column by graying it out or hiding it. I get HV data elsewhere and it wasn't a complete record because ICE does not supply data for the HV column.
Fast forward to today: I was trying to find an end-of-day ATM IV to automatically populate some probability worksheets. I figured that with a couple of attempts (iterations), I could accomplish this task with DudeTooth's application. I soon discovered that the CME SPAN HV column isn't HV at all, but rather ATM IV. See the attached snip.
This makes sense because IIRC the "complete" SPAN product (~$3000) is capable of complex risk analysis and modeling and you need an ATM IV for skew analysis and shifting.
Anyway, if my discovery is correct, for CME products no iterations are necessary, you have the ATM IV right in front of you. For ICE products, you will have to plug in the closest to the money Put or Call, but it might be an option with no open interest, in which case you'll have to move up or down a strike until you get a hit.
Thanks for figuring this one out. I could never find a definition from CME as to what their "Base Volatility" was and made the incorrect assumption that is was the HV of the underlying. Right after you posted this I just searched for "Base Volatility" without CME and found numerous sites talking about it:
The base volatility, or anchor volatility, is the average of all the implied volatilities of the options specified by the base volatility field and the curve definition. For example, if the skew definition uses calls and puts, two expiration chains, and the base is at-the-money, the base volatility is the average implied volatility of four options: the at-the-money put and call for both expirations.
The base volatility has significance during curve application. It is the point that moves the skew curve as the market’s implied volatility changes. When you save a volatility skew, you are saving a curve shape and an anchor (base) point definition. When you apply a volatility skew, the base volatility is calculated, and the skew curve is anchored to it. If the base is the at-the-money strike and the volatility of the at-the-money strike increases, the entire curve rises on the Y axis; similarly, as the at-the-money strike changes (which implies a change in the underlying price), the entire skew curve follows it along the X axis.
That's a good find. We still don't know how many strikes the CME uses; some providers use the two nearest the money (one above and one below) and I've come across at least one that uses three (the nearest to the money plus one above and one below). It doesn't really matter though. I doubt any of us are trading 100 million dollar portfolios, so a few basis points in IV or even 10 or 20 is probably not going to change a trading or hedging decision.
A related benefit: For those that don't have access to daily ATM IV data and charts, they could build a history (and then charts) using your application.
Just out of curiosity, is all of the data on the chart derived from the SPAN files, i.e. have you collected several months of history and your application calculates HVs based on the futures settlement price found in the SPAN file?
