Need help improving/extending this basic code for intraday (1-min) liquidity measure

jaybee

New member
Hello,

I have been an active READER on this site and this is my first post! I have worked on this simple script to COUNT number of 1-min bars that have no movement and low-volume. Below is my code. I need help to:
a) improve with better ways to accurately identify first-Bar and last-Bar of an intraday (1-min) instead of blindly using 390 bars for 390 minutes of a day
b) Able to calculate the same not just for TODAY, but for last say 5 days of intraday.
c) Expand to limit to COUNT calculation to only certain HOURS of the INTRADAY, example 11:30am EST to 2:30pm EST only, (basically during the mid-day).

Thank you all in advance.
-Jay
----------------------------
Code:
# Filter : Intraday Liquidity threshold filter
# Description: In the smallest possible intraday timeframe (1-min), there should not be too many quiet (low-volume or no volume) bars that are flat (high==low==open==close).  NOTE: Intraday time in minutes: 1-day = 390mins

INPUT displacement = 0;

INPUT IGNORE_VOLUME = {   _YES, default  _NO};
INPUT QUIET_VOLUME = 100;

def LL_Threshold = 60;

def o = open;
def c = close;
def l=low;
def h=high;

def boolQuietBar;

switch (IGNORE_VOLUME) {

    case _YES:
    boolQuietBar = (high == low);

    case _NO:
    boolQuietBar = (high == low) and (volume <= QUIET_VOLUME);

}

#def QuietBar_Count = if boolQuietBar then QuietBar_Count[1]+1 else QuietBar_Count[1];
def QuietBar_Count = sum(boolQuietBar, 390);

AddLabel (yes, "LL #: " + QuietBar_Count, Color.WHITE);

#plot myplot = if QuietBar_Count[displacement] > LL_Threshold then QuietBar_Count[displacement] else Double.NaN ;

#plot myplot = boolQuietBar;
 

rad14733

Well-known member
VIP
@jaybee Having written code for close to four decades now, from way back when CPU clock cycles needed to be considered and code needed to be optimized, I'll offer a suggestion for your code... The use of the case structure is superfluous for a simple yes/no decision... You could simply use the following and reduce code size and CPU clock cycles... While the switch/case structure is good practice it doesn't add anything to the code but, instead, requires extra processing... After all, if you're going to go to the extent of using short variable names for price, partially negating the code being self-documenting, you might as well reduce it further... Actually, now that I look back at your code, those variables aren't even used... It may sound like nitpicking but, again, I constantly optimize my code out of habit...

All that said, it's good to practice the many concepts that Thinkscript provides... Keep at it... (y)

Ruby:
INPUT IGNORE_VOLUME = no;
if IGNORE_VOLUME then boolQuietBar = (high == low) else boolQuietBar = (high == low) and (volume <= QUIET_VOLUME);
 

jaybee

New member
@rad14733 , my utmost respects and salute to you for your valuable advice and suggestion on optimizing my code. I 100% agree with your best-practice. I myself come from 'embedded system firmware programming' background, having starting coding mostly in 100% assembly language for 8-bit, 16-bit microcontrollers and latter x86 CPU BIOS Firmware. However now knowing the 'ThinkOrSwim's high-level scripting languages internal preprocessing and compiler/interpreter architecture I have not able to see the big-picture but definitely prefer to keep optimal coding in mind (and better naming convention!! I was trying to use this convention become sometime I need to repurpose others code from TC2000 software code to TOS code!).
Very nice to virtual meeting you. I recently joined this community. But I see that this is a very active community and great support and comradery. Thanks again.
 

rad14733

Well-known member
VIP
@jaybee Nice to meet another bit-fiddler... I used to write Motorola assembly language code for the 6809 and 68000 family of microprocessors back in the 1980's... I even wrote custom EPROM code and wrote device drivers back before they were readily available for various hardware... I can't say that I miss those days... I recoded the same text formatting code multiple times and eventually reduced the code from over 2000 lines to somewhere around 1600 lines, but not by choice... Seems I had a bad drive data cable and when I saved the code it never wrote to the drive... What I thought was the code reloading when I was verifying was actually just the code stored in buffer... Every time I recoded from printout (i was smart enough to do that after the first failed save), I would find ways to optimize a bit more... That was a week of coding I'll never get back...

Welcome aboard, just in case I failed to welcome you previously...
 

jaybee

New member
@jaybee Nice to meet another bit-fiddler... I used to write Motorola assembly language code for the 6809 and 68000 family of microprocessors back in the 1980's... I even wrote custom EPROM code and wrote device drivers back before they were readily available for various hardware... I can't say that I miss those days... I recoded the same text formatting code multiple times and eventually reduced the code from over 2000 lines to somewhere around 1600 lines, but not by choice... Seems I had a bad drive data cable and when I saved the code it never wrote to the drive... What I thought was the code reloading when I was verifying was actually just the code stored in buffer... Every time I recoded from printout (i was smart enough to do that after the first failed save), I would find ways to optimize a bit more... That was a week of coding I'll never get back...

Welcome aboard, just in case I failed to welcome you previously...
Haha! Classic memorable debugging all-nighter type story! Similar background, with 8031, 8051 microcontrollers based industrial controller/monitoring/data-logging devices and later to Intel 8085/8086/80186 based X.25 network-communication boards, interfacing with passive keyboard-matrix/4-line-LCD-display with it's own 7x5 dot-matrix character set that we had to keep a look-up-table for!! Yes, those were the times we had to optimize to squeeze in a few bytes and bits sometime into the 4K to 16K EEPROMs! Thanks. Great a connect.
@rad14733
 

MerryDay

Well-known member
VIP
Oh no! It's the invasion of the geeks! o_O
Welcome, @jaybee. This is an awesome forum with many talented posters! You will be in good company. And we non-geeks, may not understand the whole thought process, we will appreciate your end results
 

Similar threads

Top