GitHub will automatically fork the repository to your namespace if you try to edit it online (and don't have write access).

I forked the repo by mistake (not even noticing it) as I tried to edit a typo in it, but the edit window showed it as fixed already, while I had to ctrl-R a couple of times after a while to read the fixed public version of it.

I would gladly contribute there too, but I fear I am not good enough on many sides to be of any actual help, for now.

I think there is a difference between: if(false){ Assert....} and if (rnd == something) { Assert ...} unless rnd is never equal to something. I willingly agree that this kind of test is bad but what I didn't expect was that if [@Test] is executed and assert is not then the test is a success.

You didn't well understand what I said.

I did. But there's effectively no difference between an empty test and static public void testName(){ if(false){ Assert....} }, hence my statement.

@bkaes:

If a test doesn't have any assert, it can get thrown away.

You didn't well understand what I said. All tests have an assert. The problem is than if the assert is not excuted the test is not ignored but considered as "passed". Sure, it's a flaw of mine not to have known that. The only excuse is that when you validate with correct answers you don't see that and CW has no documentation about tests in C# like the ones in the other languages.
I will modify the tests as soon as possible.

Last point: a recommendation of Microsoft or whatever is not a "violation"

It should have been read: not following a recommendation of Microsoft or whatever is not a "violation". I wrote a bit too fast. The word "violation" is too strong and made me jump! As for "believe" I don't want to discuss semantics but here it has the same meaning as in "If you believe in an idea or policy, you think it is good or right" or "promises only bind those who believe in them".
Moreover discussions about computer languages style is the source of innumerable trolls.

@GiacomoSorbi: where did you see Round("103.0102") = "103.011". I don't see that anywhere in C#. The tests in C# are the same as in Ruby and Python... except the bad randomness of a part of them. I will modify that in the morning. Hopefully "Practice makes perfect".

I see no point in trying to convert it back…

To be honest, I was mostly kidding. After everyone picked up random testing, I needed another pet-peeve ^_^. By the way, I've noticed that you forked the codewars-rules repo, but you haven't commited yet. Are you actually interested in contributing, or did you just want a copy in your own namespace? (If you're interested in updates, watch the repository instead).

@bkaes, I see no point in trying to convert it back: of course it can be done without rounding errors, as you convert a number (say 13) in base Pi and then cut it to 3 decimals (in this case).

Plus the kata is only about converting base10 numbers in other bases, irrational bases in primis.

I also partially missed something about Round("103.0102") = "103.011", but assumed it was some default behaviour in C#.

Hm? Did someone say "rounding issues"?

@GiacomoSorbi: Haven't checked this kata yet, but couldn't you convert the user's result back to the original number and compare them to solve rounding issues?

@g964: If a test doesn't have any assert, it can get thrown away. Why do you even have something like this in there? I suggest you to edit the current C# tests as soon as possible.

Last point: a recommendation of Microsoft or whatever is not a "violation"

That doesn't even make sense. Unless you meant "not following a recommendation by Microsoft isn't a violation [of WHAT?]…".

Recommandations are made for those who believe in them.

You're kidding, right? Recommendations have nothing to do with believe. The C# Capitalization Conventions are what's recommended by the maintainer/developer of the language. Nothing more, nothing less. If you don't like the idiomatic C# style, state it ("I'm not a fan of Pascal style method names"). Otherwise it's like saying I don't believe in PEP 8. Simply state that you don't want to be bothered with recommendations or don't agree with them, but don't use empty phrases.

Much appreciated, thanks for your time and your thorough answer :)

@GiacomoSorbi: I read the post and answered.

@MarFOne: I saw your post by pure chance but I want to answer two or three points:

First of all, I'm surprised to see that I just got 11 passed tests with the following piece of code

It seems that you don't understand how these kata tests work (in C# or Java). There are a number of "fixed" tests and there are random tests of the form:

[Test]
  public void Test1() {
	  int r = randomGenerator.Next(2);
	  if (r == 0) {
		  Assert.AreEqual("xxx", Converter.converter(yy, z, tttt));
	  }
  }

The [Test] is entered. If r is zero the Assert.AreEqual part is executed and you can fail or succeed; if r is not zero the Assert.AreEqual is not executed (you can't fail!) so it don't throw any error hence [Test] is considered to succeed and the test is said to have passed. So you didn't pass 11 tests... simply you didn't have to execute them.
How could you have thougth that you passed x tests with such a function result?!
I'll agree with you that it was not the best way to have random tests. I have bettered that in more recent katas!

About rounding and precision: you are asked for giving the first n decimals of your result. You are not asked for rounding, you have to truncate your result at n decimals and that'all.
Evidently along the course of the program you have rounding errors but if you don't want to have rounding errors, take only katas with strings. Nowadays languages give a sufficient precision to be able to truncate to a few decimals without impending the codewarriors. The original kata was written with result as strings. Difficult to introduce a notion of precision with Assert.AreEqual in a string.
When you truncate you are sure of the last decimal (in the limits of the language you are using) but when you round you can't be sure of the last decimal...
Last point: a recommendation of Microsoft or whatever is not a "violation", a recommandation isn't a law!-) Recommandations are made for those who believe in them.

You certainly make some interesting point, but while I seriously limited the test cases with decimals (no random decimal test case in my languages), I still wanted to keep some in the fixed tests. I knew there were some rounding issues, but keeping things (relatively) simple is what kept this kata alive instead of making it like some sort of advanced Euler problem.

For the rest, mostly including the C# part, I would suggest you to copy&paste these thoughts under the comment of the C# translator, as I seriously miss any chance or skill to fix things in that compart.

Thanks for your kind feed :)

While I think the topic is fine, I believe this exercise is quite flawed. It comes down to the lack of considerations of the rounding/precision that should be used - or further specification on how to achieve a certain precision. I can also see the main headache in the comments below seem to be caused by rounding/truncation errors.

First of all, I'm surprised to see that I just got 11 passed tests with the following piece of code

public static string converter(double n, int decimals, double nbase)
{
  return "n:" + n + ":d:" + decimals + ":b:" + nbase;
}

Using that same piece of code also reveals what I believe are the fundamental flaws. Apply a simple algorithm until we have the number of decimals we are asked to provide. Disregarding anything about the precision of the numbers involved and truncation errors in the calculation!

In the instructions (13, 3, Pi) => "103.010" - computing backwards using elementary algebra, we find that "103.010" => 3 + 1/Pi^2 + Pi^2 = 12.96449704 (10 digits of precision).

Simple rounding yields Round("103.0102") = "103.011", and computing backwards we get "103.011" => 3 + 1/Pi^3 + 1/Pi^2 + Pi^2 = 13.00317712 (10 digits of precision).

One interesting test case is the following

Test012
  Expected string length 6 but was 22. Strings differ at index 0.
  Expected: "0.3141"
  But was:  "n:0.314159:d:4:base:10"

I can't think of any scientific text that would consider it correct to return "0.3141" if we are asked for 4 decimals after the decimal point unless a considerable truncation (error) took place - what happened to "0.3142"?

Another interesting test case is

Test03
  Expected string length 10 but was 11. Strings differ at index 4.
  Expected: "36694.0000"
  But was:  "36693.CCCCC"

Rounding 36693.CCCCC to 4 decimals would give the correct result. However considering rounding makes most of the other test cases fail.
My current solution applies a small hack to get the result correct for (100000, 4, 13), but in order to satisfy the other test cases my solution is ultimately incorrect, e.g. it doesn't consider precision/rounding and it cannot handle a test case where the conversion yields 9.95 (nbase 10, decimal 1) and the expected result is 10.00.

Finally, in C#, naming guidelines (e.g. https://msdn.microsoft.com/en-us/library/ms229043(v=vs.110).aspx) recommend that Pascal case be used for method names, i.e. Converter.converter is a violation of that - perhaps 'Convert' instead of 'converter'