Thoroughly enjoyed this! I must be getting more comfortable with graphs, because I didn't have to go looking up any algorithms for this one; I just reasoned my way through it. Thanks for authoring it.

.

It was not actually a problem with the reference solution (since no reference solution is used) but I found and fixed a bug where randomly generated nodes were not guaranteed to be unique, which may have been the problem.

JS function name should be camelCase, backward compatability fix is adviced !

should be fixed, please reset trainer and verify.

In Python version, reference solution sometimes expects false, when path exists

sqj kvn [('zxz', 'kvn'), ('hbx', 'lkd'), ('wrv', 'njw'), ('ugm', 'ugm'), ('hmo', 'wrv'), ('tik', 'zdt'), ('tik', 'lxj'), ('wie', 'yzw'), ('oef', 'utn'), ('hmo', 'sae'), ('zdt', 'lsc'), ('zdt', 'liq'), ('wie', 'xlq'), ('rhk', 'liq'), ('njw', 'trh'), ('njw', 'tit'), ('tik', 'lsc'), ('zxz', 'qkw'), ('ucg', 'zdt'), ('zdt', 'gxq'), ('rhk', 'ywp'), ('lsc', 'vks'), ('tit', 'ucg'), ('utn', 'kvn'), ('lxj', 'sqj'), ('xvl', 'qkw'), ('gxq', 'xbu'), ('ugm', 'xvt'), ('aaj', 'vks'), ('ucg', 'vks'), ('ucg', 'xvt'), ('wno', 'sae'), ('fln', 'fln'), ('liq', 'pbk'), ('ugm', 'lxj'), ('oef', 'yyz'), ('wrv', 'ywp'), ('qkw', 'xbu'), ('wno', 'ucg'), ('lsc', 'gxq'), ('rhk', 'hmo'), ('hbx', 'vks'), ('wno', 'zdt'), ('qkw', 'bzn'), ('wno', 'hex'), ('rhk', 'bzn'), ('lxj', 'bzn'), ('ywp', 'wie'), ('wrv', 'rhk'), ('zxz', 'wrv'), ('bzn', 'hbx'), ('ucg', 'wno'), ('yyz', 'njw'), ('wno', 'ufy'), ('aaj', 'qkw'), ('sqj', 'lxj'), ('ufy', 'wno'), ('trh', 'njw'), ('oef', 'pbk'), ('aaj', 'bzn'), ('zxz', 'rhk'), ('njw', 'aaj'), ('lkd', 'lsc'), ('gxq', 'zdt'), ('fln', 'aaj'), ('lkd', 'rhk'), ('hbx', 'liq'), ('xlq', 'njw'), ('ywp', 'lkd'), ('wrv', 'trh'), ('tit', 'ywp'), ('gxq', 'njw'), ('liq', 'trh'), ('zdt', 'njw'), ('ywp', 'oef'), ('liq', 'fln'), ('tit', 'wrv'), ('hmo', 'hbx'), ('ywp', 'hex'), ('liq', 'yzw')]

True should equal False

Path: sqj > lxj bzn > hbx > lkd > rhk > ywp > oef > utn > kvn

But issues with existing languages should not impact the quality of new translations.

awtsh, you got me there

Haskell (maybe Purescript too?) has random tests but they are very weak, at best. But issues with existing languages should not impact the quality of new translations.

I've made a fork implementing random tests. I think they should be reasonably balanced. Performance requirements could potentially be scaled up further. If the tests work alright then they could be a basis for random tests in other langs.

Does any language have random tests? Your fork is approved.

Python Fork

• Switches to list of tuples for adjacency list
• Adds random tests

While its now an adjacency list, the tests never actually produce a case where multiple edges leading from a node matter (ie. simply directly casting the input to a dict still works).

Now looking at the tests, I see there aren't even random tests? I think this translation should not have been approved.

should be fixed