优化 文本_是否为数字 代码

御风软件

旧版的代码

  

子程序名	返回值类型	公开	备 注
文本_是否为数字	逻辑型		中间不能有空格,用正则表达式来验证字符串是否为数字字符串。
参数名	类 型	参考	可空	数组	备 注
参_文本	文本型

变量名	类 型	静态	数组	备 注
i	整数型
Len	整数型
asc	整数型

Len ＝ 取文本长度 (参_文本)
如果真 (Len ＝ 0)
返回 (假)
计次循环首 (Len, i)
判断 (asc ＜ 48)  ' a=97
返回 (假)
判断 (asc ＞ 57)  ' z=122
返回 (假)



计次循环尾 ()
返回 (真)

.版本 2<br /> <br /> .子程序 文本_是否为数字, 逻辑型, 公开, 中间不能有空格,用正则表达式来验证字符串是否为数字字符串。<br /> .参数 参_文本, 文本型<br /> .局部变量 i, 整数型<br /> .局部变量 Len, 整数型<br /> .局部变量 asc, 整数型<br /> <br /> Len ＝ 取文本长度 (参_文本)<br /> .如果真 (Len ＝ 0)<br />     返回 (假)<br /> .如果真结束<br /> .计次循环首 (Len, i)<br /> <br />     .判断开始 (asc ＜ 48)  ' a=97<br />         返回 (假)<br />     .判断 (asc ＞ 57)  ' z=122<br />         返回 (假)<br />     .默认<br /> <br />     .判断结束<br /> <br /> .计次循环尾 ()<br /> 返回 (真)

新版的代码

  

子程序名	返回值类型	公开	备 注
文本_是否为数字	逻辑型		中间不能有空格,根据ascii 码来验证字符串是否为数字字符串。
参数名	类 型	参考	可空	数组	备 注
参_文本	文本型

变量名	类 型	静态	数组	备 注
i	整数型
asc	整数型

如果真 (参_文本 ＝ “”)
返回 (假)
计次循环首 (取文本长度 (参_文本), i)
asc ＝ 取代码 (参_文本, i)
如果真 (asc ＜ 48 或 asc ＞ 57)  ' 48-57 为 0-9 的 ascii 码
返回 (假)

计次循环尾 ()
返回 (真)

.版本 2<br /> <br /> .子程序 文本_是否为数字, 逻辑型, 公开, 中间不能有空格,根据ascii 码来验证字符串是否为数字字符串。<br /> .参数 参_文本, 文本型<br /> .局部变量 i, 整数型<br /> .局部变量 asc, 整数型<br /> <br /> .如果真 (参_文本 ＝ “”)<br />     返回 (假)<br /> .如果真结束<br /> .计次循环首 (取文本长度 (参_文本), i)<br />     asc ＝ 取代码 (参_文本, i)<br />     .如果真 (asc ＜ 48 或 asc ＞ 57)  ' 48-57 为 0-9 的 ascii 码<br />         返回 (假)<br />     .如果真结束<br /> <br /> .计次循环尾 ()<br /> 返回 (真)

PS:旧版本的备注也是不对的，新版的，也修改了
另外：文本_是否为字母，文本_是否小写字母，文本_是否大写字母 是一样方式进行代码优化。

御风软件

在处理复杂的而且不规则的字符的时候，正则的确速度的确比较快
但是，如果处理简单，或者简单的数据，正则不一定快，简单意味着执行代码少。

不是你看着代码少，就是速度快，这个要通过测试来证明。
正则，你是输入了\d来表示数字，那正则引擎解析的时候，也要去遍历整个文本，然后查找每个字符是不是数字
而且，正则要创建正则对象，每次扫描还要存储扫描结果，特别是贪婪匹配这种无边界的，更加的慢

刚才，我写了代码测试
首先，在1K字符，正则，和ascii码，都是0毫秒，有的时候，正则是16毫秒
然后，1W字符，正则是0-16毫秒，而ascii码是63毫秒左右
最后，10W字符，正则是0+毫秒，而ascii码是5秒左右

