向MQL4大师们提问。还是关于双倍比较。 - 页 7

新评论
 
SK. писал (а):

这场对话似乎会无休止地进行下去。当一个新用户获得适当的经验和知识时，他通常有时间撞见规范化几次。

也许在MT5中，在进行比较操作时，强行限制实数的准确性是有意义的，比如，限制在小数点后8位（即强行执行NormalizeDouble()，数字=8）。

我不会指望你这样做。绝对不可能!
如果比较操作将被反复使用（在循环计算中，等等），那么在输入上四舍五入到8位数，输出误差可以与1相称。

我在计算SmoothedAvarege方面有这样的经验，一年前在我的应用程序中计算它。之后，我试图选择这样的工作方法，不影响双打的数字能力。
或者，正如重力001 建议的那样，改用INTAM（正如你所理解的那样，这非常耗时）。
 
SK. писал (а):

也许在MT5中，当执行比较操作时，强行限制实数的准确性，例如，小数点后8位（即强行执行NormalizeDouble()，数字=8）是有意义的。


然而，不仅是用户定义的操作拖慢了终端的速度，而且隐藏的操作也是如此。在我看来，最好是简单地在语言中引入ComparePrice函数。顺便说一下，就像Irtron一样，我认为Point/2是一个自然的措施（也许Point*0.5更好）。为了避免每次都进行除法/乘法，这一半可以成为一个预定义的变量。在不存在之前，你可以自己输入这样一个变量，并在第一次启动时计算一次。虽然，开发者可以用预定义的精度来制作双重比较的功能，即相同的，但用数字代替点/2。
 
Depfy:

你把事情搞得一团糟......:)

浮点数的比较是通过比较差值的模数与一个小的阈值来完成的。

例如，返回（fabs(d1-d2) < 1e-10）。

浑水摸鱼有什么意义......NormalizeDouble(...)函数只是为了获得漂亮的报告。

谢谢你的例子。
但你没有抓住重点，你需要更仔细地阅读。问题的实质是一般的编程风格，以及在MT4的具体案例中。
 
VBAG:
邓飞。

你把事情搞得一团糟......:)

浮点数的比较是通过比较差值的模数与一个小的阈值来完成的。

例如，返回（fabs(d1-d2) < 1e-10）。

浑水摸鱼有什么意义......NormalizeDouble(...)函数只是为了获得漂亮的报告。

谢谢你的例子。
但你没有抓住重点，你需要更仔细地阅读。问题的实质是一般的编程风格，以及在MT4的具体案例中。

你最好告诉我们这个问题的重点是什么。否则暗示--我不！明白 :)

如果我们谈论的是速度，现代处理器执行浮点运算时

几乎和整数的一样快。至于风格，对不起，实用主义的规则...。

当ASHIPS在身边时，我们谈论的是什么样的风格......只要它能发挥作用就好。

否则，除了比较两个数字，没有其他问题 :))))))))

 
VBAG:
我没有想到你会有这样的表现。在任何情况下，你都不能这样做!
如果比较操作将被反复使用（在反复计算中，等等），那么如果你在输入时四舍五入到8位数，输出的误差可以与1相称。

我在计算SmoothedAvarege方面有这样的经验，一年前在我的应用程序中计算它。之后，我试图选择这样的工作方法，不影响双打的数字能力。
或者，正如重力001 建议的那样，改用INTAM（正如你所理解的那样，这非常耗时）。


等一下。没有必要急于下结论。

首先。我不建议强行将实数变量本身的实际值取整。我建议在计算比较操作的结果时，强制对变量的比较值（副本）进行四舍五入（对于默认情况）。当然，也不能触及变量的实际值。在这种情况下，其他的计算值不会受到影响，因为在比较操作中使用的变量的原始值保留了它们的价值，循环计算的错误不会累积。

第二。我说，为了消除后果更严重的错误，我们可以走这条路。然而，为了提供更苛刻的计算，有必要保留使用指定参数的NormalizeDouble()函数的可能性。

