CUDA C++ NEAT Memory Error Fixes

First of all, please DO NOT apply if you; * Apply with a much higher bid, * Ask for a milestone or hourly pricing approach, * Don't have experience in CUDA C++ or evolutionary algorithms, * Don't have experience with debugging memory errors and undefined behavior, * Don't think that you can meet the requirements, * Depend on chatbots, thinking that you can handle the project with ChatGPT, etc. The fixed budget is based on the fact that this is not a from-scratch implementation. A substantial CUDA C++ evolutionary/NEAT-style codebase already exists, including population creation, feed-forward evaluation, mutation, exploration, genome/network handling, training logic, fitness evaluation, and a partially implemented crossover mechanism. The developer’s main responsibility is to stabilize, debug, complete, and validate the existing architecture rather than rebuild the whole project from zero. I'm looking for machine learning engineers/data scientists who are experienced with CUDA C++ and the NEAT algorithm, or at least some other evolutionary algorithms. You need to have experience in both CUDA C++ and evolutionary algorithms in order to get accepted. Since the main part of the project is related to memory errors, undefined behavior, and incomplete crossover logic, practical experience with debugging low-level CUDA C++ problems is also required. Job acceptance conditions The existing crossover mechanism has memory-related problems and some incomplete parts. The main requirement is to properly fix those problems and complete the crossover mechanism so that it works correctly with the existing architecture. The solution must fix the actual cause of the errors instead of only preventing the current crash with an extra condition, disabling the problematic code path, masking an invalid value, or adding another temporary workaround. Crossover must work correctly when the parent networks have different neurons, connections, layers, or network structures, and it must produce valid child networks without invalid pointers, incorrect neuron or connection references, uninitialized values, corrupted structures, or memory errors. The existing crossover implementation can be changed or partially rewritten where necessary, but the rest of the project does not need to be rebuilt from zero. Speciation must also be added and controlled by a true/false parameter, so the algorithm will use speciation when the parameter is enabled and continue with the existing non-speciation approach when it is disabled. Both modes must work properly, and disabling speciation must not break the current evolutionary logic. The exact implementation can be adjusted according to the existing architecture, but speciation must actually affect the evolutionary process rather than only assigning networks to groups without using those groups during selection or reproduction. The developer must also inspect the relevant parts of the code for other memory errors, undefined behavior, invalid indexing, incorrect allocations, uninitialized values, host/device memory problems, race conditions, or similar issues that may cause crashes, silent corruption, or incorrect results. There may also be errors that are currently hidden because of masking, clipping, conditional logic, current parameter values, allocation behavior, or the current network sizes. Those problems must be detected and fixed at their actual source instead of only making the final output appear valid. As much useful debugging functionality as reasonably possible must also be added to the code. Since I will continue modifying parameters, debugging the implementation, and performing different tests after receiving it, the debug functionality should make it easier to understand where and why a problem happens. Depending on the problem, it should provide useful information about the related network, parent, child, layer, neuron, connection, allocation, mutation, crossover operation, species, or CUDA operation instead of only printing generic messages. Detailed debugging does not need to remain permanently enabled during normal execution and can be controlled through parameters, compile-time options, or a debug mode. Expected functionalities: Proper functioning of the existing CUDA C++ NEAT architecture Properly completed and stable crossover mechanism Valid child networks after crossover Resolution of the known crossover-related memory errors Resolution of other memory errors and undefined behavior found in the relevant parts of the code Correct handling of parents with different network structures during crossover Optional speciation controlled by a true/false parameter Proper functioning of the algorithm both with and without speciation Proper functioning of mutation, crossover, exploration, population handling, and training logic after the changes Useful debugging functionality for detecting memory, network structure, CUDA, mutation, crossover, and speciation problems No undefined behavior or other errors that could cause the system to malfunction No masking, disabling, or bypassing of broken code paths instead of fixing the actual problem The developer should test the implementation with different reasonable parameters and network structures instead of only running the default configuration once. Crossover and mutation should be tested repeatedly, and both the speciation-enabled and speciation-disabled modes must be tested. After receiving the completed code, I will spend some time changing parameters, debugging the code, and performing different tests. Some memory errors, undefined behavior, masking-related problems, or incorrect crossover cases may only become visible after changing parameters or executing the code repeatedly, so payment will be made after I complete this verification and confirm that the agreed problems have been properly fixed. This testing period will only be used to verify the agreed crossover, memory, undefined behavior, speciation, and debugging requirements. It will not be used to add unrelated features or expand the project scope after delivery. The developer is responsible for delivering a correct, stable, reproducible, and debuggable implementation of the existing architecture. Before final delivery, the developer should also briefly explain the main problems that were found, the changes that were made, and the tests that were performed