Sunday, November 30, 2014

bonus thinkscript: sdi_avatod - average volume at time of day

bonus thinkscripts are the extra's you get when you purchase a distribution of my thinkscript suite. in the past they have mostly been thinkscripts that i pass along from other open sources. this new thinkscript is one for which i am not blogging the source code.

here is the image for my average volume at time of day script:

wmt with sdi_avatod 
average volume at time of day is an important concept for the investors business daily (ibd) crowd. in the image above the 50 day/1 hour avatod is shown as the red stairstep lines. the first hour of trading is particularly important (volume highlighted in a lighter shade of blue) as above average volume then is thought to be an early indication of institutional trading. on a holiday shortened day the the first hour of trading on wmt shows volume way above the 50 day average for the first hour of trading with a price gap to the upside. draw your own conclusions.


Monday, November 24, 2014

perhaps the best week to be long stock

seasonally speaking, thanksgiving week is one of the best weeks to be long stock as you can see from this chart with my sdi_seasonalstgy:
simulation of $10,000 of spy bought on the open of trading-day 227 (the monday before cyber-monday, more or less), held for 4 trading days,  and sold on the open of  trading-day 231 (cyber-monday, more or less) over last 20 years
next week - back to 50%

Saturday, November 22, 2014

thinkscript included: sdi_yield_label

this one is so obvious that i am surprised that there is not a standard tos study to display a stock's yield in a chart label. here's the picture:
spy with sdi_yield_label in upper left hand corner

here's the code:
################################
# sdi_yield_label: Display Yield In A Chart Label.
#hint: Displays yield in a chart label. sdi_ivp rev: 1.0.0 http://www.smallDogInvestor.com 
# author: allen everhart
# date: 22nov2014
# revision 1.0.0
# 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. 
plot labelColor=double.nan; #just to pull-in the color-chooser widget
labelColor.setDefaultColor(color.DARK_GREEN);
labelColor.hideTitle();
labelColor.hide();
addLabel(1,concat("Yield:",asPercent(getYield())), labelColor.takeValueColor());
################################

Sunday, November 16, 2014

the 80/25 strategy

one of jim cramer's favorite investing themes is to trade with 'house' money. what he is talking about is buying a stock, waiting for it to double and then selling half - at which point you have recovered the money you invested and your remaining shares have zero cost-basis (zcb.) then you retain the zcb shares until some other investment objective is met.
do you really need to wait for a doubling of price to create a zcb position?
no! the sell-half-after-doubling strategy is just the most facile arithmetic (1/2 is the inversion of 2 - anybody could do that in their head.) in reality it is somewhat rare for a stock to double within my patience time-horizon - about a business quarter - which i don't think is so unusual considering the great many choices of momentum stocks to choose from. a far more likely scenario is that a favorable stock rises by 25% in a quarter. given a 25% appreciation one could sell 80% (since 4/5 is the inversion of 5/4) of one's shares and have a house-money position on the remaining 20%. once i have my money back, i can have a great deal of patience - this is the essence my 80/25 strategy. 

one could pick other ratios to work with, say, a 75/33 (sell 75% after 33% gain since 3/4 is the inversion of 4/3), 67/50 (2/3 is 3/2 inverted) or for those golden ratio fans 61.8/61.8 (sell 61.8% of shares after a 61.8% gain - since .618 is the inversion of 1.618 - try it!) however, there is good reason to concentrate on 80/25 because our friends at investor's business daily have researched that 25% is the most common run-up in a quality stock before a pull-back occurs. ibd's strategy calls for selling 100% of the stock after a 25% gain but i think it makes sense to take the profit in stock since nobody is paying interest on cash these days, and especially if the stock pays a dividend (in which case one essentially has a small, but free, annuity.)

i have more ideas about how to implement this strategy that i will explore in follow-up posts.

Tuesday, November 11, 2014

keepin' it real with dow and gold

ok, i admit it. i'm a little freaked out with the market at all time highs and gold sinking to the center of the earth. but are the numbers faking us out? yes! i would argue. this is because the ratio of the dow to gold is only 15. since gold is considered a constant store of value, the dow/gold ratio is what economists look at when they want to back-out inflation and central bank intervention. here's the picture:

