关于直接调用ta.dmi(14,14)与通过request.security调用的差异问询

核心原因分析： #

• 数据源不一致
  直接调用ta.dmi(14,14)是基于当前图表加载的本地标的K线数据计算ADX；而request.security("NASDAQ:TSLA", timeframe.period, ta.dmi(14,14))是指定用特斯拉（NASDAQ:TSLA）的K线数据计算。如果当前图表标的不是TSLA，两者计算的数据源完全不同，结果必然存在差异。

• lookahead参数的提前数据影响
  你在request.security中设置了lookahead = barmerge.lookahead_on，该参数会让请求的数据包含下一根K线的提前合并数据，相当于用未来未完全闭合的K线数据参与计算；而直接调用ta.dmi是基于当前K线的真实历史数据计算，没有提前获取未来数据，这会直接导致ADX数值偏差。

• 数据合并规则差异
  request.security即便是同周期调用，也会按照内置的barmerge规则处理数据对齐与合并；而直接调用的指标是实时在当前图表的K线序列上逐根计算，两者的数据处理逻辑不同，也可能引发数值差异。

验证与修正建议： #

1. 将当前图表切换为NASDAQ:TSLA，此时数据源一致，差异会缩小或消失。
2. 去掉lookahead = barmerge.lookahead_on参数，使用默认的barmerge.lookahead_off，避免未来数据干扰。

修正后的示例代码： #

//@version=6
indicator("TestADXRequestSecurity", overlay = true)

[diPlus, diMinus, adx] = ta.dmi(14,14)
// 使用默认lookahead参数，确保数据源逻辑一致
[tsladiplus, tsladiminus, tslaadx] = request.security("NASDAQ:TSLA" , timeframe.period, ta.dmi(14,14))

log.info("ADX without Request Security: " + str.tostring(adx) + " | ADX with Request Security: " + str.tostring(tslaadx))

内容的提问来源于stack exchange，提问作者user3420965