Rss & SiteMap

金字塔客服中心 - 专业程序化交易软件提供商 http://www.weistock.com/bbs/

专业程序化软件提供商
共12 条记录, 每页显示 10 条, 页签: [1] [2]
[浏览完整版]

标题:[建议]建议增加历史数据。。。

1楼
bhwhui 发表于:2009/10/6 1:12:03
对于系统交易者。历史数据是很重要的,就m而言最早到2008年7月,是否少了些?建议增加到至少3年的数据(某些新品种除外)。。。
2楼
bhwhui 发表于:2009/10/6 1:14:06
不好意思,我说的是5min的数据,在“选项”里我已将5min存储改为429496周期,1min改为500,最大了吧。
[此贴子已经被作者于2009-10-6 1:15:06编辑过]
3楼
admin 发表于:2009/10/6 1:38:54

服务器目前没有这么多数据,你要很长的历史数据,到网上找找看。

目前金字塔的5分钟数据只要总体文件不超过2G大小情况支持任意大小的周期

4楼
bhwhui 发表于:2009/10/7 23:46:04

“总体文件”您是指某个目录,还是单个文件?例如上海期货数据放在data的哪个目录下?

稍微看了看,牛啊,近一年的数据1min,5min合计不到2m,2G是什么概念?能存1000年的数据?牛!

5楼
admin 发表于:2009/10/8 2:23:35

2G限制是指的单个市场的不同类别的数据。你打开DATA目录进一个市场看看就知道了,比如MIN1.DAT这个文件,不能超过2G。

目前期货市场由于品种少,所以数据量不会超过2G,但是对于股票就不够用了。后面的升级版会逐渐解决这个问题,采取64位的架构来做

6楼
金骄 发表于:2009/10/12 22:59:57
5分钟数据80天就足够了。 如果超过80天的还不够,可以用日线来研究。 如果日线还不够,那就用周线来研究。 1分钟数据,正常的3天就够了。如果3天不够用5分钟线来完成。 服务器增加了数据量,同样的增加带宽和系统资源消耗,增加运营成本。 降低系统的效率。几百人使用,可能感觉不明显,如果是几千上万人,那……
7楼
金骄 发表于:2009/10/12 23:04:02
要用到3年的5分钟历史数据,请告诉一下原理行吗? 我真的想象不出需要这么长时间的历史数据有什么用? 80天×40=320个周期,一般的均线最多也就250个周期。则320个周期足够计算出买卖条件了。 建议服务保留120天5分钟数据,20天1分钟数据,就可以满足绝大多数用户的需要。
8楼
bhwhui 发表于:2009/10/14 18:38:34

楼上是否在MACD等论坛叫"天骄期货"?呵呵呵,

如果是,您的"k线踏浪"系统我一直很感兴趣.我也一直在想构造原理,也一直怀疑系统用到了多时间架构.或者用到了波浪序列,我也编有类似的系统,不过不够你的好,反应不够你的快.向你请教.

看过你的博客,如果文章是原创,绝对的高手.特别是分时的8种分类,你一直没有写清楚,呵呵呵

 

每个人设计系统的出发点不同,我自己有个基本的前提,交易次数需要满足基本统计要求,起码需要200次以上的交易测试,

从这个角度出发,根据系统的不同,需要的历史数据量也不同,不对之处,请教....

 

9楼
bhwhui 发表于:2009/10/14 18:50:16

哦,看了几个您的回帖,不会是在说股票吧?

 

股票以前做过一段时间,确实,5min根本没必要要,日线,周线足以....

10楼
金骄 发表于:2009/10/15 21:39:51

你是为了测试而让我们的服务器增加盘后数据,有点说不过去!

 

如果你觉得有必要,服务器可以帮你挂个下载文件,提供下载,然后导入就可以了。

 

注意是下载文件,接口不能直接下载!

 

80天×40根=3200个5分钟线,一般的均线最多也就250个周期。 以后服务器接口直接下载的还要再少,5分钟数据期货最多120天,一分钟最多20天。 股票可能还要再少。

 

没有必要,假设有人120天都没有开一次软件,那算什么事呀!

假如有人需要那么长时间的5分钟线,说明这人是懂做期货的,可以从别的软件导入即可。

 

为了降低成本,请多多包涵。

 

声名: 咱不是金融天骄,也不是天骄期货。

 

意为金骄期货接口,金骄意为金屋藏娇,就是好的意思。

 

此帖希望管理员能看到,也希望有不同意见的朋友提出各自的观点。我相信这样的盘后数据99%的人都不会有意见的。

[此贴子已经被作者于2009-10-15 21:43:03编辑过]
共12 条记录, 每页显示 10 条, 页签: [1] [2]


Powered By Dvbbs Version 8.3.0
Processed in .17188 s, 2 queries.