V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  123128xyz  ›  全部回复第 2 页 / 共 4 页
回复总数  77
1  2  3  4  
16 天前
回复了 123128xyz 创建的主题 程序员 我预判,第一波 AI 洪峰已过!
@Nasdaq 好的,帖子并非拉战,仅分享我的观察与感受,个人自认为对趋势较为敏感。
16 天前
回复了 123128xyz 创建的主题 程序员 我预判,第一波 AI 洪峰已过!
@nevin47 dram 需求暴增,因为订单并非及时数据,他有生产周期,与下阶段的本地部署叠加。
16 天前
回复了 123128xyz 创建的主题 程序员 我预判,第一波 AI 洪峰已过!
@loop00 无法提供,非广告贴。
16 天前
回复了 123128xyz 创建的主题 程序员 我预判,第一波 AI 洪峰已过!
@dif 简单粗暴有道理!不过我感觉 glm 不能代表专业/普通人两种,恰好处于中间,高端需求满足不了,不会代码的人,不会硬抢。
@lavvrence 这个复权方式考虑过了,解决不了分钟 k 的复权。

经过测试,使用了一种最天才的算法,累计因子时间轴表( Cumulative Factor Timeline )
结合 stockdb 原生后缀扫描,实现快速取值计算。

stockdb:累计因子计算得到 18.67
同花顺:减法前复权得到 18.66 。
东方财富:采用 3 位精度+0.01 元的向上漂移得到 18.67 。
新浪:采用普通比例乘法复权,精度上保留了 4~5 位得到开盘 18.64

源码已更新,自带 fq 参数,支持前后左右复权。。
@zeldalyc 这个是自带 api ,sdk+自带分钟 k+自动复权,自带更新
@kingmo888 前复权数据是有问题的,所以原始已经改成不复权了,自动复权。
18 天前
回复了 xxxman 创建的主题 程序员 這一年來跟著 AI 發展的心得
我没有理解这个逻辑
[供-(程序员/AI)-需],中间只是路径。
1 、需求端悖论:原本的高价值需求程序员/外包早就可以实现,嫌成本太高那就是利益有限,利益有限那就代表教育/获客成本不对等。AI 出来是缩短了程序周期。但这些待开发的需求,又往往是并不急切的,跟 AI 提升代码速度正好相反!
2 、供应端悖论:tob 这我一直在思考,行业需求确实存在。更多的是需要扎进去,扎得越深理解越深,角色变成工人+程序员。我想问:我一个程序员如何扎到一个陌生产业,并且快速发现需求,发现需求之后,我又换一个新行业发现需求。

个人感觉 AI 未来,不在程序。而在于无限部署,边际成本趋近于 0 ,比如原本 10 万社区监控员,覆盖不了一个省,人力不能及,而换成 Ai 可以 24 小时监控,无限部署。
@goudanli 下一个版本 free-stockhq.实时+交易
@littlepanic72 实时 websocket 推送 + 交易 api 才会用到。本身也是自己在用,不限订阅数+可订阅 5000 只+0 延迟推流+自带交易 api+本地版+单文件打开即用。
@zhcode 好的,x86 的有,但是现在这个前复权的问题,我还没有想到最干净的解决办法,py 到 c 有转换开销,所以没有分发可能会改底层。我希望极速+简单+打开即用,没有乱七八糟的,否则又变成 xxxxshare 这种了。
@zljklang cf 的 ip 怎么变黄色网址了,估计是上次浏览过,所以又分给你了(纯猜测)
@ipwx duckdb 技术上来说:
最大的问题是,.duckdb 单文件无法增量更新,使用外部 Parquet 劣势放大,会慢 3 ~ 5 倍;那么每天都要下载 10 个 gb 数据。。。
另外写入:sql 需要先创建表。再写入表。写入内存缓冲。实时多进程取不到值。多并发写入死锁。单文件无法增量更新。
@piksou 都是增量更新,今天 06-30 按我这里 10-20mb/s 的话,也就是 30 秒,最慢 2 分钟完成。

前复权一天只会有几个股需要计算 factor ,这个我再考虑换成不复权,本地自己算,但感觉不是一个好的思路。或者每天更新那几只需要重算的,这个压力在我了。。。也不是很好。
@zhcode arm 吗?
关键的是:哪个数据库能做到下面的?

同步异步单文件+链式调用+横\纵列混合存储+高并发读写+http/pysdk 同时支持+通配符+正反排序+截取+多横/列同取+最新 zstd 压缩+单文件 1.xmb 大小

get()
set()
极简接口免除 sql
get("日 k",code,date).get("open,close,high").get("open,close").get("open")[n:]
更夸张的混合调用
get("日 k",code,date).set().lens().get().mset().mlens().mget().delete()
灵活到我自己都看不懂。
@niubee1 这个开源怎么说呢,我没弄懂开源的意义,调试几千上万次,自己用了两年无数修复,让他们拿去倒卖的话确实不符合我自私的人性。
@lavvrence 这个就是前复权数据,我也想的是开箱即用,后面发现遇到某只除权需要覆盖历史。正在考虑如何修正,即要:开箱即用,又要减少 update ,既要又要真不好搞。有解决方案,也求一个。
@Gamespark mac 能交叉编译的话没什么问题,本身有 linux arm 和 x86 ,一直在手机上面跑,5g 手机自带的磁盘速度挺快的,主要不知道 mac 占比多少。
@ddup 其实我全协议都有,ths,dfcf,tx,tdx,xl,cq,交易+实时 l2 也能做。关键是这些东西不能放出来。
1  2  3  4  
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1074 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 17ms · UTC 18:11 · PVG 02:11 · LAX 11:11 · JFK 14:11
♥ Do have faith in what you're doing.