CrossOver/CrossUnder v3 vs. v5
Author: dansmo
Creation Date: 3/3/2010 8:02 AM
profile picture

dansmo

#1
Hello,

is there a difference between crossUnder/crossOver between WLD4 and WLD5?
It seems to me that in WLD5 the condition is >= and <= compared to > and < in WLD3. Is this correct?
profile picture

Eugene

#2
To quote the WL4 QuickRef:
QUOTE:
Specifically, CrossOver triggers (true) if both of the following conditions are true:

@Series1[Bar] > @Series2[Bar], AND,
@Series1[Bar - 1] <= @Series2[Bar - 1]

profile picture

dansmo

#3
Okay, I found the difference.
In WLD3 I used CrossOverValue/CrossUnderValue where the conditions are sligthly different then with CrossUnder/CrossOver in WLD5.
How can I replicate the CrossOverValue/CrossUnderValue from v3?
profile picture

dansmo

#4
Maybe you can provide source of CrossUnder/CrossOver and I will modify to get CrossUnderValue/CrossOverValue and add to components?
profile picture

Eugene

#5
As a general rule for any similar queries, Fidelity doesn't provide the application's source code.

As you can see from the QuickRef, no difference exists between the V4 and V5 implementations. I'm sure because it was thoroughly tested back in 2007. Since CrossUnderValue/CrossOverValue calculations are working as expected and as per the documentation, what is the reason to add something to Components?

profile picture

dansmo

#6
As I understand it, there is no CrossOverValue/CrossUnderValue method in WLD5!
profile picture

dansmo

#7
I need this in WLD5:

QUOTE:
CrossOverValue
RChartScripts RSimuScripts RPerfScripts XCMScripts

Description

Returns true when the Price Series crosses above the specified Value.

Specifically, CrossOver triggers (true) if both of the following conditions are true:

CODE:
Please log in to see this code.
profile picture

Eugene

#8
QUOTE:
As I understand it, there is no CrossOverValue/CrossUnderValue method in WLD5!

Would you mind taking another look in the QuickRef? Specifically, at an overloaded call that both CrossOverValue and CrossUnderValue have?

Sounds like you might like to review some C# resources:

Operator Overloading in C#
Method Overloading
profile picture

dansmo

#9
Do you mean?
CODE:
Please log in to see this code.


Like you said yourself in 3/3/2010 8:13 AM :

CODE:
Please log in to see this code.


But this is different to WLD3 method CrossOverValue:

CODE:
Please log in to see this code.


Do you now see the difference?
profile picture

Eugene

#10
What kind of difference?

Version 4's CrossOverValue:
QUOTE:
@Series[Bar] > Value, AND,
@Series[Bar - 1] <= Value


Version 5:
QUOTE:
Specifically, CrossOver returns true if the current value is above the target value at the specified bar, and the previous value was less than or equal to the target value at the previous bar.


Nonetheless, you can easily program your in-house definitions to use in your Strategies - takes a line of code or two.
profile picture

Cone

#11
dansmo, we understand the difference, but we're not effectively communicating how that difference is handled in WL5.

In WL5, the CrossOver/Under methods have an overloaded parameter. If the third parameter is a DataSeries, then the function is treated like CrossOver/UnderSeries.

Likewise if the third parameter is a number (double), then the function is treated like CrossOver/UnderValue.

Understand? (If not, maybe I don't understand the question!)
profile picture

dansmo

#12
Yes, I understand this.

Do you understand which difference I mean and why it is necessary for me to have the same results as I have in WLD3´s CrossOverValue?
profile picture

Eugene

#13
As said above, you can easily program your in-house definitions to use in your Strategies - takes a line of code or two.
profile picture

dansmo

#14
Yes, I will do that.
profile picture

Cone

#15
Eugene's definitions at 9:55 are precisely the same.

Are you seeing a difference somewhere? Floating Point equality is essentially non-existent unless you take measures to force less precision.
profile picture

dansmo

#16
This difference is driving me mad....

I will try to sum things up in this post. Maybe this helps.

In WLD3 I use the following rule:

CODE:
Please log in to see this code.


In WLD5 I use the following rule:

CODE:
Please log in to see this code.

where crossUnderValue is defined as
CODE:
Please log in to see this code.


Now, here is the Series, in WLD3 vs WLD5:

bar-1: -3,3300 | -3,33
bar :-30,0000 | -30,00

In WLD3 I get the short trade at bar + 1. In WLD5 I dont get the trades, so: where is my mistake?


profile picture

Eugene

#17
if(Series[bar] < value, or "if spreadSeries[bar] < -30". How could -30 be less than -30 ???
profile picture

dansmo

#18
Thats logical. But why then is there a trade in v3?
When I change it from < to <= I get this trade, but then there are other trades appearing that should not appear.
profile picture

Cone

#19
I can certainly sympathize that a limit order doesn't take a trade when it should, but on the subject of floating point equality, how could anyone care that a calculated series precisely equals -30? If there's a problem, it should be more apparent in Version 4 since you're comparing a single precision number (a Price Series) with a double precision number, the literal -30.

In Version 5, at least DataSeries are calculated with double precision, but that does not solve the problem of floating point equality. We're talking about the difference between 0.00000000000001 and 0.

Edit: On the other hand, if your Price Series is made up of integers, then you can be precise. But in that case, you should be using a synchronized integer array and come up with your own comparison functions.
profile picture

dansmo

#20
I am so niggling because I´d like to replicate v3 trades exactly.
So, I understand that it is almost impossible to do that because of different precision?
profile picture

Cone

#21
There was a case for a SAC article in which I was trying to get precisely the same trades as the author, who I think used MetaStock at that time. We ending up finding a case dealing with precision and floating point equality that produced different results depending on the order that data were summed together.

By the commutative and associative properties of addition, you'd think that you'd arrive at the same result no matter which order you sum numbers - but don't count on it with floating point arithmetic on a computer! In reality, as far as we could tell the same "sum" was shown in double precision, but the equality test failed for one sum and not the other.

In general, I think you should be able to duplicate results, but there will be isolated cases that I'd expect to present challenges.
profile picture

dansmo

#22
Good news:
CrossOverValue gives identical trades now, I modified it this way in v5:
CODE:
Please log in to see this code.


So, the value + 0.000001 thing will give me the same trades as in v3.

Bad news:
I was not able to do the same trick for my CrossUnderValue trades.
CODE:
Please log in to see this code.


Any more ideas what trick could be necessary to overcome this difference?
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).