You can use -log10(1-p). On the "nines" it is exactly the number of nines you have:

    $ python3
    Python 3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import math
    >>> def nines(num):
    ...     return -math.log10(1-num)
    ... 
    >>> nines(.9)
    1.0
    >>> nines(.99)
    1.9999999999999996
    >>> nines(.999)
    2.9999999999999996

(Modulo floating point issues of course.)

Which then smoothly covers the entire space:

    >>> nines(.9321)
    1.1681302257194985
    >>> nines(.2)
    0.09691001300805639

But good luck getting that standardized.

▲ lanstin 3 hours ago | parent [-]

I worked at a 4 1/2 nines (99.997) place and it was pretty standard to speak of half-nines at least (although on reflection, perhaps not everyone understood that 0.7 was 1/2 of 0.9 and thought 99.995 was "4 and a half nines") - we went from 3 nines in 2015 to 4 1/2 in 2025 (maybe slide back a little in 2026) - fun task but takes sustained high-level interest in reliability for a long time.

	▲	hinkley 14 minutes ago \| parent [-]
		I don't think that people often understand that if reliability doesn't increase before an adoption cycle, the lack of it will limit the success of the adoption cycle. If I'm tasked with getting a tool to be used at least 2x as much, my first task is to reduce the failures per 1000 runs by 4x. In that way, if adoption increases by 2.5, 3x instead of the the minimum we are looking for, then the number of errors reported per week still goes down instead of up. We like to think of things as percentages but the moment they start increasing in the time domain everyone gets mad, because they asked for and received the wrong thing. And that's on top of the fact that when people are 'forced' to use a tool, any errors they experience will be lumped onto the Learned Helplessness theater they've been engaging in to avoid being made to use a tool that is going to make all of our lives easier.