June 2002

In May my brother John and I visited Larry Pesavento in Tucson, Az.  We were able to talk with Larry about his research in the areas of astro-cycles and about his books.  Perhaps we learned the most just by watching a master trader make several successful trades during our two-day visit.

Larry Pesavento is the author of 7 books, a frequent contributor to the Market Mavens web site ( www.marketmavens.com ), and has privately trained more than 300 students.  Larry has been a broker for Drexal-Burnham-Lambert, is a former member of the C.M.E., and is currently a private trader for a large hedge fund.

Larry said the ‘Holy Grail’ does not exist, but the closest thing to it can be found in astronomical phenomena.  The key planets to pay attention to are Mercury, Venus, Mars, and Jupiter.  He pays attention to aspectations of the planets and eclipses using an ephemeris.

The fascinating part of our visit was watching Larry day trade Nasdaq stocks, euro-currency, bonds, soybeans, and the S&P.  His approach was very effective and really quite simple.  He used 2 tools exclusively.  Larry said he has no interest in any of the standard studies such as moving averages, oscillators, Stochastic, or relative strength and does not use any studies.   I believe the reason for not using studies is that they lag behind the market action.

The tool he uses for picking price objectives is the Fibonacci Levels tool.  His afternoon homework to prepare for the next trading day is to mark hourly and daily bar charts with Fibonacci price levels, looking for key prices, and favorite patterns such as Gartley and butterfly patterns.  Multiple Fibonacci tools might be applied to a chart, and the keys prices are those where there is congestion of multiple levels at the same price.  The Fibonacci Levels used are 0.618, 0.786, 1.00, 1.272, and 1.618.  These 5 numbers are the 5 sacred numbers used by Larry.

The really fascinating 2^nd tool used by Larry is a proprietary analysis tool that tells him WHEN to place a trade.  This tools focuses on TIME.  Larry said that Time is the most important aspect of a chart.  Too many traders focus on Price, instead of Time, and that is why they are not as successful as they might be.  Larry had great confidence in his Time forecasts.  It clearly told him when to go long and when to go short.  Thus, he was not glued to the computer screen.  In fact, he was very relaxed when he traded and not obsessed with watching the computer charts.  We observed that Larry would know that the trade would be on until the Time for the next turn, and until that time arrived, he basically had nothing to do but wait.  And indeed he would wait.

Thus, Larry is armed with 2 effective tools: one for Price and one for Time.  When the market is trading at the juncture of these two tools, he would place a trade, which is a counter trade with the expectation that the market will reverse direction.  Larry trades at a price that is one of the Fibonacci Levels of a prior major move.  He always placed a reasonable stop at the time he made the trade.  Then he would basically count on the probabilities to be in his favor, that the market would reverse direction and his trade would work out.  If the trade did not work out, his loss would be small and manageable because of the stop loss.  The trading he did the first day of our visit had 5 winners and 2 losers, for a gain for the day of over ten thousand dollars.  Larry said a typical good day for his day trading would be up $20,000, and a really bad day would be to lose $50,000.  Of course his expectation is to have good days 3 times a week.

This is the method I observed that Larry used for his day trading.  He would watch for correlation in his Time forecast with market turns.  Call it harmony.  If the chart was showing good correlation, meaning actual turns are happening within 15 minutes of the forecast time for the turn and had the right direction going into the turn, then Larry would have confidence in the Time forecast and trade the chart.  If the correlation was ‘off’, the chart would be ignored.  So, the market has to be in sync or harmony with his Time forecasts on his 2-minute bar charts.

Then, when the market was at the TIME for a trend change, Larry would use the Fibonacci Levels tool with the 5 sacred numbers to see which level should be used for the price for his trade.  We observed for one S&P trade he made, the market was descending, but slightly above the 1.27 level.  It was time for the market to change, so he called his broker (he abhors electronic trading), placed an order to buy S&P at the 1.27 level price, and placed a stop a few points lower.  A few minutes later the S&P traded beyond his entry price by a few ticks, reversed, and then traded upward right on schedule exactly as expected.  I was very impressed to watch the master at work to correctly call both the time of the turn, and the price for the turn.  Then he basically turned his back to his computers and visited with us, quite relaxed about his trade.  The Time for the next turn was 35 minutes away, and thus this trade did not need further concern until 35 minutes had passed.  Possibly he would raise his stop to break even.  He demonstrated the greatest of confidence in his trade, and in his tools for picking the Time and the Price of the trade.

