Let's crack Sloot algorithm - infinite "compression"

[nix85]

u dont gain anything from going from 100 number table to 10,000 number table. everything just gets proportionally bigger, that is why i kept it at 100.

[nix85]

Yes, it must be 05, 55 and not 5, 55.

And we spend more memory, but delimiter is not needed.

Delimiter will be very hard to implement, if we dont know exact length of sequence.

how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer

[WhatIsIt]

I must say, you really got me into this problem!

But, it is good to talk and exercise our brains,

even if we dont find anything.

[WhatIsIt]

how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer

My thought was,



once we convert sequence into pairs of coordinates,

we read coordinates as number again and second iteration goes.

We write number of iterations into one long integer.



Can you try to explain how would you do it, just to see where I could be wrong?


Lets presume that we can write more numbers with coordinates than the number sequence really is.

[nix85]

this is my second time i am at it, like 10 months ago i was totally into it for few weeks, i started with idea of reducing big numbers to simpler formulas

for example 205891132095673 is equal to 2^10+3^30.

but this is a blind alley, no further reduction is possible. then i realized it can only be done with dynamic component on both sides parametrized the same way.

but this is nothing new, this april fool's joke video is about that https://www.youtube.com/watch?v=KOvoD1upTxM

not worthy going nuts over it, remember sloot was seeking for 20 years before he got it.