Wrong calculation for Spread SMA

[pegaltier]

I have tried to create a simple spread indicator using the playground and noticed the calculation are strange so I have compared with the same script on Tradingview and confirmed that there is an error in the calculation made by PineTS.

`
//@Version=5
indicator("Spread Moving Average", overlay=false)

length = input.int(20, "Length")
sma = ta.sma(close, length)
ssma = 100 * (close - sma) / sma
plot(ssma, "Spread SMA", color.blue, linewidth=2)

`

PineTS Playground

Tradingview

[alaa-eddine]

Thank you for reporting it, I'm able to reproduce it when I use Pine Script source code, but not when using the PineTS syntax.

which means that the problem is certainly in Pine Script transpiler layer. Good catch, these bugs are sneaky, and it tells me that I need to write more tests based on Pine Script sources .

I'll try to release a hotfix quickly

[alaa-eddine]

I just published a v0.8.1 with the hotfix.
as suspected, it was a transpiler bug, more specifically there were missing parenthesis in math operations in some situations.

I tested it with a few examples including yours and the values now look accurate

[jwernisch]

@alaa-eddine 0.8.1 also seems to fix the issues I was seeing with math functions not handling NaN and 10e10 correctly. Still testing.

[alaa-eddine]

@jwernisch awesome ! it was probably caused by the same transpiler bug, especially if you have formulas with parenthesis in your code.

[jwernisch]

Here's an example where I'm seeing issues (github seems to strip out the tabs):

`//@Version=5
indicator("normalize", overlay=true)

// pulled from https://www.tradingview.com/script/ia5ozyMF-MLExtensions/
// This fails on 10e10, -10e10, 10e-10
// e10 is not defined
// @function Rescales a source value with an unbounded range to a target range.
// @param src The input series
// @param min The minimum value of the unbounded range
// @param max The maximum value of the unbounded range
// @returns The normalized series
//normalize(series float src, float min, float max) =>
// var _historicMin = 10e10
// var _historicMax = -10e10
// _historicMin := math.min(nz(src, _historicMin), _historicMin)
// _historicMax := math.max(nz(src, _historicMax), _historicMax)
// min + (max - min) * (src - _historicMin) / math.max(_historicMax - _historicMin, 10e-10)

// attempt hard coding variables
normalize(series float src, float min, float max) =>
var _historicMin = 100000000000
var _historicMax = -100000000000
_historicMin := math.min(nz(src, _historicMin), _historicMin)
_historicMax := math.max(nz(src, _historicMax), _historicMax)
console.log(min + (max - min) * (src - _historicMin) / math.max(_historicMax - _historicMin, 0.000000001))
min + (max - min) * (src - _historicMin) / math.max(_historicMax - _historicMin, 0.000000001)

// similar issue here, console log shows result but results in Stream error: math.max(...) is not a function
// @function Rescales a source value with a bounded range to anther bounded range
// @param src The input series
// @param oldMin The minimum value of the range to rescale from
// @param oldMax The maximum value of the range to rescale from
// @param newMin The minimum value of the range to rescale to
// @param newMax The maximum value of the range to rescale to
// @returns The rescaled series
rescale(series float src, float oldMin, float oldMax, float newMin, float newMax) =>
_maxDiff = oldMax - oldMin
console.log(newMin + (newMax - newMin) * (src - oldMin) / math.max(_maxDiff, 0.0000000010))
newMin + (newMax - newMin) * (src - oldMin) / math.max(_maxDiff, 0.0000000010)

// All Fail
//normalize(-95.3654078258, 0, 1)
//normalize(na, 0, 1)

//rescale(na, 0, 100, 0, 1)
rescale(56.5806909587, 0, 100, 0, 1)`

[alaa-eddine]

@jwernisch got it, and I'm able to reproduce the issues.

could you confirm that the issues you encountered are the following:

• when you use 10e10 ==> you get error e10 is not defined
• when you use standard numbers ==> you get "math.max(...) is not a function"

did I miss something ?

[jwernisch]

Both are correct!

• when you use 10e10 ==> you get error e10 is not defined
• when you use standard numbers ==> you get "math.max(...) is not a function"

A separate comment you made got me thinking ... as a test I set these as variables and the function seems to run correctly.

rescale(series float src, float oldMin, float oldMax, float newMin, float newMax) =>
_maxDiff = oldMax - oldMin
leftSide = newMin + (newMax - newMin) * (src - oldMin)
rightSide = math.max(_maxDiff, 0.000000001)
leftSide / rightSide

[alaa-eddine]

yes, setting them as variables works, but I still need to fix a transpiler bug. more specifically with return statements when they have complex operations.
also the 10e10 error is due to a transpiler issue with exponent annotations.

both will be fixed soon :)

[alaa-eddine]

both issues are fixed in v0.8.3 (hotfix release)

[jwernisch]

That fixed the issues. Amazingly fast!

[jwernisch]

@alaa-eddine can you please look into bulitins for hlc3, hlcc4, etc.? It looks like pine rounds to 10 decimal places and the transpiler does not.

I have been testing using this library and am seeing some differences when running n_wt() and n_cci().
https://www.tradingview.com/script/ia5ozyMF-MLExtensions/

I'm not sure it matters in practice, the differences seem small at first glance but I'm wondering if the small discrepancies widen as bars increase...

[jwernisch]

Tried to fix in the pine script but found this issue as well. The precision variable is ignored in math.round(number, precision).

value = math.round(2.01234567890123456789, 10)
// expected: 2.0123456789
// actual: 2
log.info("value: " + str.tostring(value))

[alaa-eddine]

I will take a look at it.
PineTS aims for 8 decimals match with original Pine Script even though it's exact match most of the time.
a difference at the 9th decimal or more is insignificant as long as it does not accumulate ; I saw some small differences during my tests but hey are not cumulative so in real life cases they should not impact the signals.

that being said I still need to check your cases.

also math.round with precision is a confirmed bug, I'll fix it in the next release,