Be the Winner

本文探讨了在特定苹果堆游戏中应用反尼姆博弈策略的方法。通过分析苹果堆的排列和数量,玩家可以制定出必胜策略。文章提供了一个算法实现示例,展示了如何计算在不同情况下的获胜可能性。

题目

Let's consider m apples divided into n groups. Each group contains no more than 100 apples, arranged in a line. You can take any number of consecutive apples at one time. 
For example "@@@" can be turned into "@@" or "@" or "@ @"(two piles). two people get apples one after another and the one who takes the last is 
the loser. Fra wants to know in which situations he can win by playing strategies (that is, no matter what action the rival takes, fra will win). 

Input

You will be given several cases. Each test case begins with a single number n (1 <= n <= 100), followed by a line with n numbers, the number of apples in each pile. There is a blank line between cases. 

Output

If a winning strategies can be found, print a single line with "Yes", otherwise print "No". 

样例

Sample Input

2
2 2
1
3

Sample Output

No
Yes

一道反尼姆博弈!

#include <iostream>
#include <cstdio>
#include <cstdlib>
#include <algorithm>
#include <cmath>
#include <map>
#include <set>
#include <queue>
#include <stack>
#include <vector>
#include <string.h>
#include <string>
typedef long long ll;
#define INF 0x3f3f3f3f
using namespace std;
ll x;
int main() {
	int n, num, ans, k;
	while (cin >> n && n) {
		num = 0;
		ans = 0;
		while (n--) {
			cin >> x;
			if (x >= 2) num++;
			ans ^= x;
		}
		if ((ans != 0 && num != 0) || (ans == 0 && num == 0))  cout << "Yes" << endl;
		else cout << "No" << endl;
	}
	return 0;
}

 

