时间框架的列表结构和对象的可见性标志之间有什么关系吗（因为连列表的长度都不同：22 vs 23）？总的来说，我的问题是为了在一个有给定边界的周期中有效而紧凑地分配对象在时间框架上的可见性，而不是手动列出和总结标志。如果随机抽取一个任意的时间段，在其上建立一个图形对象，并且需要允许它在不早于当前时间段（即它所建立的时间段）的所有时间段上可见，应该使用什么逻辑？该算法应该是通用的，而不是针对某一特定情况。指数的相关性已经被搞砸了，甚至没有一个指数匹配。解析名字的字符串和比较再次失败，因为在可见性常数的情况下不可能处理字符串。到目前为止，我想到的是一个复杂的、模糊的和非常歪曲的实施。
int PeriodToTimeframeFlag(ENUM_TIMEFRAMES period)
{
flags=0;
staticENUM_TIMEFRAMES _p_int[]={PERIOD_M1, PERIOD_M2, PERIOD_M3, PERIOD_M4, PERIOD_M5, PERIOD_M6,
PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,
PERIOD_H1, PERIOD_H2, PERIOD_H3, PERIOD_H4, PERIOD_H6, PERIOD_H8,PERIOD_H12,
PERIOD_D1, PERIOD_W1, PERIOD_MN1};
//--- cycle for all timeframesfor(int i=0;i<ArraySize(_p_int);i++)
if(period==_p_int[i])
{
//--- at the same time generate the flag of the working timeframe
flags=((int)1)<<i;
break;
}
return(flags);
}
给开发者的问题。
为什么在测试器中不可能得到结构的字段？
MqlTradeResultprice;// 交易中的价格，由经纪人确认？它给出了0。
它在演示中运行良好。
时间框架的列表结构和对象的可见性标志之间有什么关系吗（因为连列表的长度都不同：22 vs 23）？总的来说，我的问题是为了在一个有给定边界的周期中有效而紧凑地分配对象在时间框架上的可见性，而不是手动列出和总结标志。如果随机抽取一个任意的时间段，在其上建立一个图形对象，并且需要允许它在不早于当前时间段（即它所建立的时间段）的所有时间段上可见，应该使用什么逻辑？该算法应该是通用的，而不是针对某一特定情况。指数的相关性已经被搞砸了，甚至没有一个指数匹配。解析名字的字符串和比较再次失败，因为在可见性常数的情况下不可能处理字符串。到目前为止，我想到的是一个复杂的、模糊的和非常歪曲的实施。
当然有相关性，但它是如此隐含，以至于只能写<visibility_flag>=F(<timeframe>)。
x100intraday:
如果我们随机抽取一个任意的时间段，在其上建立一个图形对象，并需要允许其在不早于当前时间段（即它所建立的时间段）的所有时间段上可见，应该使用什么逻辑？
如果它不是一个检查器)
考虑TF[i]，设置Visibility[i]...。
或 visibility=(int)(MathPow(2,i+1)-1)。
如果你需要它，那么它就不是一个棋盘了)
考虑TF[i]，设置Visibility[i]...。
或 visibility=(int)(MathPow(2,i+1)-1)。
谢谢你的可见度公式--也许我会改编它。从时间框架上的数值可以看出，这是一个度的问题，但我还没有尝试自己去重建这个公式。
是否需要-1？一般来说，Visibility[]似乎被填上了不正确的值，事实上，它应该到处都没有-1，即：1、2、4、8、16...。
当然有一种关系，但它是如此隐含，以至于只有这样写<visibility_flag>=F(<timeframe>)。
谢谢你，优雅。这正是我想做的事情，除了转变本身，这正是我所缺少的。
最后，我问了关于在_p_int 时间框架数组上回归循环的每一回合计算标志值的问题（最后应该用标志来添加一些东西），而不是只计算当前的。好吧，通过在当前时间段转移可见性标志 值，然后随着i-- 的每一次旋转，某处应该发生变化......。在这里，要么必须应用指数化公式，要么必须使用相同的移位原则。我还没有搞清楚如何...
... 虽然，是的，它是一个带有TF-参数的函数--我将尝试循环它...
然而，这又是错的。让我解释一下。在这个例子中，有静态的ENUM_TIMEFRAMES _p_int[]，用于21个项目，但我想要的是：我已经有这样一个数组，但它可以是任何长度。它是一个包含时间段的数组，在这个数组上将建立一些东西。 但它们也应该在所有较低的时间段上可见，没有一个数组是单独或从现有的数组中额外填充的。因此，我在这里提到，有必要计算当前和所有较低时间段的旗帜，并在回归循环中飞快地将它们相加，从当前时间段开始跳舞。诀窍不是创建一个完整的任何东西的预设值阵列（甚至是时间框架或可见性标志）并摆弄它们，而是在我的脑海中为每个回合只计算预设时间框架的不完整阵列。
我先走一段时间，如果遇到困难，我就会问。
为什么我不急着用(int)(MathPow(2,i+1)-1)或((int)1)<<i...如果i在那里，你可以很容易地把它替换成一个循环并运行...但是，就像在乘法和移位的情况下--它总是安全的吗？假设开发人员增加了新的时间框架，整个逻辑不就走样了吗？一开始--在有转变的例子中，我们希望当前的时期与预设的时期相吻合。
if(period==_p_int[i])因此，即使在真实的情况下，理论上完整序列中的一些时间段被省略了，或者这个序列被开发者扩展了，逻辑也不应该爬行。但是，如果我们依靠纯粹的数学，只是按公式从边界到边界地运行周期，而不看可能没有或存在的新的时间框架，那么迟早，在下一个建设中，我们会得到歪曲......为什么我不急着用(int)(MathPow(2,i+1)-1)或((int)1)<<i...如果i在那里，你可以很容易地把它替换成一个循环并运行...但是，就像在乘法和移位的情况下--它总是安全的吗？假设开发人员增加了新的时间框架，整个逻辑不就走样了吗？只是在顶部--在有转变的例子中，我们希望当前的时期与预设的时期相同。
因此，即使在真实的情况下，理论上完整序列中的一些时间段被省略了，或者这个序列被开发者扩展了，这个逻辑也不应该爬进去。但是，如果我们依靠纯粹的数学，只是按公式从边界到边界地运行周期，而不注意可能没有或存在新的时间框架，那么迟早在下一次构建中，我们会得到一个偏差......我们的担心是非常合理的。上面的代码证明了这样一个事实：设置的可见性标志 实际上是一个宏。
这将是更正确的工作方式。
谢谢你的可见度公式--也许我会改编它。我从时间框架上的数值可以看出，这是一个度的东西，但我还没有尝试自己重构这个公式。
-1真的有必要吗？实际上，Visibility[]的填写似乎不正确，事实上，它应该是到处都没有-1，即1、2、4、8、16......。
1,2,4等。- 物体在一个时间范围内的可见性。=MathPow(2,i)。
在当前和更小的1，1+2，1+2+4，1+2+4+8等，taki =MathPow(2,i+1)-1。
它在二进制代码中更清晰。
这种疑虑是非常合理的。上面的代码只是证明了可见性标志 集实际上是一个宏的事实。
正确的方法是通过它来工作。
原则上是一样的。如果你在tf的列表中改变，你就必须编辑代码。
我无法想象任何普遍的解决方案，而且我怀疑理论上不可能预见到可能的变化。
x100 intraday:
不过，又错了。让我解释一下。在这个例子中，静态ENUM_TIMEFRAMES _p_int[]是为21个项目创建的，但我想要的是：我已经有这样一个数组，但它可以是任何长度。它是一个包含时间段的数组，在这个数组上将建立一些东西。 但它们也应该在所有较低的时间段上可见，没有一个数组是单独或从现有的数组中额外填充它们的。因此，我在这里提到，有必要计算当前和所有较低时间段的旗帜，并在回归循环中飞快地将它们相加，从当前时间段开始跳舞。诀窍不是创建一个完整的任何东西的预设值数组（甚至是时间框架或可见性标志），并通过它们进行循环，而是在每个回合中只计算预设时间框架的不完整数组。
不，你不会的。必须确定时间框架和能见度的对应关系。或两个相应的数组，或切换。
+array with those TFs you need, +init calculate object visibility for every TF you use.类似这样的事情......)
我搞不清楚哪里出了问题。
2011.12.29 01:16:07 核心1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
2011.12.29 01:16:07 核心1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378
2011.12.29 01:16:07 核心1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
我绞尽脑汁，我不明白哪里出了问题？
这是编译器优化器的一个错误。谢谢你的留言，我们会解决这个问题。
该错误发生在以下结构中
VirtualSL!=0.0 可以从第一个if条件的第二部分中删除，因为这个表达式在第一部分被检查后始终为真。优化器错误将消失。已纠正，该修正将包含在下一个版本中。