NIST unit rules and conventions

Paul Theodoropoulos paul at
Fri Sep 21 18:45:20 UTC 2018

On 9/21/2018 10:58 AM, Sanjeev Gupta wrote:
> Yes, having a sentence ...
> The change in the value of the residual, after 2 hours or 35 
> iterations, should not exceed 23
> ppm is a requirement of various standards, among which are NIST 543:62 
> and FIPS
> 180 published in 2017.
> ... is slightly confusing wih the line breaks as above.
Yep, exactly.

> ... but you do not know how wide my terminal is when I display the 
> text ...

True. Which would argue for non-breaking space at virtually every 
instance of a  value/unit declaration.

This is a tough one. I am not really competent with asciidoc and its 
plenitude of options. I've already run across a few instances of ascii 
escapes in the text files for rendering the microsecond symbol and 
others - not a lot of them, but they are scattered about in the various 
doc files, and implicitly muck up appearance if viewed in one or another 
format (for me, emacs). I'm starting to lean away from the NIST guidelines (sigh). For 
example, they also recommend (#16, the very next line item):

    The digits of numerical values having more than four digits on
    either side of the decimal marker are separated into groups of three
    using a thin, fixed space counting from both the left and right of
    the decimal marker. Commas are not used to separate digits into
    groups of three.

         15 739.012 53
    15,739.012 53

I find that completely wrongheaded. Not only would it further disrupt 
documents regarding line breaks in asciidoc, I find readability 
significantly _diminished_ by that style.

So, great. here we are. I lobbied to conform to NIST guidelines, now I'm 
rebelling against them.

Let me throw this out there - I personally prefer conjoined value/unit ( 
53µs ). Sanjeev does also. Anyone else want to weigh in?

This is beginning to feel a bit like asking the board of directors to 
spend a day deciding between Dixon Ticonderoga or Faber-Castell pencils 
for the company.

Paul Theodoropoulos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list