Breakouts with Tests & Retests [LuxAlgo]The Breakouts Tests & Retests indicator highlights tests and retests of levels constructed from detected swing points. A swing area of interest switches colors when a breakout occurs.
Users can control the sensitivity of the swing point detection and the width of the swing areas.
🔶 USAGE
When a Swing point is detected, an area of interest is drawn, colored green for a bullish swing and red when bearish.
A test is confirmed when the opening price is situated in the area of interest, and the closing price is above or below the area, depending on whether it is a bullish or bearish swing. Tests are highlighted with a solid-colored triangle.
A breakout is confirmed when the price closes in the opposite position, below or above the area, in which case the area will switch colors.
If the opening price is located within the area and the closing price closes outside the area, in the same direction as the breakout, this is considered a retest . Retests are highlighted with a hollow-colored triangle.
Note that tests/retests do not act on wicks. The main factor is that the opening price is in the area of interest, while the closing price is outside.
🔹 Area Of Interest Width
The user can adjust the width of the swing areas. Changing the " Width " is a fast and easy way to find different areas of interest.
A higher "Multiple" setting would return a wider area, allowing price to develop within it for a longer period of time and potentially provide later test signals.
When a swing area is broken, a higher "Width" setting can make it more complicated for the price to break it again, allowing a swing area to remain valid for a longer period of time thus potentially providing more retest signals.
🔶 DETAILS
Generally, only one bullish/bearish pattern can be active at a time. This means that no more than 1 bullish or bearish area will be active.
The " Display " settings, however, can help control how areas of different types are displayed.
Bullish AND Bearish: Both, bullish and bearish patterns can be drawn at the same time
Bullish OR Bearish: Only 1 bullish or 1 bearish pattern is drawn at a time
Bullish: Only bullish patterns
Bearish: Only bearish patterns
🔹 Test/Retest Labels
The user can adjust the settings so only the latest test/retest label is shown or set a minimum number of bars until the next test/retest can be drawn.
🔹 Maximum Bars
Users can set a limit of bars for when there is no test/retest in that period; the area of interest won't be updated anymore and will be available and ready for the next Swing.
An option for pulling the area back to the last retest is included.
🔶 SETTINGS
Display: Determines which swing areas are displayed by the indicator. See the "DETAILS" section for more information
Multiple: Adjusts the width of the areas of interest
Maximum Bars: Limit of bars for when there is no test/retest
Display Test/Retest Labels: Show all labels or just the last test/retest label associated with a swing area
Minimum Bars: Minimum bars required for a subsequent test/retest label are allowed to be displayed
Set Back To Last Retest: When after "Maximum Bars" no test/retest is found, place the right side of the area at the last test/retest
🔹 Swings
Left: x amount of wicks on the left of a potential Swing need to be higher/lower for a Swing to be confirmed.
Right: The number of wicks on the right of a potential swing needs to be higher/lower for a Swing to be confirmed.
🔹 Style
Bullish: color for test period (before a breakout) / retest period (after a breakout)
Bearish: color for test period (before a breakout) / retest period (after a breakout)
Label Size
Test
PineUnitPineUnit by Guardian667
A comprehensive testing framework for Pine Script on TradingView. Built with well-known testing paradigms like Assertions, Units and Suites. It offers the ability to log test results in TradingView's built-in Pine Protocol view, as well as displaying them in a compact table directly on your chart, ensuring your scripts are both robust and reliable.
Unit testing Pine Script indicators, libraries, and strategies becomes seamless, ensuring the precision and dependability of your TradingView scripts. Beyond standard function testing based on predefined input values, PineUnit supports series value testing. This means a test can run on every bar, taking into account its specific values. Moreover, you can specify the exact conditions under which a test should execute, allowing for series-based testing only on bars fitting a designated scenario.
Detailed Guide & Source Code
Quick Start
To get started swiftly with PineUnit, follow this minimalistic example.
import Guardian667/PineUnit/1 as PineUnit
var testSession = PineUnit.createTestSession()
var trueTest = testSession.createSimpleTest("True is always True")
trueTest.assertTrue(true)
testSession.report()
After running your script, you'll notice a table on your chart displaying the test results. For a detailed log output, you can also utilize the Pine Protocol view in TradingView.
--------------------------------------------------------------
T E S T S
--------------------------------------------------------------
Running Default Unit
Tests run: 1, Failures: 0, Not executed: 0, Skipped: 0
To further illustrate, let's introduce a test that's destined to fail:
var bullTest = testSession.createSeriesTest("It's allways Bull Market")
bullTest.assertTrue(close > open, "Uhoh... it's not always bullish")
After executing, the test results will reflect this intentional discrepancy:
--------------------------------------------------------------
T E S T S
--------------------------------------------------------------
Running Default Unit
Tests run: 2, Failures: 1, Not executed: 0, Skipped: 0 <<< FAILURE! - in
It's allways Bull Market
Uhoh... it's not always bullish ==> expected: , but was
This shows how PineUnit efficiently captures and reports discrepancies in test expectations.
It's important to recognise the difference between `createSimpleTest()` and `createSeriesTest()`. In contrast to a simple test, a series-based test is executed on each bar, making assertions on series values.
License
This source code is subject to the terms of the Mozilla Public License 2.0 at mozilla.org
@ Guardian667
A Personal Note
As a software developer experienced in OO-based languages, diving into Pine Script is a unique journey. While many aspects of it are smooth and efficient, there are also notable gaps, particularly in the realm of testing. We've all been there: using `plotchar()` for debugging, trying to pinpoint those elusive issues in our scripts. I've come to appreciate the value of writing tests, which often obviates the need for such debugging. My hope is that this Testing Framework serves you well and saves you a significant amount of time, more that I invested into developing this "baby."
Test - Symbiotic Exiton Measure Enthropic Nexus indicatorThe Symbiotic Exiton Measure Enthropic Nexus (SEMEN) Indicator is a technical analysis tool used in trading and investing. It's name might sound complex, but its function is quite simple - to help traders make informed decisions about buying or selling stocks by predicting market trends.
The SEMEN indicator uses a combination of various factors such as volume, price action, moving averages, and other indicators to generate a single numerical value that represents the overall health of the market. A high reading indicates a strong uptrend, while a low one suggests a downtrend.
Traders can use this information to enter or exit positions with confidence.
In essence, the SEMEN indicator provides a comprehensive view of the market's sentiment and direction, making it an essential tool for any trader or investor looking to make profitable decisions in today's volatile stock markets.
~description generated with Airoboros7b
- The indicator is experimental so use at your own discretion..
Ema ScalpThis is another simple strategy based on ema
Entry Buy - 1) when close crossover ema then buy and only open one trade till it not close
2) if previous buy trade is profitable open another trade and check again trade is profitable or not
3)if trade is not profitable reset and wait for sell condition...
Entry Sell -1) when close crossunder ema then sell and only open one trade till it not close
2) if previous sell trade is profitable open another trade and check again trade is profitable or not
3) if trade is not profitable reset and wait for buy condition.....
stop loss and take profit is percentage based ...
MathSpecialFunctionsTestFunctionsLibrary "MathSpecialFunctionsTestFunctions"
Methods for test functions.
rosenbrock(input_x, input_y) Valley-shaped Rosenbrock function for 2 dimensions: (x,y) -> (1-x)^2 + 100*(y-x^2)^2.
Parameters:
input_x : float, common range within (-5.0, 10.0) or (-2.048, 2.048).
input_y : float, common range within (-5.0, 10.0) or (-2.048, 2.048).
Returns: float
rosenbrock_mdim(samples) Valley-shaped Rosenbrock function for 2 or more dimensions.
Parameters:
samples : float array, common range within (-5.0, 10.0) or (-2.048, 2.048).
Returns: float
himmelblau(input_x, input_y) Himmelblau, a multi-modal function: (x,y) -> (x^2+y-11)^2 + (x+y^2-7)^2
Parameters:
input_x : float, common range within (-6.0, 6.0 ).
input_y : float, common range within (-6.0, 6.0 ).
Returns: float
rastrigin(samples) Rastrigin, a highly multi-modal function with many local minima.
Parameters:
samples : float array, common range within (-5.12, 5.12 ).
Returns: float
drop_wave(input_x, input_y) Drop-Wave, a multi-modal and highly complex function with many local minima.
Parameters:
input_x : float, common range within (-5.12, 5.12 ).
input_y : float, common range within (-5.12, 5.12 ).
Returns: float
ackley(input_x) Ackley, a function with many local minima. It is nearly flat in outer regions but has a large hole at the center.
Parameters:
input_x : float array, common range within (-32.768, 32.768 ).
Returns: float
bohachevsky1(input_x, input_y) Bowl-shaped first Bohachevsky function.
Parameters:
input_x : float, common range within (-100.0, 100.0 ).
input_y : float, common range within (-100.0, 100.0 ).
Returns: float
matyas(input_x, input_y) Plate-shaped Matyas function.
Parameters:
input_x : float, common range within (-10.0, 10.0 ).
input_y : float, common range within (-10.0, 10.0 ).
Returns: float
six_hump_camel(input_x, input_y) Valley-shaped six-hump camel back function.
Parameters:
input_x : float, common range within (-3.0, 3.0 ).
input_y : float, common range within (-2.0, 2.0 ).
Returns: float
[UTILS] Unit Testing FrameworkTL;DR
This script doesn't provide any buy/sell signals.
This script won't make you profitable implicitly.
This script is intended for utility function testing, library testing, custom assertions.
It is free and open-source.
Introduction
About the idea: is not exclusive, programmers tend to use this method a lot and for a long time.
The point is to ensure that parts of a software, "units" (i.e modules, functions, procedures, class methods etc), work as they should, meet they design and behave as intended. That's why we use the term "Unit testing".
In PineScript we don't have a lot of entities mentioned above yet. What we have are functions. For example, a function that sums numbers should return a number, a particular sum. Or a professor wrote a function that calculates something or whatever. He and you want to be sure that the function works as expected and further code changes (refactoring) won't break its behaviour. What the professor needs to do is to write unit tests for his function/library of functions. And what you need to do is to check if the professor wrote tests or not.
No tests = No code
- Total test-driven development
Ok, it is not so serious, but very important in software development. And I created a tool for that.
I tried to follow the APIs of testing tools/libs/frameworks I worked or work with: Jasmine (Javascript), Mocha/Chai (Javascript), Jest (Javascript), RSpec (Ruby), unittest (Python), pytest (Python) and others. Got something workable but it would be much easier to implement (and it would look much better) if PineScript had a higher-order functions feature.
API
_describe(suiteName: string)
A function to declare a test suite. Each suite with tests may have 2 statuses:
✔️ Passed
❌ Failed
A suite is considered to be failed if at least one of the specs in it has failed.
_it(specName: string, actual: any, expected: any)
A function to run a test. Each test may have 3 statuses:
✔️ Passed
❌ Failed
⛔ Skipped
Some examples:
_it("is a falsey value", 1 != 2, true)
_it("is not a number", na(something), true)
_it("should sum two integers", _sum(1, 2), 1)
_it("arrays are equal", _isEqual(array.from(1, 2), array.from(1, 2)), true)
Remember that both the 'actual' and 'expected' arguments must be of the same type.
And a group of _it() functions must be preceded by a _describe() declaration (see in the code).
_test(specName: string, actual: any, expected: any)
An alias for _it . Does the same thing.
_xit(specName: string, actual: any, expected: any)
A function to skip a particular test for a while. Doesn't make any comparisons, but the test will appear in the results as skipped.
This feature is unstable and may be removed in the future releases.
_xtest(specName: string, actual: any, expected: any)
An alias for _xit . Does the same thing.
_isEqual(id_1: array, id_2: array)
A function to compare two arrays for equality. Both arrays must be of the same type.
This function doesn't take into account the order of elements in each array. So arrays like (1, 2, 3) and (3, 2, 1) will be equal.
_isStrictEqual(id_1: array, id_2: array)
A function to compare two arrays for equality. Both arrays must be of the same type.
This function is a stricter version of _isEqual because it takes into account the order of elements in each array. So arrays like (1, 2, 3) and (3, 2, 1) won't be equal.
Usage
To use this script to test your library you need to do the following steps:
1) Copy all the code you see between line #5 and #282 (Unit Testing Framework Core)
2) Place the copied code at the very beginning of your script (but below study())
3) Start to write suites and tests where your code ends. That's it.
NOTE
The current version is 0.0.1 which means that a lot of things may be changed on the way to 1.0.0 - the first stable version.
Test - Gramian Angular FieldExperimental:
The Gramian Angular Field is usually used in machine learning for machine vision, it allows the encoding of data as a visual queue / matrix.
Multiple Regression Polynomial ForecastEXPERIMENTAL:
Forecasting using a polynomial regression over the estimates of multiple linear regression forecasts.
note: on low data the estimates are skewd away of initial value, i added the i_min_estimate option in to try curve this issue with limited success "o_o.
test - autocorrelation distributionexperimental:
shows the distribution for each shift in a autocorrelation.
test - delta distributiona test case for the KDE function on price delta.
the KDE function can be used to quickly check or confirm edge cases of the trading systems conditionals.
test - autocorrelationExperimental:
finds and displays the wavelength index's of the autocorrelation wavelengths..
Test: Pattern RecognitionEXPERIMENTAL:
a test on how to compare price at different frequency's with static patterns.
Test: Chain casting functions performanceExperimental:
A simple test to check performance impact of chaining functions in pinescript.
[RS][ALPHA]Predictive Range Analysis V0this code is untested use at your own risk...
applying timed price change over the square to predict price expansion or contraction of the range, it is not predicting the future price only the range that is possible for the price to be in within a margin of error of possibility, with that said i think its very unlikely for price to fall outside the range, due to virtual constraint applied by the auto corrective/cyclical nature of price action.
