Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

\d less efficient than [0-9]

stackoverflow.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: \d less efficient than [0-9]

#62

Post by jrabone »

ars wrote: post #5
wging wrote: post #3

Earlier quoted context omitted.

...at least in C# regexes.

Anyone know if this happens in other languages?

Not true for Java. Docs even say:

  \d         A digit: [0-9]
  \p{Digit}  A decimal digit: [0-9]
which is actually somewhat depressing. I'd expect the named class to include the full Unicode digit set. It's surprising to see:

  ab1234567890cd matched 1234567890
  ab𝟣𝟤𝟥𝟦𝟧𝟨𝟩𝟪𝟫𝟢cd no match
from code using Pattern.compile("(\\p{Digit}+)");

EDIT: and perhaps more surprising to see in the logs:

  Exception in thread "main" java.lang.NumberFormatException: For input string: "𝟤𝟥𝟦𝟧"
  	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
  	at java.lang.Integer.parseInt(Integer.java:449)
That'll keep someone guessing for a while...

Re: \d less efficient than [0-9]

#63

Post by stephencanon »

joosters wrote: post #26

The quoted benchmarks all complete in fractions of a second. Not a good sign. They may be reliable results, performed accurately, but why risk it? IMO you should be running something for much longer, to protect against random short spurious events. e.g. a task reschedule, interrupts, etc could add significant variances. It wouldn't hurt to add a few more zeros to the loop and wait a minute for the results.

Those events are all on the order of micro-seconds, far shorter than the benchmark duration. A tenth of a second is an eternity on a modern CPU.

Re: \d less efficient than [0-9]

#66

Post by Erwin »

Python's methods on unicode strings also apply this logic. E.g.:

     >>>  u'١٣٦٨'.isdigit()
     True

    >>> int(u'١٣٦٨')
    1368
I suppose this could be potentially abused if you are storing and displayeing what is supposed to used as a number as unicode text, but later convert it to a number. E.g. an online shop where you are asked whether you want to pay '5꯸' for some item which looks like 5 plus some weird square, but is really int(u'5꯸') => 58 -- http://www.fileformat.info/info/unicode/char/abf8/index.htm

Re: \d less efficient than [0-9]

#67

Post by netfeed »

rwmj wrote: post #9

I was a bit surprised that Perl does not seem to be matching Unicode digits. Anyone know why? $ echo '0' | perl -pe 'print "yes: " if m/\d/' yes: 0 $ echo '੧' | perl -pe 'print "yes: " if m/\d/' ੧

The documentation says \d should match if you use /u on the regex

Re: \d less efficient than [0-9]

#69

Post by scott_s »

stephencanon wrote: post #63
joosters wrote: post #26

The quoted benchmarks all complete in fractions of a second. Not a good sign. They may be reliable results, performed accurately, but why risk it? IMO you should be running something for much longer, to protect against random short spurious events. e.g. a task reschedule, interrupts, etc could add significant variances. It wouldn't hurt to add a few more zeros to the loop and wait a minute for the results.

Those events are all on the order of micro-seconds, far shorter than the benchmark duration. A tenth of a second is an eternity on a modern CPU.

One of those events, yes. But it's possible for the system to be experiencing a bursty workload unrelated to your benchmark, and many of those events may happen. There's also the problems of startup effects, both at the high level (the VM, which in this case is .Net), the medium level (major and minor page faults) and the low level (caches).

My rule of thumb is that benchmarks which are supposed to be bound by the processor and memory should last at least 60 seconds.

Post reply on HN