补题之路:CF1156C:Match Points

探讨了在给定点集和距离约束下,寻找最大匹配点对数量的算法问题。通过对比错误思路与正确解法,介绍了如何从中间元素开始,使用类似滑动窗口的方法,有效地找到符合条件的点对。

题目描述

You are given a set of points x1x1, x2x2, …, xnxn on the number line.Two points ii and jj can be matched with each other if the following conditions hold:neither ii nor jj is matched with any other point;|xi−xj|≥z|xi−xj|≥z.What is the maximum number of pairs of points you can match with each other?

Input

The first line contains two integers nn and zz (2≤n≤2⋅1052≤n≤2⋅105, 1≤z≤1091≤z≤109) — the number of points and the constraint on the distance between matched points, respectively.The second line contains nn integers x1x1, x2x2, …, xnxn (1≤xi≤1091≤xi≤109).

Output

Print one integer — the maximum number of pairs of points you can match with each other.

ExamplesInput

4 2
1 3 3 7

Output

2

Input

5 5
10 9 5 8 7

Output

1

Note

In the first example, you may match point 11 with point 22 (|3−1|≥2|3−1|≥2), and point 33 with point 44 (|7−3|≥2|7−3|≥2).In the second example, you may match point 11 with point 33 (|5−10|≥5|5−10|≥5).

错误思路
从第一个开始二分找a[i]+z。
错误代码


#include <iostream>
#include <algorithm>
#include <cstdio>
#include <cstring>
#include <bits/stdc++.h>
int vis[200005]={0};
long long a[200005];
using namespace std;
int main(){
 int n,t;
 scanf("%d%d",&n,&t);
 for(int i = 0;i < n;i++)scanf("%lld",&a[i]);
 sort(a,a+n);
 int cnt = 0;
 for(int i = 0;i < n;i++){
  int k=lower_bound(a+i,a+n,a[i]+t)-a;
  if(!vis[i]&&!vis[k]&&k<n){
   vis[k]=1;
   vis[i]=1;
   cnt++;
  }
 }
 cout << cnt << endl;
// printf("Time cost : %lf s\n",(double)clock()/CLOCKS_PER_SEC);
 return 0;
} 

为什么错了呢?因为 4 2 1 3 4 5 这组数据就过不了。
换个思路,最多的匹配数是n/2,不妨从中间找和第一个匹配的。写起来有点像尺取。
ac代码


#include <iostream>
#include <algorithm>
using namespace std;
long long a[200005];
int main(){
 int n;
 long long z;
 cin >> n >> z;
 for(int i = 1; i <= n;i++)scanf("%lld",&a[i]);
 sort(a+1,a+n+1);
 int l = 1,r = (n+1)/2+1;
 long long cnt = 0;
 while(l<=n&&r<=n){
  if(a[r]-a[l]>=z)cnt++,l++;
  r++;
 }
 cout << cnt << endl;
}

好题,,如果我当时打了这场这题很大概率过不了hhh

