差分微积分,例子。 - 页 22 1...15161718192021222324 新评论 Volodymyr Zubov 2021.02.26 20:26 #211 Aleksey Panfilov:你的意思是,这个公式不会,相当,在电脑上工作? 它将会工作,为了工作,你需要考虑任何CPU如何处理二进制代码。 Volodymyr Zubov 2021.02.26 20:28 #212 Aleksey Panfilov:你的意思是,这个公式不会,相当,在电脑上工作? 1+1不会永远是2 所以当你编译(1+1)时,出现2的机会更大。 如果1.0001+1.00000009,那么两个将是99%,但1%不会) Aleksey Panfilov 2021.02.26 20:40 #213 Volodymyr Zubov:1+1并不总是=2当编译(1+1)时,出现2的概率更高如果是1.0001+1.00000009,那么两个将是99%,但1%不会) 是的,我遇到了成本,大约是小数点后的十分之一,(我认为这是可以接受的),如果我用目测的方式进行计算。 诚然,并非所有项目都能接受这一点。当工作中的结果与其他程序收到的预期结果不一致时,我就在我的用户算法中寻找错误,如果我没有找到,我就不得不拒绝使用程序。 Volodymyr Zubov 2021.02.26 20:48 #214 Aleksey Panfilov:是的,我确实遇到过超过小数点后十分之一的费用,(我认为这是可以接受的),如果我用目测的方式检查计算结果。的确,这在所有项目中都不太适应。当结果与另一个程序的预期结果不一致时,我就会寻找错误,如果找不到,我就不得不拒绝使用该程序。 这不是一个MQL错误。这是自x386以来微处理器中的一个错误,我们必须习惯它(错误)并以编程方式纠正它。英特尔甚至没有在i9中修复这个错误。 Aleksey Panfilov 2021.02.26 20:57 #215 Volodymyr Zubov:这不是一个MQL错误。这是自x386以来微处理器中的一个bug,你必须习惯它(这个bug) ,并以编程方式修复它。英特尔甚至没有在i9中修复这个错误。 可能在这方面不是很擅长。我想这是一个独立的工作领域,离我很远。) Aleksey Panfilov 2021.02.26 21:02 #216 Volodymyr Zubov:这不是一个MQL错误。这是自x386以来微处理器中的一个bug,你必须习惯它(这个bug),并以编程方式修复它。英特尔甚至没有修复i9的 这个错误。 那么AMD的处理器呢? Volodymyr Zubov 2021.02.26 21:02 #217 Aleksey Panfilov:这里可能不强。我想这是一个独立的行当,与我相去甚远。) 你对此无能为力。1992年以来的所有处理器都有这个错误。它让程序员把它考虑在内。 Volodymyr Zubov 2021.02.26 21:04 #218 Aleksey Panfilov:而AMD的处理器呢? 英特尔有所有的关键证书,AMD有同样的错误。 Renat Akhtyamov 2021.02.28 07:40 #219 Aleksey Panfilov:之前已经推荐过这个话题。我再次推荐它。https://dxdy.ru/post1247421.html#p1247421我想指出该主题中的帖子编号本身,它是一个娱乐性的帖子:)))。 是否有一个实施方案? 比如说截图? Aleksey Panfilov 2021.02.28 16:31 #220 Renat Akhtyamov:是否有一个实施方案?比如说截图? 纯数学的一部分? 甚至可能是纯A_rif_metrics。 你一定是在开玩笑,对吗? )) 1...15161718192021222324 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
你的意思是,这个公式不会,相当,在电脑上工作?
它将会工作,为了工作,你需要考虑任何CPU如何处理二进制代码。
你的意思是,这个公式不会,相当,在电脑上工作?
1+1不会永远是2
所以当你编译(1+1)时,出现2的机会更大。
如果1.0001+1.00000009,那么两个将是99%,但1%不会)
1+1并不总是=2
当编译(1+1)时,出现2的概率更高
如果是1.0001+1.00000009,那么两个将是99%,但1%不会)
是的,我遇到了成本,大约是小数点后的十分之一,(我认为这是可以接受的),如果我用目测的方式进行计算。
诚然,并非所有项目都能接受这一点。当工作中的结果与其他程序收到的预期结果不一致时,我就在我的用户算法中寻找错误,如果我没有找到,我就不得不拒绝使用程序。
是的,我确实遇到过超过小数点后十分之一的费用,(我认为这是可以接受的),如果我用目测的方式检查计算结果。
的确,这在所有项目中都不太适应。当结果与另一个程序的预期结果不一致时,我就会寻找错误,如果找不到,我就不得不拒绝使用该程序。
这不是一个MQL错误。这是自x386以来微处理器中的一个错误,我们必须习惯它(错误)并以编程方式纠正它。英特尔甚至没有在i9中修复这个错误。
这不是一个MQL错误。这是自x386以来微处理器中的一个bug,你必须习惯它(这个bug) ,并以编程方式修复它。英特尔甚至没有在i9中修复这个错误。
可能在这方面不是很擅长。我想这是一个独立的工作领域,离我很远。)
这不是一个MQL错误。这是自x386以来微处理器中的一个bug,你必须习惯它(这个bug),并以编程方式修复它。英特尔甚至没有修复i9的 这个错误。
那么AMD的处理器呢?
这里可能不强。我想这是一个独立的行当,与我相去甚远。)
你对此无能为力。1992年以来的所有处理器都有这个错误。它让程序员把它考虑在内。
而AMD的处理器呢?
英特尔有所有的关键证书,AMD有同样的错误。
之前已经推荐过这个话题。
我再次推荐它。
https://dxdy.ru/post1247421.html#p1247421
我想指出该主题中的帖子编号本身,它是一个娱乐性的帖子:)))。
是否有一个实施方案?
比如说截图?
是否有一个实施方案?
比如说截图?
纯数学的一部分? 甚至可能是纯A_rif_metrics。
你一定是在开玩笑,对吗? ))