所以，ascii码方式，在短的文本时候，是有优势的（1K内）
而我们大部分情况，也是判断一段短的文本是不是数字，甚至不会超过20字符，因为很可能就是获取的一个整数型的数据而已

易寒Eleven

支持一下~支持一下支持一下

御风软件

12368 发表于 2017-1-6 12:45
针对你这个主题我的意思已经表示的很明白了，写一个函数不是专门针对短字符串的，应该考虑的更全面一点
...

采纳不在于“我们”哟，哈哈，看精易官方的意思，我个人还是认为这样蛮好的。
我也只是会员而已，虽然我之前是维护精易模块的，但是，现在，我也和大家一样，是个热心会员喲。

其实，这玩意，和JSON,XML，INI一样，他们三个一样是争论个不停，都是场景和效率问题。

JSON,方便机器读取解析，所以，一般用于数据传输，提升效率。
XML，层次好，一般用于UI设计，也用于配置。
INI，就是用于配置，简单的配置。

所以，说INI效率不行，是对的，因为JSON和XML都能序列化，效率秒杀。
但是，如果只是个简单的软件，读取配置那几毫秒的差距，就是杀鸡用牛刀了。
所以，你看，易语言的用户写的程序的都是INI配置，简单，PS:我也是用这个的。。

看了你发的一个链接，知道你不用易语言，所以角度不一样
而我会其他的语言，也看过一些的技术文章，所以，我明白你的意思
但是，给你个忠告，不要和易语言用户辩论高级玩意，免得起争端，浪费时间哟
因为，易语言用户，比较偏向于用自己的想法来证明一切，而不是考虑场景和测试数据进行验证

御风软件

12368 发表于 2017-1-6 12:45
针对你这个主题我的意思已经表示的很明白了，写一个函数不是专门针对短字符串的，应该考虑的更全面一点
...

考虑应用场景，大部分用户，都不会判断一串很长的字符的
如果真的有这种特殊的需求，觉得效率不行，就只能自己写了

在精易模块的，很多其他的命令，也是这样的，都是大众和方便，所以，加了很多参数和判断。
所以，判断多，循环越多越慢，但只要是方便，和效率在可忍受的范围，都是能接受的

这个其实就是针对短字符串的。。。用正则在字符少的时候反而慢了。。字符多的用的少，这个更符合需求

幻月工作室

御风软件 发表于 2017-1-6 12:40
在处理复杂的而且不规则的字符的时候，正则的确速度的确比较快
但是，如果处理简单，或者简单的数据，正 ...

针对你这个主题我的意思已经表示的很明白了，写一个函数不是专门针对短字符串的，应该考虑的更全面一点

每次循环要读取，然后转换，再判断，和正则扫描内存的效率是没法比的，你应该能理解

御风软件

andkin 发表于 2017-1-6 12:29
听不出来我在反问么？

你以为正则自动机就没有循环了效率就是O(1)了？

看9楼置顶帖，技术交流是好事情，大家都不要过激，每种技术都有应用场景的
而正则，在处理大数据，的确有优势，而模块的这种ascii的写法，更加适合大众用户

幻月工作室

andkin 发表于 2017-1-6 12:29
听不出来我在反问么？

你以为正则自动机就没有循环了效率就是O(1)了？

呵呵，看看自己说的吧

正则效率更低的好吧，能不用尽量不用的东西

andkin

12368 发表于 2017-1-6 12:00
你好好理解一下别人说的话再来反驳，总认为自己会的很多似得

听不出来我在反问么？

你以为正则自动机就没有循环了效率就是O(1)了？

典型的只看到表面，我大笑

幻月工作室

andkin 发表于 2017-1-6 11:52
正则效率高分两方面，一是写法上，二是会写的。

写法上正则确实有优势的，写出匹配的表达式就可以了。 ...

你好好理解一下别人说的话再来反驳，总认为自己会的很多似得

这种东西应该注重效率，如果字符串很长怎么办，用正则更优化吧

长度是1000的字符串，你挨个去判断么？循环1000次是吧，然后比正则表达式扫描的速度还快是么？
^\d+$就能解决问题，你要去循环1000次，我笑了