Okay folks, this should be simple, but maybe not.
The goal is to write a function that takes a positive integer and returns a list of its prime factors. So if you did 12 you should get the list [2, 2, 3]
As neither 1 nor zero are prime, as a result should return an empty list.
This is taken from a #tdd #Kata, so if you have not done this one I encourage you to do so. If you are not into #TDD then solve it however you like.
🇳🇱
Thats solvable (goes into NP stuff but I wont invoke this here)...
Think of it like this creating prime numbers is a much easier task than checking if a number is prime. Its the whole reason cryptography works, we can generate large primes for our keys but getting those primes out after the fact is computationally difficult.
So a TDD would be a simple matter of generating a set of primes (easy) then multiply them together to get the value under test. Then send that value off to be tested and verify if the results agree with the original list of primes you generated.
Reversing the process makes all the difference in the world when testing stuff like this.
Checking for primality is not that hard either, the factorization is hard and is the reason cryptography works (certain schemes).
That said, even if it's an easier task computationally, it's not necessarily easier to implement, especially efficiently, especially for large numbers.
Sure, skip the primality test, if your genrerator does not rely on it, but who's going to test the generator?
Maybe a trivial primality test that does not need a test itself? (oh no already violating TDD) Use it to test the generator, which you can then use to test a more sophisticated primality test that you can then use to test the generator for even bigger numbers? This is a very trollish kata for TDD, and an example of a problem where you're better off relying on theory to prove correctness, an maybe only testing some components not the problem/solution as a whole.
When I say TDD, I mean it is the way of design and development. (maybe even a way of life :D )
This means following the 3 laws:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Using a Red-Green-Refactor work flow. Write just enough of a unit test for the simplest unit test. Then see that test fail(Red). Then write the SIMPLEST solution in the code to make it pass. (Green) Then refactor to remove complexity and simplify. Lather, rinse, repeat.
@freemo @namark @Lossberg The factorization problem/kata is one that I particularly enjoy, because when I am done, and I look at the 6 lines of python that it generates... I always shake my head and say "I would not have written that no matter how long I sat there, or how many times I tried." Humor me, and let's see if you see similar things....
@freemo @namark @Lossberg I realize you enjoy different types of problems, and different types of solutions. So maybe even the suggestion of this is something you may find no interest in. I can accept that. I would encourage everyone, even you to give it a try (at that absolutely ridiculous level of pragmatically following the 3 laws and using the R-G-R workflow) Maybe you will get something out of it, maybe you won't.
And by pragmatically, I mean your first test would look like:
def test_factor_zero_return_empty():
assert factor(0) == []
----
and the first code that makes it pass is:
def factor(num):
return []
-------
That is the level or pragmatism I am speaking of.
Well, from our brief discussion with @freemo we arrived at needing a prime number generator to write the test for factorization, which itself would require at least a trivial primality test, which will have to be written without a unit test. How was your approach different? Did you generate a certain amount of prime numbers by hand and deemed that acceptable?
@freemo @Lossberg
Even if that's the case, the question was what is the proper TDD approach? Generating prime numbers for the test by hand? Or factorizing a couple of numbers by hand?
Thinking about it, wouldn't that make copying the hand calculated results into the implementation the best way to comply with rule 3? That's what I would arrive at with that approach, and nothing necessarily wrong with that. In one of my recent toy projects, I needed a factorization, and I just included a short list of primes, that I used as "only/all primes", knowing that the number to factorize would be small enough (and even if it wasn't that wouldn't affect the final result much). Totally sufficient for some use cases, but I see no way to move on from that point to anything more complete or sophisticated with the strict TDD approach, for the prime number problems specifically, which I think is an odd choice for a TDD kata.
Here is a link to REPL.it Where it has been done via TDD
Short of walking you through it, here is one instance where it was walked through. You can see the the unit tests that were used, unfortunately, there is not a really good way to see each of the coding steps and refactorings. I think I will have to do a Git solution that does a commit on each phase-step.
There are a couple commented solutions that are further ideas I wanted to keep.
Here is a link to REPL.it Where it has been done via TDD
I wonder how did you come up with the 5993 test? I find it hard to verify, though I'm a particularly lazy person. Is there some sort of a trick?
Here is what I would have came up with given that sequence of test and the rules of TDD presented (not at all what I would come up with just trying to tackle the problem)
http://ix.io/2bgk/py
with the list of primes there growing with each new unit test . I think it's much simpler and also runs much faster. By any objective metric, with those TDD rules in mind, this is a superior solution, and I believe you would not be able to beat it without introducing a prime number generator or a primality test, or both, with one or the other not being tested.
@Absinthe Easy to solve yes, but rather difficult to solve efficiently!