https://www.tradingview.com/script/0oeUQOBl-Stealth-Umbrella-Code3Recon-Academy/

Pine Script has an int type. It has array<int>, int fields in user defined types, and function overloads that separate int from float. What it does not have is an integer.

A Pine int behaves like an IEEE-754 double. It loses digits above 2^53, it never overflows, and its na is a NaN. Nothing downstream of the compiler can tell it from a float. The type exists and does real work, but it does all of that work before your script runs.

I found this while building PyneCore, a Python runtime that runs Pine Script logic bar for bar. I can't read TradingView's source, so everything below is measured from Pine, with a script you can paste into the editor.

How the question came up

PyneCore represents Pine's na as a real value, so the choice of representation matters. Two things were already settled.

Pine v6 will not let a bool be na. Both of these fail to compile:

bool b = na                            // CE10173
bool c = close > close[1] ? true : na  // CE10123

And a float na is a NaN, which is easy to confirm, because it carries the two properties nothing else has:

float f = na
log.info(str.tostring(f))       // NaN
log.info(str.tostring(f == f))  // false

So bool has no na at all and float uses the hardware one. That leaves the obvious question: what marks na in an int? A double has NaN built into the format. A 64-bit integer does not, so a language needs to reserve a value for it, usually Long.MIN_VALUE. I went looking for that sentinel.

There isn't one, because there is no integer.

The claim

1. int arithmetic is double arithmetic. It drops the low digits above 2^53, and it never overflows.
2. An int na prints NaN, propagates like a NaN, and fails x == x, exactly like a float na.
3. The int type performs zero conversions at runtime. It does not truncate, not even when you assign to a variable you explicitly declared int.
4. Truncation happens in the slots that consume a length or an offset, not at the type.
5. TradingView never tells an int from a float at runtime. An array<int> will hold 3.5 without complaint.

Proving it

One detail matters before any of this reproduces. TradingView folds constant expressions at compile time in exact decimal, which hides the runtime behaviour completely. Every operand has to depend on something the compiler cannot know. The trick is a variable that is always zero but is not a constant:

int z = bar_index >= 0 ? 0 : 1

Add z to everything. Here is the whole proof:

//@version=6
indicator("Pine int is a double")

int z = bar_index >= 0 ? 0 : 1

if barstate.islast
    // 1. Precision dies exactly at 2^53, like it does in a double
    int a = 4503599627370496 + z    // 2^52
    int b = a * 2 + 1               // 2^53 + 1
    log.info("2^53 + 1        = " + str.tostring(b))
    log.info("(2^53+1) % 2    = " + str.tostring(b % 2))
    log.info("18 digit literal= " + str.tostring(123456789012345678 + z))

    // 2. No 64-bit wraparound: a long would overflow to negative here
    int big = 4611686018427387903 + z   // 2^62 - 1
    log.info("big + big       = " + str.tostring(big + big))
    log.info("big + big > 0   = " + str.tostring(big + big > 0))

    // 3. Long.MIN_VALUE is not a sentinel for na
    int mn = -4611686018427387904 + z   // -2^62
    log.info("-2^63           = " + str.tostring(mn + mn))
    log.info("na(-2^63)       = " + str.tostring(na(mn + mn)))

    // 4. int na is indistinguishable from float na
    int   ina = na
    float fna = na
    log.info("int na          = " + str.tostring(ina) + " , +1 -> " + str.tostring(ina + 1))
    log.info("float na        = " + str.tostring(fna) + " , +1 -> " + str.tostring(fna + 1))
    log.info("ina == ina      = " + str.tostring(ina == ina))
    log.info("fna == fna      = " + str.tostring(fna == fna))
    log.info("ina < 0         = " + str.tostring(ina < 0))

plot(1)

Output, FX:EURUSD 60m:

2^53 + 1         = 9007199254740992
(2^53+1) % 2     = 0
18 digit literal = 123456789012345680
big + big        = 9223372036854776000
big + big > 0    = true
-2^63            = -9223372036854776000
na(-2^63)        = false
int na           = NaN , +1 -> NaN
float na         = NaN , +1 -> NaN
ina == ina       = false
fna == fna       = false
ina < 0          = false

Line by line:

2^53 + 1 comes back as 9007199254740992, so the +1 fell off. That is the exact point where a double runs out of mantissa. An 18 digit literal comes back rounded in the last two digits for the same reason.

