V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  nzynzynzy  ›  全部回复第 20 页 / 共 61 页
回复总数  1201
1 ... 16  17  18  19  20  21  22  23  24  25 ... 61  
219 天前
回复了 AmosG 创建的主题 汽车 长途开车怎么听歌
郭德纲
其实讲真我找到一个类似的赛道你可以考虑一下,可能比你这个更有机会,你查查有个叫做木薯牛网盘中转站的类似的产品,一直有卖卡。

一些收费的资源是存在推广机制的,原理是发在一些网盘,必须是付费会员才能下载,从而吸引下载者去订阅网盘进而给资源发布者返利的,而这个网站是相当于买齐了这些网盘会员,你要哪个,把链接粘进去,这个中转站替你下载下来,你再从中转站下载,而中转站根据文件的流量收费,这样存在一个可能的利差。
一个豪华品牌的低端,一个奇怪品牌的高端,我都不选,尤其是后者,多少国产车卖着卖着这个系列就停产了,爆款也不例外,实在太离谱。

我选市场检验比较充分的、有始有终的车型,无论是国产还是合资。
另 1:我司部署的环境不支持 TS 因此用 js 写
另 2:我一些代码是 gpt 写的以节约时间,所以代码风格不一致,见谅
感谢大家回复,我把最终方案扔在 append 中了,欢迎批评

冒昧艾特一下参与讨论的朋友,也算有个交代。谢谢大家!

https://jsfiddle.net/4pyejfL8/

@xhawk #31
@ZeroAsh #30
@xuanbg #26
@catamaran #23
@changyang #22
@cybort #21
@ddzzhen #20
@Motorola3 #25
@zizon #24
@Chad0000 #15
@NoOneNoBody #13
@Sawyerhou #11
@NessajCN #12
@wingor2015 #8
@rekulas #7
@ivvei #1

如有遗漏重复请海涵。祝各位今天有个好心情。
乐高是按照欧美收入标定的价格,国内收入买起来确实吃力的。所以应该买山寨乐高,就家长和孩子两全其美了(受伤的只有乐高公司
227 天前
回复了 thinkdiff 创建的主题 信息安全 让真身行为完全消失在数字世界里?
这太简单了,只是各位老哥都是守法公民所以处处是被监控的。

如果你是法外之人,比如买卖了身份证的,那妥妥的隐身。
@zizon 对的无论 m 还是 n 都是有序的。不同冲销策略确实会导致冲销单据的范围不一定,但是余额是一定的因为余额是 transaction 的累加,和进出无关。
@Motorola3 是的。这是一个例子,实际上可能增增减减数额不会这样完全一致,可能是 100 ,-98 ,110 ,-9.98 这样。
这个情境里不仅销售会减小余额,对余额直接操作也会。而目的是寻找销售对应的余额操作(可能增加、减少),减少余额的操作不用考虑找对应。
@xuanbg 这个是关于账户的操作就比较敏感一点,用户看不见对应的、没办法核查就感到不放心。而且当时牛 p 吹出去了就做了吧虽然难度增加了。
@Chad0000 #15 而且你的例子中假设是 invoice 是可以 pending 状态先进来等待付款,和我的情况有差别,我的更像是进来时候实时判断钱够不够,不够这笔就废止了。我觉得老哥说的 cumsum 是有道理的,而且是正负都存在的 cumsum 。

这个就变成了:cumsum 的数组中找值大于 invoice 的情况,其中最靠队尾的、值大于等于 invoice 的一个或者一群值中最靠前的一个。累死我了这个描述。。。
@NessajCN #12 多谢这个还真的很类似!我感觉余额会过期是一种类似的情况,都是有序的先进先出地消耗,我继续去读一下
@Chad0000 #15 原理有点类似,或者你可以理解为预存/预支 + 购买,而且这个购买的时候要找到对应的预存/预支记录,而且预存/预支是有可能像我描述的可能性 A 这样被第一个记录拦截住,而后面其实还有预支。理想情况是能读取到第五张单据

@NoOneNoBody #13 谢谢,cumsum 确实是这个问题目前最贴切的描述,就是贪婪版的 cumsum ,我去朝着这个方向再探一探

也欢迎其他朋友继续看看!
确实这个东西昨天让我有点心烦意乱的,我打了个草稿放在 V2 然后今天发了,可能真的懂得只有我。

=============================
然后还有一个规则就是“贪婪”先进先出地消耗 JNL ,耗完就停止,举个例子

刚开始余额是 0
----
操作余额#JNL001 ,金额 100
操作余额#JNL002 ,金额-100
操作余额#JNL003 ,金额 100
操作余额#JNL004 ,金额-100
操作余额#JNL005 ,金额 130
销售 INV001 ,金额 100=>操作核销掉 JNL001-004 全部余额,因为他们叠加起来余额是 0 ,然后核销掉 JNL005 的 100 元,剩 30 元
-----
操作余额#JNL006 ,金额 100
这时候发生交易 INV002 ,金额 130 ,此时需要记录 INV002 的来源:
JNL005 ,金额 30 ,核销 30 ,余额 0 ,
JNL006 ,金额 100 ,核销 100 ,余额 0

情况大概就是这么个情况,看看还有什么没讲明白

=============================

@zizon #3
@NoOneNoBody #4
@RecursiveG #5
@Chad0000 #6
@rekulas #7
@wingor2015 #8

烦请各位如果有思路分享一下,有兴趣也可以插眼回来看
感谢各位耐心阅读。

比如以下事件按顺序发生

刚开始余额是 0
==============
操作余额#JNL001 ,金额 100
操作余额#JNL002 ,金额-100
操作余额#JNL003 ,金额 100
操作余额#JNL004 ,金额-100
操作余额#JNL005 ,金额 130
===============
截至目前账户余额是 130 元,此时发生了一单交易 INV001 ,价值 100 元
这一单需说明“这 100 块是从哪些余额操作中来的”,这时候目前面临无数种算法列举 3 种可能性

可能性 A:先进先出,够用就停
INV001 的 100 元来自 JNL001

可能性 B:先进先出,尽可能地记录
INV001 的 100 元来自 JNL001-JNL005 的叠加
JNL001 ,金额 100 ,核销 100 ,余额 0
JNL002 ,金额-100 ,核销-100 ,余额 0
JNL003 ,金额 100 ,核销 100 ,余额 0
JNL004 ,金额-100 ,核销-100 ,余额 0
JNL005 ,金额 130 ,核销 100 ,余额 30

可能性 C:
选一个够用的最大的,即 JNL005 去核销,其他无视

这个例子中追求的算法是以上的 B ,即尽可能记录 INV001 的来源
@ivvei #1 叫发生没什么问题。这个是我抽象的结果,就是打个比方。用户希望通过一笔消费能看到这笔能对应上几笔发生。

这个 transaction 和 invoice 不是一一对应的,你可以想象为客户既可以消费也可以存取,存取并不是指定消费的。

我疏漏了一些描述:
- 就是一顿存取之后,只有一笔 invoice ,不会是多笔。
- 没用到的单子就会自动结转等待下一次使用。

这个数据,算法希望对应的结果应该是

JNL001 ,金额 100 ,使用 100 ,余额 0
JNL002 ,金额-100 ,使用-100 ,余额 0
JNL003 ,金额 100 ,使用 100 ,余额 0
JNL004 ,金额-100 ,使用-100 ,余额 0
JNL005 ,金额 130 ,使用 100 ,余额 30
1 ... 16  17  18  19  20  21  22  23  24  25 ... 61  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2792 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 37ms · UTC 09:33 · PVG 17:33 · LAX 01:33 · JFK 04:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.