UPDATED GROOVY TRANSLATION

Changes:

• Changed testing framework from org.junit.Test to org.junit.jupiter.api.*
• Test Cases are now based off of the Python translation instead of the Go translation
• Now testing for when a 3rd parameter is not given
• Using @Order Annotations for Test Cases
• Other small changes

very bad description

Groovy Translation

Examples describe better than words before them.

Bad description

Sorry, I couldn't think of better names at the time. 😅

Why is everyone on Codewars allergic to naming variables? What's f? What's ff? What does x mean? It's so annoying!

Lol, I tried my best to have the shortest answer possible and I almost went with this solution...

These are completely different algorithms that just both happened to involve elevators.

Oh. Okay. I was testing it in irb but I guess I did a poor job then :')

Looking at ~/.irb_history, I did use two dots... even though I was specifically wondering about the difference between the two. Sigh.

Aight. Send it.

Thank you!

one tiny bug: rand(0...10) that's inclusive, so that's 11 outcomes where in python it's 10. I don't actually care and will approve that, would be nice if it's the same though. same with 0...5 of course

It's not inclusive.

I added the other cases.

There are also some extra edge case tests in JS which are probably worth adding:

it("more fixed tests ( d < 800 )", function() {
    assert.strictEqual( alphabet([4,51,2,51,2,1,8,204]), 51 );
    assert.strictEqual( alphabet([7,9,747,7,1,63,83,83]), 83 );
    assert.strictEqual( alphabet([520,3,39,3,13,40,40,1]), 40 );
    assert.strictEqual( alphabet([1,350,15,8050,345,350,15,23]), 350 );
    assert.strictEqual( alphabet([737,639,9,71,4422,6,54,52327]), 737 );
  });

Oh sweet. Still reading.

set operations on array? weird language. had to go try it to see if it actually did the right thing x)

one tiny bug: rand(0...10) that's inclusive, so that's 11 outcomes where in python it's 10. I don't actually care and will approve that, would be nice if it's the same though.
same with 0...5 of course

You're right, and thanks for the feedback. I made them distinct and followed the logic of Python snippet you provided. Check it out!

Hi! I will not dig into discourse to figure out why you're making this, but, the current ruby implementation is obviously wrong so it's presumably about that if I was to look.

So, I'm glad to see this already here.

However. Still wrong. This implementation doesn't guarantee that A B C D are distinct since you pick four random values for them.

One way to go about it is to put all candidates in an array and swap the chosen element with the end and then pop off the end. Another way to do it is to re-try the roll if it rolls an already chosen value - this is typically better when the pool is large and the desired amount of values is small, such as here.

Could you make that update? I'm quite keen to press the approve button after that even if I don't know ruby and will do a poor job of looking it over -- since the current one is entirely broken.

The python version has some additional code related to edge cases that uhm I have no clue if that's good or bad really, but seeing as python is the original language and has the most solve, I would copy exactly what it says there.

this is how it reads there:

        a, b, c, d = sorted(sample(range(1, 100), 4))
        
        # Tweak the inputs to generate interesting edge cases more often
        if not randrange(10):
            a = 1
        if not randrange(5):
            d = randrange(200,800)

        numbers = [a, b, c, d, a*b, b*c, c*d, d*a]
        shuffle(numbers)