Kata

Done. though i'm not sure where to use find_a(j[:],i)? Do i use it as the function?

( JavaScript is vulnerable to input modification as well. )

handled for python. What about JS?

Sorry i'm still quite unfamiliar, but how would input modification affect?

the problem is that arrays (in JS) or lists (in python) are passed by reference. Meaning that if you send the same mutable object to several functions, any of them will see the modifications done by the previous calls:

def user(x):
    x.append('user')
    return x
def refSolution(x):
    x.append('ref')
    return x

lst = []
print(user(lst))          # ['user']
print(refSolution(lst))   # ['user', 'ref'] !!

# but...:

lst = []
print(user(lst[:]))       # ['user']
print(refSolution(lst))   # ['ref']

that's an open door to cheating (for cw's purpose), but that's mostly an opened door to struggles, trying to understand "what the hell is going on?!?", for the users (since they do not see the code of the tests, so they may have a hard time figuring out that their own code is silently causing weird bugs).

[ 6, -24, -5, 18 ] 164
[ 3, 18, 14, 5 ] -357
[ 10, -3, -25, -10 ] 43
[ -9, -9, -20, -29 ] -132
[ -7, -4, 8, -18 ] -787
[ -17, 9, 15, -5 ] 129
[ -14, -11, -12, 5 ] -309
[ -25, 16, -3, 17 ] -632
[ -19, -9, -23, -1 ] -708
[ -9, -5, -16, -25 ] 169
[ -14, -19, 0, -9 ] 334
[ 19, -23, -26, -16 ] 201
[ -25, 20, -23, 14 ] 366
[ 7, 1, -29, -17 ] -315
[ 14, -19, -10, 12 ] -185
[ -22, 5, -1, -21 ] -171
[ 9, -6, 3, -2 ] -640
[ -27, -22, -8, -8 ] -457
[ -9, -19, 5, -28 ] -145
[ -27, 16, 2, 3 ] 457
[ 18, -22, 4, -26 ] -772

I've checked that they're not the same every time?

When I fork my newest solution, I get this:

Random Tests
Random
Log
findA <- [ 13, -7, 2, -10 ] 35
Test Passed
Random
Log
findA <- [ 13, -7, 2, -10 ] 35
Test Passed
Random
Log
findA <- [ 13, -7, 2, -10 ] 35
Test Passed
Random
Log
findA <- [ 13, -7, 2, -10 ] 35
Test Passed

Something weird seems to be going on. I can't yet explain it reading the tests; I agree it shouldn't happen, but it does.

@At1029: it is easy to fix JS tests. Either change:

var k = ...;
var arr = ...;
var h = solution(arr, k);

to

let k = ...;
let arr = ...;
let h = solution(arr, k);

or copy all these variables inside it.

errr... Feels like you forgot to add a slice or anything somewhere, didn't you...? x)

let k = ...;
let arr = ...;
let h = solution([...arr], k);

solution does not modify its arguments so it is not necessary to create a copy of arr.

Changing var to let fixed it.

I fully agree they should not. But did you actually check they aren't?

I did check, and for me, they are not. You can fork my solution and check for yourself.

seems that chai doesn't know what to do with BigInts. Maybe return the results as strings in JS? Or you'll need to find something more appropriate than assert.deepEqual.

EDIT: Seems actually that's only the assertion message that is causing troubles. If you can build your own for each test (with expected and actual, ofc), that may solve the problem too.

Changed the answers to string notation.

Could still have asked for a BigInt and stringified it yourself. That way, solvers can work in BigInt the whole time ( pass a in as array of bigint; n as a Number of course ).

Use appropriate datatypes! Stringifying things is very rarely the solution, and when it's necessary to work around testing framework limitations, do not bother the user with it.

so, need to go with the assertion message, I guess? Can you confirm that's what is needed here? (I know shit to chai... And actually, I know almost shit to JS... x) )

assert.strictEqual( findA([0n,0n,0n,0n],0).toString(), "0" ) should work ( haven't actually tested ).

Might include assert( findA([0n,0n,0n,0n],0) instanceof BigInt, "message" ), but can only pass all tests by returning BigInts anyway. Don't go borrowing trouble.

( duplicate message )

Thanks for the suggestion, now answers will be returned as BigInt.

advise: don't resolve the issues too quickly: as you saw, last time you created more issues than anything.

Added REASONABLE tests. and range of n

52 isn't reasonnable. -10 isn't either (even if it's "almost" reasonnable) ;)

reminder:

sample tests now need 2 more REASONNABLE tests with values of n close to -3 and 6.

EDIT :

• still lacking the fixed tests with 0<=n<3
• JS BigInt to use
• the "hint problem" (see below)

Is it fine now? I tried importing BigInt library in js but can't.

almost good. Sample tests are ok, but in the random tests, i = randint(-1000, 1000) should be: i = randint(-1000, 1000) if randint(0,20) else randint(-15,20). With 1000 tests, you'll be "sure" that boundaries will be correctly tested in almost every batch of tests.

about JS, you need to use Node 10, afaik.

Done

JS and BigInts too? (I cannot see JS's tests)

edge case needed : n between 0 and 2 (and you need to enforce some random tests with that too)

No you don't. Test edge cases with fixed tests and keep your random generator random.

Random tests are great for finding edge cases though. ( For this kata, edge cases are predictable. But they may not always be. )

No you don't.

yes you do. Without constraints, here, there had very little chances to be tested in the random tests. ;)

Which is why you test edge cases with fixed tests.

I'm willing to be wrong here, but you'll have to make me see the light. Isn't it better to be sure your edge cases are covered?

there is a fixed test about that too. ;) Might be good to have more, yes, but that was already hard to get it. x)

If you keep insisting, maybe you'll have them from the author. ;)

• about JS just use what ZED told you about, to make both versions compliant.
• the hint is too much of a hint, there.

I completely overlooked that line. So array is A[0:3] + [n]...

How did you get those values?

Get what?

Obviously

findA([-6,0,-1,6,-68])==findA([6,-1,0,-6,71])
findA([A,B,C,D,-1])==findA([D,C,B,A,4])
findA([A,B,C,D,N])==findA([D,C,B,A,3-N])

That's assuming every value must be an integer, which is true in the context of this kata but not in general.

I feel like we should use Fraction instead, but then there wouldn't be any JS version...

I've used assert.closeTo for js test cases, but for python there isn't such a function?