Performance constraints are different, and the identifyable parts are also different enough to make these two different kata's.

Thanks a lot! Good stuff. Approved.

In alot of cases this is true

But there are some scenarios where having a wall instead of a pawn changes the outcome

What I have edited:

1. changed the wording of the description to the above
2. changed the parameter name to board
3. added 2 example tests with descriptions

I used chess.com to create the images of the board

The x can be a regular int, but I choose bigint for consistency with the result.

Also, int and bigint cannot be combined in expressions. For example 1 + 1n will throw an error. That's also why I made the x a bigint in the first place.

Its ok now. Thanks for quick fix!

I've found next tests in random tests suite:

Incorrect answer for board:

000|000|080
258|790|000
041|036|257
---+---+---
106|179|504
109|400|076
004|368|910
---+---+---
792|600|143
000|010|005
005|203|008

Fourth and Fifth lines are started from 1 "106......" and "109......". Thats invalid sudoku board, because we have duplicate value (1) in first column.

Incorrect answer for board:

009|088|040
002|000|630
304|625|870
---+---+---
405|168|090
080|509|120
100|702|500
---+---+---
008|203|400
006|890|307

In first line we have duplicate value (8) (...088...)

And so on.

Approved. Let me know if you find any issue with the translation.

Approved

From the Problem Description section: You start at any initial index of your choice..

Consider the first mountain as the start.

why undefined behavior exists is a complex question. It certainly has a lot to do with the fact that C is a low-level language, providing direct access to memory and with a focus on runtime speed. It dates back from a time (50 years ago) where compilers and similar tools were much more limited than the powerhouses we know today. Many programmer errors were not detectable by compilers at the time; and even nowadays, you need a static or dynamic analyzer on top of the compiler to find most UBs in your code, because of how lax the language rules are, especially regarding memory manipulation.

It's also hard to change the rules of the languages now without breaking compatibility with the colossal amount of C/C++ code that has been written over the decades and that powers pretty much everything we take for granted, from OS kernels and embedded systems to web broswers, game engines and interpreters (Ruby, Python, PHP... all have engines written in C; major JavaScript engines are written in C++).

As textninja mentionned above, an insane amount of work has been done over the years on C/C++ compilers to make the generated code run really fast. Very often, there is a tradeoff between runtime speed and safety: for example, Java will check at runtime if you try to access an array outside of its bounds, and gracefully throw an error if you do so. This kind of checks have an impact on runtime performance. In C/C++, your array accesses are faster than Java's, but if you do an out-of-bounds access, you are on your own.

(Modern compiled languages, e.g. Rust or OCaml, try to do as many safety checks as possible at compile time, to remove as many of them as possible from the run time, thus imrpoving on both aspects at once).

Unfortunately, all of this means that undefined behavior is here to stay for the foreseeable future.

This seems a little "thin" to me. If we assume that programmer's time is more important than machine time, making the compiler faster at the cost of potential programmer confusion seems like a bad trade-off.

One of C++'s main selling points is speed, so I think it's fair to make the tradeoff for that language in particular. N.B. it doesn't just make the compiler faster, but actually allows the compiler to generate faster code.

by nature of the C/C++ languages, these kind of things are unpredictable - they are called undefined behavior for that reason. the state of uninitialized variables depends on a lot of factors, such as the code that surrounds them, how they were allocated (e.g. heap versus stack), and more broadly the entire environment (compiler, architecture, OS...)

it is easier to visualize it with an array:

#include <iostream>
#include <array>

int main() {
	std::array<bool, 32> booleans; // 'booleans' is uninitialized
	for (bool boolean : booleans)
		std::cout << boolean << std::endl;
}

if you run that on either Codewars or your machine you will most likely see many different values for the booleans (as they are bytes behind the scene)

in

bool boolean1, boolean2 = false;

the boolean1 variable is left uninitialized. On your computer you were being 'lucky' that the memory happened to be zeroed, so it was initialized to false

approuvé