Should probably switch to returning answers mod 1e9+7 or similar. Poor design when most of the runtime is taken up by bigint maths that the user has no control over.

For example, we converted our Scala translation to use Longs instead and it can handle the performance tests in 5ms rather than 4000ms.

Scala translation

There is a problem with the test for SQL kata. The sequence in the kata description start from 0 but in the test (expected results) starts from 1.

So in the description is P(0)=P(1)=P(2)=1

but the expected result is P(1)=P(2)=P(3)=1

In the SQL version the description describes the sequence of pell numbers as 0-indexed, but the test expect it to be 1-indexed.

In other words: The description states P(0) = 0, P(1) = 1, ..., but the tests expect P(1) = 0, P(2) = 1, ....

The pgsql client isn't properly parsing dollar quoted strings $$ $$

At least in Rust: missing a test with n = 0.

Numbers array seems to be sorted, but it's not specified in description.

i wrote an O(n) solutions that saves the results in a global array so the the loop to find the next value starts from the last item in the array if it's not already in it. this algorithm only passes around 6 tests since the numbers are lines and lines of digits. any suggestions?

I don't see a test case that covers this stipulation in the description: "Both elements of the pair must be unique".

A test like this would do it:

SumOfTwoSumTargets(new[] { 4, 6, 10 }, 6, 11);

Where if you picked {4, 4} you'd end up with the wrong sum.

I don't get why my very first and simpliest approach is not working.
It fails at 1.000.000 final test.
If i put 1.000.000 on sample test by my own, it pass the test, but not yours.
--> assertEquals(new BigInteger("3944199426501073095"),Padovan.Get(1000000)) on sample pass the test, on yours i get an gooooogle number.
I think i'm missing something important, but can't see it.