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.

This module contains the indicator routines for CSTM_RPT. 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).

This module contains more of the indicator routines for CSTM_RPT.

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_date_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_date_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 4 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 UINT julians. There are conversion routines to do any translation. The julian conversion routines are in the julian module J_DATE_R.C.

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.

This module contains various low level DOS disk interface routines. Warning - routines in this module can fetch things that if written back to disk - Could (and if Murphy has anything to say about it WILL) mung things up VERY bad. So don't write these back unless you know what you are doing. Ok you been warned, it's your foot.

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.

This module contains the EGA mode charting subsystem. These are the level 2 & 3 functions.

TDF_Lib buyers - if one wished to port this package to a different graphics platform like BGI all you would have to do is rewrite &| front-end &| simulate the level 1 functions and variables in SM_GRX.C & SM_GRX2.ASM, the level 2 functions in this module will require a look (and maybe some work) and then the level 3 functions will run clean.