Kata

I took out the floating point numbers ( and I fixed the typo in the random test headers ). I did not take out the negative zeroes; you can reverse engineer what is expected from testing.

This still does not make it a well-written or well-designed kata ( which is a shame really ), but at least it's solvable now.

Because the reference solution isn't even arbitrary precision real arithmetic, the answer derived by the reference solution is simply wrong. e.g:

1000000000000000 / 3896526038118073 =   
Expected:    '0.25663885990172302343866078834952392091192966443253258931043169884814443475859689408669779071203048'
instead got: '0.25663885990172302292589578160906176584827770888387331907749834099698695209475275668754975679175249'

The correct result is 0.25663885990172302292589578160906176584827770888387331907749834099698695209475275668754975679175249426790238934990... as shown by Wolfram Alpha:

http://www.wolframalpha.com/input/?i=1000000000000000+%2F+3896526038118073

Edit: as another demonstration of the incorrect behaviour, I tested some inputs where a === b, and the reference solution aren't even giving 1.0000...:

4413009194955343.5 / 4413009194955343.5 = 
Expected: '1.00000000000000018128219649179667453475071807778479860673338614478811930419432495701952533845572735'
instead got: '1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'

2543978772493869.5 / 2543978772493869.5 = 
Expected: '9.99999999999999818307358842815939036168824334963639236381663286780869761669083041842512192848775626'
instead got: '1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'

Needs tests with large initial dividend and a small divisor. Very large (or small) quotients aren't tested at all.

Since this is a kata about big decimal, the typical stuff should be banned, aka all the ways that can cause require('bignumber.js') to work.

Also there is no point in identifying -0. It's considered practically the same to everything except to Object.is, and even (-0).toString() gives 0. It's analogous to saying that all NaNs are equal, which is absurd, an artifact of IEEE floats standard and not a good practice in any means.

There is no point in getting digits below precision of a double, because they aren't even resolvable. Even a change in the tiniest significant bit in the divisor will cause the result to change significantly after the 16th digit (aka 1/Number.MAX_SAFE_INTEGER).

I don't think you really understand the intracacies of arbitrary precision real arithmetic. They simply aren't done this way. To begin with, passing numbers in as floating point values is already a grave mistake. They should be passed in as strings (but then this kata would be a duplicate to https://www.codewars.com/kata/divide-numbers-as-strings).

Random tests section titles has a typo: Things like -2345658712136251.5 = 7811398559714191 = should be -2345658712136251.5 / 7811398559714191 =.

Nice kata! Looks like it covers every possible edge case. Got me thinking quite a bit. And more over - this could be a useful function in many other applications! Thanks