dow / gold study (source chart of dow-gold is hidden)
in prosperous times the dow/gold ratio ranges into the 20's and 30's. we are not even back to the levels we were at before the housing bubble burst. so if you're thinking the market has flown too high and gold too low, think again!



Saturday, November 1, 2014

how to 'soup'-up thinkorswim

thinkorswim (tos) is my trading platform of choice. it provides a full-featured charting platform with extensive quoting of many different markets (some of which you would pay extra for on other platforms just to see 'em,) and a robust user-programmable scripting language. however, at times, it is a love/hate relationship. this is because application performance is not always great.
the garbage about java...
i think the first thing to recognize is that tos is written in the java programming language. java is an object-oriented language that is based on a dynamic-memory technique called heap storage. heap storage enables programmers to concentrate on solutions and less on housekeeping. in particular, a java programmer doesn't have to figure out the the prickly details of when to deallocate memory. in java, memory deallocation is automated by a software subroutine called the garbage collector. the garbage collector sifts the heap looking for objects that have a zero reference-count and deallocates them. thus, heap storage vanquishes a whole raft of memory-leak considerations that are the bane of non-heap programs. garbage collection is done automatically and is triggered by low-levels of available heap (also explicitly in the tos help/system tab but something is wrong if you need to do that.) the trade-off with heap storage is a higher requirement for memory. the higher requirement comes from the need to have a high level of free memory in the heap so as keep the garbage-collector relatively inactive. several pointers that follow address the proper care and feeding of java's heap storage.
up your bits and bytes...
the bit-number refers to the number of bits used to compose the address of a particular byte in memory. a 32-bit machine can create a unique address for 2^32 (2 raised to the 32th power) bytes. which means that a 32-bit machine can only ever utilize 4 gigabytes of ram. now, if you are on a 64-bit machine then you probably don't know what i'm talking about. that is my first advice to soup-ing tos. upgrade to a 64 bit machine that has a boat-load of memory. a 64-bit machine can assign an address to 2^64 bytes (about 16-million terrabytes) which is to say you are only constrained by budget as to how much memory you can install on a 64-bit machine. at some point the amount of memory installed is overkill but applications are like furniture and expand to fill all available space. you should get at least 8 gigabytes which is twice the amount of memory that can be addressed by a 32-bit machine.
up your processors...
also, most pc's these days have multiple processors. this enables a computer to literally walk and chew-gum - genuinely parallel (not just concurrent) computing. java supports parallel processing by a programming technique called threading, and tos undoubtedly is a multi-threaded application. which means, that at a minimum say, it could be running the garbage collector in parallel while your chart is painting. (2/28/16 alas, the garbage collector suspends all threads and always runs single-threaded resulting in the infamous gc-pause, for this reason you might want to consider running two instances of tos) if you are puchasing a machine on which to run tos then more processors are better. quad-core is a buzzword i hear a lot, maybe there is an even greater multiple available. my old clunker is dual core.
a virtual fairy-tale...
your operating system is like a sly gigolo - it makes an application feel like it is the only application in the world. to a running application, the memory address space it sees starts at zero and ends at the architecture limit (2^32 or 2^64) and the app has not a care in the world about whether the memory it is accessing is actually loaded into memory or conflicts with another application's memory. the os's job is to translate this fairy-tale, single-application viewpoint into the real-world of the physical machine where the program starting address is definitely not zero, there is far less ram than the architecture limit and there are multiple applications vying for system resources. in order to accomplish this the os employs a memory trick called virtual memory in which the os divides memory into chunks, called pages, and backs them to the mass-storage device (i.e. disk.) which is all to say that despite having a boat-load of the fastest random-access memory that money can buy your system's performance still has a disk-speed component because of virtual memory. there are two points of soup'ing advice that address the proper care and feeding of virtual memory:
up your page-file...
the first advice is to make sure your computer has an adequately sized page-file. the page file is the backing-store for the memory of a running application. so, however much memory your running applications occupy, there must be as much space available (and then some) in the page file on disk. a general rule of thumb is that the page-file should be twice the size of the ram and it doesn't hurt to have more. under-utilization is the only downside to an overly large page-file, whereas, an under-sized page-file will cause your system to thrash (where the os gets into a vicious cycle of transferring the same pages between ram and the pagefile.)
solidify your experience...
the other bit of soup'ing advice that follows from virtual memory is to upgrade your disk to an ssd (solid-state disk.) ssd's eliminate the delay of having to wait for a physical read-head to move (called seek time) to the right spot above a spinning disk and greatly reduce the delay in reading data caused by the speed at which a physical disk passes beneath the read-head (called rotational latency time.) basically, ssd technology is something like 10x faster than hard disk technology, and much more if you are on a disk that is 4 or 5 years old. this is like crack for a memory hungry application like tos. i spent $120 at staples to buy a 100gb ssd. it took me 30min to copy the image from my clunker hard drive and the performance improvement was night and day, not least to mention my vista os reboots in under a minute now.
up your memory settings...
as for tos memory settings, i set mine to the 1280-1280 maximum available to my 32-bit machine. this means when tos starts up it allocates a heap of 1.2 gigabytes all at once. the trade-off is that other applications might be starved for memory when i have tos running. however, for me, when i am trading everything else is secondary.
throttle your quote-speed...
even with all these stops pulled-out, i still was experiencing some nasty performance problems that were only remedied by restarting tos. by monitoring the help/system display i could see that my system was exhibiting a behavior i call heap-thrashing. this is a vicious cycle whereby the free memory would deplete to 25k or so, then the garbage collector would free 125k or so, and then 100k would get immediately allocated. i believe that this behavior is a quote-speed problem because it only occurred when the cash-market was open and when i adjusted the quote-speed from real-time to max 10-second delay (on the settings/application-settings dialogue) i was able to almost completely eliminate this problem while preserving a substantially live-market experience. on the help/system tab you can monitor the number of quotes per minute being received by tos. when i was experiencing heap-thrashing i was receiving in excess of 12,000 quotes per minute. after throttling this back to max 10-second delay this number went to about 3,000 quotes per minute.
cable it...
additionally, i see intermittent performance problems. all the local platform metrics are 'nominal' but there's an intermittent delay drawing a chart or updating data in a custom watchlist column. when this happens there's probably a communication delay. i have found through trial and error that my thinkorswim platform experience is smoother when i cable directly to my router with an ethernet cable instead of using wi-fi. now, a lot of things can go wrong with radio communications. in my former career i was programming computer systems that communicated by radio to terminals and one such system was experiencing intermittent delays. the problem was diagnosed and corrected only after a month of full-time consultation with radio experts who used hi-tech monitoring equipment (side note: be careful what you say on a cell-phone because all that gets transmitted un-scrambled on public airwaves.)  it turned out that a similar system running on a different frequency that was only used between 10am and 11am in the morning was creating what the radio experts called 'harmonic distortion.' so with the density of wi-fi routers in some locations it doesn't surprise me that there is sometimes a hard-to identify problem with wi-fi communications. i never could diagnose my tos issue with wi-fi because everything else worked great- webpages loaded instantly, pings showed no packet loss -only tos was hampered. even so, i stay tethered to my router.
up your isp...
i have word that the thinkorswim servers are physically located in in dallas. you can check your communications delay to the dallas area using internet speed tests such as this. here's what i get for this test:

i am getting a relatively good tos experience with this level of communication service. upping the speed of isp communications will enable you to receive more quotes per minute over the same bandwidth but you also have to have a fast enough and big enough bucket on the other end to handle all those quotes. in retrospect, i think, perhaps, some of my tos performance issues might be related to my upgrading from dsl, where i was getting 1 mbs, to cable modem. 


here's the system config with which i am having a good tos experience:
  • 32 bit machine
  • dual-core
  • 2 gigabyte ram
  • solid-state disk.
  • 4 gigabyte pagefile
  • 1280-1280 tos memory settings
  • max 10-second delay quote-speed.
  • 10base-t cable to 20mb/s router
  • 20mb/s cable modem

but my next machine might be configured like:

  • 64 bit machine
  • quad-core machine
  • 8+ gigabyte ram
  • solid-state disk.
  • page-file 2 to 3x ram
  • maximum tos memory settings.
  • maybe real-time quote-speed.
  • 10base-t cable to 20mb/s router
  • 20mb/s cable modem