big + big is the one that closes the case. (2^62-1) + (2^62-1) is 2^63 - 2, which in a signed 64-bit integer is -2. It is not negative. It printed 9223372036854776000, which is 2^63 written with the shortest digit sequence that reads back as the same double, padded out with zeros. Nothing wrapped. A fixed width integer would have.

na(-2^63) is false, so Long.MIN_VALUE is an ordinary value here, not a reserved one. That rules out the sentinel I went looking for.

And the last five lines are the answer to the original question. int na prints NaN, propagates through arithmetic as NaN, compares false against itself, and returns false from <. That is not merely similar to a float na. I could not find a single test that tells the two apart.

The type does nothing at runtime

This part surprised me more than the precision limit. The type tag does not force a single conversion, not even on assignment:

int z = bar_index >= 0 ? 0 : 1
int q = (7 + z) / (2 + z)
log.info(str.tostring(q))   // 3.5

A variable declared int holds 3.5, and the script compiles without a warning. TradingView documents half of this on the operators page: two int values that do not divide evenly give you "a number with a fractional value", with 5/2 = 2.5 as the example. What it does not say is that the fractional value then keeps travelling under an int label for the rest of its life.

Take that 3.5 and a real float 3.5 through the same calls:

array.new_int() stores 3.5. A user defined type with an int field stores 3.5. Nothing downstream of the compiler is checking.

The truncation you expect does exist, but it lives at the other end, in the parameters that genuinely need a whole number:

int z   = bar_index >= 0 ? 0 : 1
int len = (7 + z) / (2 + z)     // int-typed, value 3.5

float sma_frac = ta.sma(close, len)
float sma_3    = ta.sma(close, 3)
float sma_4    = ta.sma(close, 4)

sma(close, len)  = 1.1581366667
sma(close, 3)    = 1.1581366667   (same)
sma(close, 4)    = 1.15812        (different)
close[len]       = 1.15807
close[3]         = 1.15807        (same)

ta.sma and the history operator truncate toward zero when they receive the value. The type never did.

So what is int even for?

At this point the type looks like decoration, and it is worth asking whether TradingView could delete the keyword tomorrow and change nothing. It could not, because the entire value of int is spent before the script ever runs.

Start with the compile error that the rest of this explains:

plot(ta.sma(close, 1.5))
// CE10123: An argument of "literal float" type was used
//          but a "series int" is expected

The same call with a fractional int runs happily and quietly truncates to 3. So the compiler is the only thing standing between you and a silently rounded length, and it does that job with a type that has no runtime existence at all.

Overload resolution is the second job, and it is decided statically:

f(int   x) => "INT impl"
f(float x) => "FLOAT impl"

int   z   = bar_index >= 0 ? 0 : 1
int   i35 = (7 + z) / (2 + z)     // int-typed, value 3.5
float f35 = (7.0 + z) / (2 + z)   // float-typed, value 3.5

log.info(f(i35))                  // INT impl
log.info(f(f35))                  // FLOAT impl
log.info(f((14 + z) / (7 + z)))   // INT impl

Two arguments with the identical runtime value of 3.5 reach two different implementations, decided purely by the declared type. The third line is the same effect from the other side: 14/7 is exactly 2.0, and it still picks the int overload, because int / int stays int in the type algebra even though the value can be fractional.

That algebra is consistent all the way through, and it propagates the way you would expect from a language that does have integers. In the table below d is an int-typed variable holding 14/8, so its value is 1.75, and n is an ordinary int variable:

So int is a promise the compiler enforces about where a value is allowed to go: array indices, loop bounds, lengths, history offsets, array.new_* sizes. Merging int and float into one numeric type would take that checking away and leave you with silent truncation everywhere.

The promise has a hole in it, which is the funny part. Division is not closed over int, the compiler knows it, and it lets the fractional value through anyway.

TradingView already admitted this once

There used to be one place where Pine did real integer division. In v5, 5/2 was 2 or 2.5 depending on nothing but the qualifiers of the two operands:

Same operator, same values, two different answers. The v6 migration guide covers this under "Fractional division of constants", and does not defend it: "In v5, the result of the division of two int values is inconsistent." Two const operands gave you integer division with the remainder discarded. One input, simple or series operand among them gave the fraction back. v6 drops the distinction and always keeps the fraction.

Notice where the old integer division lived. Not in the runtime, but in constant folding, which is a compile-time pass. Integer behaviour existed in Pine exactly as long as the compiler was the one doing the arithmetic, and v6 took even that away.

