Before reviewing the code we should get the docstring right.

Here are my issues:

1. The correct way to do this:

(e.g. 343.44 and 0.45) into human readable
    numbers with estimated standard deviations (e.g. 343.44(45))

would actually be this:

(e.g. 343.44 and 0.45) into human readable
    numbers with estimated standard deviations (e.g. 343.4(5))

unless the esd was between 0.1 and 0.14 in which case it would be

(e.g. 343.44 and 0.14) into human readable
    numbers with estimated standard deviations (e.g. 343.44(14))

2. we are likely returning a list of strings, not a numpy array. What do you want to do if the function is handed a string rather than a list? This should be discussed in the docstring.
3. The function name is actually the name of our entire project, not this little utility function (machine readable literature!). We should use a name that is easily readable and captures what the function does.
4. For the descriptions we usually follow the numpy standards:

 Parameters
    ----------
    param1 : int
        The first parameter.
    param2 : str
        The second parameter.

    Returns
    -------
    bool
        True if successful, False otherwise.

note the "The" and the colons

I would move from np_array to list before doing string operations I think. This works, but it is a bit illogical.

we will need to test an esd between 0.10 and 0.14 (e.g., 0.13), which behaves differently. Also, we would like to decide what to do (and to test) when the number is not the same number of signficant figures as the esd, e.g. number is 343.1 and the esd is 0.45, or the number is 343.3598 and the esd is 0.56 or 343.1 and esd is 0.045 and so on (try and think of all the possibilities) Please also make sure that we are testing rounding up and rounding down.

let's pass back lists of strings rather than np array think

Do you really want a bunch of string parsing in this function? I suggest no. Just take lists of strings?

you don't need to specify the name of the variable that is returned, since the name will die with the function on return.

don't do string parsing inside this function.

@sbillinge: From bullet point 2 regarding mr_to_hr: "we are likely returning a list of strings, not a numpy array. What do you want to do if the function is handed a string rather than a list? This should be discussed in the docstring."

So you don't want us to accept strings but only discuss in the docstring?

please check that this is fixed (strings are not accepted, no string parsing insded the function, and docstring reflecting all this)

let's model good behavior here and use examples that follow good practice! :)

it should be 0(100) and 0(100) rather than 10(100) and 10(110)

also maybe good to have examples where the main number rounds up and rounds down. for example, 120(20) and 150(20) are testing the same thing, so make the second one 154 pm 20. Also, I don't see any esd rounding getting tested.

not that kind of fix....just round so it is correct!

splits human readable numbers with estimated standard deviations (e.g. 343.4(5)) into machine readable numbers and
    estimated standard deviations (e.g. 343.4 and 0.5).

get the number of significant figures on the esd's right here

this list of tests is ok, but why are we testing four improper number/esd values and only one proper one? maybe also do a 243(6) and a 3200(300)? sthg like that?

good! I like it!

This is another edge case that we should think about. Right now it is 1 +/- 1.4, which is really the same as 1.0 +/- 1.4.

Should that go to 1(1), 0(1), or even 1.0(14)?

@sbillinge Right now, we stick to the convention that when the esd > number, the number is set to zero and the esd is rounded to one significant figure. Do we want different behavior ( regarding the edge case above: 1.0(14) )?

After conversation with @sbillinge @maak-sdu we decided the desired behavior should be (7.26, 100) -> "7(100)" and (50, 100) -> 50(100).

We think we need a new test for Simon's edge case, something like (1, 1.4) -> 1.0(14) . How about (1, 1.5) -> 1(2).

Please can you make the tests look like this and then make the code pass tests? Thanks so much.

@sbillinge: during our meeting today, @berrakozer and I arrived at the following principles. Those are the ones that we will try to follow while editing the behavior of the function.

Whenever the number < esd, the number of significant figures for the number and esd should be one,
whenever the 'esd convention' (see next paragraph) is not in use:

number	esd	number(esd)
1.1	10	1(10)
1.1	11	1(10)

Edge cases, where we only have one significant figure for the number, but add a 'point zero'
to follow the 'esd convention' used elsewhere in the function, we have two significant figures for the esd:

number	esd	number(esd)
1	1.4	1.0(14)
1.2	1.4	1.0(14)

The 'esd convention' should be used whenever the order of magnitude for the esd is equal to or smaller than
that of the number, n_esd <= n_number:

number	esd	number(esd)
1.031	0.0014	1.0310(14)
1.031	0.014	1.031(14)
1.031	0.14	1.03(14)
1.031	1.4	1.0(14)
1.031	14	1(10)
1.031	15	1(20)