最近好累,今年才开始找工作就打算收心了

作者在寻找工作的过程中感到身心俱疲,尽管面对两家提供户口的机会,但还是决定稍作休整,专注于技术积累。反思去年的经历,今年更加注重待遇与个人发展。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近好累,今年才开始找工作就打算收心了

    今天优快云博客是只能写点心情之类的东西了,最近2天一直在找工作,周2从焦作回到北京,周3开始找工作,面试了2家公司,感觉好累,去年面了那么多家,都没感觉累,为什么现在累?想想也该收收心了,时间虽然还充裕,但是想想有合适的就签了吧。

    今年刚开始找工作,没想到2家都有户口,好好考虑下,没多少时间了。在我今年更看重待遇的情况下,竟然有户口,哎!强求的时候倒是没有,不强求了,反是有了,世界就是这么奇怪。今天面试回来,感觉真是累啊,又接到昨天早晨面试公司继续面试的电话。都过3面了,还面试,哎!累!

    差不多就签了,我也不想再找了。本打算去百度,搜狗,甲骨文等大型公司试试,但是感觉累了。

    工作头3年好好做技术吧,我感觉这个实在。

    想好了,就把工作签了,然后好好休息几天,进入下一个起点。

    还有博客必须要有计划,要是不罗列知识点,回来累的话,真是不知道该写什么了,只能瞎写点东西了。