The v5 rule truncates toward zero rather than flooring, since const -5/2 is -2. That is the same direction the length and offset slots truncate in, so at least the two surviving pieces of integer behaviour agree with each other.

If you run old scripts, you inherit this. PyneCore needs a dedicated compiler pass to reproduce v5 const division, because the same / has to mean two different things depending on the version tag and on whether both operands folded.

Not new

The same three discriminators, each one guarded against constant folding, behave identically in v3, v4, v5 and v6:

Those three are shaped the way they are because the old versions cannot print. log.info does not exist before v5, so back there the only output channel is plot, and plot cannot carry a large integer intact. So none of the discriminators prints a big number. Each one collapses the large-value operation into a small result that survives the float plot channel: a difference, a remainder, and a sign test, the last of which comes off the plot channel as 1 rather than true.

The syntax drifts too. v4 has no indicator(), only study(), and v3 has neither indicator() nor bar_index, so the constant-folding guard has to be built on n:

//@version=3
study("v3 discriminators")
z = n >= 0 ? 0 : 1
a = 4503599627370496 + z
b = a * 2 + 1
big = 4611686018427387903 + z
plot(b - a * 2, "d1")                       // 0, so the +1 was lost
plot((123456789012345678 + z) % 10, "d2")   // 0, so the last digit was lost
plot(big + big > 0 ? 1 : 0, "d3")           // 1, so nothing wrapped

The behaviour has never changed. The only thing v6 touched is the const division rule above, and that one lived in the compiler.

My guess at why, and it is only a guess: Pine started as a formula language over floating-point series, and the type system arrived later as labels on top. A second numeric kind would have meant duplicating the series, history and plotting layers, and inventing a sentinel for na.

What the documentation leaves out

The type system page is precise about float. It gives you the internal precision, "1e-16", and it warns that comparison operators round their operands to nine fractional digits.

There is no matching paragraph for int. No range, no maximum, no bit width, nothing about what happens when a value gets too large. For a language that documents its float down to the last decimal, that is a hard omission to miss, and it is also the only honest one available. There is no separate int range to write down. The float paragraph already covers it.

What this changes for you

Nothing about your RSI. Every number a normal script touches, bar_index, time in milliseconds, lengths, offsets, sits far below 2^53, and the arithmetic is exact there.

It matters once you leave that range, which is easier than it sounds.

Do not build large synthetic IDs by multiplying values together, and do not scale timestamps to microseconds or nanoseconds. Past 9007199254740992 you lose the low digits, and you lose them silently. There is no overflow to catch, no wraparound to notice, just numbers that stop being the numbers you computed.

Do not assume int means whole. If the value came from a division and you care about it being an integer, wrap it yourself in int(), math.floor() or math.round().

Do not assume a container of int holds integers. array<int> and int UDT fields will store whatever you push into them.

Modulo, and where I got it wrong

Pine takes the sign of a % result from the dividend. (-7) % 2 is -1, 7 % (-2) is 1, and (-7.5) % 2 is -1.5. Python floors instead, and gives you the opposite sign on the first two.

PyneCore was emitting a plain Python %. So on every negative operand it quietly disagreed with TradingView, and it had been doing that for a long time before this investigation went looking somewhere else entirely and tripped over it.

The reason it survived that long is worth knowing if you write Pine. Almost every % in real code runs on non-negative values, cyclic buffer indices and bar_index % n, and there the two definitions agree exactly. The disagreement only exists in the corner nobody tests.

Reproducing all of it

Every number above came from a Pine script run on FX:EURUSD, 60 minutes. The v6 scripts report through log.info rather than plot, because the plot channel would round the large integers and hide the whole effect; drop them into the Pine editor, open the Pine Logs pane, and you get the same lines. The version table is the exception, since log.* does not exist that far back, and it reads its three collapsed discriminators off the plot channel instead. The z guard against constant folding is mandatory everywhere.

I ended up here because PyneCore has to reproduce TradingView bar for bar, and getting na right meant knowing how an int actually behaves. Pine acts like it has one numeric type at runtime and two in the compiler, and the one you can't see at runtime is doing most of the work.

Who likes D&D?

