ID:2112199
 
var/regex/comma_expression = new("(\\d)(?=(\\d{3})+$)","g") // hidden init proc, I know I know.

#define commafy(x) comma_expression.Replace(num2text(x,12),"$&,")


Example:
var/number = 150255
src << commafy(number) // 150,255
src << commafy(9999999) // 9,999,999


(Note: This is the first time I've done anything with regex, it can probably be improved and I don't know it, so let me know!)

Edit: Updated to globalize the /regex and turn the proc into a #define
is this like turning 1000 into 1,000?
Give an example of before the regex, and example of the after, please.

Just incase I did hit the nail on the head with 1000 -> 1,000
the regex is

var/numbertext = "1000"
var/regex/number_commas = new("(?<=\\d)(?=(\\d{3})+(?!\\d))","g")
number_commas.Replace(numbertext, ",")

Which results in "1,000"

This works by finding the spot where the comma should go (numbers before it, 3 behind it) and substituting a comma there.

works for 1,000, 1,000,000, 1,000,000,000 and so on
Making the comma regex global will improve performance by doing the regex-compiling step only once in world init.

You can actually also make commafication a #define rather than a proc in that case, for improved performance.
In response to CrimsonVision
CrimsonVision wrote:
is this like turning 1000 into 1,000?
Give an example of before the regex, and example of the after, please.

Just incase I did hit the nail on the head with 1000 -> 1,000
the regex is

> var/numbertext = "1000"
> var/regex/number_commas = new("(?<=\\d)(?=(\\d{3})+(?!\\d))","g")
> number_commas.Replace(numbertext, ",")
>

Which results in "1,000"

This works by finding the spot where the comma should go (numbers before it, 3 behind it) and substituting a comma there.

works for 1,000, 1,000,000, 1,000,000,000 and so on


Yep, that's what it does. From the looks of it, your regex isn't much different than mine when it boils down to it, albeit yours is slightly slower to process. Mine seems to work as far as BYOND's precision can go.

I'm pretty new with regex so I may be reading yours wrong, but what's the actual difference?

In response to Lummox JR
Lummox JR wrote:
Making the comma regex global will improve performance by doing the regex-compiling step only once in world init.

You can actually also make commafication a #define rather than a proc in that case, for improved performance.

Ah nice, I wasn't sure if global regex variables would process correctly on subsequent calls, but I'll definitely change that and rewrite it into a #define as well.

Well when I tested yours earlier I couldn't get it to work.
I've since tried again and it works now.
*sigh*

Here's one thing mine handles better:
The string "1000000 1000000"
Yours: "1000000 1,000,000"
Mine: "1,000,000 1,000,000"

Yours relies on the number being the only part of the string and there only being one number, where mine can act on strings that contain more than just the number(s).

For example:
The string "1000 apple"
Yours: "1000 apple"
Mine: "1,000 apple"

tl;dr mine's more robust if you're feeding it existing strings, rather than just num2text()'d numbers.
(as you probably guessed these comparisons are purely on the regexes, not any extra proc/macro gubbins, my test procs allow strings in them where as yours don't so the benefits my regex provides might not even be a thing you need)
Ah gotcha, makes sense. For a different purpose it's definitely ideal, but like you said, mine is more for passing numbers through and using the result.

That explains why yours takes slightly longer to work, it's doing a bit more work.