- 精华
- 0
- 在线时间
- 369 小时
- UID
- 1986
- 积分
- 777
- 帖子
- 74
- 阅读权限
- 60
- 注册时间
- 2008-7-25
- 最后登录
- 2019-3-30
- 精华
- 0
- UID
- 1986
- 积分
- 777
- 帖子
- 74
- 主题
- 11
- 阅读权限
- 60
- 注册时间
- 2008-7-25
- 最后登录
- 2019-3-30
|
以前正常工作的代码,在3.2.8版里结果不正常,换回老版又正常,最后发现是新版里Text函数转6位以上数值时,自动用了科学记数法,才导致问题的出现。
例如,日期数值,4位年份+2位月份+2位日期,共8位数,用科学计数法后就只有6位有效数字:
日线级别上每个Bar的日期转文本输出到外部文件,源代码为FileAppend("C: \\Formula.log","CurrentBar="+Text(CurrentBar)+" Date="+Text(Date));
输出结果:
CurrentBar=19 Date=2.01004e+007
CurrentBar=20 Date=2.01004e+007
CurrentBar=21 Date=2.01004e+007
CurrentBar=22 Date=2.01005e+007
CurrentBar=23 Date=2.01005e+007
CurrentBar=24 Date=2.01005e+007
而在以前版本里,结果应该是:
CurrentBar=19 Date=20100428
CurrentBar=20 Date=20100429
CurrentBar=21 Date=20100430
CurrentBar=22 Date=20100504
CurrentBar=23 Date=20100505
CurrentBar=24 Date=20100506
本来将日期写数据库再读出后还能做精确到日的比较,现在有效位数只有6位,相应的比较只能精确到月了。
日期还好办,是定长格式的数值,大不了按照当年解决千年虫的思路逆向操作,减少位数,也能凑合着规避,但
如果记录的是绩效,就麻烦了:各位操作股指的,输赢应该都是上十万了吧?用科学记数法,起码除非绩效发生数量级的变化,否则都被抹平了。而且绩效这种数值,从0到无穷大,都有可能,用户没法自己在代码里打补丁,也不应该让用户打这种补丁。
同时必须考虑到,策略易是需要通过数据库与相应的图表互动的,而数据库里的记录只能用文本格式,数值和文本之间的转换非常频繁而重要。
现在,如果要使用新版,用户只好手工检查以往代码里每一处涉及6位数以上文本转换的部分,这样的工作量和隐患是用户无法承受的。不知道此次修改是否必须,至少留一个选项,让用户可以自行决定用哪种方式转换数值。
急盼回音! |
|