I can't see your comment, it's hidden

Great and rewarding challenge, so much fun

The Rust translation of this kata depends on having solved the Rust version of the Isomorphism kata, which no longer exists.

Hi I was wondering, are there any missing exercises/functions for the rust type?

This is smart but extremely slow!

A bijection is an isomorphism in the category of sets, meaning that it is just an invertible one-to-one mapping between two sets.Many categories can be thought of as sets with additional structure (e.g. groups, rings, differentiable functions etc.) and an isomorphism requires the structure of the category to be preserved. For example if you are mapping in the category of groups, then you need to map the identity element of the first group to the identity of the second group and you need to preserve the group law so that f(a*b) = f(a).f(b) where * is the group operation of the first group and . is the operation in the second group.

The fact that there is a hint in the instructions to look at the wikipedia page for a bijection rather than the category theory definition of an isomorphism is actually a fairly subtle clue how to solve one of the parts of the kata which can only be solved by possibly breaking the isomorphism structure.

this stuff seems to be broken, not sure if it's currently solvable. TraceshowID doesn't show any evaluation.

You can encode maybe as well

That's the neat part : nowhere. (Well kinda, but no spoil).

Well, I have a working thing but I'm not sure it's what was expected. I'll look at the other solutions when I'm done with this kata.

Ps : does your version of join really go through all elements ? If that's not the case then the tests may take elements forever.

Currently, I am battling a bit with Haskell so my join function doesn't do much; but when it "worked", it indeed went through all elements, except that you would see 2^n elements of the first stream before seeing the first of the n-th stream, which is probably why it broke down (NB. when I click on Attempt, it successfully passes the first batch of tests for LazyThunk, but not for LazyOption, because it times out — so the implementation is correct, it's just too long)... Whatever, I guess I'll just change the order, even if that's a bit longer to code.

About Haskell, I'm a noob too. I was hinting at the documentation eg. zipWith.

I don't even know where to put the initialization !

That's the neat part : nowhere. (Well kinda, but no spoil).

Finally about join : the order doesn't matter because it is not tested, but the tests still need to access some elements so they have to be at a reasonable position (something exponential would not be reasonable).

Ps : does your version of join really go through all elements ? If that's not the case then the tests may take elements forever.

This kata is quite under specified, yeah. In case you (or anyone) want to know what a function is supposed to do, it’s likely to be equivalent to the homonymous Haskell function.

Unfortunately, I know almost nothing about Haskell (if I'm currently 4 kyu in Haskell it's merely because I found Kata were you don't need to know how to code in Haskell to finish them).

For fib_aux, let’s say it’s a bit like building a list recursively, but adding stuff to the tail side lazily in the future

My problem about that is how do I reuse already built information. I mean, I don't even know where to put the initializatoin!

tail and join, can (and should) be really lazy. After all it’s a ’a L.t (or a Stream of it), so no evaluation is needed right now.

Modifying signatures in general will most likely stop anything from even compiling. (but refactoring modules is possible, as written in the solution setup).

After some thoughs, I realized what I was supposed to do for these.

The order of the element doesn’t matter in join, you just need to have every element of the « 2D stream » in the output « 1D stream ».

Except it does :') I tested my solution and it [stack overlowed / exceeded the allowed runtime] because the order I chose made it so that you have to wait very long before you actually reach the first element of the n-th stream. But I guess that's easy to fix (just a bit sad that my unpractical solution is rejected). I realized after posting that it was not because a given order was enforced, but rather because mine was really bad.

Thanks for the tips! I think the only thing I am still struggling with is the fibonacci one...

• The order of the element doesn’t matter in join, you just need to have every element of the «  2D stream » in the output « 1D stream ». Trying to exhaust the first stream, then the second, etc … will not work because they are, well, infinite.

• Modifying signatures in general will most likely stop anything from even compiling. (but refactoring modules is possible, as written in the solution setup).