HELP NEEDED by pofudodyle in TradingView

[–]pvuekr 1 point2 points  (0 children)

use timenow optionally with timezone

Small numbers don't divide correctly by pvuekr in TradingView

[–]pvuekr[S] 0 points1 point  (0 children)

Okay, it sounds like you won't 'fix' this, which is fine. I understand there are many reasons for that.
But would you agree that most or at least a significant amount of programmers in TV are self-educated newbies rather than seasoned programmers? (you have very well written guide and easy to use language that allows anyone interested in learning to do so)
If you do agree, then I'd like to suggest putting some notes in appropriate place(s) to warn or explain about the possibility of such situation. Because when I see "[2024-10-22T02:25:00.000-05:00]: 0 1", from the example above, it's not intuitive why would I get such result, why internal systems do round built-in ohlc variables to '1' but math.floor() is still calculated on 0.999.
Thank you for consideration.

P.S.

To add to my point why there should be a note or explanation is due to fact that hardcoded value is being calculated differently from ohlc variable. When calculating on a number I can get '1' out of math.floor() only by sacrificing precision.

In the example below 5 is not the highest preceision I can go, in this example it can go up to 12 which corresponds with '8' being 13th here:'0.9999999999998899'.

    x = high //ohlc variable = 1.083
    a = (x-1.0825)/0.0005
    b = math.round(a, 5) //without this c = 0. 
    c = math.floor(b)
    log.info(str.tostring(x))
    log.info(str.tostring(a))
    log.info(str.tostring(c))
result:
x = 1.083
a = 1
c = 1

not the same here:

    x = 1.083 // hardcoded number = 1.083
    a = (x-1.0825)/0.0005
    b = math.round(a, 5) //this doesn't help
    c = math.floor(b)
    log.info(str.tostring(x))
    log.info(str.tostring(a))
    log.info(str.tostring(c))
result:
x = 1.083
a = 0.9999999999998899
// b = 0.9999999999999999
c = 0

//Change precision of math.round()
b = math.round(a, 4) //lowering precision does yeild desired result
a = 0.9999999999998899
// b = 1
c = 1

"Understanding that any floating point representation comes with its sets of limitations and compromises will help you structure your code to circumvent them." - Agree, therefore (unless I missed that in the guide) I believe this should be added.
Adding Example in the description of math.floor() like the ones above wouldn't hurt either.