判定回文串
来源:互联网 发布:js 获取跨域脚本错误 编辑:程序博客网 时间:2024/05/23 10:12
回文串判定
Time Limit: 1000MS Memory limit: 65536K
题目描述
输入一串字符(长度小于100),判断该串字符是否是回文串(正序读与逆序读内容相同)。
输入
输入一串字符(长度小于100)。
输出
若该串字符是回文串输出“yes",否则输出”no“。
示例输入
asdfgfdsa
示例输出
yes
使用递归的必需条件
- 可以通过递归调用来缩小问题规模,且新问题与原问题有着相同的形式
- 存在一种简单情境,可以使递归在简单情境下退出
一般对递归思想的介绍,都是说将大问题分解为一个个小问题。本人觉得,带着 “如何将问题规模缩少”的思想 比 “将大问题分解为一个个小问题” 的思想要更好地编写递归程序。
避免常见的错误
- 检验递归实现是不是以检查简单情景开始。在几乎所有情况中,递归函数都开始于关键字 if 。如果你的函数不是这样,那么应该仔细检查程序并确信知道自己在做什么
- 正确地解决了简单情景了吗?在递归程序中很多bug都是起源于简单情景的不正确解决。如果简单情景是错误的,那么对更复杂问题的递归解决将会继承相同的错误
- 递归分解使问题更加简单了吗?递归的作用在于,随着问题解决的进行,它将变得越来越就简单。即每一次递归调用中,参数值将会越来越小
- 简化的过程是不是逐渐地达到了简单情景,或者是不是遗漏了一些可能性?常见的一个错误就是没有将全部情况的简单情景测试都包括其中,这些情况可能作为递归分解的结果而产生出来。简单说:你需要正确地将所有的简单情景分析出来
- 函数中的递归调用是不是表示了在形式上和初始问题真的完全相同的子问题?当使用递归分解问题时,关键在于子问题形式的同一性。如果递归调用改变了问题的本性,或者违反了一个初始化的假设,那么全部过程就被破环
- 当使用对递归跳跃的信任时,递归子问题的解决方案是否对初始问题提供了一个完整的解决方案?将一个问题分解为递归子问题仅仅是递归过程的一部分,一旦子问题得到了解决,那么也必须能够将他们重新组装从而得到全部的答案
简单的递归入门
#include <iostream>#include <string.h>#include <algorithm>using namespace std;int fun(int low, int high, char *str, int length){ if (length == 0 || length == 1) return 1; if (str[low] != str[high]) return 0; return fun(low+1, high-1, str, length-2);}int main(){ char str[101]; cin >> str; int length = strlen(str); if(fun(0, length-1, str, length) == 0) cout << "no" << endl; else cout << "yes" << endl; return 0;}
0 0
- 判定回文串
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- 回文串判定
- java回文串判定
- 1524--回文串判定
- 回文串判定(栈)
- 回文串判定
- SDUT 1524 回文串判定
- 回文串判定 (sdut oj)
- 回文串判定 解法一
- SDUT-1524 回文串判定
- Java学习笔记(一)
- XMLHttpRequest对象
- C:递归求斐波那契数列
- SSO 基于Cookie+fliter实现单点登录 实例解析(一)
- jsp页面显示当前时间
- 判定回文串
- error C2440: “=”: 无法从“const char [11]”转换为“LPCWSTR”
- java架构师之路
- UIScrollview的使用
- 经典游戏中的游戏编程
- WEB程序设计之CSS(一)
- 开贴之言
- Java的编译时异常和运行时异常的区别
- 第九周项目5 程序填充