Larry uses the Ensign 6 program in 2002, an older DOS based program written by Ensign Software and very popular 10 years ago.  He also has the QCharts program, but that seemed to be secondary or used as a back up data feed.  (Note:  Larry has since switched to the Ensign Windows program.)  His Ensign screens showed one or two charts.  On the screen he would overlay a list of symbols showing the current price and net.  He did not use any studies and did not look for divergence.  While day trading he only looked at 2-minute bar charts.  His charts had his proprietary Time tool, and the Fibonacci Levels tool (typically just 1) that would be drawn when a price needed to be selected for the trade about to be made.  If the market was at the 0.618 level, that is the price that would be used.  He did not have any preconceived notion as to how much profit a trade needed to have when it was removed.  He traded based on knowing the Time for the next turn, and took what ever Fibonacci Level price the market was nearest WHEN it was the time for a trend change.  Sorry I keep harping on the issue of Time, but it definitely was the KEY to the method Larry uses for day-trading.

Now, a Fibonacci Levels tool is readily available in most charting software packages.  However, the timing tool Larry uses is proprietary and not available in any commercial software package.  Believe me......it is proprietary and his closely guarded secret.  Rather than leave everyone groping for a timing tool, permit me to suggest consideration of the following timing tools as possible substitutes. 

1)  Use the Fibonacci Ruler where the measurement is from trend low to trend low, and the extension percentages beyond the right side low are the sacred numbers of  0.618, 0.786, 1.00, 1.272, and 1.618.  This idea is discussed in the January 2000 Trading Tips newsletter.

2)  Use the End-of-Square in the Pyrapoint tool in Ensign Windows.   This is a powerful tool that suggests price levels and measures time.   Many of the market turns occur at End-of-Square.  The biggest disadvantage of using Pyrapoint is you will have excess End-of-Square boundaries.   More can be read about Pyrapoint in the January 2001 Trading Tips newsletter.

3)  Use Gann Fans placed on significant trend lows and highs and watch the intersection of fan lines with each other and with the horizontals from the trend lows and trend highs.  This timing technique was discussed in the July 2000 Trading Tips newsletter.

4)  Use cycles to find repetitive patterns.  Read more about cycles in these Trading Tips newsletters:

February 2000   'Cycle Calendar'
December 2000  'Cycles Tool'
February 2001  'Moon Phases'

This chart illustrates the process of using the Fibonacci Levels tool in conjunction with a timing tool (cycles in the example).   The cycles tool shows a pattern of an opening low and a mid-day low.   The conjunction of the timing tool with the Fibonacci levels tools would give a Buy at the 127% price of 9.45 at 12 o'clock on May 30th.  This is not one of Larry's trades because Larry does not follow any stock under $20 and does not use the cycles tool for his timing.  The example was hand picked with the benefit of hindsight to illustrate the principles being taught.

Now, is Larry's timing based on any of the above?  The answer is no, it is not.  His timing tool is mathematical and examines past data for repetitive behavior.  Sorry the suggestions listed above will not be as effective as Larry's timing tool.  I wish I had his tool.  I would use it if I had it because I think his tool gives him a competitive advantage and puts the probability of a winning trade in his favor.  It truly was a pleasure to watch a master trader at work:  comfortable, confident, and very successful.

Larry has a web site, managed by one of his students. The web site address is www.tradingtutor.com.  To learn more about Larry Pesavento, please visit his web site and check out the services that are available there.

Sacred Numbers
Where do the sacred numbers come from?    All are related to the Fibonacci number sequence as follows.

• 0.618 is the Fibonacci sequence ratio.  Example  55 / 89 = 0.618

• 0.786 is the square root of 0.618.

• 1.00 is 100 percent of the measured distance.

• 1.272 is the square root of 1.618.

• 1.618 is the inverse of 0.618.

Analysis:

Part II

The First Trading Day of November, on a Monday is POSITIVE 75% of the time.  And, what's interesting about these is, that 5 of the 8 times this occurred, the HIGH of the DAY was after 3:00 pm.  Here's a couple to whet your appetite.

Tip:  So as you can see from just these small pieces of research, HISTORICAL ANALYSIS, can be very interesting.

There are so many things you can do.

December Expiration Weeks have closed POSITIVE 70% of the time.  So do October.

I've recently been doing some studies on the DOW.  It's really weird.  I decided to take a look at some market crashes, so I could run some sort of comparison to the 9/11 crash.  I found that the chart was ghostly similar to 1929.

Let's take a look.  Here is the current Dow chart.

The September 2001 Crash/Bottom is "in place".  OK. Now let's look at 1929.

