Follow

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 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.

@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.

🎓 Dr. Freemo 🇳🇱@freemo@qoto.org@Absinthe Easy to solve yes, but rather difficult to solve efficiently!