Module Table of Contents

Demonstration Programs & Useful Utilities

ANSI C simple and exponential style moving average routines. This module also contains a routine to support leading (what Joe DiNapoli calls Key Of The Day) and lagging a moving average array or a display indicator array.

Let's take this opportunity to show an overview to the stand-alone indicator modules. The stand-alone indicator modules are designed to be called by the user with the user provided data where as the CSTM_RPT indicator routines are called by CSTM_RPT for the user. The standalone modules all have a consistant user interface.

Each indicator will have its own typedef-ed data structure which will contain all the internal vars necessary to calculate the indicator. This data structure will also handle caching of the raw input data stream if this is necessary for the calculations. There will be 2 routines for allocation and deallocation for each indicator structure. There will also be a reset routine to reset the internal vars for a new data series. These routines will be of the form -

???     *new_???_struct() ; // this call may have arguments for some inds.
void    free_???_struct( ??? *ind_ptr ) ;
void    reset_???_struct( ??? *ind_ptr ) ; 

typedef struct {                // Simple moving averages
    float   sma ;
    int     ma_length ;
    int     data_idx ;
    int     enough_data ;
    float   *data ;             // internal data cache
}   SMA ;


SMA     *new_sma_struct( int ma_length ) ;
void    free_sma_struct( SMA *sma_ptr ) ;
void    reset_sma_struct( SMA *sma_ptr ) ;

void update_sma_struct( SMA *sma_ptr , float new_data ) ;

// given - float *data_array ; // loaded with some data

sma_ptr = new_sma_struct( 20 ) ; for( i = 0 ; i < max_data_cnt ; i++ ) {
update_sma_struct( sma_ptr , data_array[ i ] ) ;
if( sma_ptr->enough_data )
printf( "SMA = %f \n" , sma_ptr->sma ) ; }

The other form directly calculates any indicator suitable for charting. This means that the returned indicator also contains some magic cookie values for the graphics subsystem - IND_VAL_INVALID which means that the indicator is not up to speed and so graphics subsystem suppresses the plot of that data point. The indicator will either be simple float arrays for simple indicators like SMA's or typedef-ed structures for more complicated indicator systems like Bollinger Bands. These routines expect to given a DATA_REC data series and a which field to use flag. The calc routine will handle the allocation & deallocation of the low-level indicator structure but now your program will be responsible for ownership of the higher level indicator display structure.

void calc_sma_ind( DATA_REC *data_ptr ,
int data_cnt , int which_field , float *inds , int ma_length ) ;

// given - DATA_REC *data_array // loaded with 50 bars of some data // and a - float *sma_20_inds ;

sma_20_inds = my_calloc( sizeof( float ) * 50 ) ; calc_sma_ind( data_array , 50 , DF_CLOSE , sma_20_inds , 20 ) ;

// that's all you need to do and then you can grfx = draw_cmd_chart( GRX_FULL__SCR , GRX_FG_FLT_DATA , 50 , sma_20_inds
, "SMA 20" ) ; // to display it

And here is a more complicated example -

typedef struct { // Bollinger Bands indicator display structure
float *upper_band ;
float *mean ;
float *lower_band ;
float *percent_b ; } BBAND_IND ;

bband_ptr = new_bband_ind_struct( 20 ) calc_bband_ind( data_array , 50 , DF_CLOSE , sma_20_inds , 20 , 2.0 ) ;

// that's all you need to do and then you can grfx = draw_cmd_chart( GRX_FULL_SCR , GRX_FG_DATA_REC , 50 , data_array ,
"Some Data with BBands" ) ; overlay_line_plot( grfx , bband_ptr->upper_band , MA1_COLOR ) ; overlay_line_plot( grfx , bband_ptr->mean , MA1_COLOR ) ; overlay_line_plot( grfx , bband_ptr->lower_band , MA1_COLOR ) ; free_bband_ind_struct( bband_ptr ) ;

ANSI C adaptive moving average routines based on Perry Kaufman's 03/93 Futures article.

ANSI C weighted moving average routines.

ANSI C standard deviation routines.

ANSI C least-squares and best-fit linear regression and time series line regression indicator routines.

ANSI C dual frequency trigonometric regression routines. The math came from Perry Kaufman's book and the errors in the book have been corrected.

ANSI C Moving Average Convergence / Divergence and Moving Average Convergence / Divergence Histogram routines. All of the MACD routines are front-ended by macros to provide the MACDH routines. And since an MACD is just a dual moving average crossover with one more parameter for a trigger line, the MACD routines have also been front-end by another set of macros for DMAC support (the DMAC new macro will supply a dummy value for the trigger line length). So once the enough_data is field goes TRUE the DMAC value will be in the macd var.

