Decimal separators: what Clarida accepts and what it shows

Half the world writes 0.5 and half writes 0,5, and a qPCR platform has to work for both without ever changing the number. Clarida resolves this asymmetrically: it accepts either separator when you type, and always shows and exports a point. This note explains the rule, why entry and display are governed differently, and the one case Clarida deliberately refuses to interpret — digit grouping, where 1,234 could mean two very different quantities.

A threshold of nought point five is written 0.5 in the United Kingdom and 0,5 in Belgium. Both are correct. Neither is a rounding, an approximation, or a matter of taste — they are the same number under two conventions, and roughly half the world uses each.

For most software this is a cosmetic problem. For a platform holding standard-curve concentrations, efficiency values and quality-control thresholds, it is not: a separator misread by one character silently changes a scientific result, and the change is invisible because the wrong number still looks like a number.

Clarida handles this with a deliberate asymmetry. When you type, either separator is accepted. When Clarida shows you a number — or exports one — it is always a point.

It is tempting to make everything follow the reader's language: show 0,5 to a Belgian user, 0.5 to a British one. Clarida deliberately does not, and the reason is what happens to the number after it leaves the screen.

The text shown in a table is the text you get when you copy it. A results table copied into Excel, a value pasted into an email, a figure caption quoted in a manuscript — all carry whatever separator was on screen. If that separator followed the viewer's browser language, the same experiment copied by two colleagues would produce two different files, and one of them would be misread on paste. Scientific data interchange assumes a point, and formats like RDML are specified that way.

So the output side is pinned to a point everywhere: tables, charts, reports, clipboard, and file exports. This is not a setting, and there is nothing to configure. It is a property of how the numbers are rendered.

Entry is a genuinely different problem, because what reaches the field is outside Clarida's control:

• The keyboard may not match the country. Plenty of scientists on comma locales work on US-layout keyboards, and many numeric keypads emit a point regardless of the operating system's setting.
• Pasted data is usually already point-separated. Instrument exports, RDML files and vendor spreadsheets overwhelmingly use a point. Someone copying 0.0001 out of a supplier's file should not be told it is invalid.
• A field is not a document. When you type into a single numeric box, there is no surrounding context to make a comma mean anything other than a decimal point.

Rejecting the comma would punish people for their hardware. Accepting it costs nothing, provided the rule is narrow.

Exactly one separator character. It is always the decimal separator. The number of digits after it is irrelevant.

Whatever you type, a point is stored. The comma never reaches the database, the calculations, or an export.

Note the third row: 1,234 is read as one point two three four, not as one thousand two hundred thirty-four. That follows directly from the rule — there is one separator, so it is the decimal separator. Digit count plays no part.

This matters more than it looks. The obvious alternative — treat three digits after a comma as grouping — would mean a comma-locale user could type two decimal places but not three, with nothing on screen to explain why. An arbitrary cliff in the middle of ordinary entry is worse than a rule that is occasionally strict.

Digit grouping is not supported anywhere. Not 1,234,567, not 1 234 567, not 1.234.567.

This is the one place where a general rule is impossible. 1,234 means one thousand two hundred thirty-four to one reader and one point two three four to another, and no amount of surrounding context settles it reliably. Rather than guess, Clarida applies the single-separator rule and refuses anything that implies grouping.

The honest consequence: if you paste 1,234 intending one thousand two hundred thirty-four, you will get 1.234. Two things limit the damage. Numbers pasted from a real spreadsheet usually carry both a grouping separator and a decimal one — 1,234.5 — and that shape is rejected outright rather than misread. And where a field has a defined valid range, an out-of-range result is refused regardless of how it was typed.

A rejected entry is always visible: the field reverts to its previous value rather than storing something unexpected. Clarida never silently accepts a number it could not parse.

Everywhere Clarida writes a number for you:

• Tables and charts in the analysis workflow, including axis labels and tooltips
• Copied and exported data — clipboard, spreadsheet export, and the electronic lab notebook
• Reports, both on screen and in the exported artifact
• RDML export, where the format itself requires it

Alongside the separator, Clarida follows the %g convention used by Python, R, MATLAB and printf for deciding when to switch to scientific notation, at six significant digits by default — so 0.00123 stays readable while 0.0000123 becomes 1.23e-05. Quantities with an established convention keep it: Cq to two decimals, geNorm M to three.

If a number you typed was stored differently from what you meant, or a field refuses an entry that looks reasonable, that is worth telling us about. The rule above is intended to cover ordinary scientific entry without exception, and a case it handles badly is a defect rather than a limitation.