The 'fromAscii85' tests are pretty broken in that they don't check size. So if you return a zero-byte result, it will 'pass.'

One of the test on test_encoding_with_multiple_zero_bytes_inside_a_binary

[61, -8, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -98, -109, 119, -85, -92, 23, -111, -112, 31, -108, -125, -55, -44, -73, 95, 79, -120, 76, -53, 39, 12, -16, 102, -61, 120, -110, 2, -59, 55, -74, -120]

The seconds 4 bytes blocks are all Zeros(null), whyit expects this expected:<<~4nocm[zzz]!!!"jPBX('(Qje$P_7*-...>, only 3 zzz instead of 5 zzzzz for that block?

To say there's a C++ version of this Kata is stretching things somewhat. The challenge's "interface" is identical to the C version. Instead of this:

struct block { const char *data; int n; };
char *toAscii85 (block b);
block fromAscii85 (const char *string);

what about this?

std::string toAscii85(std::vector<char>&);
std::vector<char>& fromAscii85 (const std::string&);

and you could get rid of the block struct and those macros, which while tolerated in C, are considered bad practice in C++ (even more so lower case ones). It also doesn't force the caller to manage the memory of the returned pointers (the sample tests as they stand leak memory).

Hey there!

I guess that your not escaping correctly the test cases for c++. Could you check if you are escaping correctly special caracters in the refence string, such as backslash '\'.

Under a certain test case, whithin the test "Now is the time for all good men to come to the aid of their country". The test shows a mismatch.

I've tried two different implementations (With C old plain strings and C++ std::string) both return the same output. Even thought only the std::string approach works correctly on this test case. I've compared the encoded values on several tools to compare and my output look like correct.

This is the output with the problem.

b.data: (Now is the time for all good men to come to the aid of their country) b.n: (68)
total_tuples: 17
4e 6f 77 20 ENCODING! !>b2: 21 3e 62 32 3a - 'Now '
69 73 20 74 ENCODING! =DblB 3d 44 62 6c 42 - 'is t'
68 65 20 74 ENCODING! .<rOB 2e 3c 72 4f 42 - 'he t'
69 6d 65 20 ENCODING! (E.lB 28 45 2e 6c 42 - 'ime '
66 6f 72 20 ENCODING! 4]DoA 34 5d 44 6f 41 - 'for '
61 6c 6c 20 ENCODING! &aK;@ 26 61 4b 3b 40 - 'all '
67 6f 6f 64 ENCODING! !^_5B 21 5e 5f 35 42 - 'good'
20 6d 65 6e ENCODING! -\kD+ 2d 5c 6b 44 2b - ' men'
20 74 6f 20 ENCODING! ENVE+ 45 4e 56 45 2b - ' to '
63 6f 6d 65 ENCODING! q3Hr@ 71 33 48 72 40 - 'come'
20 74 6f 20 ENCODING! ENVE+ 45 4e 56 45 2b - ' to '
74 68 65 20 ENCODING! .5,DF 2e 35 2c 44 46 - 'the '
61 69 64 20 ENCODING! p60;@ 70 36 30 3b 40 - 'aid '
6f 66 20 74 ENCODING! 6,:eD 36 2c 3a 65 44 - 'of t'
68 65 69 72 ENCODING! umtOB 75 6d 74 4f 42 - 'heir'
20 63 6f 75 ENCODING! 4>fC+ 34 3e 66 43 2b - ' cou'
6e 74 72 79 ENCODING! EoKKD 45 6f 4b 4b 44 - 'ntry'

<:2b>!BlbD=BOr<.Bl.E(AoD]4@;Ka&B5_^!+Dk-+EVNE@rH3q+EVNEFD,5.@;06pDe:,6BOtmu+Cf>4DKKoE>

3c 7e 3a 32 62 3e 21 42 6c 62 44 3d 42 4f 72 3c 2e 42 6c 2e 45 28 41 6f 44 5d 34 40 3b 4b 61 26 42 35 5f 5e 21 2b 44 6b 5c 2d 2b 45 56 4e 45 40 72 48 33 71 2b 45 56 4e 45 46 44 2c 35 2e 40 3b 30 36 70 44 65 3a 2c 36 42 4f 74 6d 75 2b 43 66 3e 34 44 4b 4b 6f 45 7e 3e

Could you take a look at this please?

Testing_ASCII85_encoding_with_random_binary_input
Random encode binary input

What does it mean? :-D

Testing_encoding_with_multiple_zero_bytes_inside_a_binary
Random zero strings binary input

