Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I'm looking for some suggestions or advice for building a divergence indicator for oscillators such as the 3/10 oscillator. The idea is to have two functions. One is to alert a warning signal on every bar when a divergence is forming - so if the oscillator has a lower high, the moment price makes a higher high, the signal begins and prints until either the divergence is gone (the oscillator catches up and also makes a higher high) or the entry signal appears. The entry signal is the slope of the oscillator reversing. Thanks!
Can you help answer these questions from other members on NexusFi?
There are two filled orders in the example shown in image - order 1 is the first filled, and order 2 is the second filled, each has its own attached stop order as shown.
Currently if stop 2 is hit, then order 1 exits and order two remains with the big stop of order 1 --
Is there a way to exit the nearest order 1 when hitting its stop ...?
These orders should be attached orders and not sure they work to stop other orders -- in this case, stop 2 is used to exit order 1 though it is attached to order 2 ?
I need to understand the logic of Sierra handling multi orders with their own attached stop or limits --- simply is there a way to exit the nearest if any stop is filled ?
What is the best code practice for the following scenario:
1- The white line is used as a trigger for switch long or short in this case.
2- If closed above the line , then we are long
3- We save the price level corresponding to the white line while the break point ..
4- If price closed below that level, then it is switching to short...
Since we will save versus each call of the trading system, I think persistent variables can be used.
What can be the best code practice in this case ? I am not an expert with persistent variables and tried several times but with no luck -- can u provide a code snippet that I can use an example to code the above scenario ?
Far quicker to supply what you have already coded to see where you went wrong than a dump of 1 to 2 lines of code. Which will start multiple back and forth questions.
Thanks a lot for your response.
I have added the persistent variables to hold the price level at a break of the high or the low to retain their values between function calls with each new bar
Then I have added this main code to decide long or short and it seems to be working for now
The new issue might be related to the floating point imprecision as when there is a bar that has <close =low > or <close ==high> the code doesn't recognize the event like in the bar circled in the image ..
Also how to let the code know the initial condition long or short , once we activate the trading system on the chart -- does it make backward calculations on all the bars in the chart to determine the initial condition ? or we need to add an input and the user can define the initial long or short status ?
Long or short here is a status that is then used to let the algo enters orders ..
What are all these? And what are you trying to achieve with them?
Also are you sure they are doing what you expect? I'm guessing they are SCInputRef variables and you want them to act as persistent bool variables? If they are I've never seen SCInputRef used like that.... not to say they don't work but,
You should use PersistentInt and set them to 0 or 1
L, S, x, y are boolean inputref that are used to make transitions between long and short based on the <if> conditions.
SCInputRef L = sc.Input[12];
SCInputRef S = sc.Input[13];
SCInputRef x = sc.Input[14];
SCInputRef y = sc.Input[15];
I am noting a new issue that is non-related to persistent variables --It is as explained in the chart image and it is related to floating point imprecision. This is handled in Spreadsheet by rounding to the ticksize -- simply if there is a bar that has the low equals the close or the high equals to the close, the code starts not to work for the break condition.
The new issue might be related to the floating point imprecision as when there is a bar that has <close =low > or <close ==high> the code doesn't recognize the event like in the bar circled in the image ..
You can use the sc.FormattedEvaluate() function to do the comparisons without floating point imprecision.
Is there any setup for the entire code to avoid this problem - The issue should be well known - or this will need to change every comparison of the price crossing or breaking a line using that complex function ?
L, S, x, y are boolean inputref that are used to make transitions between long and short based on the <if> conditions.
SCInputRef L = sc.Input[12];
SCInputRef S = sc.Input[13];
SCInputRef x = sc.Input[14];
SCInputRef y = sc.Input[15];
They are not meant to be used like that. In the thousands of lines of code by SC I've never seen them use the SCInputRef as a variable. You should be using persistent int.
mosalem2003
Is there any setup for the entire code to avoid this problem - The issue should be well known - or this will need to change every comparison of the price crossing or breaking a line using that complex function ?
The issue is well known that's why there is this solution.
This,