For an example lets calc a McClellan Oscillator -

// given 2 float arrays of data : adv[] & decl[]

mcc_ptr = new_dmac_struct( 19 , 39 , FALSE ) ; for( i = 0 ; 1 < 40 ; i++ )
update_dmac_struct( mcc_ptr , adv[ i ] - decl[ i ] ) ;

printf( "McClellan Osc = %4.0f \n" , mcc_ptr->macd ) ;

ANSI C Bollinger Band indicator routines.

ANSI C Relative Strength Index routines.

ANSI C stochastics and Williams' %R routines prototypes and typedefs.

ANSI C routines for Welles Wilder's Parabolic Time/Price indicator.

ANSI C Mike Poulos' Random Walk Index indicator routines.

Routines for calculating Fibonacci price retrace and expansion projections.

Standardized data file access routines to support Computrac/Metastock, CSI and ASCII data files. For use by the commercial TDF product line. At a abstract level this module is driven by ticker_strs and returns standard records of type DATA_REC (date,high,low,close,vol,open,open_int). It expects that the GLOBAL vars data_path & database_type have already been setup. Random and sequential access is supported for all database types.

standard call flow -
1. - int lookup_data_file_num()
2. - FILE *open_data_file()
3. - int get_data_record_n() and then multiple
int get_next_data_record() Or this alternate method
1. - int lookup_data_file_num()
2. - FILE *open_data_file()
3. - int load_one_intraday_day()

There is also a lazy-mans do everything routine in MEMCPTDT.C that is layered on this module -
1. - DATA_REC *load_last_n_data_records()

The standard database path routines. These 6 routines have been broken out from DTFL_ACC.C (which is where they belong) so programs like FIB_CALC could use them and not suck in all the data access routines they don't need. The define_database() call is used by programs that don't use program configuration files. Program that do use prc_cnfg.c will get the validate_data_type() and validate_data_path_str() called for them from the cnfg_table and just need to call set_database_vars().

ANSI C routines to support creation, writing & updating of CompuTrac & MetaStock datafiles. Warning though - they do not update the label field in the master record. Also creation & writing of ASCII files is supported.

There are 4 main entry points to this module.

output_cpt_dt_file() is used to write a data series to disk in a
binary Computrac/Metastock format. The resulting data file will
contain only the given data.

output_ascii_dt_file() is used to write a data series to disk in a
ASCII format. The resulting data file will contain only the given data.

append_cpt_dt_file() is used to append a data series to a disk file.
The data file will contain its original data plus the new data.

update_cpt_data_record() is used to update an existing data record
on disk.
update_cpt_data_record() standard call flow -
1. lookup_data_file_num() // lookup your ticker
2. open_date_file_4_update()
3. get_data_record_n() // fetch the target record
4. do your updating on the DATA_REC
5. update_cpt_data_record() // and put it back

These are a few routines layered on top of the standard datafile access routines to support memory caching of the master file info. The module is slightly mis-named, only Metastock memory caching & lookup is supported (to support Computrac you just need to check a different field).

The other major functions in this module - find_date_record_by_date() and load_last_n_data_records() do support all database types.

The standard output_device support routines. This module allocates the flags and the FILE *output_device. This is the place that command line switches of /a /o /p are all supported.

This module is the home for all user-interface, standard product routines.

A few utility routines that don't need a whole module.

A set of routines to read an ASCII configuration file and process it's data and store the info back in the caller's main() module. The user program must allocate a CNF cnf_table[] and a cnf_table_size. If config_file == NULL then use the default config file from prc_cnfg.h. Normal use would be like - ld_ascii_data_file( get_config_file(),process_config_file,debug_flag ) somewhere very early in the program activation. The normal default is to ignore non-matches to the cnf_table but you can turn-on error reporting by setting the GLOBAL var cnf_report_error to TRUE.

Error msgs and constants for the file access and cmd line configuration routines.

Date formats supported are MM/DD/YY, European DD/MM/YY, and YYMMDD strings, YYMMDD floats and UWORD julians. There are conversion routines to do any translation. The julian conversion routines are in the julian module J_DATE_R.C.

This module has also been updated to support year 2000 issues. A LONG YYYYMMDD format has been added with a collection of conversion routines. Since a single precision IEEE float only has 7 digits of accuracy 1900 - 1999 dates are mapped to 00-99 and 2000+ dates are mapped to YYYY - 1900.