Didn't get it too :-D All tests passed except these two. But nice kata.

generateRandomBinaryData and generateRandomReadableStrings doesn't exist in Typescript (not available in global nor as an import)

Your random tests use the user's encode function to make the encoded versions of the random strings. This has a number of issues:

• All of your encoding test cases compare the user's encode function output to itself, making them always succeed (and completely useless), and giving users the illusion that their encoder code works, even if it doesn't.
• All of your decoding test cases use the output of the user's encoder as their input. If the encoder doesn't work properly (even though the encoder test cases succeed due to the previous issue), the decoder will be given bad strings as its input and will make people think your test cases are broken (which you can see examples of in the comments).
• Your random tests, which are supposed to stop hardcoding, can now be easily bypassed. My latest solution highlights this.

An easy solution to this is to include your own encoder in the test cases and use that to generate the answer key instead of the user's encoder.

What's the output for <!!>? I'm getting

✘  Expected: , instead got: 

Hi all. I would like to know the output for the input: '<!!>' ?

I run my code and the system throws:

Expected: , instead got: ,

why?

Explain, please result of this test (Python):

(Is it an error in the test?)

Testing ASCII85 decoding with random binary input:
INPUT: <O>U2<^Q,>

'\x905Y\xfb\xbf\x8f' should equal '\x905Y\xfb\xbf\x8e\xb9\xec\x80\x14\xbc\xac\x166\xb0o\x8b\x01{\xf9\x13% yl\x06\xf6\xf1\xc0\x91\x12)"%I\xe5s\xcb\x19\xb6}\x9d\x8fe/$\r\x7f\x00\xad\xd3\xb2\xe5\xeb;\x93l<3\xd9\xb8l\x05\x80K\x03\xa6\xfdN\xc7\x97r\xdaB\x909\xe7\xbc72\xb2\xb8\x17\xe7\xef2\x90lR\x152\xc8*\xec\x11\xd0\n\xf6\x14\x19\x89\xbf\xf5\xbc\xf2\x88\xd6\xac\x08\x9b\x1f\xea\x19u\xcb.;\xdb\x9e\xae\xd2\xdd\x91.\x96\xaa\x19\xa8k$I\xcb\xc9\x93y\x8e\x92\x99k\x94* \x81\r\x80\x80\x84\xa9Q\xdeXo\x18{fh\xd7\xaeV\xa3ce\xe4\ty\xd0\xe3\xb1Q\xe2\xa9\xc2\x8b\xed\x9f\x12\x0f\x9aS\x027|\x96\xea|\x05!J\x85\xb1!z\xf3\xb4\x05t\xdd\x0f\xd6\xcc\xfc\xd57\x7f U\xef\xb4l\t\xb7\x05\xb9\x89\xd1\xbf\xb8v\x1b\xc7F\xe1@\x9fM\x1d?\xb3Q\x94\x9eL-\xe6\xf6\xc4\xe8\xc4\x8e\xc3,\x05\x96wxa\x03\xbf\xfa\x0b\xd0]\xdb3\xa5YR\x14\x9d\x7f0\xe1%w\t\xba +l\xfd\xf9\xa1K\xd4\xb4\xa2hR\x8a\x14\xfc\x1e\xd6H\xf3\x91\xfb\xb0\xe8\xb6X\xd1\xbe&\xd1\x9c\x9cR\xd8\x80\x17a\x1b\xd3\xb0-C\x895\xbc\xac\xe7\xe3"\xdf\xff\x1a\x10j\xc0Z\xa1\xc7[\xcb\x04\xde\xdd\xf6\xf8\x90\x9f\x9b6\t\x0f\xba\x10\xdcIuq\x98\x1b<\xb7[\x80\xec\xbfr9\x8d\x9c\xa1\xe6\x8d\xab\xc0\xb0\r\xe9\xe0\xe1\xf5\xf1;\x15O<\xc1\x8f\x17\xc2i\x87\x0e\x98\x12\xdc\xb6\xaf\x13\x9eI[!\t\x12\xcc\xd1\xc0\x14\x95r\xb6\xa2\x97\xfa\x13\xd6\xf9\xd6\xe98\xc0\x12\x88W\xb9\xa4b?\x8cc\xd1\x81\x1c\xea\xb4\xb4\x9b/\xe4o7\xa8\x13\xdd\x98@\x86\xf6\xa5\xb4\xbeQ df\xc3\xc9\x15Af\x17\xf4vY}\xb4c\x8e\xe2\x08c\xe3K\xfe[\xae\xe9\x13\xcd#\t\xfdtv\x8b\xef\xcfF_-9 \x97Yg\xcb\xd2\xcb\xf6\xc1,{8\x1a\xc4y\xcf\x95\x86X\x02\xf7\x07\xbc\x94,v\xce\x82\x0e'\r-f,j3\xe4\x86\xd6e\xda8Mg%SK6\xb0V\xdeA\xd8\x1a%l\x11\xa6\xfa\zz\xc9\x1c\xcaZ\xac)3\x88L8{yg\xfa\xf9\xcc\xd4TM\x1f\xe2\xd6\xa9v\xef\xf7MfA\xd8\x82\x0f\x05'\x9b\xed\x1c\xc8\xab\xd4\xd6\xc7+Ves\xa4Y\xd7\xed!\xa0\xf3\xc14\xaa%\x84RK6\xf4\xbd\xa2s\xc9!\xc8o_\xd3\xe2\n6\x11bH1I\x89\x19\x924Z\xa9:\xe6\xb7\xcd\xa2\xd4\xf3k\xfd\xf1\x05\xb3j\t\xfb\xe4x\xad\x14u\xe5U\x9b\x84=\xbe\x1a\xaa\x9d\x9e$\x95\x80\x10\xd91U\xd5\xf6\x98\xd1\xc9\xc2\x9a\x7f\xb9\xab@t\xc4\xf9\xfd\xfcv+\xd3\xf9\xa6+[d2\rX\xa3Q\xba;Z\x97\xc9q\xcamM\x11\xf2\xfc\xec\x13\xafT\xc2^\x01\xa5G\xd1~\x9a["Ef\xd7\xdd\xa0\xd6\xbaf"p\xb5\xe1\xf2\xa3RSX\xc0B<\xfd\xe8\x89\x18DX\xb3\xd3\xd3i\xcb\xccL\xeaK\xe2h\xa8\xabT?\xf7#\x96\x1e\x9a\xb0\x02u0\xf6yT\xc6\x83\xb1rm\x03=\xcb{@xl\x8e\x0b1\xc8\x17\x00|"t\xd5`6\x0c\xde\xc2\x88\x80i\xd5J\xa8\xa7\xa5\xce\xa1:S\xfe\x9d\x86\xe2V!\x981\x90tmEtG|%\x1e\x08&,m\xe2O\xe6\xdb(n(9\x13F\x9d\x9d\xd3\x98 B\n\xe5P\xd9P\xae\xad\xc1Pq\xdcC\xab\xee[\xe1\x01\x0e%\xd5t\xa0\xde\xa2\x89M\x9f\x8bUE\xb2\x014\x9a\xff\xb0[\x86\x15\xf4\xc7\tp~&\xfc\x89@\x9ag\xe6\xd6\xae\xe6\xc0|\xe6\xf4'\xb3\xc8\xd4\xf0\xea#\xedd~\xd7\x01\xca1\x17\xc8\xc7\xf1Z\xa7*\x0b\xf2\xef\xa6\x16+;\x82KW\x02\xedx\x16{\xf2\xeaH g}\xfa\xceG\x80Z\xc5\xc9\xef\xc2Z\x08\xf6\r-P\xd1\xa3\xad\xc0?\xde2\x1f\xdd\xa9\xdf\xacl\x12\xff\x87Z\xa9\xa9\xda\xa6\t\xe91\x10\x92\xdbGm\x0b\xbf\x8f'

Reading the discussion and having worked through most of the kata (stuck on decoding binary), I would say there are two clear changes that should be made to the test cases:

1. the tests for 'encoding' binary data are vacuous and should be removed. They are only testing that the warriors toAscii85 function produces the same result as itself. So they are no test of the toAscii85 function at all and thus should be removed. I'd recommend just keeping the 'decoding' binary tests and rename them 'test of binary encoding and decoding'

2. tests should ideally not involve randomness that changes each time the test is run. Ideally if randomness is required they should be seeded, so they are at least consistent from one test run to the next. Not so straightforward in JavaScript, but see http://stackoverflow.com/questions/521295/javascript-random-seeds

otherwise great kata - I have no bitwise operations at all in my current version, so thinking I have a different issue to others. Now I think about it sounds like bitwise might be more efficient. I'm probably failing the binary section because of odd interactions between binary and regex and/or string operators

Is the java version of this relevant?? I was thinking about contributing...There are very few questions for java on codewars

You should escape test output.

http://imgur.com/8tz1I7t