Example of PaperTrade Broker bug !

[TraderJO]

I was just able to document an anomaly in the Paper Trader that I've experienced before. The attached screen shot shows the Trade History tab...note the P/L column for a break even trade. This is also displayed in the Unrealized P/L of the Summary tab for an open trade when current price = entry price.

This does not happen all the time, which is the frustrating thing. Today my stop had trailed down to B.E., and this began to happen, and my script generated the following error> Line:577, Paper Trade Broker must have Stop/Limit price...

Here are lines 576 - 577 of my system's script...

576: nAsk = getMostRecentAsk();
577: if ((vPaperTrade == 1) && (nBarIndex == 0)) vPTrade.Buy(getSymbol(), StopExitContracts, PaperTradeBroker.LIMIT, nAsk);

The first trade of the day worked it's way through this block of code with no problen at all, and then....BAM!! Gotcha! Perhaps someone at eSignal has some explanation for this? I doubt I'm the only one experiencing these quirks. TIA for any help.
___
JO

[TraderJO]

Oops...didn't seem to attach the screen shot properly. I'll try again
___
JO

[Doji3333]

possible solution...

this is an "exponential number" - meaning....

this number is so small that is virtually represents ZERO.

Exponential numbers are controlled by the "-" or "+" near the end of it. in this case, the 2.2???-NN means that this number is actually something like....

0.000000000000022???

And it probably due to a rounding issue within esignal. I doubt very highly that you could get a positive number to skew your paper trading results. The only reason you would have a "+NN" number is if it was REALLY HUGE - like "trillions" in profits.

Hope this helps.

B

[TraderJO]

And an example of entry pricing error..

Wow...am I lucky. I just managed to get an example of the entry pricing error I mentioned in my recent Tick Replay thread. A trade was just entered LONG @ 1189.00 (1189.50 ask?) and the Paper Broker shows and entry price of 1179.50. Don't I wish; an instant 30 points on a 3 lot!

I've also seen this before. It happens using MARKET orders, and LIMIT orders with a specific price specified. The attached chart shows the trade entry, and two profit objectives being hit and filled. The price for the objectives was calculated correctly, even though the entry price is ten points off. Of course the P&L is all screwed up as a result of this wierd entry price.
___
JO

[TraderJO]

Here's the fill that the Paper Broker gave me....
___
JO

[Doji3333]

looks to me...

that you have some errors in your code...

I understand you are reporting this as a potential BUG, but I can't see that as the problem. I would think your code is passing the price parameters to the Paper Trader module - thus your system is pushing the bugs into the Paper Trader module.

I have quite a bit of experience with the Paper Trader module and would expect it to "do exactly what you tell it to do". Plus, I have not experienced these types of problems before. That does not mean there is NOT a problem I don't know about - but I would strongly suggest going thru your code and adding DEBUG lines to it just before each trading action. This way, you can verify the values that you are passing to the paper trader module.

Again, I could be wrong, but I suspect your code is the culpret - not the paper trader module..

Best regards,

Brad

[TraderJO]

Thanks for the reply Brad. I'm aware that this result is an exponential number. The question remains, why is it there? If you subtract 1079.50 from 1079.50 you should get ZERO, and not some "exponentially small" number. This is probably what caused the script to generate it's error as well. An internal eSignal problem I guess.

Also, this problem happens intermittently. It even happens if you place a trade manually with an order entry ticket. In this current situation; placing the order with efs; the error can happen with a MARKET order or a LIMIT order with the price explicitly specified! Therefore....the paper trader does NOT "do exactly what you tell it to do". Sorry, but I write "bug free" code

Take care,
___
JO

[TraderJO]

or............

there could be an issue with the getMostRecentBid() or Ask functions. I'll try embedding this debug line in the following code block and see what happens tomorrow. Maybe these Bid/Ask calls get trashed internally some how and return sporadic results. If that's the case I'll have to code for bid or ask within +or- 2 ticks on either side of the last price, or something like that, eh?


if ((nsignal < 0)) {
//Enter new position
nBid = getMostRecentBid();
nTradeEntryPrice = nBid;
debugPrintln("Trade Entry Price = " + nTradeEntryPrice);
if (nBarIndex != 0) nTradeEntryPrice = open(); //Looking at historical data
if ((vPaperTrade == 1) && (nBarIndex == 0)) vPTrade.Sell(getSymbol(), 0 - DefEntryContracts, PaperTradeBroker.LIMIT, nBid);
drawShapeRelative(0, high() +.25, Shape.DOWNTRIANGLE, null, Color.maroon, Shape.ONTOP, getValue("rawtime") + "S");
Alert.playSound("ChimeDown.wav");
Strategy.doShort("Go Short", Strategy.MARKET, Strategy.THISBAR, DefEntryContracts);
:
:
}