# P4879 ycz的妹子 ## 题目背景 ycz 有很多很多的妹子(ycz:瞎说) ## 题目描述 机房神犇 ycz 有 $n$ 个青梅竹马,她们分别住在 $1~n$ 号城市中。小时候的她们美丽可爱,但是由于女大十八变,有些妹子的颜值发生了变化,但是十分重感情的 ycz 神犇不忍心抛弃她们,于是记录下来了她们颜值变化的值,我们用 $C, x, y$ 表示第 $x$ 个城市的妹子的颜值下降了 $y$ 。长大之后的 ycz 非常有魅力,有许多妹子被 ycz 迷得神魂颠倒,我们用$I, x, y$ 表示第 $x$ 个城市有一个妹子喜欢上了 ycz ,她的颜值为 $y$ ( $y$ 有可能是负数,但是 ycz 来者不拒)。但在中途有一些妹子和 ycz 吵架了,于是就分手了,我们用 $D, x$ 表示**第 $x$ 个妹子**和 ycz 分手了。 最近神犇 ycz 要去全国各地他的妹子们,为了方便计算,我们珂以把 ycz 的妹子所在的城市当作是一条直线,并且挨在一起。神犇 ycz 由于忙于和他的妹子们联系此时已经很累了,于是交给你一个这样的任务:他想知道他在某个时间去他的所有妹子们珂以获得多大的愉悦度,这个愉悦度为他的妹子的颜值数,你要做的就是求出这个愉悦度之和(注意长大后妹子们的颜值可能为负数/滑稽)。 注意:每个城市只允许有一个妹子,也就是说后来喜欢上 ycz 的妹子会赶走之前这个城市喜欢 ycz 的妹子~~(一城不容二女)~~。 UPD: 青梅竹马都是喜欢 ycz 的。 分手的第 $x$ 个妹子不是第 $x$ 城市的妹子,是指从前往后数第 $x$ 个有妹子的城市的妹子。 青梅竹马长大后就是妹子。 修改的值 $y$ 不为负数,但是颜值减去之后可能为负数。 ## 输入格式 ycz 有 $5 \times 10^5$ 座城市,开始时,前 $n$ 座城市各有一个妹子,第 $i$ 座城市妹子初始的颜值为 $a_i$。 有 $m$ 次以下四种操作。 - `C x y` 第 $x$ 座城市的妹子颜值减少 $y$ - `I x y` 第 $x$ 座城市出现了一个颜值为 $y$ 的妹子,如果在此之前,第 $x$ 座城市已经有妹子,则之前的妹子被驱赶。 - `D x` 第 $x$ 个有妹子的城市 中的妹子与 ycz 分手 - `Q` ycz 想知道他所有妹子的颜值总和是多少 ## 输出格式 对于每一个$Q$输出一个整数 ## 输入输出样例 #1 ### 输入 #1 ``` 5 10 1 2 3 4 5 Q C 3 2 Q I 6 6 Q D 4 Q C 5 2 I 7 9 Q ``` ### 输出 #1 ``` 15 13 19 15 22 ``` ## 说明/提示 **样例解释:** 妹子颜值变化如下,删除的就没写在下面了。 ``` 1 2 1 4 5 1 2 1 4 5 6 1 2 1 5 6 1 2 1 3 6 1 2 1 3 6 9 ``` 对于 30% 的数据,$1 \le n,m \le 10$ 对于 70% 的数据,$1 \le n,m \le 1000$ 对于 100% 的数据,$1 \le n,m \le 100000,|a_i|,|y| \le 10^9$
最新发布
03-15
<think>嗯,这个问题看起来有点挑战性。我需要设计一个算法来模拟yzc和妹子们的交互过程,包括颜值变化、新恋情和分手,同时还要高效计算任意时刻剩余妹子的颜值总和。首先,我得理解清楚题目中的各个操作和要求。 首先,题目涉及到几个关键操作:颜值的变化、新增恋情、分手,以及实时查询剩余妹子的总颜值。这些操作需要高效处理,尤其是当数据量大的时候。所以,我得考虑合适的数据结构来支持这些操作。 对于颜值的变化,可能需要批量更新某个妹子或某些妹子的颜值。这时候,如果使用数组或链表,每次更新可能需要遍历,时间复杂度会很高。如果妹子数量很大,这显然不够高效。有没有办法将颜值的变化延迟处理或者用某种方式快速计算总和呢? 然后是新增和删除妹子。新增的话,通常是在数据结构末尾添加,但删除的话,如果使用数组,可能需要移动元素,导致O(n)的时间。链表的话,删除是O(1),但查节点可能需要O(n)。所以可能需要一种既能快速查又能快速删除的结构,比如哈希表或者平衡二叉树? 接下来,总颜值的高效计算是关键。每次操作后都要能快速得到总和。这让我想到可能需要一个变量来维护当前的总和,并在每次增删改时更新这个变量。比如,当新增一个妹子时,总和加上她的颜值;删除时减去她的颜值。颜值变化的时候,总和的变化就是差值。这样总和的计算可以在O(1)时间内完成。 但是,这里有个问题:颜值的变化可能不是针对单个妹子,而是可能批量变化,比如所有妹子颜值增减某个值,或者根据某种条件变化。例如,题目中提到“颜值变化”可能有两种情况:对单个妹子的修改,或者对某个集合的修改(比如所有有男友的妹子)。这时候,单纯维护总和变量可能不够,特别是当批量操作频繁时。 比如,如果有一个操作是给所有当前有男友的妹子增加5点颜值,这时候如何高效处理?这时候可能需要将妹子们按照是否有男友来分组,比如用两个变量分别维护有男友和无男友妹子的总和。或者使用更复杂的数据结构,比如分段记录。 不过,假设题目中的颜值变化主要是针对单个妹子或者某个特定条件的小群体,可能需要更灵活的处理方式。例如,使用哈希表来记录每个妹子的当前颜值,并用一个总和变量来维护总颜值。这样,当某个妹子的颜值变化时,只需要更新总和变量:总和 = 总和 - 旧值 + 新值。新增妹子时,将她的颜值加入总和,并在哈希表中记录;删除时从总和减去,并从哈希表中移除。这样,单个操作的时间复杂度是O(1)的,总和查询也是O(1)。 不过,如果有批量操作,比如将所有妹子的颜值乘以某个系数,这时候逐个修改的话时间复杂度是O(n),这可能会很慢。但题目中的问题描述是否包含这种批量操作呢?根据用户给出的问题,可能题目中的颜值变化是针对单个妹子或者某种特定情况下的妹子,比如每次事件可能只影响一个妹子或者几个妹子,这时候上述方法可行。 但需要进一步明确题目中的具体操作类型。例如,假设每个事件是以下三种之一: 1. 修改某个妹子的颜值(增加或减少某个值)。 2. 新增一个妹子(颜值初始值已知)。 3. 某个妹子分手,被移除。 这时候,总和可以用变量维护,每个操作的时间复杂度都是O(1)。例如: - 新增妹子:总和 += 颜值,哈希表添加条目。 - 删除妹子:总和 -= 颜值,哈希表删除条目。 - 修改颜值:总和 += (新值 - 旧值),更新哈希表。 这样总和的计算非常高效。但问题可能在于,实际题目中的操作可能更复杂,比如分手的条件是什么?比如,妹子是否根据某种状态(比如有男友)被移除?或者,分手指的是某个特定妹子被移出列表? 如果每次分手事件是移除某个特定的妹子(比如根据ID或索引),那么上述方法有效。但如果有其他条件,比如当颜值低于某个阈值时自动分手,那么可能需要更复杂的数据结构,比如优先队列或者平衡二叉搜索树,来快速到符合条件的妹子。 但根据问题描述,用户可能只需要处理基本的新增、删除和修改操作,而分手事件可能是指特定妹子的移除,所以可以用哈希表来维护妹子列表,并用总和变量来维护总颜值。 但是,可能需要考虑妹子之间的关系,比如是否有男友,或者是否处于恋爱状态,这可能影响某些操作。例如,可能有规则,比如当妹子有男友时,她的颜值变化方式不同。这时候,可能需要将妹子分为不同类别,并分别维护总和。 例如,假设妹子分为有男友和无男友两种状态,当她们有男友时,颜值的变化可能有不同的处理方式。这时候需要两个哈希表,或者两个分组来分别记录她们的颜值,并维护两个总和变量。这样,当某个妹子的状态变化时(比如从无男友变为有男友),需要从原来的组中减去,并添加到另一组中,同时更新总和。 这种情况下,数据结构可能需要支持快速的状态转移和对应的总和计算。例如,每个妹子有一个状态属性,当状态改变时,调整其在两个分组中的位置,并更新总和。此时,总和的总和是两个分组的和之和,查询总颜值总和只需要O(1)。 综上,可能的解决方案是: - 使用哈希表或字典来跟踪每个妹子的当前状态(颜值、是否有男友等)。 - 维护总和变量,在每次增删改操作时更新总和。 - 如果存在分组(如是否有男友),则分别维护各组的颜值总和,总和为各组的和之和。 例如,假设妹子可能处于恋爱状态或单身状态,每次分手事件会将该妹子从恋爱组移到单身组,或者直接移除。这时候,可能需要维护两个总和:单身组的总和和恋爱组的总和,总和为两者之和。 或者,分手事件可能直接导致妹子被移除,此时总和需要减去她的颜值。例如,每个妹子在恋爱期间可能会被移除(分手),此时需要从总和中去掉她的颜值。 但问题中的描述可能更简单,即每个妹子在分手后就不再属于当前考虑的集合。因此,每当发生分手事件时,该妹子被移除,总和减少对应的颜值。 因此,数据结构的设计可能包括: - 一个字典或哈希表,存储每个妹子的唯一标识(如ID)和其当前颜值。 - 一个总和变量,记录所有当前妹子的总颜值。 这样,每个操作的处理如下: 1. 新增妹子:生成唯一ID,将颜值存入字典,总和加上该值。 2. 删除妹子(分手):根据ID到颜值,总和减去该值,从字典中删除。 3. 修改妹子颜值:根据ID到旧值,总和减去旧值,加上新值,更新字典。 此时,总和查询是O(1)的,每个操作的时间复杂度也是O(1),假设哈希表的操作是O(1)。 但问题中可能还存在其他条件,比如颜值的变化可能与时间或其他因素相关。例如,每个妹子的颜值可能每天变化,或者每次交互后变化。这时候可能需要更复杂的状态跟踪。 另外,题目中的“新恋情”可能指的是新增一个妹子到当前集合中。而分手则是从集合中移除。 因此,核心的数据结构是哈希表+总和变量。这可能足够应对题目中的操作。 但需要考虑如何高效处理可能的分组或条件查询。例如,如果存在多种状态,可能需要维护多个分组的总和。例如,假设妹子分为活跃和非活跃,或者有男友和没有男友,那么每个组的总和维护起来,总和即为各组之和。 但根据用户提供的引用内容,可能题目中的具体操作需要更详细的分析。例如,在引用[4]中提到DNS重绑定攻击的相关流程,但这可能与当前问题无关,可能引用内容中的某些部分被错误地包含进来。 回到问题本身,用户的问题是关于如何设计算法来模拟妹子们的颜值变化、新增和分手,并高效计算总颜值。因此,可能需要明确以下几点: 1. 每个妹子的唯一标识方式(例如,ID)。 2. 操作的类型:例如,添加妹子(带初始颜值),修改某个妹子的颜值(增量或新值),删除妹子(分手)。 3. 查询总颜值的要求是实时的,任何时候都可以得到当前总和。 假设这些操作都是针对单个妹子的,那么哈希表+总和变量的方法应该是可行的。但如果有批量操作,比如将所有妹子的颜值增加某个值,那么这种方法会导致O(n)的时间复杂度,这可能不够高效。此时,可以考虑使用惰性更新的方法,例如,维护一个全局的增量,然后每个妹子的实际颜值等于存储值加上增量。但这样在删除妹子时需要考虑如何处理增量。 例如,如果有一个全局变量delta,表示所有妹子的颜值都增加了delta,那么每个妹子在存储时的实际颜值是stored_value + delta。当需要修改所有妹子的颜值时,只需调整delta。此时,总和的计算公式为sum_stored_values + delta * count,其中count是当前妹子的数量。这样,批量增加或减少可以通过调整delta来实现O(1)的时间复杂度。但是,这种方法只能处理全局的批量操作,无法处理部分妹子的批量操作。 如果题目中的批量操作是针对部分妹子(例如,所有有男友的妹子),则需要更复杂的分组处理。比如,维护两个变量:delta_group1和delta_group2,分别对应不同分组的全局增量。这可能变得复杂。 回到原问题,假设题目中的颜值变化都是针对单个妹子的,或者全局的。例如: - 修改单个妹子的颜值:直接更新她的值,并调整总和。 - 全局修改(例如,所有妹子颜值+5):此时总和 += 5 * count,此时count是当前妹子的数量。这时候总和的维护可以通过一个全局的base值,每个妹子存储的颜值是相对于base的偏移。或者,更简单的方式,当有全局变化时,总和 += delta * count。例如,如果每个妹子的颜值都加5,那么总和直接加上5乘以当前妹子的数量。这可以通过维护当前妹子的数量和一个全局的delta变量。但这种情况下,每个妹子的实际颜值可能需要根据全局delta和自身存储的值来计算。例如,实际颜值 = stored_value + global_delta。这时候,当要修改单个妹子的颜值时,需要将她的stored_value调整为 (实际新值 - global_delta)。这可能比较复杂。 不过,这可能取决于具体的操作类型。如果题目中没有全局的批量操作,那么不需要这样处理。因此,在用户的问题描述中,可能需要先明确操作的类型。但用户的问题可能没有详细说明,因此需要假设最可能的情况。 根据用户的问题,可能需要处理以下事件: 1. 新增妹子:颜值初始为某个值。 2. 妹子颜值变化:可能增加或减少一定数值。 3. 妹子分手:被移除。 4. 查询当前所有妹子的总颜值。 因此,数据结构需要支持: - 快速插入(新增妹子)。 - 快速删除(分手)。 - 快速更新颜值。 - 快速查询总和。 在这种情况下,使用哈希表存储妹子ID到颜值的映射,同时维护一个总和变量,是可行的。每次插入时总和加上新值,删除时总和减去该妹子的值,更新时总和减去旧值加上新值。这样,所有操作的时间复杂度都是O(1),总和查询也是O(1)。 例如,用Python的话,可以用一个字典来保存妹子对象,总和用变量total保存。每次操作: - 新增妹子:total += 颜值,字典添加条目。 - 删除妹子:total -= 颜值,字典删除条目。 - 修改妹子颜值:total += (新值 - 旧值),更新字典中的值。 这样,所有操作的时间复杂度都是O(1),总和查询直接返回total的值。 但需要考虑线程安全或并发问题,但题目中可能不需要考虑这些。 那这样设计的话,代码的大致结构可能是这样的: 用一个类来管理妹子: class GirlManager: def __init__(self): self.girls = {} # 妹子ID到颜值的映射 self.total = 0 def add_girl(self, girl_id, yz): if girl_id not in self.girls: self.girls[girl_id] = yz self.total += yz def remove_girl(self, girl_id): if girl_id in self.girls: self.total -= self.girls[girl_id] del self.girls[girl_id] def update_girl(self, girl_id, new_yz): if girl_id in self.girls: old_yz = self.girls[girl_id] self.total += (new_yz - old_yz) self.girls[girl_id] = new_yz def get_total(self): return self.total 这样,每次操作都是O(1)的时间复杂度。妹子ID需要唯一,比如可以用自增的整数作为ID,或者在新增妹子时生成唯一的标识符。 但是,题目中可能还涉及到妹子的状态变化,例如,新恋情可能意味着新增一个妹子,而分手意味着删除。因此,只要将新增和删除对应到add_girl和remove_girl方法即可。 这样,这个设计应该能满足题目的要求。例如,模拟yzc和妹子们的交互过程,包括颜值变化、新增和分手,并高效计算总和。 但需要考虑如果妹子颜值的变更是基于某种公式,比如每天增加一定数值,或者根据其他条件变化。这种情况下,可能需要定期更新所有妹子的颜值。此时,逐个更新会导致O(n)的时间,这可能不够高效。但题目中是否包含这种情况还不明确。如果存在这种批量操作,那么上述方法可能不够高效,需要其他优化手段。 例如,如果有操作是“所有妹子颜值增加10%”,那么每个妹子的颜值变为原来的1.1倍。此时,总和需要重新计算,或者可以维护一个乘法因子。例如,使用两个变量:base_multiplier和base_add,每个妹子的实际颜值是 (stored_value * base_multiplier) + base_add。这样,批量操作可以调整base_multiplier和base_add,而无需修改每个妹子的存储值。例如,当需要全体增加10%时,可以设置 base_multiplier *= 1.1,同时 base_add *= 1.1。当需要全体增加5点时,base_add +=5。这种方法可以将批量操作的时间复杂度降到O(1),但单个妹子的更新需要根据当前的base来计算实际值。这可能比较复杂,但适用于频繁的批量操作场景。 不过,如果题目中没有这种批量操作,那么这种方法可能过于复杂。因此,需要根据题目要求选择合适的方法。假设题目中的颜值变化主要是针对单个妹子,则最初的简单方法足够。 总结: 数据结构选择哈希表(字典)来存储妹子ID和颜值的映射,并维护一个总和变量。这样,所有操作的时间复杂度都是O(1),满足高效的要求。因此,算法设计如下: - 使用字典存储妹子信息,总和变量维护总颜值。 - 新增妹子:添加条目到字典,总和增加。 - 删除妹子:从字典移除,总和减少。 - 更新颜值:更新字典中的值,调整总和。 - 查询总和:直接返回总和变量。 这样,无论妹子数量多少,每个操作的时间都是常数,非常高效。 接下来,需要编写代码实现这个逻辑。例如,在Python中: class GirlManager: def __init__(self): self.girls = dict() # key: girl_id, value: yz_value self.total = 0 def add_girl(self, girl_id, yz): if girl_id not in self.girls: self.girls[girl_id] = yz self.total += yz def remove_girl(self, girl_id): if girl_id in self.girls: self.total -= self.girls[girl_id] del self.girls[girl_id] def update_girl_yz(self, girl_id, new_yz): if girl_id in self.girls: old_yz = self.girls[girl_id] self.total += (new_yz - old_yz) self.girls[girl_id] = new_yz def get_total_yz(self): return self.total 这样,每次操作都是O(1)时间。例如: gm = GirlManager() gm.add_girl(1, 100) # 新增妹子1,颜值100 gm.add_girl(2, 200) # 新增妹子2,颜值200 print(gm.get_total_yz()) # 300 gm.update_girl_yz(1, 150) # 妹子1颜值变为150,总和300-100+150=350 print(gm.get_total_yz()) # 350 gm.remove_girl(2) # 移除妹子2,总和350-200=150 print(gm.get_total_yz()) # 150 这应该能够处理新增、删除、更新和查询操作,时间复杂度都很低。 但可能还需要考虑妹子ID的管理,确保每次新增的妹子有唯一的ID。例如,可以使用自增的ID: class GirlManager: def __init__(self): self.girls = dict() self.total = 0 self.next_id = 1 # 自增ID def add_girl(self, yz): girl_id = self.next_id self.girls[girl_id] = yz self.total += yz self.next_id += 1 return girl_id 这样,每次调用add_girl时,自动分配一个唯一的ID,并返回该ID,方便后续操作。 这样,用户不需要自己管理ID,系统自动生成。 综上所述,这样的设计能够满足题目的需求。因此,代码实现如上述所示。</think>### 问题分析 要模拟yzc与妹子的交互过程并高效计算剩余妹子的颜值总和,需处理以下操作: 1. **动态维护妹子集合**(新增、删除) 2. **快速更新单个妹子颜值** 3. **实时计算总颜值** ### 数据结构设计 1. **哈希表**:存储妹子ID与颜值的映射,实现$O(1)$时间的增删改查 2. **总和变量**:独立维护当前所有妹子的颜值总和,实现$O(1)$时间查询 ### 算法实现 ```python class GirlManager: def __init__(self): self.girls = {} # 妹子ID到颜值的哈希表 self.total = 0 # 实时维护的总颜值 self.next_id = 1 # 自增ID生成器 def add_girl(self, yz_value): """新增妹子并更新总和""" girl_id = self.next_id self.girls[girl_id] = yz_value self.total += yz_value self.next_id += 1 return girl_id def remove_girl(self, girl_id): """移除妹子并更新总和""" if girl_id in self.girls: self.total -= self.girls[girl_id] del self.girls[girl_id] def update_yz(self, girl_id, new_value): """更新妹子颜值并调整总和""" if girl_id in self.girls: old_value = self.girls[girl_id] self.total += (new_value - old_value) self.girls[girl_id] = new_value def get_total_yz(self): """直接返回预计算的总和""" return self.total ``` ### 关键点说明 1. **哈希表高效操作**:通过哈希表实现$O(1)$时间复杂度的增删改查,适应频繁动态变化场景[^1] 2. **总和预计算**:在每次操作时同步更新总和变量,避免遍历计算的开销 3. **自增ID管理**:通过`next_id`保证妹子唯一标识,简化外部调用逻辑 ### 示例调用 ```python manager = GirlManager() id1 = manager.add_girl(80) # 新增妹子,颜值80 id2 = manager.add_girl(90) # 新增妹子,颜值90 print(manager.get_total_yz()) # 输出170 manager.update_yz(id1, 100) # 修改id1妹子颜值到100 print(manager.get_total_yz()) # 输出190 manager.remove_girl(id2) # 移除id2妹子 print(manager.get_total_yz()) # 输出100 ```
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值