问题来自今日力扣 偶然发现使用std::function定义dfs函数比原生函数或auto定义慢很多，使用斐波那契简单计算一下时间，代码放在最后。 结果如下，可以看到auto和普通定义的递归函数时间开销差不多，而function定义的递归函数慢了快5倍(当然随着计算量增大，倍数会逐渐减小，但还是很慢就是了)。 check fibo(30) <dfs_ori > ret: 1346269 done! 6425ms <dfs_func> ret: 1346269 done! 41189ms <dfs_auto> ret: 1346269 done! 6492ms gpt给出的解释如下，以后还是投入auto怀抱了~ 在C++中，当你使用std::function来包装一个lambda表达式或函数时，可能会发生拷贝构造的情况。这是因为std::function是一个类型安全的函数包装器，可以包含任何可调用对象（函数指针、成员函数指针、函数对象等），因此在构造std::function对象时，会涉及到对象的拷贝构造或移动构造。 在你的情况中，当使用fu
关于CIDEr的介绍可以看这里，个人感觉讲的比较清楚 唯一有个问题是计算TF的时候，提供的公式是term_freq/sum(all term_freqs)，但是已知的代码库(如pyciderevalcap)里只有term_freq项，提了一个issue在这里 https://github.com/tylin/coco-caption/issues/66
Python中创建对象时，会涉及__init__和__new__两个函数，个人感觉前者较为常见。 创建对象时发生了什么 创建一个类对象首先会调用该类的__new__方法(接下来省略下划线)，new方法本身接受一个类参数cls，一般就是自身，随后会通过super函数得到该类的父类，并调用父类的new方法进行对象的创建（因为所有类都基于object，所以最终都会调用object的new方法） super函数（实际上是类，这里为了简明，使用相同功能的函数替代）的输入为类cls，和某个实例obj，super做的事情就是找到obj的父类并返回，这里我们使用python的mro函数得到obj对象对应类的父类列表。mro这个类方法是python解决多重继承问题的方案，简单理解就是mro会返回调用类的父类链，列表靠前的元素是靠后元素的子类。那么super的做法就是得到obj对象类的mro列表，取出mro列表中cls的后一个元素，也就是cls的最近父类。 def super(cls, obj): mro = obj.__class__.mro() return mro[mro.index
Typecho加个email提醒咋这么费劲呢.... 复盘 腾讯云的主机升级php挺费劲的，试过remi源直接安装php8，但是typecho识别出来的还是老版本. Solution: 源码安装，2核2G大概编个20min，可参考这里 几个插件都不维护了，找到一个比较新的这里, 但是存在数据库相关的问题 Solution: 见issue 虽然复盘完也就两个小问题，但是当时真的搞半天，原因可能有 typecho调试比较幽默，报错才有信息看，后面参考了一个php log才舒服一点，见stackoverflow 时间为大晚上，缺水 Note 发送邮件我选择了同步发送，所以评论响应有点慢，请多见谅
RLHF PPO的时候为了节约成本，训练时一个batch的数据会多次利用，即多次更新actor model和critic model。 和Reference KL distance用于限制PPO模型和原始SFT模型之间的距离(防止PPO训歪，这一项是加在Reward model产生的R中，如deepspeed chat)一样，多次更新actor model也需要有原始actor model作为约束，因此actor loss计算中会有一项$logits/old\_logits$(和原始KL相比，去除了log，近端策略优化裁剪) actor loss代码如下(from deepspeed chat) def actor_loss_fn(self, logprobs, old_logprobs, advantages, mask): ## policy gradient loss log_ratio = (logprobs - old_logprobs) * mask ratio = torch.exp(log_ratio)
Axuanz
Updating as per fate.
