5 kyu
Hex Dump
199 of 262anter69
Loading description...
Algorithms
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.
What's with the white spaces?
nvm, last line trickery
Nice one, well done.
Sample tests are not using
itblocks in Python.See here for some additional information: https://docs.codewars.com/languages/python/authoring#testing-framework
fixed
I'm trying the C++ version. The test is fine, but on my attempt, I get
Note that this is in tests.cpp, not main.cpp.
You should use
using namespace std;. Why should it be a kata issue?This has already been fixed.
I can do a
in my code to fix it, but that's bad practice.
I misunderstood, the problem was from the tests, sorry.
The bytes should be represented with
std::vector<unsigned char>instead ofstd::vector<char>in C++.I intentionally used
char. The Java version uses a byte[] in which the byte is a signed value. I wanted to mimic that here also which is why I usedcharinstead ofunsigned char.Just as FArekkusu, I also do not think it's the best design decision.
First of all, what does keeping consistency with Java in this regard help here? C++ and Java are two totally different languages with different set of rules, and programmers have to struggle with different types of difficulties. I think it's pointless to forcefully reflect problems from one language in another language where they can be avoided.
Second,
charis not equivlent to Java'sbyte.byteis guaranteed to be signed, and signedness ofcharis platform-dependent. Exact equivalent of Java'sbytein C++ would besigned char, or, even better,int8_t.charis not.I am not sure what exactly you wanted to achieve by mimicing properties of Java in C++, but I think it's both unnecessary, and not realized correctly.
Input should be passed as
const &in C++.I see this is just a suggestion, so I'm wondering if it is required for input being passed as const &, or is it just good practice? My understanding is the & (ref) allows mutation of the original ref. Would it be better in this case to drop the & in the argument so the function is working with a copy? Please forgive my limited understanding of references.. still kinda new at this. :)
I've updated the C++ translation so the input is passed as
const &now also.Random tests for
dehexcan be cheated in C++.I haven't "fixed" this as I need a little clarification to what you mean that they can be cheated. I'm still in the process of learning the tricks of the trade. :)
sByteshould be defined in files where it's actually used in C++.Think I got this resolved also. Again, let me know.
Sample and final tests are missing required headers in C++.
I believe this is now fixed. Let me know.
Posted a C++ translation for this Kata. Its my first translation, so I hope I did it right!
Please see the above issues and fix them ;-)
Solved most of the issues now, I think. Thanks for blindly accepting the translation too! :)
I'll wait for
FArekkusu's feedback before resolving the issues, but thanks :-)@anter69 approve the fork, it seems to be alright now.
After actually attempting the C++ version I found several more issues but I fixed them myself. Now there's a new problem which I didn't put much thought into and thus ignored, but it really should be changed.
Since I'm already a contributor I can adjust my code and simply replace the user's and reference solutions, or the author could try fixing his monstrocity himself. @anter69 what do you think?
For Java, I think there an un-tested edge case which I saw happen very rarely in the random tests.
When the final byte(s) of the data are spaces (0x20) it seems the RHS text part is not supposed to be trimmed (for those bytes).
In other words, there is a subtle un-tested distinction between spaces which should be trimmed (when last line > bytes) and spaces which should not be trimmed (when last data is 0x20)....
I contacted the translator to check
Well, I didn't receive a reply. Would you/could you fix it?
I dont think Dinglemouse is reporting a bug, but rather suggesting a fixed test to be added for this edge case; something like this:
Right. I forget the details, but that's what I meant. I guess I marked it as ISSUE simply because the absence of the edge-case test could allow incorrect solutions (with over-zealous trimming) to pass.
EDIT: I think I was referring to a multi-line output where some lines (NOT the last one) happened to end in spaces which should not be trimmed.
e.g. imagine if that
21 29from the first row of the example was20 20-- then there should be untrimmed spaces on the RHS of that line. But trimmed spaces still on the last row (because Kata instructions said FOR THE LAST LINE "trim the trailing spaces from the end of the line.")It was awsome kata, it took me two days to solve it :) Thanks for sharing it
Happy to hear that :-)
On the random tests, we have this one:
00000000: d3 81 8d bf d3 8d 2c b3 cf 7a 5c 40 8c 7b c1 9a ......,..z@.{.. 00000010: 4e 2a 40 84 19 7e 41 c0 81 91 b6 f6 e3 0d 2f c5 N*@..~A......./. 00000020: 86 7d a7 88 82 21 1f 63 f3 f5 9d a9 93 78 78 16 .}...!.c.....xx. 00000030: 64 76 93
I logged the size of the byte array, it's 48, where are the last 3 showing up?
this is mine:
00000000: d3 81 8d bf d3 8d 2c b3 cf 7a 5c 40 8c 7b c1 9a ......,..z@.{.. 00000010: 4e 2a 40 84 19 7e 41 c0 81 91 b6 f6 e3 0d 2f c5 N*@..~A......./. 00000020: 86 7d a7 88 82 21 1f 63 f3 f5 9d a9 93 78 78 16 .}...!.c.....xx.
still java, I guess. I have to find someone to fix it, or I will remove the translation
I am so sorry it was my code issue, it's fixed now :) it passed! I will resolve both of the issues.
OK
Hello, i don't see how transform 1a 2b in b'\x1a\x2b' because the '\' is forbiden in string (need two \)
Are you misreading that? There are no backslashes in that string.
No it's in the other way :
transform a="1a" => aa=str.encode(hex(int(a,16))) give b'0x1a' but i can't transform it in b'\x1a' and then concatene with the others bytes
thanck you
"1a"probably doesn't encode tob"\x1a"though, right? You can't encode "purple" like that, there's nob"\xpu\xrp\xle"in hexdump(data) with \x1d\xc4\x15\x25\x91\xe6\x09\x59\x04\x99\x15\x29\x0a\x45\x21\x29 we find 1d c4 15 25 91 e6 09 59 04 99 15 29 0a 45 21 29 Then in the way back 1d c4....is transform in \x1d\xc4.....
I think I might finally see what you're saying
\x1dis one byte. A byte is 8 bits, it can have one of the values 0..255. So which of 0..255 is\x1d? Maybe start with something simpler, like zero, then one, then two. (And there are no backslashes anywhere here, same as how a list doesn't have['s in it)no backslashe in \x1d ? :-) \x1d have the value of 1d (in hexadecimal) or 29 in decimal \x1d is a byte the same with b'0x1d' i want to change b'0x1d' in \x1d and then concate with other \x... to make \x1d\xc4\x15\x25\x91\xe6\x09\x59\x04\x99\x15\x29\x0a\x45\x21\x29 for exemple
you did. you got 29. that's what
\x1dis. it's 29. you would append 29 to your bytestring. not"29", that's not a number, that is text.29. a bytestring is a bunch of bytes. a byte is an integer. your first byte is 29.I found the solution : hex_val='1dc41525' print(binascii.a2b_hex(hex_val))
result=b'\x1d\xc4\x15%'
Nice Kata! I learned about bytes class. I ignored so far in my journey. Thank you!
how does the memory address works? like... hex number 1 should be: 00000001, but in the test cases it is 00000010
It starts from 0 and as you display 16 bytes of data per line, the next line shows memory from 16 (10 in hex), then the next line from 32 (20 in hex), etc
got it, thank you
this kata is lowerranked i think..btw great kata ;-)
Memory address uses lowercase or uppercase for hexadecimal numbers?
Lowercase. Description updated.
found in the random tests:
line 2 and 5: you have unprintable chars instead of dots, it seems. When writing this message, I have 2 red points showing up instead of chars in those two lines where I put the
X:Indeed, chr(127) is not printable...
Fixed the checker function and the description. Thanks for spotting!
Oh, and you may trim your other comment a bit, because it makes screws up the page :-)
Errr... I cannot anymore, now that there are answers to it... X-)
not completely fixed: With ashorter batch of random tests, I get now:
you still generate/have invalid chars somewhere
Note, I'm using python 3.6.0. Could that be part of the problem? (surely I don't use the way you thought about)
Did you reload the page? And try with python 3.4 too.
This comment has been hidden.
X-D
ok, working in python 3.6. I dumbly made shit in my regexp (in the number at the beginning of the lines...). All good, now. And thanks for the added fixed test: without that I may never have found the problem. ;)
OK, great!
This comment has been hidden.
If you mean that there are extra characters -- yes, that's strange. The others (Voile, suic, ZED.CWT) didn't report any such issues. Try printing the input/output -- it shouldn't time out.
Otherwise the tests strings' max length is 10^4, I don't think that's too much :-)
why so big strings? it just makes the debugging really cumbersome. For now, I'm failing at the first random test, but I don't have a clue of the reason. Might be useful:
I added a fixed test that checks all bytes from 0-255, and made the random test scale up as you proceed (from 100 to 10^5).
I marked @Blind4Basics long post as having spoilers, it'll hide it for everyone that hasn't solved the kata.
Approved ;-)
Thanks! Although I'm surprised it was ranked 5 kyu :-)
That was fun! Thanks, suic
Happy to hear that!
Amúgy meg visszatértél? :-)
Igen, meg tavaly novemberben. Amugy koszonom a "Hungarian Cardinal Numerals"-on vegzett munkat :) Udv., suic
P.S.: Ez esetleg erdekelhet.