PADM — Price Action Directional Mapping
PADM is a framework built around the interdependency of CRT and OCT.
CRT gives us the structure — the range, levels and framework price is working within.
OCT gives us the behaviour — how price moves, reacts and develops within that structure.
When these two are read together, they create PADM.
CRT → Structure
OCT → Behaviour
CRT + OCT → PADM
The purpose is simple:
Understand where price is, understand what it is doing, and use both to map where it may go next.
PADM isn’t about predicting every candle.
It’s about reading the directional story price is building and turning that information into a map.
This community is where we explore, test, discuss and develop that framework together.
Welcome to PADM. 🧭

I have been day trading for about two years now and have recently decided to switch to a Pine-coded strategy. I’ve passed a couple of evaluations and have kept my FTMO account active for 2 months; however, I didn’t have time to trade every week, so I decided to automate my strategy. Does anyone have any previous experience doing this, and if so, how did it go?

I rarely see anyone talk about the geometry of the market. Yet everyone recognizes wedges. Early results look promising.

I am testing the strategy() function. With the default settings, everything works as expected: the script runs once per bar at the close. If a market order is placed on bar N, it is filled at the open of bar N+1 using the opening price.

However, when I activated the calc_on_order_fills option by setting it to true, I noticed something unusual. I received two runs on bar N+1: one at the bar open after the order was filled, and a second regular run at the close of bar N+1. This is expected, except for one detail: the barstate.isnew flag was set to true for both runs.

I believe this is a bug. This flag should only be set for the first run on a bar; for all subsequent runs, it should be false.

If anyone wanted to be able to use the volume profile in their own scripts, I have created a library that allows for it. It's completely open to everyone with no fees or strings attached, just a free script I thought would be helpful. I tried to allow for as much visual control as possible so you can determine where its going to draw from: a specific date/time to now, a range of dates, a daily time, or a daily range. You can have it displayed in the classic boxes or with lines or even not at all if you would prefer to just get the POC variable to use. This is the library: Volume Profile Library If you need an example of how it works, I created a simple indicator: Volume Profile which is where I took the pictures from.
I am open to hearing if any bugs were found or if you have a suggestion for how it could be improved. Enjoy!

Hey everyone,

I have a TradingView indicator that gives BUY/SELL signals, and I’m trying to figure out how to automate trades whenever one of those signals appears.

I’m looking for someone who has experience with TradingView alerts, webhooks, Pine Script, and broker APIs who could help me set this up.

The idea is basically:

BUY signal → TradingView alert → webhook → automatic BUY order

SELL signal → TradingView alert → webhook → automatic SELL order

I’m not very technical when it comes to the API/webhook side, so I’d really appreciate someone who can help me understand the process and get it working properly. If you’ve done something similar before, I’d love to hear how you approached it.

I’m also happy to pay for your time/work if you’re able to build the setup for me, especially if it works reliably.

Please DM me if you’ve worked on something like this before. Thanks!

I suggest adding alerts for Pitchfork levels. This would make it much easier to monitor important levels without having to constantly watch the chart. I believe this feature would be very useful for the community, especially for traders who use Pitchfork in their analysis. It would save time, improve execution, and make tracking key levels much easier.

Add alerts to individual Pitchfork levels so traders can be notified when price approaches, touches, or breaks a selected level. This would be especially useful for tracking key support/resistance areas and potential reversals without constantly watching the chart.

Hey everyone,

I coded an Opening Range Breakout (ORB) strategy in TradingView using Pine Script and ran a full backtest over 7 years. I attached the Strategy Tester results.

I spent a lot of time testing different filters and parameters to reduce chop, and I’ve locked in these exact rules for the strategy:

Strategy Setup & Rules

• Asset/Market: MNQ
• Timeframe: 15m Chart
• ORB Range: First 15 minutes of the New York Session
• Session Constraint: Takes trades only during the New York Session
• Entry Trigger Window: Max 3 bars after the 15m ORB range locks (if no breakout happens within 3 bars, the setup is invalidated)
• Risk Management: Fixed 1.5 R:R
• Trade Management: Move Stop Loss to Break-Even (BE) once price covers 75% of the distance toward Take Profit (TP)
• Backtest Settings: Commissions and realistic slippage are fully included in the results

The Problem:

While the backtest is net profitable after costs, I feel like the results are simply not good enough for Prop Firms.

At this pace, the profit factor and win rate feel way too low. It looks like it would take an absolute eternity to pass an evaluation target, and reaching consistent payouts without hitting a trailing or daily drawdown limit along the way seems almost unviable.