所以我的建议并没有限制语言的能力，而是扩展了它们。

然而，考虑到在比较操作中，通常使用的是价格值（即数字=4），在绝大多数情况下，这种错误根本不会发生。因此，使用拟议的技术将减少导致不可预测的后果的错误数量。

 
lna01:
在没有这种情况下，你可以输入这样一个变量，在第一次启动时计算一次。

你不能。

或者说，你可以编写程序字符串，但没有人（包括开发人员）会保证这个变量的值在EA的整个生命周期内严格保持不变。 这不是关于程序代码的准确性，而是关于计算的技术特点和存储变量值的技术规则。如果不是这样，这个问题根本就不会存在。

按照目前的情况，初始值123.00000000000的变量在被用于计算的时候可以显示为122.999999999999。尽管该变量的值自创建以来从未改变过，只是被程序调用参与其他计算。

这实际上就是为什么会有这些大惊小怪的事情发生。这就是为什么我们创造了使用NormalizeDouble()的必要性，尽可能地接近实际计算，最好是直接在if、for、while语句的条件下使用。

 
SK. писал (а):
lna01:
虽然这一点不可用，但你可以自己输入这样一个变量，并在启动的第一次启动时计算一次。

你不能。

或者说，你可以编写程序字符串，但没有人（包括开发人员）会保证这个变量的值在EA的整个生命周期内严格保持不变。 这不是关于程序代码的准确性，而是关于计算的技术特点和存储变量值的技术规则。如果不是这样，这个问题根本就不会存在。

按照目前的情况，初始值123.00000000000的变量在被用于计算的时候可以显示为122.999999999999。尽管该变量的值自创建以来从未改变过，只是被程序调用参与其他计算。

这其实就是为什么会有这些大惊小怪的事情发生。这就是为什么我需要在尽可能接近实际计算时使用NormalizeDouble()，最好是在if、for、while语句的条件下使用。

天哪，我想我开始明白所有的大惊小怪是怎么回事了......

总而言之，我想你不需要编造什么。这一切都取决于情况。目标是什么？如果两个数字的尾数可以相差0.1，如果它是关键的，那是一回事，如果它不重要，那是另一回事。这取决于彼此之间的比较。但是，真正的编译器所提供的灵活性是真实的和必要的，IMHO。

:)

 
SK. писал (а):
这里的问题不是程序代码的准确性，而是计算的技术特点和存储变量值的技术规则。如果不是这样，这个问题就不会出现了。
关于计算，这是真的，但在我看来，有了存储，一切都会变得更好。而当数字=4时，第15位数字的差异不应起到作用。
 
Depfy:

天哪，我想我开始明白所有的大惊小怪是怎么回事了......

一般来说，我不认为有任何东西是可以编造的。因为这一切都取决于具体的情况。目标是什么？如果两个数字的尾数可以相差0.1，如果它是关键的，那是一回事，如果它不重要，那是另一回事。这取决于彼此之间的比较。但是，真正的编译器所提供的灵活性是真实的和必要的，IMHO。

:)


我无法回答 "编造 "的问题。显然，这取决于要思考的问题：)

例如，在某些情况下，像Point/2这样的发明确实可以使计算具有一定的准确性。 然而，最好使用开发人员的建议，即一劳永逸（直到新的文档），在计算比较操作时，将使用NormalizeDouble()函数作为一项规则。

 
lna01:
SK.写道：（a）。
这里的问题不是程序代码的准确性，而是计算的技术特点和存储变量值的技术规则。如果不是因为这个，这个问题甚至不会出现。
对于计算来说是这样的，但我想对于存储来说应该是更好的。而在数字=4的情况下，第15位数字的差异应该不重要。

而且，如果你使用NormalizeDouble()，也不会有问题。而如果你不使用它，那就是运气问题了。
1234567891011
新评论