yesterdaysun

yesterdaysun

V2EX 第 145085 号会员,加入于 2015-10-30 14:03:58 +08:00
今日活跃度排名 22903
根据 yesterdaysun 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
yesterdaysun 最近回复了
https://en.wikipedia.org/wiki/Rounding
可选的舍入方式有 6 种, 常说的四舍五入对应 infinity 这种, 在 c#里面也叫 AwayFromZero, 但是这个会有统计学误差, 所以另一种常见的舍入方式是 even, c#里叫 ToEven, Java 里叫 HalfEven, 也就是上面有人提到的银行家舍入

不同的语言, 不同的函数使用的舍入规则都是不一样, 比如 toFixed 和 Math.round 用的就是不一样的, MySQL 的 decimal 和 float 规则不一样, 如果追求 100%精确的话就得去看文档他们用的到底是哪一种方案, 或者 Java/c#这种可以有选项让你控制使用哪一种舍入规则
之前有段时间研究过数独, 如果像第五版里说的用类似穷举的方法解数独没有问题, 可以解出来, 顶多一些难题要花费好几秒钟, 但是即使是一些简单的题, 没有经过优化, 计算机最终的步骤数都在千到万这个级别, 这样出结果没有问题, 但是要输出可以给人看的步骤太粗犷了一点.

说白了, 这里的穷举只是相当于应用了基本的唯一余数技巧和候选数加回溯的算法, 要真的生成可以给人看的步骤, 需要实现人所用的技巧, 比如 https://hodoku.sourceforge.net/en/techniques.php 这里列出的几十种从简单到复杂的解题技巧, 但是这样算法逻辑就会大大复杂了

不过这个 HoDoKu 是开源的, 可以用他的 C#算法复刻一遍转成文字再输出, 大概可以
180 天前
回复了 williamcc 创建的主题 ? Python ? Python 大佬帮忙看看,机器人题目
@williamcc 摸鱼写了一段, https://gist.github.com/yesterdaysun/ee0bfa5b6d8a54d53c0fe0e79b8e923f

取巧, 用了两次 DFS 回溯, 第一次以分数为目标, 然后重新 DFS 以出口为目标, 分数是最大了, 但是步数可能不是最优的, 懒得搞了
180 天前
回复了 williamcc 创建的主题 ? Python ? Python 大佬帮忙看看,机器人题目
算了, 无聊百度了一下直接搜索答案, 你自己看吧: https://blog.51cto.com/u_13019/7301342
180 天前
回复了 williamcc 创建的主题 ? Python ? Python 大佬帮忙看看,机器人题目
@williamcc 不太清楚你这个题目的要求到底是什么? 如果只是让人外部输入来控制上下左右移动, 那就简单了, 循环接收输入, 判断可不可以前进, 然后上下左右移动, 非常容易

但是如果是要自动找到终点, 那就是不是什么"条件语句和循环语句"的事情了, 必须上算法, 一般来说就是回溯算法, 可以用深度优先搜索(DFS), 或者广度优先搜索(BFS), 你可以了解一下, 网上的代码应该还挺多的, 通关应该比较容易, 但是想要分数最大, 得加点优化手段, 得做全遍历, 得在先找到终点之前把所有的路径遍历完, 最后再走终点路径, 会稍微复杂一点
180 天前
回复了 williamcc 创建的主题 ? Python ? Python 大佬帮忙看看,机器人题目
dfs 吧, 不过题目好像要求分数越高越好, 要改成 bfs?
181 天前
回复了 1000copy 创建的主题 ? 程序员 ? 喜欢和有效是两码事
个人理解: 敏捷里面, 快速迭代是最核心的价值, 2 周是一个合适的时间, 超出这个时间, 团队整体就会效率低下, 因为大家需要在一个不长不短的时间节点收到反馈, 互相沟通, 改进方案, 重启下一个迭代

所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心

虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.

估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"

总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分
220 天前
回复了 yesterdaysun 创建的主题 ? MySQL ? 问一个复杂的基于产品属性的 SQL 查询
@MoYi123 大哥, 能详细说一下这个方案吗? 是不是要换 ES, MySQL 能搞么
要不用解构的方式导出本地变量计算, 算完再导回 dict

A, B, C, D, E, F, G, H, I, J, K, L = dict.values()

A = B + C
D = E - F
G = H * I
J = K / L

dict = {"A": A, "B": B, "C": C, "D": D, "E": E, "F": F, "G": G, "H": H, "I": I, "J": J, "K": K, "L": L}
我大概能理解 OP 的思路, 很多年前我做一个 C#的项目的时候, 那时候是架构师自己搭的框架, 思路就是所有的 Service 放到一个静态类里面, 比如叫 ApplicationServiceManager, 简称 ASM, 任何时候要用的时候直接 ASM.UserService.GetUser()就行, 其实用起来也挺爽的, 要用的是时候直接 ASM 点 XXX 出来所有的 Service, 当时架构找呢么解决初始化和循环依赖的我已经忘了, 但是至少这条路是可行的

但是我还是觉得这套思路和现行的 Spring 体系不太搭, 就像楼上说的, 现在只要用 lombok 配合构造器注入, 几乎是无感的引入需要的 Service, 感觉挺简洁的, 那套集中式的 Service 管理感觉要自己在底层架构引入很多额外的约定和设计才能做出来, 感觉也比较重, 也不利于代码维护和单元测试

总之相比之下我还是偏向普通 Spring 的注入体系
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5598 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 08:22 · PVG 16:22 · LAX 01:22 · JFK 04:22
Developed with CodeLauncher
? Do have faith in what you're doing.


http://www.vxiaotou.com