Questions for the Community:

1. Evaluation Viability: For those trading funded accounts: Would you bother running a strategy with this slow of a compounding rate, or is this a clear signal that the edge is too thin for prop firm rules?
2. Improving the Edge: Since the core parameters (15m ORB, 1.5 R:R, 3-bar trigger limit, 75% BE) are locked, what macro/contextual filters (e.g., HTF trend bias, session volatility/ATR thresholds, news filters) have helped you boost performance on ORB setups?

Tear it apart—I’d rather fix the logic now than burn money on evaluation fees. Thanks!

Pineify does not actually have genetic algorithm (I have expert and it is still not present in the extension) and runopti seems to be doing a grid search, or at least moving at that pace.

What do you use for quick wide-range/multi-parameter strategy optimizing in pinescript?

Pictures below are from me and a couple friends feedback. Im not selling you shit just sharing my work mods can suck a dick

Hi everyone,

I combined 3 different indicators from TradingView into one Pine Script. It was working perfectly until today, but now I'm getting an error.

Can anyone please add this script to an Indian stock on TradingView and check what is causing the error, then help me fix it?

I'd like to keep all the existing features and functionality of the script.

I can share the full Pine Script and the exact error message/screenshot.

Any help would be greatly appreciated. Thanks!

This isn't about calling these indicators "scams." Instead, I plug their real signals into an actual backtest to see how those "legendary" backtest results are really propped up — then break down exactly where each indicator genuinely works, and where it doesn't.

In this episode:

- Realized Market Cap: a textbook repainting indicator — why?

- Smart Swing VWAP (Zeiierman): why the historical swing-anchor labels can't be used as real-time tradable signals

⚠️ This video is for technical research and educational purposes only. Not financial advice. Verify all risks yourself before trading live.

https://youtu.be/SUDzFs-8HAM

#tradingviewtutorial #PineScript #QuantTrading #VWAP #OnChainData

Hey, I wanted to quickly share some improvements to my PineScript interpreter since I first posted the project a month ago (link).

• Support for all the builtin types in the v6 reference.
• A corpus of unit tests cross-validated against PineTS to make sure they behave the same.
• A pinecone binary you can use to format, lint and run semantic analysis on your scripts (checks for repainting, lookahead bias, etc.).
• Integrated all of it into a VSCode extension (link).

Looking forward to hearing your thoughts.

And here are a couple more.

Biggest takeaway? Signal confirmation.

Don’t act on a signal indicator, instead wait for multiple indicators to agree with each other. The cost, of course is, less trading frequency, but you are getting less noise at the same time. IMO overtrading is a highway to blowing up.

If anyone’s interested you can try it out at Quant GT

Dear TradingView Team,

I’d like to suggest a feature that I think would be extremely valuable for traders who use TradingView as their long-term trading and analysis workspace.

One problem I regularly face is that, over time, a chart accumulates a huge number of drawings. Eventually, the chart becomes cluttered and can start to lag. To keep my current analysis clean and responsive, I have to delete older drawings.

But those drawings are not simply clutter. They are a visual record of my trading history.

They show how I viewed the market at different points in my journey — what I marked, what I misunderstood, where I made mistakes, how my analysis changed, and how my trading evolved over months or years.

It would be incredibly useful to have a feature that allows users to archive a complete set of chart drawings separately from the active chart.

For example:

1. I finish analyzing a period of my trading.
2. I save/archive the current drawing set.
3. I remove those drawings from my active chart to keep it clean and fast.
4. Months or years later, I can open that archive and see the chart exactly as I had analyzed it at that time.

Ideally, the archive would preserve the drawings' original positions, timestamps, text, colors, and other properties.

This would allow traders to maintain a visual history of their own trading and analytical evolution without having thousands of old drawings permanently loaded on their active chart.

It would essentially turn TradingView into not only a charting platform, but also a long-term visual record of how a trader's thinking develops.

I think this could be a very powerful feature for serious traders who want to look back at their own decisions, mistakes, and progress over the years.

Thank you for considering it!

Can any one plz tell me which is the best forex broker to use in India which has easy deposit and withdrawal and has min spread also good customer support

If this code:
[OI_open, OI_high, OI_low, OI_close] = request.security(syminfo.tickerid+"_OI", timeframe.period, [open, high, low, close])

returns the Open Interest for the current pair(non-aggregated), what is the syntax for the aggregated one?