• Definitions of call depth are inconsistent between infinitely recursing and terminating branches. And that's fine!

    For terminating branches, the depth is defined to be 0. That's a definition, and that's fine.

    For branches that will ultimately recurse infinitely, depth is defined as the number of calls from an initial one, up to but not including a call of a pattern that has been called before. This is not really explained well, but it's a workable definition.

    What would deserve explanation is that, for recursive branches only, you have to count the initial non-cycling part. This is not consistent with terminating branches, and there is no description, no example or example test that I could find that clarifies this. Which means it's a surprise in the Submit tests, and I don't like that kind of surprises.

    Relatedly: it only comes up as a random test. There should be a fixed test for it.

  • OK, I was finding the min / max cycle length in previous submit ...

  • errr... It's about finding cycles for sure! x) But you have to count their "perimeter" the right way (and there is that little twist... see below)

    Though, rather than to analyse only the first encountered infinite loop and get stuck in it like the robot would be, your code will have continue deeper in the calls to find the depth of any infinite recursion or terminating call. Then it should return the minimal and the maximal depths encountered, as an array [min, max].

  • Ok, so it's not about finding cycles, it's about depth, though similar.

  • That's the example of the description... => study it more! ;p

    You're not counting the depths appropriately, that's why you end up counting this "non loop" to reach 3 (and it effectively isn't the correct loop).

    not an issue (of the kata) closing. Poke at me if needed.
    cheers

  • For Java solution, when submit, for code p1P2P3qp2P1qp3P1qP3, it failed with error tip: expected:<[2, 3]> but was:<[2, 2]>

    Seems the test consider 3 -> 1 -> 2 -> 1 -> 3 to be a cycle.

    But, according to wikipedia https://en.wikipedia.org/wiki/Cycle_(graph_theory) ,the only repeated vertices are the first and last vertices, so here both 3 and 1 appeared twice.

    So ... is this a possible issue ?

  • Possible minor typo in description,considere means consider ?

  • corrected, I believe. Thx.

  • Random tests for Java sometimes produce programs with multiple definitions for the same pattern like

    p2P1qp1P2qp2P2qP2

    I think that such sequences are invalid Roboscript programs.

  • Hi, that is truly good point. Thank you for this kind discussion. To be absolutely sure that we change it in a right way we have to add some kind of reference to a well-known book/resources, or, may be better, an opinion poll voting results from the Forum taking into attention Kaiser-Meyer-Olkin Measure of Sampling Adequacy and votes weights.

    Imho, it is not such an important case.

    If you think another way, one can propose to add a little note at a line of the task.

  • Yes, if we would introduce "cycle length" then a lot more modifications would be needed. And although "cycle length" helped me to finally understand the task, I'm not sure it will be that helpful to others.

    It could also introduce another misunderstanding. Concider this "infinite cycle":

    P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> (P3)

    Would the "cycle length" here be 6 or 4? You could argue for 4 because the "cycle" jumps back from P6 to P3 and therefore the "cycle length" must be 4. So, better not go there...

  • sticking to "depth" rather than to "cycle length"?
    "branch" is a good idea, yes.

  • I really find it hard to judge that. The reason I was confused was because I didn't understand the description well enough. I read it twice and then only concentracted on what it said about the task. That was my mistake. But looking at the comments here, I can see that more people struggled with this. Let me therefore try to propose a better task description. It now is:

    "Though, rather than to analyse only the first encountered infinite loop and get stuck in it like the robot would be, your code will have continue deeper in the calls to find the depth of any infinite recursion or terminating call. Then it should return the minimal and the maximal depths encountered, as an array [min, max]."

    My proposal would be:

    "Though, rather than to analyse only the first encountered infinite loop and get stuck in it like the robot would be, your code will have continue deeper in the calls to find the depth of any infinite recursion or terminating branch. Then it should return the minimal and the maximal depths encountered, as an array [min, max]. Note that the depth of a terminating branch is, by definition, zero."

    So I call it a "terminating branch" instead of a "terminating call", which is more in line with the text above the task description, and I added the note.

    Will this help? I don't know. Getting these concepts across is just difficult.

  • Loading more items...