how close I was to do this, my solution cannot be compared to this.
These memory limited BF kata are just full of absolutely unreadable answers and I find that hilarious.
Actually [+] is faster for values in range [129, 255] and [-] is faster for values in range [1, 127].
0 and 128 are indifferent. So you can prefer one over the other only if you have an idea of your values' distribution. In real cases, [-] seems better in most cases, as all ASCII characters are in range [0, 127].
Hey What WTH??
My code was working PERFECTLY* on EVERY BF interpreter I could find on the web
(* including every specific case i.e.
"A" --> "A"
"strings" --> "s")
and and didn't contain more than 52 characters...
But here for some reason, it keeps "timing out"!?
(but executes perfectly fine on every bf interpreter, with instant result)
...This is very frustrating :/
Yup. Did the same but replacing the "-" by a "+", as I had thought in this particular case, going "upwards" would be "slightly faster" (like "254 max length instead of 255")...
...But now I'm thinking of it, it isn't, as the first bit we start at is not yet incremented; so still 255 max length in both cases...
...I guess I should have stayed with "-" as this version looks "cleaner"/"more explicit" ^^
OH re-wait; in fact, the "+" version might indeed be slightly "faster" after all: like 32386 increments instead of 32640 decrements...
...I guess... (Unless I'm wrong?.. I think I need some sleep)
I think our solutions might be failed with 128+128 as inputs but they only allow 32-126, so that is not a problem.
Sure, no worries. In terms of your solution, it does what it's designed to do (and passes all the tests) so is correct and valid, I found it pretty obvious what it was doing (you'd be amazed how rare this can sometimes be), so it is a good and viable solution. The only thing I would say is you don't need needless comments. Commenting that you've created an empty variable for example, doesn't add anything IMO.
In practice, given your's has a higher complexity class than an optimal solution, then in the real world you would probably go with the more optimal solution, especially here since it's trivial to do so. That said it depends on how much of a bottleneck it actually is as to whether you'd bother (i.e. if you knew for certain this would only ever be called with arrays of 10 elements of less then optimising it would be unnecessary, just as an example). There is a saying: premature optimisation is the root of all evil.
This comment is hidden because it contains spoiler information about the solution
woops, replied to wrong comment, how to delete?
I've ran it locally and this solution gives 3 for input [3, 4, 5, 6, 3] - which is the correct answer. How are you running the function? (I just copied and pasted into a file and ran it using Node)
Hi @neilm. If I pass in the array: sumOfDifferences([3,4,5,6,3]) it appears my solution gives a different answer than this solution code does. Which is returning the correct answer here and how, since both passed the testcases? Mine returns 3, his code returns 6 for the above sample
ı solved the kata but ı dont understand the code line ?
it is little bit weird.