![]() |
1
seers 63 天前 via iPhone
落库,空间换时间
|
![]() |
2
phrack 63 天前 via iPhone
不玩彩票的我根本看不懂。不是每一期开奖都是随机摇的数字吗?看以前的数据有什么用啊?
|
3
52boobs 63 天前 via Android
常见几个优化思路,并行多线程,优化算法或简化模型来减少计算量,寻找合适的数据结构并存储有用的信息。你看着点用就是了。
|
4
wxf666 63 天前
|
![]() |
5
Juszoe 63 天前
从产品角度考虑,30 秒和 1 秒对客户的区别大吗?从描述来看,每期只会计算 1 次?
值得你花大代价来优化吗?如果你单纯当作算法题来做,那是挺好的。 我想到一个最简单的方案,是预先把这 618 期算好入库,以后每期增量入库一遍,计算 C618 的所需要的 A1 到 Q15X 直接就有了,用不着复杂的优化。 |
![]() |
6
abcbuzhiming OP |
![]() |
7
abcbuzhiming OP @Juszoe 其实这是我自己在考虑要不要进行优化,客户那边,还没有进一步反馈。
它这个东西,不单单是算 618 期这么简单,是用户点击任意一期,你都得拿到这一期前 618 期的数据。 预先算题是不行的,因为历史记录已经高达 6935 期。要把这么多期都算出来,那可要不少时间。 可能上面有个人说的落盘是正道,我现在也想干脆把计算和展示分开算了,用户想重新算就点计算按钮然后等时间,平时就是展示历史数据,切换的也快 |
8
wxf666 63 天前
@abcbuzhiming #6
1. 存历史 A1 、……、C618 数据,有啥不好吗? - 数据太大? 每期 1KB ,1W 期也才 10MB 呀? - 计算太慢? 存历史后,每期只需 30 毫秒( Q15X 节省 3.6W 次计算,C618 节省 4442W 次计算), 1W 期只需 5 分钟呀? - 附带 MySQL 太麻烦? 带个 SQLite 单文件呗?这货才 1MB 。。 2. Everything 也是 for 循环遍历 file list 吧? 否则《正则》搜索全部文件,能怎么《特化场景》呢? ![]() ![]() |
![]() |
9
Juszoe 63 天前
@abcbuzhiming #7
>> 用户点击任意一期,你都得拿到这一期前 618 期的数据。 我明白,但是直接拿历史数据的速度,好过重新再把前 618 期算出来吧,再结合这堆数据把当期一算就完事了。 你刚刚又提到一个展示历史数据的需求,那入库就是最合适的方案嘛。 |
![]() |
10
yidinghe 63 天前
这个。。。你看看能不能用 SQL 写。
|
![]() |
11
clf 63 天前
入库呀。难道彩票历史的数据还能变不成?
|
12
NoOneNoBody 63 天前
java 不懂,但这个用 pandas 很容易写,性能的话,因为都是纯数字,可以用 numba 优化
A1,A2,Q15B Q15R P15B P15R 这些,只要当期结果出来,就可以计算,然后作为当期数据的附加字段一并存入数据库,以后就只是读取而已 现在就是不知道这个 C618 要算多复杂,反正从次数上看,计算量其实很少,而且是可以并发的 如果 C618 对每期来说也是定值的话,就是第 C618[n+1]计算出来后,C618[n]还是不变,那这个 C618 也是可以入库的,以后无需计算 基本上 pandas rolling 就可以 |
![]() |
13
lesismal 63 天前
A1 这种直接查 map 就行了,无需遍历
### 查表法 1. A2 这种涉及顺序的,可以使用查表的方法: 开奖结果的 hash 值作为 mapA 的 key ,因为是 5 个数字而且彩票这种数字通常不大,一个 uint64 甚至 uint32 就足够做 hash 值了。每个奖期信息作为 value 并且排序后的数组作为 map 的 value 。如果用 c++,multimap 内部红黑树自动就是排好序的,不需要自己排序数组之类的 假设不同的下标为 targetIndex=0, 然后就只要查 map hash 值得到相同的、如果不等于 targetIndex 就找 targetIndex=当前 index+1 并查找下一个 hash 相同的。当然,如果遍历平均为 5 、开销也不大, 那这种可能不划算、根据实际测试情况、可以考虑就用遍历 2. Q15B/Q15R/P15B/P15R 这些,都可以用对应期段的数据建各自对应的表,然后直接查表就能计算出 key 对应的 value 数量,不需要遍历几十期、匹配上则+1 的方式去计算 这个过程中只建表一次,然后上面的 1/2/3 都是直接查 map 就出结果了 ### C618 建表的过程可以同时根据期号做倒排索引,C618 回退 618 期、计算每期时,把上述过程中建表的只需要删除临界的一期、加入需要的一期,所以这个过程中不需要重复建整个表,只是滚动删、增一期,整个流程的建表开销不需要太大 我不了解实际需求,以上仅供参考 |
![]() |
14
Sawyerhou 62 天前 via Android
换语言,落库,并发都是可行性很高的方法。
如果实在不愿意,那就试试 java 的矩阵库,比如 Joinery(不保证好用,得看文档确认一下)。 Q15B 循环就可替换为 sum(df[31:60]==x), C618 也可类似优化。 纯循环没有索引和矩阵计算,优化起来不太容易, 手撸轮子也可,但不太有必要。 |