Физики рассказывали. Что если у них есть задача сильного и слабого взаимодействия множества частиц в пространстве (в данном случае - на плоскости) - то они строят вокруг частиц дополнительные структуры данных QuadTree/OctalTree и дальше считают сильное взаимодействие только для частиц которые лежат внутри некого минимального квадрата (куба). Прочие - игнорируют.
Я к тому - как оптимизировать на знании того куда дальше пойдет эта информация.
Wataru, по поводу dfs/bfs.
Алгоритм для сверх больших досок можно сделать детерминированным.
- на больших расстояниях оба коня должны двигаться в сторону сближения.
- правило единого цвета клетки в силе.
- когда кони заходят в окрестность квадрата 3х3 - остаётся ровно 1 ход до сближения. Там - небольшое количество вариантов. Я посчитал.
А можешь показать как выглядит таблица в нормальной sqlite-консоли. Вот как тут.
$ sqlite3
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> select * from list;
Предположительно у тебя null стоит вместо дат. Но это надо как-то проверить.
Darya Boo, основной каркас остается - тот-же самый.
Только при накоплении строки мы слова пишем не в StringBuilder а в коллекцию слов.
Когда достигаем условия maxChars - добиваем коллекцию пробелами между слов
до тех пор пока не достигнем ТОЧНОГО размера maxChars.
Более элегантное решение на расчете пробелов через деление и остаток от деления но я-бы
его не далал т.к. добивание пробелами - вполне себе годное решение. И быстрое. Разница
в перформансе почти не будет заметна.
Роми, у них был американский стандарт напряжения. И я не решился купить. Нужна будет либо переделка либо какой-то адаптер напряжения. Но они мне внешним видом понравились.
Владимир, у меня переезд на новое железо не происходит за 1 день. Все равно старый ноут еще какое-то время работает. Там - слишком большой зоопарк нужного софта и настроек.