I see from other solutions that the Linq option I was missing hardly was 'ThenBy' to sort the names inside List.
You cannot! But I can't stop anyone adding a polyfill..
Finally addressed this... Stopped the use of require.
Added the note, thanks for the suggestion :)
Please provide the note in description that the use of 'BigInteger' classes is banned BEFORE user attempt the test.
I understand it's kyu 4 so no simple solution can be used here, but it should be clearly noted- not something I see when I'm already attempting the final solution.
Upvoted- thanks for this tip. I completely missed that word and ended up with some tests failure.
@FArekkusu - your drawing is deceptively misleading. First off, the kata does not explain that there could be obstacles in the path. Secondly the path to get to the target, with the obstacle, would be
NORTH WEST WEST SOUTH SOUTH SOUTH EAST EAST
without the obstacle.
I'm sure you can cook up an example with an obstacle (perhaps a one way door?) where the paths
NORTH SOUTH EAST WEST
NORTH EAST WEST SOUTH
(or similar) are not equivalent.
The kata is ill-posed because the it gives the impression of a single algebraic set, but the test uses two separate sets.
Please consider updating the kata description to clarify the intent. Thanks.
I agree! Would be a less trivial problem to solve too.
Found it... I was not checking for one othe kind of null input
Exit code: 0
Signal code: 11"
My code is working for empty string, having '/', '0', '9', ':', starting or ending with a digit....
Em, FArekkusu, didn't you draw ["NORTH", "WEST", "SOUTH", "SOUTH", "EAST"] ?
Check your code.
Pointers are 64-bit, rdi is the only correct variant, you can't use edi. Addresses can be higher that 4 GB; in real world with address space randomization the probabilty is very high.
As noted in wiki the NASM katas are compiled with nasm -f elf64, that means you can pretty fine just use RDI instead of EDI for 64 bit access
How about something like this to make sure solutions don't truncate addresses?
const char *const s = "11";
char *const buf = malloc(((size_t)1 << 32) + sizeof(s) - 1);
char *const boundary = (char*)((intptr_t)buf & ~(intptr_t)0xffffffff | 0xffffffff);
cr_expect(has_digits(boundary + 1));
(It looks like mallocing 4 GB is OK and unused pages are reserved but never commited.)