什么时候 刀剑神域 中的 NerveGear 实现了, 再说元宇宙的事情. 之前都是太监上青楼

@sujin190 有影响的 https://pytorch.org/docs/stable/notes/randomness.html 但是应该不会影响最终性能(89 -> 88 这种区别)

@passMeBy paddleOCR 的小模型还挺快的,我这边一般都是一张文档 3 秒(CPU), 大模型和小模型精度在我的使用场景下基本没差...

@passMeBy 这个我就不太清楚了, CNN 的那个是原来做实验的时候要把 CNN 设置一个随机数定死(具体忘记了),然后才能让跑分一致,但是那个一般不会影响特别大. cnocr 现在好像是 pytorch 了,当时用的时候因为是 mxnet 转 onnx 不好用就放弃了. 上面说的 paddleOCR 是比较好的方案,虽然也有坑. 现在感觉就是生产环境 onnx 天下第一,paddlepaddle 框架的话,除了脏话没啥想说的

cnn 的快速实现结果是可能不稳定的, 好像是有办法关闭, 但是那种应该是不影响到性能

也有可能是一个是 cpu 一个是 gpu 再加上导致不一样, 但是也不至于到影响精度的程度.....

感觉图像被压缩的可能性更大一点....

特斯拉的自动驾驶就是花架子, 应该说现阶段所有的自动驾驶都是花架子,有 acc 和车道居中就够了. Tesla 的优势不是好开么.....

如果照着漫画拍,还是不要看了,漫画结局就是类似于: 我不想要大圆满但是我也想不出别的好的结局,那大家(读者)就都不要好过吧! 这种结局.

现在看动画的希望就是希望结局改了

1. 没有
2. 不应该这么用
3. 实体类直接交给 service 处理对应业务就行了, controller 不应该在这里处理东西
4. 确实会有只需要实体类中的部分值进行某个业务的(如创建), 这个地方有一些解决方案,比如持久化的和前台的不是一个,一对多,再转换. 持久化类进行继承(有弊端也有好处)

这种的意义是啥, 就像 ++i+++=++i++, 没有任何意义

有能力,没牵挂就赶紧跑啊!!!

其实吧,大部分人其实都不明白,或者说没有真正明白 996 什么的是什么. 亦或者说是一种利己主义和明哲保身,很多东西的不透明和选择性执行造成了工薪阶层的高风险成本. 这种环境下,不主动不拒绝拼命干一阵然后赶紧跑(或者被赶跑)成了最优解,毕竟主动拒绝看长远都需要稳定和保障,而这两样...

以后交流全在 im 上呗，有记录有时间，做没做会不会，一目了然啊

为什么听你们说这么简单，我 PayPal 弄个香港和美区账号费了好大劲……比如手机号和风控

混动，雅阁啊………

就我看来, 大部分类似于蔚来的车厂, 造车的思路就是智能手机装四个轮子. 车子首先是好开, 其实都是次要的.

特斯拉不管有什么问题, 至少他是一辆好开的车.

大部分传统车企的电动和那些新势力大部分不太一样, 他们至少是在造车(不管是因为他们想明白了的原因还是因为他们没想明白的原因)

要是没办法只能买电车,然后买了 model3, 动能回收我肯定不想开, 单踏板觉得不管怎么想都不安全. 就想改写 final 的变量没写 final,看着没啥跑着也很好,但是不知道什么时候哪个小伙子就给你改了代码

虽然 model3 没 crbs 各种负面新闻, 看着也廉价.... 但是奈何对手不行,那个价位的电车还是它牛逼啊....真的是同行衬托....如果不是电车,那个价位可以来个小点的油车,应该选择还是很多的(考虑安全性的情况下)

@Cu635 这个不是 UOS 的,是硬件的,UOS 其实没怎么用,最终用麒麟了. 怎么说呢, UOS + aarch64 坑的不行, 换成麒麟以为源什么的至少比较好弄, 最终也是一地鸡毛. 空光盘就是一个缩影而已,所有所谓的国产自主都不咋地

老婆同意了，银行卡提示余额不足🌝