翻译 SourceForge logo Home Browse Ethernet bridge tables Mailing Lists Thread: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 Brought to you by: bdschuym Summary Files Reviews Support Mailing Lists Tickets ▾ Code Mailing Lists Menu ▾ ebtables-user [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Bart De S. <bds...@pa...> - 2006-12-18 19:09:02 Hi all, I've just uploade release candidate 3 of ebtables v2.0.8. Changes: * fixed a few reported bugs * ebt_among --among-dst-file and --among-src-file: allow the list to be given in a file (circumvents command line max. line length) * ebt_nat --snat-arp: if it's an arp packet, also change the source address in the arp header * ebt_mark --mark-or, --mark-xor, --mark-and Cheers, Bart Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Carl-Daniel H. <c-d...@gm...> - 2006-12-19 13:44:46 Hi Bart, the -fPIC problem on x86_64 is still there: # make [...] ld -shared -soname libebtc.so -o libebtc.so -lc getethertype.o communication.o libebtc.o useful_functions.o ebtables.o ld: ebtables.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ebtables.o: could not read symbols: Bad value make: *** [libebtc] Error 1 If you need more information about the problem, please take a look at http://www.x86-64.org/lists/discuss/msg05760.html . Besides that, I get these warnings: ebtables.c: In function `list_em': ebtables.c:324: warning: long long unsigned int format, uint64_t arg (arg 2) ebtables.c:324: warning: long long unsigned int format, uint64_t arg (arg 3) ebtables.c:326: warning: long long unsigned int format, uint64_t arg (arg 2) ebtables.c:326: warning: long long unsigned int format, uint64_t arg (arg 3) extensions/ebt_among.c: In function `parse': extensions/ebt_among.c:348: warning: implicit declaration of function `close' This patch fixes them: --- ebtables-v2.0.8-rc3/ebtables.c 2006-12-17 22:27:17.000000000 +0100 +++ ebtables-v2.0.8-rc3-modified/ebtables.c 2006-12-19 13:24:41.000000000 +0100 @@ -321,9 +321,9 @@ uint64_t bcnt = hlp->cnt.bcnt; if (replace->flags & LIST_X) - printf("-c %llu %llu", pcnt, bcnt); + printf("-c %llu %llu", (unsigned long long)pcnt, (unsigned long long)bcnt); else - printf(", pcnt = %llu -- bcnt = %llu", pcnt, bcnt); + printf(", pcnt = %llu -- bcnt = %llu", (unsigned long long)pcnt, (unsigned long long)bcnt); } printf("\n"); hlp = hlp->next; diff -urN ebtables-v2.0.8-rc3/extensions/ebt_among.c ebtables-v2.0.8-rc3-modified/extensions/ebt_among.c --- ebtables-v2.0.8-rc3/extensions/ebt_among.c 2006-12-17 22:27:17.000000000 +0100 +++ ebtables-v2.0.8-rc3-modified/extensions/ebt_among.c 2006-12-19 13:08:15.000000000 +0100 @@ -7,6 +7,7 @@ */ #include <stdio.h> +#include <unistd.h> #include <string.h> #include <stdlib.h> #include <getopt.h> Explanation: uint64_t is unsigned long long on i386, but unsigned long on x86_64. The problems of creating rules on x86_64 is still there. However, it seems that Al Viro has fixed something in this area: http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bb2ef25c2c62444b8fdb0346a23658a419803df9 Regards, Carl-Daniel -- http://www.hailfinger.org/ Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Bart De S. <bds...@pa...> - 2006-12-22 18:37:32 Op di, 19-12-2006 te 14:44 +0100, schreef Carl-Daniel Hailfinger: > Hi Bart, > > the -fPIC problem on x86_64 is still there: <snip> > Explanation: uint64_t is unsigned long long on i386, but unsigned long > on x86_64. Should be fixed in CVS, thanks. > The problems of creating rules on x86_64 is still there. However, it seems > that Al Viro has fixed something in this area: > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bb2ef25c2c62444b8fdb0346a23658a419803df9 That's unrelated, it fixes the checking for maliciously constructed ebtables tables. cheers, Bart Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Carl-Daniel H. <c-d...@gm...> - 2006-12-23 01:29:15 Bart De Schuymer wrote: > Op di, 19-12-2006 te 14:44 +0100, schreef Carl-Daniel Hailfinger: >> Hi Bart, >> >> the -fPIC problem on x86_64 is still there: > > <snip> >> Explanation: uint64_t is unsigned long long on i386, but unsigned long >> on x86_64. > > Should be fixed in CVS, thanks. Thanks! >> The problems of creating rules on x86_64 is still there. However, it seems >> that Al Viro has fixed something in this area: >> http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bb2ef25c2c62444b8fdb0346a23658a419803df9 > > That's unrelated, it fixes the checking for maliciously constructed > ebtables tables. Then normal ebtables userspace on x86_64 definitely counts as malicious. I was referring to this part of the changelog: > While we are at it, don't subtract unrelated pointers... The problems with loading rules on x86_64 have disappeared after applying the patch series from Al Viro. However, the "among" match still reports problems: # ebtables -t nat -A ebtables-experiment --among-dst 2:3:4:5:6:7=192.168.0.1,2:3:4:5:6:8=192.168.0.3,2:3:4:5:6:9=192.168.0.2 -j ACCEPT old_size=56,new_size=1124, sizeof(ebt_entry_match)=40, msize=1084 wh_dst_ofs=16 The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. dmesg says (debugging added by me): ebtables: among: wrong size: 1084 against expected 1080, rounded to 1080, sizeof(ebt_among_info)=12, wh_size(dst)=1068, wh_size(src)=0, sizeof(ebt_entry_match)=40 kernel msg: ebtables bug: please report to author: match->check failed The source of the problem is easy to spot: In userspace, wh_dst_ofs==16 (because (**match).match_size==16 at line 357 in extensions/ebt_among.c), but in kernelspace we check wh_dst_ofs against sizeof(struct ebt_among_info)==12. That is obviously going to fail. Always. Regards, Carl-Daniel -- http://www.hailfinger.org/ Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Bart De S. <bds...@pa...> - 2006-12-23 17:22:31 Op za, 23-12-2006 te 02:29 +0100, schreef Carl-Daniel Hailfinger: > The problems with loading rules on x86_64 have disappeared after > applying the patch series from Al Viro. Well, I'll be damned :) > However, the "among" match still reports problems: > The source of the problem is easy to spot: > In userspace, wh_dst_ofs==16 (because (**match).match_size==16 at > line 357 in extensions/ebt_among.c), but in kernelspace we check > wh_dst_ofs against sizeof(struct ebt_among_info)==12. Are you saying sizeof(struct ebt_among_info) differs between userspace and the kernel? Please double check this... cheers, Bart Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Carl-Daniel H. <c-d...@gm...> - 2006-12-23 19:37:56 Bart De Schuymer wrote: > Op za, 23-12-2006 te 02:29 +0100, schreef Carl-Daniel Hailfinger: >> However, the "among" match still reports problems: >> The source of the problem is easy to spot: >> In userspace, wh_dst_ofs==16 (because (**match).match_size==16 at >> line 357 in extensions/ebt_among.c), but in kernelspace we check >> wh_dst_ofs against sizeof(struct ebt_among_info)==12. > > Are you saying sizeof(struct ebt_among_info) differs between userspace > and the kernel? Please double check this... No, I wanted to say that match_size is set in userspace to something which is != sizeof(struct ebt_among_info). More diagnostics: on x86-64: libebtc.c:1175 in ebt_register_match: m->m->match_size set to 8 aligned from 6 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 56 aligned from 52 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 32 aligned from 28 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 8 aligned from 8 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 24 aligned from 24 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 8 aligned from 2 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 72 aligned from 72 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 16 aligned from 12 (among) libebtc.c:1175 in ebt_register_match: m->m->match_size set to 32 aligned from 32 on i386: libebtc.c:1175 in ebt_register_match: m->m->match_size set to 8 aligned from 6 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 52 aligned from 52 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 28 aligned from 28 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 8 aligned from 8 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 12 aligned from 12 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 4 aligned from 2 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 72 aligned from 72 libebtc.c:1175 in ebt_register_match: m->m->match_size set to 12 aligned from 12 (among) libebtc.c:1175 in ebt_register_match: m->m->match_size set to 24 aligned from 24 Userspace sets wh_dst_ofs=EBT_ALIGN(sizeof(struct ebt_among_info)), but the kernel expects wh_dst_ofs=sizeof(struct ebt_among_info). On i386, the EBT_ALIGN macro has no effect for the among match, but on x86_64 it does. That explains why the bug was never noticed on i386. So we either change the kernel or userspace. Changing the kernel would mean that suddenly all existing userspace works. Regards, Carl-Daniel -- http://www.hailfinger.org/ Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Bart De S. <bds...@pa...> - 2007-01-10 19:08:19 Attachments: patch_among.diff Op za, 23-12-2006 te 20:37 +0100, schreef Carl-Daniel Hailfinger: > Userspace sets wh_dst_ofs=EBT_ALIGN(sizeof(struct ebt_among_info)), but the > > kernel expects wh_dst_ofs=sizeof(struct ebt_among_info). On i386, the EBT_ALIGN > macro has no effect for the among match, but on x86_64 it does. That explains > why the bug was never noticed on i386. > > So we either change the kernel or userspace. Changing the kernel would mean > that suddenly all existing userspace works. It's best not to force people into using a specific kernel, so adjusting userspace is the thing to do. Please test the attached userspace patch. Cheers, Bart Re: [Ebtables-user] [RELEASE] ebtables version 2.0.8-rc3 From: Carl-Daniel H. <c-d...@gm...> - 2008-01-28 17:13:26 On 10.01.2007 20:08, Bart De Schuymer wrote: > Op za, 23-12-2006 te 20:37 +0100, schreef Carl-Daniel Hailfinger: > > >> Userspace sets wh_dst_ofs=EBT_ALIGN(sizeof(struct ebt_among_info)), but the >> kernel expects wh_dst_ofs=sizeof(struct ebt_among_info). On i386, the EBT_ALIGN >> macro has no effect for the among match, but on x86_64 it does. That explains >> why the bug was never noticed on i386. >> >> So we either change the kernel or userspace. Changing the kernel would mean >> that suddenly all existing userspace works. >> > > It's best not to force people into using a specific kernel, so adjusting > userspace is the thing to do. > > Please test the attached userspace patch. > I'm very sorry, but I have been unable to take the machine in question out of production to test the patch. I found a commit in OpenVZ which touches the code in question and will probably be upstreamed sometime. http://git.openvz.org/?p=linux-2.6.24-openvz;a=commit;h=a3d28217a51b57b2980f5fc1203cf7b402ca9bb7 Regards, Carl-Daniel
12-16
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值