PyneCore now runs integers the way TradingView does

On TradingView there is no integer at run time. Every number in a Pine script is a double; int exists only in the type checker. The most important consequence is what na means for an integer: it is the same not-a-number a float carries, and it flows through arithmetic and comparisons exactly like a float’s na does. A bar counter before warm-up, an na returned from a lookup, an integer that never got a value — on TradingView these are all one thing, and every rule that governs na in a float governs them too.

PyneCore used to run a real Python integer here, and a Python integer has no not-a-number. The gap had to be bridged with a wrapper object standing in for the missing value, which meant a second set of rules for how na behaves on integers, a second set of places where it could differ from the chart, and a slower path every time the two representations met. This release removes the distinction at its root: PyneCore keeps int as a static type and runs every number as a double, so an integer’s na is now a plain not-a-number with the same behaviour as a float’s, at native speed.

Doing that correctly needed something new: a static type inference pass that walks the script before it runs, works out the Pine type of every expression by the measured TradingView rules, and resolves overloaded calls once, up front. It is what lets 14 / 8 stay an int-typed 1.75 the way TradingView holds it, and still pick the integer version of a function. Where TradingView truncates an int, PyneCore now truncates at the same slot; where TradingView keeps the fraction, so does PyneCore. math.round with a precision argument was rebuilt against measured TradingView output on the way, and Pine v4 and v5 scripts get back the three-state bool they were written for.

No Pine-converted script had to change for this. Hand-written Pyne code that hands an int-typed value to a Python list index keeps working as well, because the loader now truncates at those points. The one place the change shows is an f-string, which prints 0.0 where it used to print 0; the type reference documents the idiom to use instead.

More info: https://pynesys.io/blog/pine-script-has-no-integers/