The regular expression of JS number format

But the recent leaves gave me a regular, let me suddenly enlightened, than I wrote more sharp, so today take out a simple say (just say the decimal part of the match).

First look at what I wrote before:/\d+ (?: \. \d+)? (?: [ee][+-]?\d+)? \.\d+ (?: [ee][+-]?\d+)?/
The dead leaves found in jQuery:/(?: \ D*\.) \d+ (?: [ee][+-]?\d+)/PS: I removed [+-] because there was no need to match that. )
It's obviously a lot sharper.

My idea is actually very simple, according to the official description and then wrote a bloated regular.
You can see it in the MDN JavaScript Guide Values, variables, and literals#floating-point literals section.
The syntax for the JS number format is described as [(+-)][digits][.digits][(Ee) [(+-)]digits] (PS: This is not a regular)
So I wrote a rough expression (?: \ d+)? (?:\. \d+)? (?: [ee][+-]?\d+)?
At that time looked more comfortable, but in the test, I found a serious problem, can be empty match, simply said that any empty string can match the success.

This is a serious bug, so I split it into two parts to fix the bug, so I got the bloated code above, and there was no way to limit it.

In fact, I think is too simple, I just follow the traditional idea of writing the regular, first match the integer, and then match the decimal, the last match index ...

Then look at the regular/(?: \ D*\.) \d+ (?: [ee][+-]?\d+)/write too domineering.
His idea is to match the floating-point number, then match the integer after the decimal point, then match the index, the same 3 parts, but the matching order is different.
Of course, if a floating-point number is not matched, backtracking discards the match, directly matching the integer and exponent portions.
This doesn't need to be split into two expressions.

Let's do a test, first remove the test, the data is as follows:

123
1.23
1.2e3
1.2e+3
1.2e-3
.123
.12e3
.12e+3
.12e-3

Regular:/(?: \ D*\.) \d+ (?: [ee][+-]?\d+)/

Found that 123 did not match, and that the floating-point data that followed would match correctly.
Why is this, because (?: \ D*\.) is a must match to. , so the integer cannot be matched successfully.
(?:\ D*\.) You can backtrack and then find that the second expression is empty or does not match.
Naturally let the position to the back of the \d+ to match, so the integer can match successfully.

This is a positive despot is the use of minimal code to achieve optimal performance, of course, the whole number of backtracking is necessary, but the performance will not have much problem.

Let's take a look at a test:

var str1 = "123, 1.23, 1.2e3, 1.2e+3, 1.2e-3,. 123,. 12e3,. 12e+3,. 12e-3";
var str2 = "123 123 123 123 123 123 123 123 123 123 123 123 123 123 123-123";

var Re1 =/\d+ (?: \. \d+)? (?: [ee][+-]?\d+)? \.\d+ (?: [ee][+-]?\d+)?/g;
var re11= new RegExp (Re1.source, "G");

var Re2 =/(?: \ D*\.) \d+ (?: [ee][+-]?\d+)/g;
var re22= new RegExp (Re2.source, "G");

Console.log (
Str1.match (Re1). ToString () = = Str1.match (re22). ToString (),
Str2.match (Re1). ToString () = = Str2.match (re22). ToString ()
);

Test (STR1, Re1, "str1 Re1") (STR1, Re11, "str1 re11")
(STR1, Re2, "str1 Re2") (STR1, Re22, "str1 re22");

Test (STR2, Re1, "str2 Re1") (STR2, Re11, "str2 re11")
(STR2, Re2, "str2 Re2") (STR2, Re22, "str2 re22");

function Test (str, RE, name) {
Console.time (name);
for (var i=0; i<1e6; ++i) Str1.match (re);
Console.timeend (name);
return test;
}

For floating-point and integer 1 million match tests, you can see the floating point test difference of 0.1 seconds, the integer difference of 0.2 seconds.
This is already a very small performance difference, some garbage regular, 1 million test may be more than 10 or dozens of seconds.

Such a small knowledge point let me open up the horizon, in fact, just write less, see less, so has been to the, technology this thing, must see more, think more, write just the line.
All right, today's sharing is over, see you tomorrow.