yuqs

关于swin精度不对齐问题，在commit - https://github.com/Oneflow-Inc/libai/commit/7275a1c7bbb7e29f821dab18630e0a31e8a697d4 之前的log是这样的，和pytorch版本差距巨大： libai: [log.txt](https://github.com/Oneflow-Inc/libai/files/9445186/log.txt) facebook: [log_swin_tiny_patch4_window7_224.txt](https://github.com/Oneflow-Inc/libai/files/9445202/log_swin_tiny_patch4_window7_224.txt)

精度不对齐详细讨论在：https://github.com/Oneflow-Inc/libai/discussions/366

目前有什么办法避免这个问题嘛，或者有flow.cat的替代形式

> > 目前有什么办法避免这个问题嘛，或者有flow.cat的替代形式 > > 可以先禁用view（export ONEFLOW_DISABLE_VIEW=1），同时把flow.split改成for循环的方式，每次处理一个item。 > > ```python > for i in range(A.shape[0]): > process A[i] > ``` > > 不过需要注意的是，禁用view可能会造成某些tensor setitem操作不能正确执行。 好的非常感谢 我去试试

相关具体解释在代码中已经有了注释，都是以Notes为开头

> > 1. 第一个认为可以扩展的地方是验证器的输入无法简单地从模型输出获得，因为在libai中，默认所有的计算是在模型中计算完毕。但我在复现Nerf时存在需要每个epoch中batch的索引，这个需求模型无法完成，经过chengpeng老师的指导，我将代码转移到了Evaluator中，并继承之。但是模型的输出需要通过libai/evaluation/evaluator.py中210行开始的检查，因此无法轻易通过，只能像NeRF项目中采用projects/NeRF/modeling/System.py中411行开始到416行结束的形式，以及projects/NeRF/evaluation/nerf_evaluator.py中38行开始到44行结束的形式通过冗余代码来实现。 > > 2. 第二个认为可以扩展的地方是可以借鉴openmmlab采用装饰器的形式，毕竟以后的项目肯定不可能都是公司的人来实现，用户也会为了自己需求进行扩展。这样的话，可以通过装饰器来将相应的模型，数据加载器，验证器加入其中并实现轻易地扩展。 > > 第二点我没有太get到， 用装饰器来实现轻易的扩展， 和目前在config里面使用lazycall在python层面进行自由的拼接， 看上去打成的目的是一样的。 > > 有个issue有过对于这个详细的讨论，从使用感官和添加代码的量来看，目前config下的lazycall的调用方式应该是比较灵活的。 #12 我感觉确实有道理，仔细一想确实Lazycall的方式比较灵活

是的，其他numpy类型是可以被转换为Tensor

好的学到了

I finish the submission on huggingface. Thx!