代码随想录训练营 Day 7 | 哈希表法2 + 双指针法2

1.哈希表法（续）

典例1： LeetCode 454 454. 四数相加 II - 力扣（Leetcode）

联想：首先这道题从本质上讲，和LeetCode 1 两数之和是比较接近的。

         宏观来看，两道题都是从每个数组中取出一个数，从而满足某一个特定和。

        由此，不难想到，解题方法由哈希表map入手。

        同两数之和的解决方案，我们需要取一个数组做哈希映射，其它数组进行遍历。

        小tip ： 如果是1+3的情况，时间复杂度确实比较高，不如2+2的性能好。

        另外，两数之和的value记录的是下标位置，而本题的value记录出现次数，这完全是由题目要求决定的，和具体的解题策略、思路等无关，不应成为思考的干扰项。

    备注：清晰的思路以及......不是很熟练的语言用法——已经提前预定二刷了。

典例2： LeetCode 383     383. 赎金信 - 力扣（Leetcode）

备注：没什么好说的......和 LeetCode242一模一样。 

 2.双指针法（续）

典例1：LeetCode 15 15. 三数之和 - 力扣（Leetcode）

 联想：区别于454，本题总共只给了一个数组进行查询，而454则是每个元素来自一个数组。

            对于一个数组内的“搜索问题”，运用双指针可能会方便一些（诸如滑动窗口之类的）。

 备注：这道题细节满满，去重之路可谓道阻且长。

            1.先做递增，以首元素大于0作为结束条件，减少了无端的遍历，是想不到但好用的技巧。

            2.首元素nums[i]去重时，前比（nums[i - 1]）和后比（nums[i + 1]）效果不同。

                如果是后比，当 i 遍历到与 left 临近时，会排除掉nums[i]和nums[left]相同的可能。

             （这个可能算是隐藏boss级bug, 一般人很难想到，可谓叹服）

            3.left 和 right 的去重，要写在取值之后。

               因为要确保已收罗一个可能结果，避免遗漏。（如000000的情况）

同例4: LeetCode 18 18. 四数之和 - 力扣（Leetcode）

备注：延续15.三数之和的思路，无非是剪枝和去重的成分考虑。

          很容易忽略的条件是，由于负数的原因，剪枝操作要附加 target > 0。