※ 引述《ken915007 (Ken_Wu)》之铭言： : 目前正在使用java实作data mining的方法... : 实作中，在想一个问题，就是字串比对 : 怎样的字串比对才有效率? : 推 qrtt1:看能不能在资料前处理时统一成数字, 要结果再转成字串 12/05 08:20 : → ken915007:若item要是多的话…这样转数字~最後在反转~也是要时间 12/05 12:12 : → ken915007:酷!! 难道不能这样用?还是比较不好?? 12/05 12:14 : → qrtt1:处理简单的型别绝对比物件来的有效率 12/05 13:41 : → qrtt1:关联用 fp-tree 比较有效率的说 :P 12/05 13:43 : 嗯! 我有看过这些方法~但精准度apriori会比较高点...所以才想用apriori， : 但缺点就是要重覆扫资料... : 有点离题了^^ 重点不是这演算法= = : 我想知道对於字串的比对~像上面的范例~大家会用什麽方法去比对是否有出现过 如果 input data 没有可 exploit 的性质 且 algorithm 一定得写成原文中所述的话 那我目前只能想到 「确认所有的 String 比对使用 hashCode 以 fail-fast」 这就要去读 JDK source code 去看 containsAll() 及 String.Equals 的实作 还有 String.hashCode 有无把 hashCode cache 起来 如果没有的话，可以把 String 包成另一个 class 再实作 hashCode cache class StringAndCachedHashCode { Int32? hashCode = null; String string; internal StringAndCachedHashCode(String string) { this.string = string. } internal Int32 hashCode() { if (hashCode.HasValue) return hashCode.Value; else { hashCode = string.hashCode(); return hashCode.Value; } } } 再要更上层楼的话，就得确认 containsAll() 有实作 fail-fast 且还可以对 input data 做 statistical analysis 看能不能让 containsAll() fail-fast-er :p (例: always 从最稀有的 element 开始 check 'containsAll()') 另外一件很重要的事，这里碎碎念一下 performance tuning 与任何其他的 scientific method 没有不一样的地方 perf tuning 的新手最常犯的一个错误就是疯狂的把所有能想到的手段都试作 却没有严谨地检视 ROI (return of investment) 我会建议原 po 这样做: 1. Identify a set of well-understood test data. 2. Set your perf. tuning goal 3. Identify a method to measure against your perf. goal. 4. Watch your code under a profiler and identify the type of improvment that can bring you the biggest ROI 5. Implement the improvement 6. Test your new implementation with the test data from step#1. 7. Measure perf. improvement with the method from step#3. 8. Only if you have not met your perf. tuning goal, go back to step#4. Otherwise, call it a day. 当然，如果没有 deadline 或有无限的时间…以上方法自然不适用… XD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 65.87.177.87 ※ 编辑: AmosYang 来自: 65.87.177.87 (12/05 17:33) ROI := return of investment 中文可以翻作 投资报酬 ? deadline -- 作业/报告/老板耐心 的期限 易言之，最後这一段我想讲的是「perf. tuning 的 engineer practice」 有的时候一些 tweak 在理论上会有帮助 但实质上效益却不大，且要花很多时间去实作 这就是所谓的 low ROI 这就只能靠良好的 engineer practice / scientific method 去验证 通常 80/20 rule 很少出错；在学校里教导的是 software engineering 但在现实生活中能养活人的是 software business perfect solution 的 ROI 多半不如 something just good enough 有些道理我也无法三言两言说得很清楚 :) 反正如果没有 deadline 的话一切好谈 XD ※ 编辑: AmosYang 来自: 65.87.177.87 (12/05 18:24) ※ 编辑: AmosYang 来自: 65.87.177.87 (12/05 18:25)