Task 3: Simulate Election (4 marks) To select the winner of the election, instant-runoff voting (IRV) is used. This method selects a winner over the course of a number of rounds. The following procedure is repeated until there is only one candidate left: Assign each ballot to the candidate who is ranked highest on that ballot and who has not yet been eliminated. Eliminate the candidate(s) with the lowest number of assigned ballots in that round, so they are not counted in future rounds. For this task, you must run a simulated IRV for an election given a list of valid positional ballots. Write a function simulate_election(ballots, parties) You need to write a function that returns the full history of elimination rounds for the given election. Arguments: ballots: a list of valid positional ballots. parties: the ordered list of parties contesting the election. Returns: a list of elimination round history, where each round consists of a tuple with: A dictionary mapping each remaining candidate to their vote total A set of candidates to be eliminated after that round. Details: If two candidates are tied for the lowest vote total in a round, they are both eliminated simultaneously If there is no unique winner, your program should raise a TiedElectionError as defined at the top of the provided code. As a reminder, you can raise an error using the built in Python statement raise TiedElectionError. This is a custom Exception type that we have defined for you. You can use it like any other Exception , and there is no need to understand how we have defined it. Interested students can learn more about custom object and classes in this optional worksheet. Example Calls:
10-17
(c++题解,代码运行时间小于200ms,内存小于64MB,代码不能有注释)It’s time for the company’s annual gala! To reward employees for their hard work over the past year, PAT Company has decided to hold a lucky draw. Each employee receives one or more tickets, each of which has a unique integer printed on it. During the lucky draw, the host will perform one of the following actions: Announce a lucky number x, and the winner is then the smallest number that is greater than or equal to x. Ask a specific employee for all his/her tickets that have already won. Declare that the ticket with a specific number x wins. A ticket can win multiple times. Your job is to help the host determine the outcome of each action. Input Specification: The first line contains a positive integer N (1≤N≤10 5 ), representing the number of tickets. The next N lines each contains two parts separated by a space: an employee ID in the format PAT followed by a six-digit number (e.g., PAT202412) and an integer x (−10 9 ≤x≤10 9 ), representing the number on the ticket. Then the following line contains a positive integer Q (1≤Q≤10 5 ), representing the number of actions. The next Q lines each contain one of the following three actions: 1 x: Declare the ticket with the smallest number that is greater than or equal to x as the winner. 2 y: Ask the employee with ID y all his/her tickets that have already won. 3 x: Declare the ticket with number x as the winner. It is guaranteed that there are no more than 100 actions of the 2nd type (2 y). Output Specification: For actions of type 1 and 3, output the employee ID holding the winning ticket. If no valid ticket exists, output ERROR. For actions of type 2, if the employee ID y does not exist, output ERROR. Otherwise, output all winning ticket numbers held by this employee in the same order of input. If no ticket wins, output an empty line instead. Sample Input: 10 PAT000001 1 PAT000003 5 PAT000002 4 PAT000010 20 PAT000001 2 PAT000008 7 PAT000010 18 PAT000003 -5 PAT102030 -2000 PAT000008 15 11 1 10 2 PAT000008 2 PAT000001 3 -10 1 9999 1 -10 3 2 1 0 3 1 2 PAT000001 3 -2000 Sample Output: PAT000008 15 ERROR ERROR PAT000003 PAT000001 PAT000001 PAT000001 1 2 PAT102030
08-12
翻译成中文,只做翻译:8.2. Simultaneous Probe Tiebreaking The astute reader will observe that there is a race condition inherent in the previous description. If two hosts are probing for the same name simultaneously, neither will receive any response to the probe, and the hosts could incorrectly conclude that they may both proceed to use the name. To break this symmetry, each host populates the query message's Authority Section with the record or records with the rdata that it would be proposing to use, should its probing be successful. The Authority Section is being used here in a way analogous to the way it is used as the "Update Section" in a DNS Update message [RFC2136] [RFC3007]. When a host is probing for a group of related records with the same name (e.g., the SRV and TXT record describing a DNS-SD service), only a single question need be placed in the Question Section, since query type "ANY" (255) is used, which will elicit answers for all records with that name. However, for tiebreaking to work correctly in all cases, the Authority Section must contain *all* the records and proposed rdata being probed for uniqueness. When a host that is probing for a record sees another host issue a query for the same record, it consults the Authority Section of that query. If it finds any resource record(s) there which answers the query, then it compares the data of that (those) resource record(s) with its own tentative data. We consider first the simple case of a host probing for a single record, receiving a simultaneous probe from another host also probing for a single record. The two records are compared and the lexicographically later data wins. This means that if the host finds that its own data is lexicographically later, it simply ignores the other host's probe. If the host finds that its own data is lexicographically earlier, then it defers to the winning host by waiting one second, and then begins probing for this record again. The logic for waiting one second and then trying again is to guard against stale probe packets on the network (possibly even stale probe packets sent moments ago by this host itself, before some configuration change, which may be echoed back after a short delay by some Ethernet switches and some 802.11 base stations). If the winning simultaneous probe was from a real other host on the network, then after one second it will have completed its probing, and will answer subsequent probes. If the apparently winning simultaneous probe was in fact just an old stale packet on the network (maybe from the host itself), then when it retries its probing in one second, its probes will go unanswered, and it will successfully claim the name. The determination of "lexicographically later" is performed by first comparing the record class (excluding the cache-flush bit described in Section 10.2), then the record type, then raw comparison of the binary content of the rdata without regard for meaning or structure. If the record classes differ, then the numerically greater class is considered "lexicographically later". Otherwise, if the record types differ, then the numerically greater type is considered "lexicographically later". If the rrtype and rrclass both match, then the rdata is compared. In the case of resource records containing rdata that is subject to name compression [RFC1035], the names MUST be uncompressed before comparison. (The details of how a particular name is compressed is an artifact of how and where the record is written into the DNS message; it is not an intrinsic property of the resource record itself.) The bytes of the raw uncompressed rdata are compared in turn, interpreting the bytes as eight-bit UNSIGNED values, until a byte is found whose value is greater than that of its counterpart (in which case, the rdata whose byte has the greater value is deemed lexicographically later) or one of the resource records runs out of rdata (in which case, the resource record which still has remaining data first is deemed lexicographically later). The following is an example of a conflict: MyPrinter.local. A 169.254.99.200 MyPrinter.local. A 169.254.200.50 In this case, 169.254.200.50 is lexicographically later (the third byte, with value 200, is greater than its counterpart with value 99), so it is deemed the winner. Note that it is vital that the bytes are interpreted as UNSIGNED values in the range 0-255, or the wrong outcome may result. In the example above, if the byte with value 200 had been incorrectly interpreted as a signed eight-bit value, then it would be interpreted as value -56, and the wrong address record would be deemed the winner. 8.2.1. Simultaneous Probe Tiebreaking for Multiple Records When a host is probing for a set of records with the same name, or a message is received containing multiple tiebreaker records answering a given probe question in the Question Section, the host's records and the tiebreaker records from the message are each sorted into order, and then compared pairwise, using the same comparison technique described above, until a difference is found. The records are sorted using the same lexicographical order as described above, that is, if the record classes differ, the record with the lower class number comes first. If the classes are the same but the rrtypes differ, the record with the lower rrtype number comes first. If the class and rrtype match, then the rdata is compared bytewise until a difference is found. For example, in the common case of advertising DNS-SD services with a TXT record and an SRV record, the TXT record comes first (the rrtype value for TXT is 16) and the SRV record comes second (the rrtype value for SRV is 33). When comparing the records, if the first records match perfectly, then the second records are compared, and so on. If either list of records runs out of records before any difference is found, then the list with records remaining is deemed to have won the tiebreak. If both lists run out of records at the same time without any difference being found, then this indicates that two devices are advertising identical sets of records, as is sometimes done for fault tolerance, and there is, in fact, no conflict. 8.3. Announcing The second startup step is that the Multicast DNS responder MUST send an unsolicited Multicast DNS response containing, in the Answer Section, all of its newly registered resource records (both shared records, and unique records that have completed the probing step). If there are too many resource records to fit in a single packet, multiple packets should be used. In the case of shared records (e.g., the PTR records used by DNS- Based Service Discovery [RFC6763]), the records are simply placed as is into the Answer Section of the DNS response. In the case of records that have been verified to be unique in the previous step, they are placed into the Answer Section of the DNS response with the most significant bit of the rrclass set to one. The most significant bit of the rrclass for a record in the Answer Section of a response message is the Multicast DNS cache-flush bit and is discussed in more detail below in Section 10.2, "Announcements to Flush Outdated Cache Entries". The Multicast DNS responder MUST send at least two unsolicited responses, one second apart. To provide increased robustness against packet loss, a responder MAY send up to eight unsolicited responses, provided that the interval between unsolicited responses increases by at least a factor of two with every response sent. A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course. Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described in Section 9, "Conflict Resolution". 8.4. Updating At any time, if the rdata of any of a host's Multicast DNS records changes, the host MUST repeat the Announcing step described above to update neighboring caches. For example, if any of a host's IP addresses change, it MUST re-announce those address records. The host does not need to repeat the Probing step because it has already established unique ownership of that name. In the case of shared records, a host MUST send a "goodbye" announcement with RR TTL zero (see Section 10.1, "Goodbye Packets") for the old rdata, to cause it to be deleted from peer caches, before announcing the new rdata. In the case of unique records, a host SHOULD omit the "goodbye" announcement, since the cache-flush bit on the newly announced records will cause old rdata to be flushed from peer caches anyway. A host may update the contents of any of its records at any time, though a host SHOULD NOT update records more frequently than ten times per minute. Frequent rapid updates impose a burden on the network. If a host has information to disseminate which changes more frequently than ten times per minute, then it may be more appropriate to design a protocol for that specific purpose.
最新发布
10-18
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值