Some similarities.  Enough to pay attention.  Enough to make someone want to see what's next.  Here is what followed.

Yes.  One of the biggest BEAR markets in history!

Hmmm. How about we take a look at Pearl Harbor, a similar tragic event in U.S. History.  If history serves me correct, that was December, 1941.  Let's take a look.

So, the Attack on Pearl Harbor was in December, and the Dow "bottomed" a few months later.  Ok. I guess we would want to see what happens next.  That sounds like a good idea.

WOW.  Looks like one of the biggest BULL markets in history.

Which do we have, if any, I do not know.  But I do know that I have these charts printed out, along with some other ones, and I'll be paying very close attention to them!

Customer Feedback:

"Dom's program is fantastic.  I am able to call up charts from any date in history and analyze them for patterns that help me in my trading.  There are several time frames available, to accommodate for different trading styles.  The settings are also customizable, and Dom is always happy to answer questions via telephone or email.  For serious traders, Vista Charts is indispensable."  -db

"Vista Charts has helped me get my chart history together.  It is easy to use and extremely flexible.  It creates clear, concise, easy to read charts.  Once I set the parameters, I could print off the charts faster than my printer could go (I have an HP4050N).  For example to print 5 minute charts, I set the scroll function to 81 bars, so I could go to the day before/after with one keystroke.  I could adjust each chart on the fly as they were printing, changing the scaling as well as the horizontal positioning of the bars.  This program made easy work of getting my chart history together."  -jg

Dom's web site:  www.vistacharts.com

Part III

In the prior two parts of this series, I covered some basic concepts about ESPL, then discussed many of the programming features present in ESPL.  This segment will examine memory storage issues, and then I have a long wish list of features I’d like to see added to ESPL.

Information in any computer program needs to be stored in memory, so what’s the big deal?  There are two issues:

• to what instances is the data available;
• at point in time does the data cease to exist (referred to as persistence); and
• to what part of the program is the data available (referred to as scope).

Before addressing these issues, we need to remember how Ensign Windows uses our ESPL code.  Referring back to the first article in this series, our ESPL code is invoked from Ensign Windows on each occurrence of the related event.  That is, an ESPL study is called for each new price tick (or at the close of each price bar, if so configured).  For timer related ESPL, the code is called each time the configured time expires.  For keyboard related code, it is called when the related keystroke is hit.  Also remember that for studies, color bar studies and drawing tools, there is a separate instance of the ESPL program, for each study that is applied to a chart.

Since there may be many instances of our ESPL study, active at a given time, there might be data that we want to exist and be available to all instances of the study, and across invocations.  That is, if we set a value in one invocation of one instance of the study, and we want that value to be available to another instance (obviously in another invocation), then we can use ESPL global data.  This data is declared in the var block of the outer most var-begin-end block of code.

This next memory mode is the most important one, to me.  I frequently use data that I want available only to the current instance of the study, and I want it to exist across invocations.  The idea here is that each instance of a study will have it’s own set of data.  The data in one instance is not to be shared with other instances.  However on each invocation of an instance (i.e. each tick or closed bar), I need the values that were set on the prior invocation to be in tact, just as I left them, at the end of the prior invocation.

If you are just learning the ESPL language, you might think that ESPL does not provide for such an important memory mode.  Then you take a closer look at the documentation for the SetUser() method.  Here you see that Ensign provides six arrays of data, for every instance of a study.  Note that the elements in these arrays are of type real, so they can only hold numbers.  Boolean, String and other data types can not be stored in these arrays.  I should point out that I am discussing details about the new version Ensign (aka Super Ensign).  The older version has similar characteristics with some differences.  Of the six arrays, the first four are available to display lines (and/or markers) on the chart.  These arrays are dimensioned from 1, to the configured maximum number of bars for the chart. The fifth array is dimensioned the same.  The sixth array is dimensioned from 1 to 50.

Since only the first four arrays are used to display lines on the chart, what are the fifth & sixth arrays used for?  You guessed it, they are available for Private Persistent data.  Any value stored in these arrays will be private to the study instance that owns the array.  In addition, those values will be saved and remain available on each invocation of that instance.

To be complete about it, Super Ensign allows for the storage of 3 Private Persistent String data elements, with the SetUser() built-in function.  This is a very welcome addition to Super Ensign.

Next, consider the data that we want accessible to all methods (generic term for procedures and functions).  It does not need to exist across invocations, nor do we want its content shared with other instances of the study.  Since we don’t care what happens to the data when we leave the current invocation, then this type of data can be implemented with global data (outer most var section) also.  However, it is imperative that at the start of our code, for each invocation, we initialize the data, since we have no idea what might be left there from some prior invocation or from some other instance.