I guess we'll start making new discoveries after the opening bell tomorrow. I hope they're positive ones.
___
JO

[Doji3333]

My best guess...

Jo,

My best guess is that it is a ROUNDING issue within esignal. The only reason I suggested it was in your code was because we are all human and often have human faults.

If you have verified your code is "bug free", then this is an obvious issue for esignal to look into. But the question enters my mind as to "why does it happen sometimes and not others"... Generally, with computers there is a "cause and effect" (IMHO).

Thus, what is the cause and why does it happen sometimes with your and my code - possibly others?? Again, this is probably something that esignal is aware of, but to be safe, we should verify the issue is not originating within our code - you know "garbage in - garbage out"...

Best regards,

Brad

[Doji3333]

Good thinking Jo...

I have found that "I'm often to blame for the problems in my code"... and I'm not saying you are the cause of the problem, but often enough I find that "I am the problem with my code" - like others find (I'm sure).

The debug lines will quickly resolve IF your code is the issue or not.

Anyway, good thinking and if there is anything I can do to help, let me know.

B

[soylent]

Just something I've noticed:
When I'm running in 'replay' mode using the paper-broker, sometimes I get a wacky fill. (I use the buy/ask window that attaches to my screen).

I think I get a fill from the 'current' price of NQ instead of the "BAR REPLAY" price.

Anyhow, no scientific evidence, but I have resorted to hand-writing my entry/exits when manually testing a scenario...

-c

[Doji3333]

replay...

I'm pretty sure replay does not work with the paper trader module..

You should use the Backtesting functions (like Strategy.doLong() or Strategy.doShort()).

Papertrader is designed for realtime simulation.

B

[TraderJO]

Thanks for all the input guys...

Soylent - I've had similar experiences with tick replay as well. I tried implementing suggestions made by Gavishti; in my other thread regarding tick replay; and they didn't fix my problems. I think Brad is right about replay mode too. I think it's ok for testing out code logic, etc., but not for serious "simulated" paper trading at this point. It may get better though, so let's keep our fingers crossed.

Brad - while adding the debug lines to my code I figured I may as well plan for some contingincies that I'm sure will pop up, so I'm going to try out the following method of working around any wierd results I may get from calls to the getMostRecent...() functions. Can't wait for the market to open tomorrow now !


if ((nsignal < 0)) {
//Enter new SHORT position
nBid = getMostRecentBid();
if (nBarIndex == 0) debugPrintln(CurrentTime + ": SELL @ Current Bid => " + nBid);
if ((nBid > (close() + 0.50)) || (nBid < (close() - 0.50))) nBid = (open() - .25);
nTradeEntryPrice = nBid;
if ((nBarIndex != 0) || (nBid == 0)) nTradeEntryPrice = open(); //Looking at historical data OR a bad RecentBid
if ((vPaperTrade == 1) && (nBarIndex == 0)) vPTrade.Sell(getSymbol(), 0 - DefEntryContracts, PaperTradeBroker.LIMIT, nBid);
drawShapeRelative(0, high() +.25, Shape.DOWNTRIANGLE, null, Color.maroon, Shape.ONTOP, getValue("rawtime") + "S");
Alert.playSound("ChimeDown.wav");
Strategy.doShort("Go Short", Strategy.MARKET, Strategy.THISBAR, DefEntryContracts);
:
:
}


Also, while debugging my debug code this evening, I noticed that any quote window changes in the current Bid & Ask will not be picked up by the getMostRecent...() calls until a new trade registers in the tick stream. This was noticed during Globex night trading, so volume was very low. During RTH and with a fast market it'll be interesting to see what kind of results I get. This observation alone, could account for subtle slippage on trades with the paper trader during real time markets, but might actually give a more realistic feel. We'll see. It certainly doesn't account for the bizarre fills I've seen the last few days though. I'll keep you all posted on what I discover here.

Good night all,
___
JO

[Doji3333]

Hey Jo.. (Hendrix Flashback)

What did you find?? I would be interested in hearing your results.

B

[TraderJO]

Not good news...

Hey Brad,

oops...that doesn't remind me of any song

Anyway, what I'm finding out is interesting, but odd. First trade today filled by paper trader @1090 when I passed it a limit price of 1089.75 with the nBid variable. Then the stop was hit at 1094.25; a bid of 0 was returned by getMostRecentBid(); I set the bid to close()+.25 which should have then been 1094.50; the the papertrader filled the stop @ 1094. Very strange stuff. Here's a screen shot of the debug values and the paper fills. I'll have to add a debug print after I reassign the entry price variables so I can see what value was actually passed to the paper broker after I "fixed" the bad bid price.
___
JO