The relationship between high(), low(), and close()

[arbifox]

This is just an FYI to all out there, maybe it will help some . . .

I have been testing a couple of programs, and I am always trying to minimize the differences between live and backtested results, and I have gotten my results to match fairly well.

The one thing that I might do is that in a backtested portion of my code, if I am looking to get out on a stop, I will test the high() or the low() of the bar to see if the value is higher/lower than my respective stop.

However, once the EFS is processing live data, I test only the close(), thinking that at one point the close() has to equal the high() or the low() if you are watching every single tick pass. Meaning, that for a 3 minute bar, I thought the close() at one point would equal the high() or the low().

I can not tell you how many times I have seen the high() get changed and the close() was never set to the value of the high(). The same is true with the low(). What this means is that if your stop is missed in this manner, I would get a sell in backtest since I test the high(), but not have a sell if the EFS is running live since the close() is never set to the specific value of the high() which also happens to be the stop.

I am not sure I explained this well enough, but if anyone ever has any questions, just reply to this and I can try to explain better.

Thomas

[eSignal_JasonK]

Hello Thomas,

What you are describing doesn't sound right to me. I haven't experienced this behavior. Try the code example below as a test. You should see many instances where close() is the same price as high(). Perhaps I'm just misunderstanding what you're describing. Can you put together a sample script that can better demonstrate the problem you're having?

function preMain() {
    setPriceStudy(true);
    setStudyTitle("test");
    setShowCursorLabel(false);
    
}

function main() {   
    if (close() == high()) {
        debugPrintln("close: " + close() + "  high: " + high())
    }
    return;
} 

[arbifox]

Try using ES #F

I am experiencing this on a 3-minute bar, with the ES #F. I have a few instances recorded where this is true, but I will try to trap for the exact case. I will try to whip up a script, but just try it out on the E-Mini.

T

[eSignal_JasonK]

Hello Thomas,

FYI, As far as I can tell, when a trade occurs that equals or exceeds the high of the bar, close() and high() are returning the same price at that instance.

[arbifox]

thanks for checking this out . . .

Jason,

I am not sure why, but it does happen. I do have a pretty chunky EFS, so is it possible that a particular "tick" can be skipped if there is too much going on at once? If the EFS is very robust, is it possible that I can miss a few ticks?

Thanks for your help though . . .

Thomas.

Thomas,

You may consider timing your efs and documenting the time it takes to cycle when the ticks are coming in. I'm not quite sure how you could diagnose if you had missed any ticks in real time, however, perform a tick download and perform the test in tick playback mode.

Write a small efs with the timer and a tick counter. You will have to use the time object versus bar time. Run the small efs for a while, either using debugPrintln or outputting close(), time and # of ticks to a file. Save the information.

Put similar steps in your large efs and re-start the playback file. Save the information and compare the information with the small efs results in excel or some other program where you can view the info side by side.

[eSignal_JasonK]

Hello Thomas,

That could be a possibility. The solution for you may be to check the high and close in your conditions. This way, if a tick was skipped for some reason and the tick that was skipped created a new high, your condition should still be met.

if (high() >= vPrice || close() >= vPrice) {
// your code
}

[arbifox]

Jason,

Your last post is exactly what I am doing for now, Steve . . . yours will take a bit more doing, but I see the point. Thanks a million guys, I appreciate your help in this.

The one thing I can tell you, I am very very impressed with the application as a whole, the entire EFS - DO - IB TWS, probably one of the smoothest three tier application set-ups I have seen. I am coming from envirnments with application servers, database servers, load balancers, so I am used to much larger headaches.

Thnaks again,

Thomas

[xygeek]

There's a chart posted further down in the thread with a formula output window showing prices with excessive decimals. I see this occasionally in my own work and hope someone can explain it. If possible I'd like to be able to avoid this.

http://share.esignal.com/ContentRoot...ehigh_0220.png

[ACM]

xygeek
One way is to use formatPriceNumber(value) which will return a value in the same format as the symbol displayed in the chart.
Alex

[xygeek]

Thanks Alex, that's one I wasn't aware of. I had been using .toFixed() to cover it up until it became important to me to figure out what was causing it. So far it remains unpredictable and I should have spent more time composing that post because I left out my major concern. If I can't predict high() after it's occurred then how can I trust my calculations further down the page from there? For instance when using this stop entry:

if(high() > 97.63) then buy;

It seems possible that unpredictable odd decimal can skew back tests and trigger erroneous real time entries. Or is there something I'm missing that can clarify this?

Btw, I wanted to thank you for all the code and charts you post.

Regards,

xygeek

[ACM]

xygeek
First of all my pleasure.
In response to your question I think it may be best for someone from eSignal to clarify the issue. In the mean time though when defining a specific value I would probably suggest using formatPriceNumber() to ensure that it meets the format and resolution you have set in your charts and conditions.
Alex

[xygeek]

Will someone from eSignal please acknowledge something is being done about this? The code below simply stores high() in a var named h, yet when it's returned to the formula output window or written to a file it produces obvious errors. Try it on a 1 minute MSFT chart.

var bi=null;
var h=null;
var init=null;

var f1=new File("test.txt");

function preMain() {

setComputeOnClose(true);

debugClear();
}

function main(){

bi=getCurrentBarIndex();

h=high();

debugPrintln(" bi= " +bi+ " h= "+h);


if(bi== getOldestBarIndex()) f1.open("wt");

f1.writeln(" bi= " +bi+ " h= " +h);

if(bi == -1) {f1.flush(); f1.close();}

return h;
}

[Doji3333]

why don't you try this..

try this... use the ".toFixed(2)" function to force a runcation of the code.

var bi=null; 
var h=null; 
var init=null;

var f1=new File("test.txt");

function preMain() {

setComputeOnClose(true);

debugClear();
}

function main(){

bi=getCurrentBarIndex();

h=high().toFixed(2)*1;

debugPrintln(" bi= " +bi+ " h= "+h);


if(bi== getOldestBarIndex()) f1.open("wt");

f1.writeln(" bi= " +bi+ " h= " +h);

if(bi == -1) {f1.flush(); f1.close();}

return h;
}