6 kyu
2D array inner join
77 of 178mik
Loading description...
Fundamentals
Matrix
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.
Nice kata, well done.
Javascript:
Max Buffer Size Reached (1.5 MiB), even though I'm logging nothing.
Solution fails even though I pass all the tests.
Are you sure you're not logging anything? I submitted 10 times, not a single time I got this error.
This comment has been hidden.
I just checked, there are no console logs anywhere in the tests :D
And again, using your given code, 5 submits worked without a problem.
Try switching to node 10 and resetting the kata, if that's not already the case.
Switching to node 10 (it was set to 6.11 by default) fixed the problem.
@B1ts: Thank you very much for your help!
python at least:
sample tests should contain at least one test with indA and indB different from zero and another with indA != indB
The random tests are sometimes generating cases where different matching keys are interleaving with each others, while nothing is told about how to handle that in the description:
Either to add the requirement to keep the original order, based on arrA (meaning O(n²) approach is somewhat a requirement... :/ ), or sort the random arrays before sending them to the user (according to indA and indB ; sounds like the worst option here, maybe), or modify the way the assertions are done so that actual and expected values are sorted before comparison?
edit: for instance: this solution passes the random tests only from time to time because of the unspecification above (btw, could be good to increase the number of random tests to 100)
SQL is never guaranteed to return the rows in some particular order, so particular ordering should not be tested at all.
Do the columns have different data types in different rows?
yes
then the only reasonable option is to sort the outputs before comparison, I guess?
or conversion to a set of tuples? (might be better to change the ouput type, then)
That's a huge issue as well.
yep...
=>
sorted(..., key=str)?that or
Counter(map(str,...))?In both cases, the assertion message should provide the original outputs (and surely the description should warn about the way the tests are processed)
Sigh.. Maybe it should just be reverted to work with ints in random tests after all..
since there is no modification of the inputs, I think that a "string and (sort or count)" approach could do it. It "only" needs a custom assertion function, then.
I'm afraid you opened a nasty can of worms with this, B4B :P Sorting the results seems to be the least of my worries. I wish this wasn't approved so hastily.
That means changing how random tests are generated. (fixed tests seem fine)This seems fixable. Assigning each column a random type generator function (each with chance to generate null, NaN for numbers, None for python, etc.)
I'll try playing around and fixing this later tonight.
Made some changes
Please confirm that it's working and if issue is resolved (especially python)
Lastly, I feel strongly that
undefinedshouldn't be populating lists at all,nullis enough. Undefined shouldn't exist in SQL queries. Change my mind.sounds good to me (I checked python version)
I just wonder about one single thing now: shouldn't the assertions of the fixed tests use the sorting too?
Why the hell JS tests still have
undefinedandNaN?!Fixed tests are not sorted in JS as well.
That's because the initial author had them in, so we left them for a while. I removed
NaNandundefinedaltogether.Might be some typos from copy pasting, idk... Please tell me it's fixed now =/
I hcecked pythoàn and it sounds pretty good. The only remaining trouble is the concatenation of the describe/it blocks. 2 ways out of this:
print("<COMPLETEDIN::>")@B4B, I tried option number 2. Better now?
yup, well done. :)
( JS )
Changed
Testtochaibecause failure messages were showing[Object].This should be reflected in the random tests as well.
I don't see much point in that...
Or this sentence can be removed to make everything integer-exclusive. As long as the description and tests are consistent either option would suffice. Given that, this does indeed provide zero additional challenge (and makes no sense in typed languages) I prefer the latter option as well.
I already added heterogenous list generator for random tests. Please confirm that it's working. (Indeed, nothing really changes, except being consistent with description. If languages like haskell can't generate such list, then it should also be fine)
At least in JS, the test message for the two tests with
NaNkeys are incorrectly marked asNon matching rows (null).Fixed those messages. But at the same time, it's not mentioned how
NaNshould be handled. The description mentions only finite numbers. And because of simple comparisons failing withNaN, no solutions (including author's) consider them as valid.I'd argue the ref solution should be changed to allow matching on
NaN, just like other falsy values.Edit: actually, the description says that
NaNshouldn't be present in arrays at all. So, what do we do here?Amend the description: take out "finite".
NaNis a primitivenumberlike any other.Matching on
NaNis not a good idea;NaN /= NaNis default behaviour for JS ( and others ).Can't throw in all falsy values together -
nullandundefined( by spec ) andNaN( by definition ) are not like0and"", which match just fine..
Well then, I suggest we remove the word
finitefrom description. But then, should we leave out mentioningNaNat all, and just rely on default behaviour?Once you decide that, I'll change python version accordingly, and then I can approve the haskell translation :>
Yes. Just don't mention
NaN.I've removed "finite".
.
Python 3 should be made available.
Or does it make more sense to just remove the Python translation?
Apparently, it's borked beyond salvage.
enabled
The description should be made language-independent.
Can you do it? I can't, I don't know Python.
There seems to be not that much language dependence even there.
nullandundefineddo not match: addNone,Nothingand similar placeholders for non-values?NaNis probably automatic everywhere already ( it is used in tests in JS ).Indeed, the only difference is that python uses
None, whereas JS hasnullandundefined.NaNisn't even tested in python, I think. Feel free to change the description, idk how to handle it with multiple langs :(As for comparisons, python doesn't have
===(afaik), and has no problems comparing arrays with same elements and same order ([1,2] == [1,2],[1,2] != [2,1],None == None). But we're not testing for arrays anyway.Remove
undefinedfrom JS tests, and test only integers andnull-like values in all languages?I meant idk if there's a way to render a portion of description based on selected language, or if you have to re-post entire description with few words changed.
You're probably right, it makes sense to remove undefined, and adjust universal description to match on primitive values and
null-like values.You can render a portion of the description depending on language (
```if:pythonand```if-not:pythonwould do that. those blocks render as text, not as code ), but there is only one description for all languages.I think I agree with Bits here;
nullmakes more sense as SQLNULLthanundefineddoes, but I see no reason to restrict your primitives to numbers or even to integers ( except in Haskell, because it doesn't do heterogenous lists ).Like this?
I said the wrong thing. Yes, it should be limited to primitives and
null-like values.Yep that's the markdown I was looking for, thanks!
I updated the description and changed JS ref solution to match on
null, but notundefined. That invalidated a lot of solutions =/ (only JS)Does that fix this issue?
Ehm, no?
It should not match on
null. How did we get here?No updates to the reference solution should have been necessary,
null( and friends in other languages ) should not match, andundefined( in JS ) should not be applicable. And, becauseNaN != NaN,NaNshould also never match.Doing it that way does not invalidate any existing solutions ( including the example solution ) and is consistent with the SQL way of doing things.
Oh crap, I misunderstood you.. I reverted it back, and I'll leave it be now. My apologies :X
Both versions should be good now. I also reduced JS random tests to have less elements, as this isn't perfomance task and it is now similar to python's tests (change it back if you disagree). We've already wasted too much time on some kata that's nothing special and has no active author :P
Btw, this issue was about description, and I think it's fixed now.
I also think it's fixed, and I think I'll need to fork the Haskell translation again for updates.
You can't specify non-existent columns for
JOINin SQL, and the expected behavior is not explained anywhere.Python again?
JS implicitly returns those values as
undefined, and description says you should never match onnullorundefined.Haskell doesn't do this, because you can't.
Does Python default to something if you cluelessly program it?
Well, if you try to access anything out of bounds, it will throw (so no return value). You can (and have to) guard against that in code. Do you think larger indices should be removed altogether? ( would be inconsistent with JS translation, but at least JS has defined behaviour for it in description :P )
I've removed it in my proposed Haskell translation for precisely that reason: it throws.
I'd suggest taking it out of Python as well.
It's not in SQL, you can't do it, and it presence in JS seems to be an artifact of JS' particular handling of index OOB. IMO the best option would be to kill it off in JS as well.
Ok, I changed indices in python to be within bounds. Feel free to remove it from JS too.
I'll take a closer look at this tomorrow.
Removed that one test from JS as well.
No sample tests (in Python at least).
Can you copy them over from Submit tests? Original author isn't coming back to do it, I fear.
added.
Thx Bits.
Haskell translation
( updated for fork for description update )
I click approve -> confirm, and nothing happens, no error message either. Why?
Possibly because in the first week only an author can approve.
Another reason (not as common) is that I don't think you can approve translations if the author of the translation didn't complete the kata (forfeited).
It probably doesn't apply to this one though.
Haven't noticed that problem. I thought I had a counterexample, but it turns out I don't. Anyway, it's not applicable here.
Updated Haskell translation
Approved eventually. :D
Thx.
I haven't followed the discussion above closely, so the translation may have gotten stung by the wasps' nest in the meantime. Oh well, somebody might let us know ..
Needs random tests
Added
This comment has been hidden.
@ZozoFouchtra thank you for the suggestion. Yes, it makes sense. I will add more explanation to make it clear that each row of the first table will need to be compared to each row of the second table and will add more test cases.
This comment has been hidden.