Lorentzian Classification KNN ML Indicator for TradingView
Lorentzian Classification combines technical features, a logarithmic distance calculation, stateful vote selection, filters, and kernel regression. Its “prediction” output is a model score, not a calibrated probability or an independently verified trading advantage. This guide describes the current Pineify component and the checks needed before interpreting its labels.
What the Component Calculates
The component constructs features from normalized RSI, Wave Trend, CCI, and ADX calculations, including two RSI configurations when five features are selected. Its distance sums logarithms of one plus absolute feature differences. The logarithm compresses large differences relative to an untransformed sum; it does not identify news events or automatically discount old observations by age.
Do not describe the implementation as an exact textbook nearest-neighbor search. Its candidate loop uses a changing distance threshold, persistent vote arrays, and an index condition that excludes multiples of four. That condition does not ensure selected observations are at least four bars apart.
The stored label compares the current source with its value four bars earlier. It is not a direct lookup of the next four bars after each selected feature observation. Consequently, the label name and four-bar holding logic do not by themselves establish a validated four-bar forecast.
The Max Bars Back setting also affects the evaluated region and loop bounds. The current implementation does not simply maintain a rolling collection of the latest N observations. Save the available history and script version when comparing results; data-start changes can affect stateful calculations.
Add and Inspect the Indicator
- Select Lorentzian Classification in Pineify and record its settings.
- Generate the script and check it in TradingView's Pine Editor.
- Inspect the kernel line, entry/exit outputs, score, and optional statistics separately.
- Save the symbol, chart timeframe, data history, and configuration before comparing another run.
- Observe completed realtime bars and reload behavior before relying on alerts.
A generated script still needs compilation and behavioral review. This article does not certify the underlying model's predictive accuracy.
Signals, Filters, and Exits
The entry outputs combine a changed directional signal with enabled EMA/SMA and kernel conditions. A positive score alone is not necessarily a new long-entry event. Optional filters change eligibility; they do not guarantee that the surviving trades are better.
Kernel coloring can use the rational-quadratic estimate's direction or the relationship between rational-quadratic and Gaussian estimates when smoothing is enabled. A color change and a classification entry are distinct events. Define their allowed ordering if a strategy combines them.
Dynamic exits have an implementation constraint: they are selected only when dynamic exits are enabled and the EMA filter, SMA filter, and kernel smoothing are all disabled. Otherwise the strict exit branch is used. Enabling all those features together does not produce the advertised combination of dynamic exits and moving-average filters.
Read the Statistics Table Correctly
| Table field | Interpretation | Boundary |
|---|---|---|
| Winrate | Counted wins divided by counted completed trades | Uses the library's signal accounting, not your broker fills |
| Trades | Count of outcomes under the helper's rules | Not an audit of every possible entry policy |
| WL Ratio | Number of wins divided by number of losses | Not average win divided by average loss and not profit factor |
| Early Signal Flips | Direction changes within the short holding window | Describes instability of the signal sequence, not a verified market regime |
A ratio of two wins to one loss says nothing about the currency size of those outcomes. Both a profitable and a losing system can have that count ratio. The optional estimate mode does not incorporate every execution cost, gap, or latency scenario and should not be called a guaranteed worst case.
Three Research Questions
Entry Baseline
Use a completed startLongTrade event when flat, enter on the next modeled bar open, and exit on a completed endLongTrade event. Specify how repeated or missing exit events are handled and add a separately defined protective stop if required. This is an educational specification, not a reported test.
Score Threshold
Compare the baseline with a preselected score threshold while preserving the same exits and sizing. The score is a sum of stored labels; zero labels and stateful candidate selection mean a value should not be converted directly into a probability or an exact bullish-neighbor fraction without inspecting the stored sample.
Measure removed winners and losers and show sample sizes. A higher score has no demonstrated general guarantee of more reliable follow-through.
Kernel Filter
Compare the same entry/exit specification with the kernel filter enabled and disabled. If changing smoothing, record that it also affects kernel-state interpretation and dynamic-exit eligibility. Changing several settings at once makes it harder to identify the cause of a result.
Settings and Data Limits
Use the current component's defaults as a reproducible configuration, not an optimized recommendation. A small preselected parameter comparison is easier to assess than searching many timeframes and feature combinations until one chart looks favorable.
Feature count changes the distance inputs; it is not simply a “faster signal” knob. Neighbor count changes the vote collection and score scale. Available history, initialization, and the evaluated region affect how many usable observations exist.
No fixed number of signals per week or universal best market is established here. Report the actual event count for a saved configuration. A rare signal is not inherently more reliable than a frequent one.
Backtesting and Automation
A full strategy must specify actual orders, fills, costs, stops, sizing, and reversal behavior. The indicator table is not a replacement for that simulation. Use TradingView's strategy documentation to check when orders are created and filled; same-close execution is not an automatic consequence of a signal.
Reserve later data before selecting settings and inspect individual trades around signal flips and exit-mode changes. Keep the code version and loaded history with the report. A fixed risk-budget percentage does not guarantee survival or limit losses through price gaps.
Alerts need their own timing and execution configuration. The calculation does not itself gate all events on confirmed bars. Current feature values and kernel estimates can change while a bar forms, and the data-window-dependent state prevents a blanket “never repaints” claim. Consult the repainting guide.
Frequently Asked Questions
Does the score give the probability of an upward move?
No. It is a sum of selected labels under this implementation. Probability interpretation would require a defined forecast event and independent calibration on later observations.
Does the algorithm guarantee neighbors four bars apart?
No. Its index-selection condition excludes multiples of four; that does not enforce a minimum four-bar distance between selected observations.
What does WL Ratio measure?
The displayed ratio divides the number of wins by the number of losses. It does not compare the average size of gains and losses.
Why might dynamic exits not activate?
The current implementation requires EMA filtering, SMA filtering, and kernel smoothing to be disabled before it selects the dynamic-exit branch.
Is the indicator proven better than RSI or MACD?
No such comparison is established here. Those indicators also respond to changing data; a machine-learning label does not replace controlled evaluation of complete strategies.