Still having trouble with floating point comparisons:

{msg} - actual and expected differ at index 1 ==> expected: <5.461111421504143E14> but was: <5.4611114215041425E14>

I will mark the issue as resolved then

I believe I forked your solution with the fixed version? I don't quite know how it works it's my first solution in codewars sorry.

• Please stick to Java naming conventions for methods which is camelCase(). (I fixed it quickly before more solutions fly in)
• Please don't put the reference solution into Preloaded, it is accessible from the solution.
• You don't have to seed a new Random with something gathered from Math.random().

Should be done now. Please let me know if there is anythng else!

The margin of error should be relative to the size of the result.

Otherwise, it'll still compare unequal for large results. For example:

array contents differ at index [0], expected: <6.419391364110259E14> but was: <6.419391364110258E14>

Ok I've added margin for the doubles checking, I believe everything should be fine now?
Please let me know!

• There is this assertion in JUnit 5, which allows checking of fuzzy equality of arrays: https://junit.org/junit5/docs/5.0.1/api/org/junit/jupiter/api/Assertions.html#assertArrayEquals-double:A-double:A-double-java.lang.String-
• Even if you specify the value of G, assertions can still fail if users use another formula, or another order of operations (please see https://docs.codewars.com/authoring/recipes/floating-point).

Even if there would be no assertion for arrays of floats, you can create one:

void assertDoubleArrayEqual(double[] expected, double[] actual, double delta, String msg) {
   assertEquals(expected.length, actual.length, "{msg} - expected and actual have different lengths");
   for(i = 0...length) {
     assertEquals(expected[i], actual[i], delta, "{msg} - actual and expected differ at index {i}");
   }
}

or something similar.

Tests should now show the expected vs actual value as you suggested.
As for the floating point errors, we don't exactly know how to handle that since we are comparing the Arrays themselves using assertArrayEquals, since we are giving the gravity constant and the rest of the values are Integers we didn't expect to have that issue.

Random tests are doing some weird checking, and gives clueless test feedback such as

expected: <4> but was: <3>

The tests should be done to show better failure messages (it should show expected and actual value instead of how many values in the array match; we're not playing Mastermind here).

Speaking of which, the random tests are failing most probably because of floating point errors. Please use proper floating point checking with assertApproxEquals. The sample tests should do this as well.

Should be fixed now!

Tests cannot be run:

src/test/java/SolutionTest.java:16: error: <identifier> expected
    double[] static newtonSol(Integer[] force, Integer[] radius, Integer[] mass1, Integer[] mass2){
            ^
src/test/java/SolutionTest.java:16: error: invalid method declaration; return type required
    double[] static newtonSol(Integer[] force, Integer[] radius, Integer[] mass1, Integer[] mass2){
                    ^
2 errors

Nitpick: g should be named G in initial code. g is typically the acceleration on earth surface (aka 9.81).

Similarly, parameter names are inappropriate: names like force should be about a single value, not on the list of values. Something like forces or forceArray is more appropriate as its name.

Java Translation