What is the need for those "mathematical monospace/bold/sans" characters? Should that be a font issue?
\d less efficient than [0-9]
41–50 of 80 posts
Re: \d less efficient than [0-9]
#42Earlier quoted context omitted.
...at least in C# regexes.
Anyone know if this happens in other languages?
All the same speed in JavaScrip http://jsperf.com/regexcwm/2
Re: \d less efficient than [0-9]
#43Regex is a really powerful tool, but sometimes I wonder just how well people actually understand it as the vast majority of people (myself included) seem to be self taught in the syntax - only learning the bits they need as and when they need it. The problem is, regular expressions is packed full of counter intuitive idiosyncrasies which make perfect sense once they're explained, but are far from obvious. Take this f…
The speed difference is bigger than I would have expected - about one order of magnitude in perl with a simple test script : http://ideone.com/Yso23W
Re: \d less efficient than [0-9]
#44Earlier quoted context omitted.
Nor in python: print re.match(r'\d','੧') None
it does when using the re.U flag re.match(r'\d', u'੧', re.U) sys.version 2.7.3 (default, Mar 4 2013, 14:57:34) \n[GCC 4.7.2]
Also, when using Python 3.2 it seems to be the default behavior
Python 3.2.3 (default, Oct 19 2012, 20:10:41)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match(r'\d', '੧')
Re: \d less efficient than [0-9]
#45I wonder what kind of security vulnerabilities could be looming in validators not expecting non-ascii 0-9 digits and using this regex?
I'm betting quite a few. People should use library number parsers, even if they reject all non-[0-9].
Re: \d less efficient than [0-9]
#46I tend to use ranges (e.g. [0-9]) as they seem to me to be more standard than the token for "any digit" (often \d, but in elisp (Emacs) it's [:digit:])
Re: \d less efficient than [0-9]
#47Short answer: \d includes all the Unicode characters from http://www.fileformat.info/info/unicode/category/Nd/list.htm
Is that actually a good thing? If I'm using \d to validate numbers (for example to check before string to int conversion, or IP address, phone number, or any other use), other unicode digits are not helpful to me. It's great to support unicode, but I don't think the \d should have been extended this way. Add a \ud or something.
Maybe specify the subset of unicode you're expecting in the headers, and have the compiler do the nitty gritty?
Re: \d less efficient than [0-9]
#48Regex is a really powerful tool, but sometimes I wonder just how well people actually understand it as the vast majority of people (myself included) seem to be self taught in the syntax - only learning the bits they need as and when they need it. The problem is, regular expressions is packed full of counter intuitive idiosyncrasies which make perfect sense once they're explained, but are far from obvious. Take this f…
Use the s/, Luke
s/^\s+?(.*)\s+?$/$1/gRe: \d less efficient than [0-9]
#49Regex is a really powerful tool, but sometimes I wonder just how well people actually understand it as the vast majority of people (myself included) seem to be self taught in the syntax - only learning the bits they need as and when they need it. The problem is, regular expressions is packed full of counter intuitive idiosyncrasies which make perfect sense once they're explained, but are far from obvious. Take this f…
Use the s/, Luke s/^\s+?(.*)\s+?$/$1/g
That wouldn't work. First, it will only grab at only one whitespace character at the beginning and at the end. Second, if there was whitespace at the beginning or the end but not both, it won't match at all. "^\s* (.* ?)\s* $/$1/g" would work.
Re: \d less efficient than [0-9]
#50The fact that character ranges like [a-z] can depend on the value of LC_COLLATE is also something not many people are aware of.
$ echo "ä" | LC_COLLATE=C grep '[a-z]'
$ echo "ä" | LC_COLLATE=en_US.UTF-8 grep '[a-z]'
ä