测试 "CopyTicks"。 - 页 23 1...161718192021222324252627282930...47 新评论 fxsaber 2016.10.18 14:21 #221 Renat Fatkhullin:最理想的做法是把你需要深入的东西下载给自己一次，然后只在微秒内从附近的缓存中下载新的东西。如果你每次都做深层查询，而又无法进入磁盘，那当然是你自己的错。 你能给我看看9月第一周的蜱虫历史最优化检索的代码吗？ Renat Fatkhullin 2016.10.18 14:44 #222 fxsaber: 你能告诉我获取9月第一周的蜱虫历史的最佳方法的代码吗？自己写吧，这不是一件难事。查询准确的日期并将其保存在本地数组中。在缓冲区外工作时，不存在优化。只有当你从缓存中下载最后4096个刻度时，优化才有意义。 fxsaber 2016.10.18 14:49 #223 Renat Fatkhullin:自己写吧，这不是一件难事。对确切的日期进行查询，并存储在一个本地数组中。这样，你就不能事先知道在所需的间隔上有多少个刻度。没有办法确定计数参数。问题就在这里。要抽出自9月初以来的所有历史，设置计数=万亿--当然，你可以。然后使用二进制搜索在数组中找到结束日期并截断。但这个三里屯根本就不是一个技术性的方法。要么我们需要用from、to重载这个函数。或对数据库的索引访问。 [删除] 2016.10.18 14:56 #224 Renat Fatkhullin:优化只有在从缓存中下载最后4096个刻度时才有意义。从参考资料来看。速度输出： 终端在缓存中为每个符号存储4096个最后的刻度，以便快速访问（对于有运行堆栈的符号--65536个刻度）。 还有大约65536个ticks（含堆栈）--这不已经是最佳状态了吗？ Renat Fatkhullin 2016.10.18 19:08 #225 我们将在下一个版本中准备对CopyTicks进行改进。也许我们会让快速缓存自适应地自动扩展到128k ticks，这将允许编写更容易的程序（不需要麻烦地下载，而且经常可以直接从快速缓存中获得所需的容量）。我们将增加一个额外版本的函数，所以它将有可能接受带有确切日期的报价，从&到 fxsaber 2016.10.18 19:54 #226 Renat Fatkhullin:我们将在下一个版本中准备对CopyTicks进行改进。可能会使快速缓存具有自动扩展到128k ticks的自适应性，这将允许编写更容易的程序（不需要麻烦地恢复下载，并且经常直接从快速缓存中获取所需的容量）。我们将增加一个额外版本的功能，能够接受有确切日期的报价，从和到。谢谢你!关于完全加载的历史从&到，可能，会说零GetLastError。请注意，现在（而且随着你所介绍的改进措施的出台），要想得到从时间之前的勾选是非常困难的。因此，我建议使计数和负数--不仅对未来（向右），而且对过去（如从==0）的刻度要求。那么查询以前的历史就会一直很方便，而且是最佳的（你的实现）。 [删除] 2016.10.19 05:11 #227 fxsaber:谢谢你!一个完全下载的历史记录从&到可能会由一个零的GetLastError表示。请注意，现在（以及你所指出的改进措施的引入），要获得从时间之前的勾选是非常困难的。因此，我建议使计数和负数--不仅对未来（向右），而且对过去（如从==0）的刻度要求。那么查询以前的历史就会一直很方便，而且是最佳的（你的实现）。 最好让CopyTicks()的重载一次完成，与其他Copy...()函数一样。 fxsaber 2016.10.19 05:15 #228 Alexey Kozitsyn: 最好使CopyTicks()的重载与其他Copy...()函数相同。 那么我们将不得不放弃默认计数和从。 [删除] 2016.10.19 05:45 #229 fxsaber: 那么我们就必须放弃默认的计数和从。为什么？以CopyBuffer为例，我们现在有了这个。intCopyBuffer( intindicator_handle,// 指示器手柄 intbuffer_num,// 缓冲区编号 的指标datetimestart_time。//日期 intcount,//有多少个copy doublebuffer[]// 数组，数据将被复制到这里。);有一个计数和从（start_time）。你建议添加这个。intCopyBuffer( intindicator_handle,// 指示器手柄 intbuffer_num,//指标缓冲区编号datetimestart_time。// 从哪个日期开始datetimestop_time,// 直到什么日期doublebuffer[]// 数组，数据将被复制到这里。);所以我们可以双向复制，对吗？只是，用ulong（以微秒为单位）代替datetime。我将在将来为其他一些目的添加这种重载。intCopyBuffer( intindicator_handle,// 指示器手柄 intbuffer_num,// 指示器缓冲区编号 intstart_pos,//我们从哪里开始 intcount,//我们复制多少个 doublebuffer[]// 阵列，将复制数据)。这就是全部。 [删除] 2016.10.19 05:48 #230 fxsaber: 那么我们将不得不放弃默认计数和从。起初没有仔细阅读...是的，我必须这样做。那又怎样？如果开发者会扩大缓存--只有在加载足够大的tick history 时才会慢一些，而且往往没有必要这么做。而对于实时加载不会受到任何影响（将从缓存中获取）。我认为从日期到日期的加载，比试图保存默认参数要重要得多。 1...161718192021222324252627282930...47 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
最理想的做法是把你需要深入的东西下载给自己一次，然后只在微秒内从附近的缓存中下载新的东西。
如果你每次都做深层查询，而又无法进入磁盘，那当然是你自己的错。
你能告诉我获取9月第一周的蜱虫历史的最佳方法的代码吗？
自己写吧，这不是一件难事。
查询准确的日期并将其保存在本地数组中。在缓冲区外工作时，不存在优化。只有当你从缓存中下载最后4096个刻度时，优化才有意义。
自己写吧，这不是一件难事。
对确切的日期进行查询，并存储在一个本地数组中。
这样，你就不能事先知道在所需的间隔上有多少个刻度。没有办法确定计数参数。问题就在这里。
要抽出自9月初以来的所有历史，设置计数=万亿--当然，你可以。然后使用二进制搜索在数组中找到结束日期并截断。
但这个三里屯根本就不是一个技术性的方法。要么我们需要用from、to重载这个函数。或对数据库的索引访问。
优化只有在从缓存中下载最后4096个刻度时才有意义。
从参考资料来看。
速度输出： 终端在缓存中为每个符号存储4096个最后的刻度，以便快速访问（对于有运行堆栈的符号--65536个刻度）。
我们将在下一个版本中准备对CopyTicks进行改进。
我们将在下一个版本中准备对CopyTicks进行改进。
谢谢你!
关于完全加载的历史从&到，可能，会说零GetLastError。
请注意，现在（而且随着你所介绍的改进措施的出台），要想得到从时间之前的勾选是非常困难的。因此，我建议使计数和负数--不仅对未来（向右），而且对过去（如从==0）的刻度要求。
那么查询以前的历史就会一直很方便，而且是最佳的（你的实现）。
谢谢你!
一个完全下载的历史记录从&到可能会由一个零的GetLastError表示。
请注意，现在（以及你所指出的改进措施的引入），要获得从时间之前的勾选是非常困难的。因此，我建议使计数和负数--不仅对未来（向右），而且对过去（如从==0）的刻度要求。
那么查询以前的历史就会一直很方便，而且是最佳的（你的实现）。
最好使CopyTicks()的重载与其他Copy...()函数相同。
那么我们就必须放弃默认的计数和从。
为什么？以CopyBuffer为例，我们现在有了这个。
intindicator_handle,// 指示器手柄
intbuffer_num,// 缓冲区编号 的指标
datetimestart_time。//日期
intcount,//有多少个copy
doublebuffer[]// 数组，数据将被复制到这里。
);
有一个计数和从（start_time）。
你建议添加这个。
intindicator_handle,// 指示器手柄
intbuffer_num,//指标缓冲区编号
datetimestart_time。// 从哪个日期开始
datetimestop_time,// 直到什么日期
doublebuffer[]// 数组，数据将被复制到这里。
);
所以我们可以双向复制，对吗？只是，用ulong（以微秒为单位）代替datetime。
我将在将来为其他一些目的添加这种重载。
intCopyBuffer(
intindicator_handle,// 指示器手柄
intbuffer_num,// 指示器缓冲区编号
intstart_pos,//我们从哪里开始
intcount,//我们复制多少个
doublebuffer[]// 阵列，将复制数据
)。
这就是全部。
那么我们将不得不放弃默认计数和从。
起初没有仔细阅读...是的，我必须这样做。那又怎样？如果开发者会扩大缓存--只有在加载足够大的tick history 时才会慢一些，而且往往没有必要这么做。而对于实时加载不会受到任何影响（将从缓存中获取）。
我认为从日期到日期的加载，比试图保存默认参数要重要得多。