Saturday, July 27, 2013

sdi_aispy revision 1.0.1 released

due to a recent update in the tos platform the scripts for sdi_aispy strategy and the sdi_aispymind chart study failed. there has been a decrease in the number of digits to 15 that thinkscript will accept. consequently, i went back through these two scripts and rounded off the network weightings accordingly. this script performs as well as before - an interesting experiment that demonstrates that there is not an extremely high degree of tuning in these numbers.

this result leads me to ask, what resolution of weights is sufficient? having such a large degree of resolution in the weighting creates a huge solution space. to see this, imagine the weights of this network are limited to take on only 10 different values and there are only 2 weights in the nn. the solution space is the number of possible configurations. there 10 possibilites for the first weight and 10 possibilities for the second weight. thus there are 10*10 or 100 possible solutions. the aispy nn has 51 weights, so constraining the weighting to 10 possibilities would have 10^51 solutions, a big number but not nearly as big as the solution space now stands. the floating point number scheme in java is represented by 64 bits. this gives 16 places past the decimal. the genetic algorithm favors searching weights in the low single digits, between -3 and +3, say.  so as things stand that solution space is verry big ~ 6*10^16^51. this is a stupendously large number 6*10^816 or many hundreds of orders of magnitude greater than a googol (10^100.) on one hand, it is testament to the power of the evolutionary process that it can find any profitable solution in such a huge space. on the other hand, this big a solution space is overkill and i think is a situation whereby more might be done with less. i think i will have to revisit this problem with a reduced solution space.

Monday, July 22, 2013

thinkscript included: sdi_ivp - iv percentile in a chart label

i have been following tastytrade's usage of iv percentile but it is a little awkward to use. usually you have to go the trade tab then open up the option statistics and wait for all that to populate. i think i have a better solution - just put that number in a chart label and keep it handy on the chart. here's my solution:

sdi_ivp on netflix - not a trade recommendation
this is a short and sweet solution. there is just one caveat - if you change the aggregation period higher than day then the tos platform will complain and the chart label will disappear.

here's the code: (how to install)
release 1.3 description here.

input period = AggregationPeriod.DAY ;
# sdi_ivp: Display Implied Volatility Percent Range as a label
#hint: Displays the Implied Volatility Percent Range (aka rank, aka pecentile) as a chart label and as a chart indicator. the chart indicator plots as color-coded dots along the chart high and indicates when the iv%r was high/mid/low in the past. the chart label shows the curent numerical value and has the same color coding as the indicator. sdi_ivp rev: 1.31
# author: allen everhart
# date: 19jul2013
# revision 1.3.1 3/9/2014
#    a. eliminate use of takeValueColor which doesn't seem to be reliable.
# revision 1.3 3/2/2014
#    a. ivr indicator enhancement to show when the ivp was high/mid/low in the past
#    b. tie the label color to the ivr color
#    c. made label text an input parameter.
#    d. use double.POSITIVE_INFINITY AND double.NEGATIVE_INFINITY for gap filtering instead of +/-999999999 (just for code correctness)
# revision 1.2 9/18/2013
#    enhancement to permit user to select label color
# revision 1.1 9/13/2013
#    previously sdi_ivp printed N/A if there were gaps in the imp_volatility data. now gaps are ignored.
# copylefts reserved. This is free software. That means you are free
# to use or modify it for your own usage but not for resale.
# Help me get the word out about my blog by keeping this header
# in place.
declare upper;
#hint period: time period to use for aggregating implied volatility. sdi_ivp rev: 1.31
input length =252 ;
#hint length: #bars used to determine the high/low range of implied volatility
input highPct = 50 ;
#hint highPct: threshold for changing ivr indicator to high color.
input lowPct = 50 ;
#hint lowPct: threshold for changing ivr indicator to low color. note: if lowPct >= highPct then midrange color is suppressed.
input ivprPlacement = {default chartHigh, chartLow};
#hint ivprPlacement: macro control of ivr indicator placement.
input ivprOffsetFactor = .02;
#hint ivprOffsetFactor: fine control of ivr indicator placement.
input labelText = "IV%R";
#hint labelText: default text means: implied volatility percent range.

def ivGapHi = if isnan(imp_volatility(period=period)) then double.POSITIVE_INFINITY else imp_volatility(period=period);
def ivGapLo = if isnan(imp_volatility(period=period)) then double.NEGATIVE_INFINITY else imp_volatility(period=period);
def periodHigh = highest( ivGapLo,length=length);
def periodLow = lowest( ivGapHi, length=length);
def ivRange = periodHigh - periodLow ;
def ivp = round( 100*(imp_volatility(period=period) - periodLow)/ivRange, 0);

plot ivpr;
switch(ivprPlacement) {
    case chartHigh:
        ivpr = if isnan(close) then double.NaN else highestAll(high)*(1+ivprOffsetFactor);
    case chartLow:
        ivpr= if isnan(close) then double.NaN else lowestAll(low)*(1-ivprOffsetFactor);
ivpr.defineColor("high", color.GREEN);
ivpr.defineColor("mid", color.YELLOW);
ivpr.defineColor("low", color.RED);
  if ivp>=highPct then ivpr.color("high")
  else if lowPct<highPct && ivp>lowPct then ivpr.color("mid")
  else ivpr.color("low")
AddLabel(1, Concat(labelText,Concat(": ", ivp)),
  if ivp>=highPct then ivpr.color("high")
  else if lowPct<highPct && ivp>lowPct then ivpr.color("mid")
  else ivpr.color("low")

Monday, July 15, 2013

sdi_yearClose revision 1.0.2 released

previously the yearClose script produced a java stack overflow. this probably was the result of an incompatibility with a thinkorswim platform update - the original script certainly was not released in that condition. now, this is corrected.


Sunday, July 14, 2013

sdi_yesterClose 1.2.2 released

the yesterclose script has been updated to correct for an incompatibility with recent changes to the thinkorswim platform. previously, yesterclose would result in a java stackoverflow. this was certainly not the case when i first published the script so something has happened on the thinkorswim platform that didn't like this script. release 1.2.2 corrects this problem.