Some ANSI C Julian date routines.

These routines will support hidden holiday tracking providing a way to check a julian date to determine if the market will be open.

A collection of MSDOS time and date routines.

Conversion routines for handling T-Bond data.

A collection of useful string manipulation routines (they all expect NULL terminated strs).

A couple very simple ANSI C parse and identify routines. These are meant to do white space parses on a str to support simple vocabularies or simple destructive converts. For complex vocabularies you should use YACC or BISON.

A few wrapped MSDOS directory functions.

A program to easily run multiple indicators and systems in parallel against a data set and then generate a custom report for the user.

The basic program logic is that the user gives us a report template file and 1 (or more) data ticker strings. We first process the template file into process records. The template lines consist of file constant verbs or action verbs. The concept is that process records process data items into output values. Once the template file is parsed, each of the user requested data files are loaded in turn and run against the report template. This program uses the Indicator Engine in the TDF_lib dll.

A Q & D program to load 1 to 4 charts (and possible indicators) and possibly dump the chart out to disk as a bitmap file (which can be converted to a JPG by cjpeg). This is also a fine example of the G_WIN subsystem.

From the command line the program can be controlled to produce normal OHLC bar charts or candlesticks or equivolume charts. The program then displays the chart in 6 predefined production screens of various layouts and indicators. If also has a couple of demo screens.

This program can be built 2 ways - as either a standard windows app (with a WinMain() ) or as a console app (with a standarc C main() ). If built as a windows app you can call it from a batch file and draw any number of graphics windows up on the screen (see MRK_VIEW.BAT). The console app style is used to be called from a batch file to dump bitmap files suitable for converting in JPG for use on a web page (the program SS2.EXE is built this way). I build a fresh daily chartbook automatically for my internal web site this way.

TDF_Lib buyers - sorry but this program release is meant only as a demo program of the graphics subsystem so I have AWK-ed out EPSON printer stuff and some proprietary indicators.

A Q & D to dump CSI & Computrac master and data files to stdout to see what I've got.

A Q & D program to read a file of ASCII cycles and track where a market is in relation to them. Another goal is to track what Jeff Bower at FNN humbly calls Bower power shifts (cycle confluences). And now cross-ref the market high/low extremes and Fibonacci time projections from a FIB_RPT report in too.

This is a simple example program used to monitor multiple program's output or general health across your LAN. This program works by monitoring udp tranmissions from the watched target programs. The way is it currently configured I use it to monitor data flow on my lan generated by 2 real-time data collection packages during market hours. And I monitor my unix server 24 hours / day. When some-one goes quiet for more than 90 seconds I update the screen display to crashed and repeat a siren alarm every 60 seconds.

Some simple handy-dandy binary tree routines.

This is a nice dual purpose program. It's main function is a udp addressable display screen suitable for black-board message display from another app (either machine local or lan wide). The secondary function is being a nice example program for some of the capabilities of the QS_WIN (Quote Screen Windows) routines.

A collection of routines to build and support a circular byte buffer. Suitable for storing and buffering a data stream from a device like a serial port. Or you can buffer display characters to a tty style window.

This module contains the indicator routines for Indicator Engine. From the abstract view this module meant to process sequentially - globally available DATA_REC data points through the defined report template via the process_records. For each DATA_REC data value each of the defined process records while be called by sequence of their definition (they'll be called in-order). This means for DATA_REC # 1 - process records 1 to N are executed, then DATA_REC # 2 is processed, etc.. Since the process records are processed in order this means that process records can also generate data that can be further processed by subsequent process records on the same DATA_REC pass (exp. DATA_REC # 1 / process record #1 builds a output value that DATA_REC #1 / process record # 2 can then use).

All of the indicators can be thought of as objects attached to the process records. Each indicator object has two main routines - an allocate routine and a calculate routine (beginning with allocate_ & calc_ respectively). It may also have a initialize routine to reset itself between multiple data series if it needs to (these routines begin with init_). Of course there are other helper routines too. Also some indicator objects are layered on top of other indicator objects (exp. MACDs are built out of SMAs or EMAs). For this reason some indicators also have alloc_ routines that allocate, initialize and return the pointer to a virgin indicator object.

Also each indicator object internally caches the data that it is provided during the update calls so it is possible to calculate indicators of indicators. Sometimes this could be of dubious value (like calculating a stochastics indicator of a moving average), other times it can be very valuable (like a standard deviation study of any indicator).