Williams %R values out of 0 to -100 bounds about stock.indicators

[DaveSkender]

I think you're getting false readings from null values in WilliamsR, at least that's my best guess.
I'm not triggering anything outside of the range.

You can run this test from the tests/indicators directory in the affiliated 1127-williams-r-bounds branch, with the following command:

dotnet test --filter Issue1127 --logger:"console;verbosity=detailed"

output for symbol "A", ~1 year daily bars

2023-01-20 
2023-01-23 
2023-01-24 
...
2023-02-07 
2023-02-08 -55.117270788912776
2023-02-09 -76.86567164179117
2023-02-10 -71.80722891566255
2023-02-13 -41.0738255033558
2023-02-14 -62.0134228187921
2023-02-15 -78.30985915492967
2023-02-16 -89.58333333333323
2023-02-17 -83.64140480591513
2023-02-21 -94.61852861035428
2023-02-22 -93.09290953545218
2023-02-23 -85.36147400197784
2023-02-24 -85.90941114974666
2023-02-27 -80.34135587827546
2023-02-28 -81.53451057930502
2023-03-01 -93.72209821428577
...
2023-10-20 -65.62054208273881
2023-10-23 -64.05135520684723
2023-10-24 -96.69421487603304
2023-10-25 -75.8545454545454
2023-10-26 -69.2363636363636
2023-10-27 -80.43636363636365
2023-10-30 -73.98809523809521
2023-10-31 -60.42168674698793
2023-11-01 -62.383612662942255
2023-11-02 -52.389819987585334
2023-11-03 -24.14649286157666
2023-11-06 -26.40603566529488
2023-11-07 -5.761316872427912
2023-11-08 -14.75964793500333
2023-11-09 -25.930941096817875
2023-11-10 -20.98849018280295
2023-11-13 -27.82667569397428
2023-11-14 -4.389928986442911
2023-11-15 -5.191873589164786

[bsambrone]

Thanks for the pointer, i'll check that out!

[DaveSkender]

I was able to trigger a precision based out-of-bounds error with an unrealistic price and precision change between consecutive bars. This is just a rounding error and not worth trying to address.

     High ($)        Low ($)      Close ($)          Williams %R
     24485000       24433000       24480000   -4.347826086956516
0.00000001293  0.00000001284  0.00000001000  -100.00000000000001 <<

The only real fix for this rounding error is to move to decimal precision data types and the performance tradeoff isn't worth the likelihood of this happening in real data scenarios.

[DaveSkender]

Thank you for submitting this issue. While I don't see any unintended errors beyond these minor precision errors due to unrealistic swings in significant digits of prices, it is good for us to review periodically as a sanity check. In this case, it gave us the opportunity to improve our unit test scenarios.

Thank you.

If you do find something unusual that we didn't address, let me know and I'll reopen.