And maybe, in the case of 0, the number of zeroes after the decimal point, plus one in front, is the number of significant digits. So 00.0000 would have five.

In practice, I think this would be better expressed as 0 ± 0.00013 or something ( and exactly 0 would be extremely unlikely ).

OK, now I can make a case for any number of digits ( depending on the number of zeroes ).

Two precisions could be added to the existing rules:

• a measure (since we're really talking about measures and physical quantities when we're talking about significant figures) can't have no significant digit ;
• if all digits are equal to zero, the last zero is the significant digit (edit : which means that the human or the machine has made a measure that is close to, let's say, 0 meter, 0 centimeter, 0 millimeter, etc. (according to the used scale)).

I fail to see how 0 and 0.0 ( and 0.00, &c ) can ever have different numbers of significant digits.

And I think it should just be specified how many they have, because I can make equally good cases for both zero and one ( though I like zero better ).

From what I've read today, these two examples are correct. But you're right, the current presentation of the rules is a little confusing. IMO, a hierarchical presentation of the existing rules (with maybe a new one for 0 itself, to make it straight) should do the job. I will come back in the coming days with something structured in that way (if no one has a better idea in the meantime).

Fixed in the forks above.

Ok, but now I expect you to deal with the issue above :P

Done.

JS approved, but now Python fork needs to be forked again to fix merge conflict.

JS and Python forks that address this issue, please review (author inactive):

• add a few tests related to the issue in the sample tests ;
• copy the sample tests in the fixed tests, and add some new fixed tests related to the issue.

The Python and JS implementations don't follow the specifications, especially this part:

Zeroes at the beginning of a number are not significant

The evaluation of "00.000227095" should yield 6, and the evaluation of "00.003550880000" should yield 10.

The description does (Zeroes at the beginning of a number are not significant), but not the implementations. I'll open an issue about that.

You're right, the kata does not follow the definition of "significant figures".

Same thing in Python and JS.

Why 00.000227095 is expected to have 9 significant figures (and not 6) or 00.003550880000 expected to have 12 (instead of 10)?

IMO, if you apply the second rule Zeroes at the beginning of a number are not significant, the two precedent numbers have respectively 6 and 10 significant figures. What am I missing ?

For the additional tests there looked to be multiple versions of n in each test. Is this a mistake? I did not undertand that. I passed the main tests but those I could not.

Okay, I think that makes sense to me... Maybe I'll take the Kata down for now, and republish it when I've had time to refactor everything.

Thanks for the feedback!