错误、漏洞、问题 - 页 257

[[删除]]

alexvd:

它看起来并不像。

事实证明，只有2次（45次）亏损的交易，都是买入。

也许我找错了地方？

标记为红色：空头头寸是45个中的5个。让我们假设40是95%。问题--为什么5=100%，假设-5%是符合逻辑的。

虽然在我看来，在这种情况下，应该是5（11.11%）和40（88.89%）。

alexvd:

试着清除缓存。尝试了不同的选项，不同的浏览器--添加成功了。

你是 直接在评论中插入图片，而不是作为附件，是吗？

是的，在文本中。我会试试的，虽然它被添加到这个论坛上没有任何问题...:)

[Alexey Da]

Interesting:

标记为红色：空头头寸是45个中的5个。比方说，40是95%。问题--为什么5=100%，假设5%是符合逻辑的。

虽然，在我看来，应该有5个（11.11%）和40个（88.89%）交易。

一共有45个交易。

1. 出售时5元，购买时40元
   
2. 2个无利可图（2个要买），43个有利可图（总数）。

这里我们有以下结果

5笔卖出交易--5笔，而且100%盈利（不亏损）（即所有交易都是盈利的）。

买入交易 - 40笔，其中38笔是盈利的，即38*100%/40=95%。

更多

有利可图的交易 - 45个中的43个，即43*100%/45=95.56%。

亏损交易 - 45笔中有2笔，即2*100%/45=4.44%。

[[删除]]

alexvd:

一共有45个交易。

1. 出售时5元，购买时40元
   
2. 2次亏损交易（2次买入交易），43次盈利交易（总计）。

我们拥有的交易总数

卖出交易--5笔，其中获胜（而非失败）的交易--100%（即所有交易都是盈利的）。

买入交易 - 40笔，其中38笔是盈利的，即38*100%/40=95%。

更多

有利可图的交易 - 45个中的43个，即43*100%/45=95.56%。

亏损交易 - 45笔中的2笔，即2*100%/45=4.44%。

谢谢你，现在很清楚什么是什么了。

[[删除]]

我已经注意到这种效果。当把指标 添加到图表中 时（在一个单独的窗口中），主蜡烛图停止更新（价格冻结），尽管在有报价的窗口中一切正常 - 价格从红色变为绿色。尽管该指标只被添加到一个符号的窗口中，但价格在另一个窗口中也被冻结。指标的初始化和计算都在正文中：如果（prev_calculated==0）。不从前一天开始的收盘价参与计算（当前收盘价不参与）。在指标计算完成后，价格开始与窗口同步移动和变化。
你可以在图片中看到它。

[Alexey Da]

-Alexey-:

我已经注意到这种效果。当把指标 添加到图表中 时（在一个单独的窗口中），主蜡烛图停止更新（价格冻结），而在有报价的窗口中一切正常 - 价格从红色变为绿色。尽管该指标只被添加到一个符号的窗口中，但价格在另一个窗口中也被冻结。指标的初始化和计算都在正文中：如果（prev_calculated==0）。不从前一天开始的收盘价参与计算（当前收盘价不参与）。在指标计算完成后，价格开始与窗口同步移动和变化。
你可以在图片中看到它。

第一个计算结果是非常耗费资源。检查一下，也许指标代码没有以最理想的方式编写。

[[删除]]

alexvd:

第一个计算结果是非常耗费资源。检查指标代码是否没有以最优化的方式编写。

亲爱的 alexvd，不幸的是，指标现在有3000多行代码，有20多个类，而且很难对代码进行优化（循环中的几千亿次计算操作），这个数字可能会增长到10000大概。我的意思是，有可能以某种方式将蜡烛图中的报价更新分离到一个单独的程序线程中，将指标计算的加载分离到一个单独的线程中。坦率地说，当我开始工作时，我不认为性能问题会在台式电脑上出现得如此迫切，而我也想使用一台小型笔记本电脑。

[Anton]

-Alexey-:
我的意思是，可以将蜡烛图中的报价更新分离到一个单独的程序流程中，将指标计算 的加载分离到另一个流程中。

图表中报价的更新只是显示终端的基础数据，指标也是在此基础上计算的。为了节省资源，终端基础数据作为输入数据传递给指标，即在指标计算完成之前不能改变。

[[删除]]

antt:
在图表上更新报价只是显示终端数据库的数据，这些数据也被用来计算指标。为了节省资源，终端基础数据作为输入数据传递给指标，即在计算指标 之前不能改变。

明白了，谢谢!

[[删除]]

-Alexey-:
亲爱的 alexvd，不幸的是，指标现在有3000多行代码，由大约20多个类组成，而且优化代码相当困难（循环中的几千亿次计算操作），而这个数字可能会增长到10000左右。我的意思是，有可能以某种方式将蜡烛图中的报价更新分离到一个单独的程序线程中，将指标计算的加载分离到一个单独的线程中。坦率地说，当我开始工作时，我没有想到性能问题会在台式电脑上出现得如此迫切，而我也想使用一台小型笔记本电脑。

尝试优化指标的性能，对象和线条的数量并不重要。最有可能的是使现有的指标（有3000行）以必要的速度工作。

一个有趣的变体是把所有资源密集型的计算放到定时器中（如果它看起来是可行的），那么这些计算将不会在每个tick上执行。

而且我想尽可能地优化计算器的盒子（在合理的范围内）。

[[删除]]

Interesting:

尝试优化指标，对象和线条的数量并不重要。最有可能的是使现有的指标（有3000行）以必要的速度工作。

一个有趣的变化是，如果我们把所有资源密集型的计算放在一个定时器中（如果可能的话），那么这些计算将不会在每一个tick上执行。

而计算器块应该尽可能地优化（在合理的范围内）。

原则上，有可能对工作进行一些优化，因为一些相同的数据是在不同类别的对象中计算的，也就是说不是一次。但在这里我们面临另一个问题，即--远离许多黑盒子的概念，每个黑盒子都可以被调试，并对它充满信心（即每个对象是一个完全自主的单元，如果计算一些中间数据，在不同的对象中是相同的，移动到对象之外，自主性将失去，允许单独调试每个类。在这种情况下，程序的结构化就会丢失，也就是说，我将无法理解我所写的东西，而且最轻微的错误也不可能抓住。调试速度也将大大增加，因为我必须运行整个算法，而不是只运行其中的一小部分。这就是物体的数量对速度的影响。

这就是为什么我认为类似的优化可能会在最后阶段尝试，当指标完全创建、调试和测试后，但不幸的是，这仍然是一个漫长的过程（我已经在初始阶段工作了大约4个月，因为我终于意识到我已经准备好尝试它了）。在计量经济学和数学的书籍中，所有的东西都分散在不同的书中（实际上没有统一的材料细节介绍），作者在术语和算法上有错误和差异，初学者只有在参考百科全书式的字典时才能发现，理论信息与实际实现的可能性相冲突，即以数值方法的形式实现，而数值方法本身又对软件环境的功能提出了要求），这个过程是漫长而乏味的。

根据计算的逻辑，它必须在每根蜡烛形成后发生，所以它原本应该被放在 "是新条 "函数的主体 中，但它的时间可以超过这个间隔的事实使我把它放在if(prev_calculated==0)函数的主体中，这样它在调试阶段就只发生一次。我会考虑你的定时器建议 - 谢谢。