In general, I’d propose something like…
(word $Word means frequency $Freq)
(split word $Word into $Chars)
(split $Chars by @\. into $Left and $Right)
(join $Left into $Leftword)
(understand $Left as number $First)
…
However, the . character is treated specially by the Dialog parser, and will always appear in a word on its own. And moreover, the first stage of the parser (after figuring out dictionary words) is to split the input on . and then, so your program would never be given all the words together!
The best I can think of is to modify the definition of (parse commandline $Words) to call a new predicate (early rewrite $Input into $Output) before doing any parsing, then look for periods between numbers and turn them into some other character of your choice (• or the like) before handing it back to the parser.
But this is…not especially elegant. There’s been talk of a preprocessing stage between input and tokenization, which would make this significantly easier, but it doesn’t work with Dialog’s current charset-independent model.
So while this is theoretically possible, unfortunately, I doubt it can be done in a very pleasant way. It may be easier just to move the setting to Europe and use a comma for the decimal separator instead.