The final memory mode supported by ESPL is local memory.  This is memory that is declared inside of a procedure or function.  It is only accessible from inside that method, and it ceases to exist when execution leaves the method.  This type of memory is frequently called automatic, since it automatically ceases to exist upon leaving the method.  These data items are declared in the var section of each method that requires them.  It is important to note that upon entry to a method, these data items have an undefined content; and so it is again imperative that your code initialize their content.

I have used three characteristics to describe these memory modes: Instance private or global, Persistent or not, and Method global or local.  With three characteristics, there should be 8 different possibilities; yet I have only discussed four.  What about the rest?  Most of them make no sense; however there is one that I should mention.  Most programming languages allow for the dynamic (at run time) allocation of data.  This data would be private to the instance that allocated it.  The data is persistent, in that it survives across invocations; and yet it’s access is local to the code that knows where to find it.  This last characteristic implies that we need another data item, that holds the location of the dynamically allocated data.  This location holder is called a pointer.  The pointer can be stored using any of the data modes already discussed.  Problems arise when the pointer ceases to exist and we have not de-allocated the dynamically allocated memory.  I should mention that there are ways to deal with that problem, such as is done in the Java programming language, where no explicit de-allocation is required.  ESPL does not support this memory mode.

(Editor's Comment:  Any number of real arrays can be created by declaring variables of type TArray.   Any number of string arrays can be created by using the powerful TStringList data type.   ESPL manages one global TStringList variable called sList that is global and freed by Ensign upon program termination.)

If we were talking about some other product, writing and distributing a wish list would most likely be a waste of time.  But we are talking about Ensign Windows and Howard Arrington.  Ensign (especially Super Ensign) is so full of wonderful features, but the number one thing, in my mind, that puts it way ahead of the rest, is the fantastic support provided by Howard, Kimball Hansen, Sheldon Lamont and Mike Lamont.  As for new features, and wish lists, we need to realize that Howard and team, only have two hands, and 24 hours each day.  Yet, when there is a problem, or a significant number of requests for a feature, then amazingly it’s in the next release, which you can download the next or following day.

Operating Environment

Multiple Code Files – As was discussed in the first article in this series, Ensign works with at most one ESPL code file, at a time.  Thus if you have three ESPL studies that you like to use, you need to put them all into one ESPL file (or at least, reference other code files with the Include statement, from one master file).  If you have your three studies, and you are not constantly added and changing them, then this system would work for you.  On the other hand, if you play around with 10 or 20 studies, color bar studies, drawing tools, and timer or keyboard related code, then this mode of doing things becomes very cumbersome.  I would like to see Ensign use multiple code files.  I would like to put one study into its own file.  Then tell Ensign to apply that file to the current chart. I could add as many ESPL studies to the chart as I wish, each in their own file.  The same ESPL study/file could be added to multiple charts as well.  To maintain the ability to have related studies together in one file, I would keep the concept of the ESPL (aka Who) value.  This value would be unique within each ESPL file, but does not need to be unique across ESPL files.

More Advanced User Study Parameters – The primary method of passing configuration information to a running ESPL study, from Ensign, is through the three parameter fields in the properties window for the ESPL study.  This is somewhat limiting in that:

• there are only three parameters,
• the parameters must be numeric, and   
• the names of the parameters can not be set by the ESPL code.

(Editor's Comment:  The Grid Line control could be used to pass 19 Boolean check box states.  The draw line color boxes can be used to pass color parameters.)

I would like to see a mechanism where the ESPL code could tell Ensign the quantity, identity (names) and type of the parameters to be shown in the study’s properties window.  This could be done either through a special section in the source code file, that is read by Ensign (statically, not at run time); or it could be done through methods that the ESPL calls at run time.

A True Debugger – When testing and debugging ESPL, the only debug tool available is the writeln() method.  This method writes values to the output window of the ESPL editor.  I would like to see a full featured debugger, with:

• break points,
• source level statement stepping,
• execution continuation,
• variable viewing (click on a variable name to see its value, or a watch window), and
• variable setting (ability to change the value of a variable, during execution).

(Editor's Comment:  A variable watch window is available, but it is of limited use because of the lack of break point capability.)

In all honesty, I have no idea if any of this is even possible, with the way Ensign is written; but remember, this is a wish list.

Return Statement – as I mentioned in the prior article in this series, the lack of this statement leads to an excessive use of either if-then-else statements, or goto statements.  In conjunction, I would like to see the built-in variable Result replaced with the use of a parameter to a return statement.

Break and Continue Statements – these statements provide the ability to leave a looping statement (such as while, until or for), or to go to the top of the loop without completing the current pass through the loop’s body.  These statements are common in many conventional programming languages.  I classify them as convenience statements.

Forward Referencing – ESPL only allows backward referencing.  This means that any reference to a procedure or function must occur after that procedure or function has been declared.  As a result, when programming with a standard top-down approach, the top level methods must be placed at the end of the file.  In addition, extreme care must be given to the order in which methods are declared in the file.  Most significantly, multiple method recursions (A calls B, and B calls A) becomes impossible.  I would like to see forward referencing allowed, which would alleviate the three problems mentioned here.

Structures – I would like to see the ability to declare complex data types, such as structures.  A structures is a grouping of other data types (such as some integers, some reals, some Booleans, etc.) into one group, so that the group can be referenced as a whole.

Arrays of Data Types – Ensign currently does provide for arrays of reals.  However these arrays are created with special built-in methods, rather than with data declaration.  The use of methods is nice, since it allows the dimensioning of the array to be determined at run time.  So I would like to see the current method retained.  In addition, I would like to see the ability to declare arrays of any data type, including arrays of structures and arrays of arrays.

Classes and User Defined Objects – Many conventional programming languages today use a style of programming called "object oriented".  Examples of such languages are C++ and Java.  A class is similar to a structure, in that, it is a grouping of simpler elements; however a class also allows the defining of methods within the context of the class.  Objects are instances of a class.  Typically, objects are instantiated (allocated) at run time, and the methods know which object to operate on, by referencing the object and method together.

Pointers and References – a pointer is a data variable that provides a reference (i.e. an address) to some other variable.  Pointers are essential when using dynamic memory allocation (discussed above, under Memory Modes).  Pointers can also be used to reference statically declared data.

Preprocessor Macros – preprocessor macros allow the ESPL software developer to declare names for constant values that will be used in the code.  An example might be

This declares the name MacdValue to be replace by the constant integer 1 whenever that name appears in the code.  This happens before the code is compiled. The name is not a variable, and thus takes up no space in the running program.  There is also no execution time spent, to obtain the value 1, since it was simply a constant, at the time the code was compiled.  The benefit of preprocessor macros is that the code is easier to read and debug, since constant values can be replaced with meaningful names.

Ability to download extensive historical data – when back-testing a programmed trading system, the more data it is tested with, the more reliable the system. Related to this, is the feature to be able to build charts of any timeframe, from downloaded data.  Currently Ensign needs to download back data for each timeframe chart used.

(Editor's Comment:  The File | File Manager | Merge tool can be used to build any time frame that is a multiple of a lower time frame data set that is present.  Up to 60 days of intra-day data and 10 years of daily data can be downloaded from the eSignal servers, or by using the Internet Services download tool.  Ensign data files can store up to 65,535 bars.) 

More Built-in Reporting and Support for Back-Testing of Systems – The current reporting mechanism for back-testing is the Trading Details report.  This report is wonderful.  It reports trades taken by the ESPL program, number of winners & losers, each trade’s profit/loss, a running balance, and more.  Other analysis would be useful. Such as daily and weekly trade results, maximum run up and maximum draw down.  Trade results for different times of the day would also be of interest.

Built-in Support for Optimization – Optimization is the process of fine tuning a trading system, to produce the best results.  This could be done by having Ensign vary the values of parameters to an ESPL trading system, over defined ranges, and by a defined step sizes.  For each value, the trading system would be run, and the trading results captured.  A specific value in the trading results would be specified to be the one compared for best results.  When the system had been run for each of the parameter settings, an optimization report would show the trading results for each setting, and those settings that produced the best results.

I am aware that the above wish list is not only lengthy, but it would seem that I am asking for the world on a silver platter.  I know. But isn’t that what a wish list is for?  Do not get me wrong, as I mentioned at the start of this series of articles, ESPL is the best charting system programming language I have seen.  Yet even the best, can be better.

I hope that through these articles I have provided some insight into why I feel ESPL is so wonderful.  I also hope that I have provided a hint or two, of things you might want to do with ESPL. I thank you for reading, and I thank Howard for giving me this opportunity to express my views.

Happy coding.

(Editor's Comment:  Mr. Levin is a capable programmer and available for hire to work on your ESPL programming projects.  Contact him by e-mail at plevin1@tampabay.rr.com)