1330:【例8.3】最少步数

探讨了在一个100x100的棋盘上,马如何利用日和田两种走法从任意起点到达左上角(1,1)点的最短步数。通过广度优先搜索算法(BFS),遍历所有可能的方向,最终找到从给定起点到目标点的最少步数。

1330:【例8.3】最少步数

【题目描述】

在各种棋中,棋子的走法总是一定的,如中国象棋中马走“日”。有一位小学生就想如果马能有两种走法将增加其趣味性,因此,他规定马既能按“日”走,也能如象一样走“田”字。他的同桌平时喜欢下围棋,知道这件事后觉得很有趣,就想试一试,在一个(100×100)的围棋盘上任选两点A、B,A点放上黑子,B点放上白子,代表两匹马。棋子可以按“日”字走,也可以按“田”字走,俩人一个走黑马,一个走白马。谁用最少的步数走到左上角坐标为(1,1)的点时,谁获胜。现在他请你帮忙,给你A、B两点的坐标,想知道两个位置到(1,1)点可能的最少步数。
【输入】
A、B两点的坐标。
【输出】
最少步数。
【输入样例】

12 16
18 10

【输出样例】

8
9

解题思路:

这题想到的就是bfs,大致就是用队列将每一种结果保存,然后依次出队列,找到目标状态。一共有12个不同的方向可以选择,用一个二维数组保存方向向量,用另一个二维数组来记录棋盘上的点是否被走过。
代码:

#include<iostream>
#include<queue>
using namespace std;
const int M = 105;
bool mp[M][M] = { false };//整个棋盘的信息
int vis[12][2] = { {2,1},{2,2},{1,2},{-1,2},{-2,2},{-2,1},{-2,-1},{-2,-2},{-1,-2},{1,-2},{2,-2},{2,-1} };//vis为方向向量,一个有12个方向
struct crood
{
	int x, y;//坐标
	int step;//走到该点所需要得步数
};//crood记录每个点的位置以及多少步走到该点
int ans;
void bfs(int x,int y)
{
	queue<crood>que;//队列保存状态
	crood now, next;//now是当前的状态,next表示下一步的状态
	now.step = 0;
	now.x = x;
	now.y = y;
	mp[x][y] = true;
	que.push(now);//当前状态入队
	while (!que.empty())
	{
		now = que.front();//更新状态
		que.pop();//出队
		for (int i = 0; i < 12; i++)
		{
			next.x = now.x + vis[i][0];
			next.y = now.y + vis[i][1];
			next.step = now.step + 1;//走一步
			if (next.x == 1 && next.y == 1)//达到目标
			{
				ans = next.step;
				return;
			}
			if ((!mp[next.x][next.y]) && next.x > 0 && next.x < 101 && next.y>0 && next.y < 101)
			//该点没被走过,一定要注意是否越界
			{
				mp[next.x][next.y] = true;//标记已走
				que.push(next);//入队
			}
		}
	}
}
int main()
{
	int x, y;
	while (cin >> x >> y)
	{
		memset(mp, false, sizeof(mp));
		bfs(x, y);
		cout << ans << endl;
	}
	return 0;
}

bfs与dfs总结与详解

翻译成中文,只做翻译: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&#39;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&#39;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&#39;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&#39;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&#39;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
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值