Blog

A very ambition task for create model for agricultural background for 
grain harvesters. I want use this model for debugging software for optimization technical process of threshing. This model must be work with model of harvester together.

I understand that is complex and really difficult work but I hope than I can create first simple version for basement.

Why C++ is enought and good desicion for this? Why not Matlab (or SimInTech, or Engee)? Of cource I use mathematical packages for create math description of model. And I use C++ for create
SW than can uses information about agricultural background from file (moisture, consist of green mass and grain, full weight of mass). C++ is a good selection because I must updated my models (of several parts of them) for create digital twin. Didital twin is a part of SW than may be working in real time on electronic control unit. Native language for ours systems is C/C++. And when I wrote code myself I could avoid unnecessary redundancy than gets Embedder Coder from Matlab.

Let’s consider a simple function called longTimeFunction. It simply prints a message indicating it has started, waits for three seconds, and then prints a message indicating it has finished.

If we run this function using std::jthread – leveraging the wrapper class’s dtor for convenience – the program will terminate successfully; this is because std::jthread automatically calls join() in its dtor when the thread object is destroyed.

If we use std::thread, however, the program will terminate with an error, as join() is not called automatically in the dtor, requiring us to call it manually.

This is a key difference between the two when terminating a thread by destroying the object. Of course, there are other differences as well.

Russian version below.

Modern neural networks aren’t about intelligence and innovation, but about finding matches from existing knowledge. Using them to generate new algorithms that the world doesn’t yet know about isn’t a good idea. In any case, it would be a compilation of existing versions, and there are, of course, no guarantees that these algorithms will work.

A neural network as a coding assistant is a great idea for typical, routine tasks: writing a large number of getters and setters, writing numerous obvious unit tests, and formatting code according to requirements. I can’t say I often use them for such tasks, but it does happen sometimes.

However, using neural networks to find errors in algorithms is a pretty bad idea, and here’s why. If the algorithms are new, developed for a highly specialized task and have no analogues, then you risk leaking your code and intellectual property. Ultimately, all of this will likely be available to all users, and the neural network itself is unlikely to help you achieve acceptable results. There have been plenty of examples of this in the news in recent years. If the algorithms are classical, a neural network can certainly find and fix an error, but what value will it have? Based on the experience of students, I can confidently conclude that the constant use of neural networks for developing and finding bugs in classical algorithms significantly reduces cognitive abilities: finding bugs, maintaining legacy code, and writing your own algorithms becomes increasingly difficult.

The basic rules should be as follows.

1. No neural networks for analyzing new algorithms or new unique code.
2. No neural networks for programming that compromises your abilities: use them only for routine operations and information retrieval.
3. Trust, but verify.

And Russian version.

Современные нейросети это не про интеллект и новое, а про поиск соответствий из уже готовых знаний. Использовать их для генерации новых алгоритмов, про которых еще не знает мир, не очень хорошая идея. В любом случае это будет компиляция из уже существующих вариантов, причем гарантий по работе этих алгоритмов, разумеется, не будет.

Нейросеть, как помощник в написании кода – отличная идея для типовых, рутинных задач: написать большое количество геттеров и сеттеров, написать много очевидных юнит-тестов, отформатировать код в соответствии с требованиями. Не могу сказать, что я часто использую их для таких задач, но иногда бывает.

Однако, использование нейросетей для поиска ошибок в алгоритмах достаточно плохая идея и вот почему. Если алгоритмы новые, разработанные вами для узкоспециальной задачи и не имеют аналогов – то вы получаете утечку своего кода и интеллектуальной собственности. В итоге все это будет с большой долей вероятности доступно всем пользователям, а сама нейросеть врядли поможет вам получить приемлемый результат. Примеров этому уже достаточно много в новостях последних лет. Если алгоритмы классические – безусловно нейросеть сможет найти и исправить ошибку, но в чем будет тогда ваша ценность? На примере студентов, могу смело делать вывод о том, что постоянное использование нейросетей для разработки и поиска багов в классических алгоритмах сильно снижает когнитивные способности: искать баги, поддерживать legacy-код, писать свои алгоритмы – становится все сложнее.

Основные правила должны быть такими.

1. Никаких нейросетей для анализа новых алгоритмов и нового уникального кода.
2. Никаких нейросетей для программирования в ущерб своим способностям: используем только для рутинных операций и поиска информации.
3. Доверяй, но проверяй.