4 kyu
BasE91 encoding & decoding
188 of 498user7657844
Loading description...
Algorithms
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
This comment has been hidden.
Python new test framework
Bad kata. We have none of instructions in description. Like already said in comments, if you are good searcher on web you will find what you need to do..
Some info on encoding algorithm
Shame to see the feedback in the other comments unaddressed. Not a good kata, not much more to add.
Holy cow. This looks like a terrible kata. No description. No information about the algorithm available. Only possible sources are code. And as it seems since many years... Should be retired.
I agree wholeheartedly. Nevertheless, the satisfaction rating is 54/116. It must be a puzzle and not an algo kata.
Really? We are supposed to implement an encoding but are not told how that encoding works?
I don't get how to decode or encode this! The instructions are not clear!
Are the expected and actual backwards?
(adding that they are talking about java) and to answer the question, yes. inital code (returning empty string) results in test output:
Bonus issue: s/charakters/characters
This comment has been hidden.
The Go translation seems wrong: the apostrophe (') is used instead of the quote character (").
I think you are right. The Go trainslation is wrong.
Got the same mistake Expected : "...*B[AS"1AbUo..." to equal | : "...*B[AS'1AbUo..."
Test for this kata wrong.
the apostrophe (') not in the basE91 alphabet
Spent a few hours trying to figure out what I am doing wrong. Simple tests work but random tests I fail about 20. Heres an example:
It seems to be the same bug... I am not making my solution using bit shifts as I want to understand it first... Any suggestions would be great!
Can someone kindly add JS translation ?
Hrmph. Solving in go.
My solution is passing the sample tests, but when I Attempt, it's erroring with this:
since my code never calls Sprintf or uses an int64, I'm fairly sure the problem isn't in my code - but 7 people have completed the kata in go, so I'm not entirely sure what to think.
:edit: updating after digging about, this error is coming from vet, which is apparently being called on the solution before running it, and which detects this sort of issue, among other things, that the compiler doesn't normally look for.
So, either in the update today or at some other point in the last 6 months, solutions started to be vetted.
Resolved
ah, you're one step ahead of me, just came to resolve or delete or at least edit the issue with an explanation and found you've beaten me to it xD
The instructions are somewhat confusing.
I had trouble finding reference material, and only by reading pre-existing source code did I figure out that I was reading the characters in the wrong direction, and you need to pull the 13/14 bits from the least significant bits, not quite how I understand Base64 works.
For example: 'H','e' in binary is 01001000 01100101... The first 13 bits would be 0100100001100 which encodes to "pZ". The algorithm to produce a result that starts with ">O" needs the byte order to be reversed to 01100101 01001000 and taking the 13 rightmost bits: 0010101001000 or 78d 14d.
Biggest issue is that the random tests are not random, just testing against a sequence of "%s".
Sad to see that most of the solutions are copies of Joachim Henke's C# source code from Codeplex. Some just changed the variable names he used (b, n, v) to more meaningful ones (queue, bits, val); some just changed from string to stringbuilder; some just added a completely superfluous "and 255" operation to an array of bytes...
This is more an exercise of research skills than coding skills.
Instructions?? Which instructions?
Hello everyone!
I found some strange issue while testing BasE91 encoding/decoding on the site https://www.dcode.fr/base-91-encoding.
Suppose you have aligned 13-byte input string (such length is chosen because no zero bit will be added while breaking to 13-bit blocks)
encode('1234567890123') == 'QztEml0o[2;(8YAS'
My intuition says that if you replace only one character in the input, the encoded BasE91 result will also differ only in few symbols. The results on the site supports my hypothesis:
encode('A234567890123') == 'gztEml0o[2;(8YAS'
encode('1234567_90123') == 'QztEml0o)9;(8YAS'
encode('12345678901*3') == 'QztEml0o[2;(8Y"R'
The same thing occurs if you use grave accent (backtick) symbol:
encode('1234567`90123') == 'QztEml0o[2;(8Y"R'
But if you place backtick into the second position in the input string, you'll get a wierd result:
encode('1`34567890123') == 'z"Yv$Sb%ob^heMAJ'
It also appears for longer inputs, e.g.:
encode('Baby, did you forget to take your meds?') == 'xDOfZfTXwSztI_apVR/2).&Y$F)&nuYiWPgZk>;N%y60PmcW'
Backtick is in the first place:
encode('`aby, did you forget to take your meds?') == '?DOfZfTXwSztI_apVR/2).&Y$F)&nuYiWPgZk>;N%y60PmcW'
Backtick is in the third place:encode('Ba`y, did you forget to take your meds?') == 'xD~eZfTXwSztI_apVR/2).&Y$F)&nuYiWPgZk>;N%y60PmcW'
But the second:
encode('B`by, did you forget to take your meds?') == ')"0P6P3LYJ,WF|6U51kbiki5=Cj>TXN!509MSn_zgZe,HTOL'
It seems that BasE91 implementation on that site doesn't work properly :/
My solution passed all the tests but failed with a backtick in the only the second position. I've fixed it locally, and updated my solution, but only the first solution is showing up for me.
It is the exception where you can encode 14 bits instead of 13 (For values 8192 - 8280). This throws off the bits of the following characters and will give you the results you found. If you put an '@' or '`' in the second position it will happen.
@samscudder Eh? When encoding, you always just turn each 13 bits of input into two characters - you don't care what symbols they came from, you will always just take the next 13 bits. Now, when decoding, there are illegal patterns that would decode to 14 bits - specifically,
D"
through""
would become 8192 through 8280, which would require 14 bits to represent in binary. Those will never be produced by a valid encoder, though.Still confused though - the linked encoder decodes it's own results consistently, so idfk what's going on there. Tried it in my own solution and I get:
That's input -> encoded -> decoded, and as yanykin originally expected, changing one character only affects the 2-3 characters of the encoded value.
so, yeah. Not a clue what's going on with the linked site's encoding/decoding that's making it skew the entire output in those cases.
This is what happens when people implement something from a vague description instead of a detailed spec :P
I'm having this same issue (I think) as I pass all tests and random tests except when there is a backtick. I don't quite understand the problem? Could someone ellaborate?
I found this description of the encoding/decoding algo, hope it helps: https://www.dcode.fr/base-91-encoding
It is really a bad idea to publish a kata like this without any hints of how the encoding works. As some people mentioned below, it is actually easier to find a working code than the specification when you force users research the algorithm themselves.
Can anybody of the editors update the description with some specification for this encoding?
This comment has been hidden.
Go translation
hrm. Thought I'd poke you since you translate this to go, and presumably wrote the go tests. Go was updated to 1.10 about 12 hours ago, and I'm now getting a very strange error when I Attempt with my solution (sample tests run fine)
I can't see how my solution could be causing this - though I can't be certain, but I'm not returning int64 values, so it seems improbable. Any way you can check if the test was somehow broken by the update? I'd appreciate it!
I've changed it before deploying the update and it's working. This is probably some cache issue.
This comment has been hidden.
Hmm. Needs 4 things - instructions, and C, C++, and JavaScript versions.
Link down, no instruction to do this kata.
Link is working now.
This is still a copy-paste kata, without instruction.
Yeah, at the linked page, it mentions 0-bytes, but it doesn't say what they are. We really need more concrete instructions.
I agree it lacks instructions.
If you look at base64 kata it has a link to the wiki where it fully explains the algorithm.
Actually there does not seem any description of base91 on the internet. I don't even know where to get started, apart from reading the source code of some implementations.
I believe there's nothing else, actually...
I agree.
Java translation, in the exemple test cases, the
assertEquals
are in the wrong order, it should beassertEquals(<expected>,<actual>)
.Created a fork that fixes according to your suggestion.
Waiting for the author to approve.
The linked documentation was far from sufficient. I ended up having to read the source code to figure out how the encoding actually works. Once I had read the source code, the Kata was not nearly as interesting.
I think this would be a really good Kata if the instructions included a full specification of basE91 encoding.
Please review and approve my translations :D
@Voile
I love you :DScala translation
Groovy translation
Kotlin translation
Java translation
This comment has been hidden.
This comment has been hidden.
Description is far from sufficient... Unless the process is perfectly equivalent to base64 encoding? (if so, a link toward the other kata would be the minimum to add, I believe!)
Added a link.
thx!
Link down. Now you can't solve this kata.
The (current) link doesn't describe the encoding process. It only has a map of symbols <--> bytes and some statistics on data size.
It's not perfectly equivalent to base64, I tried to use the same code with the different map and it produces different results from what is expected.
Approved
(People ranked it purple for some reasons. Don't ask me why
¯\_(ツ)_/¯
)This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
Thank you! :)