Может для каких-то астрофизических расчетов и нужны такие экстремальные диапазоны, но там явно не нужна система времени, привязанная к земле, луне и даже к солнцу (то есть дни, месяцы, года).
Только копии каталогов у меня создают не «помойку» а проблему поиска в старых проектах, которые могут располагаться «чёрт знает, где». Места хранения текущих проектов я, более-менее, помню. Соответственно, гит должен иметь дело со всеми, весьма разнородными проектами сразу, а способен ли он на это, я не знаю.
Для этих проектов можно использовать единый Git репозиторий. А если нужно иметь именно физически несколько папочек, то существует git worktree - он позволяет работать над разными ветками в разных папках, причем все это работает в рамках единого репозитория (в отличие от обычных копий). Кстати, это фича недооцененная и далеко не все про нее знают/пользуются.
Мне, лично, нравится! Doc-файлы просто комфортней читать, чем текстовые.
Это проприетарный формат, для открытия таких файлов еще нужна дополнительная программа. К тому же не текстовый - не удобно дифать. Markdown - разумный компромисс между читабельностью, и он подходит для системы контроля версий.
Дело не консольных командах, это, вообще, не проблема, а в наличии посредника. «Зачем нам кузнец? Кузнец нам не нужен!».
Тогда и посредник в виде doc файлов не нужен.
Единственный смысл осваивать гит, я вижу, если надумаю публиковаться на Гитхабе. Пока, еще не решил, нужно ли мне это?
Не обязательно куда-то публиковаться, если использовать гит.
Может быть, только прототип этого «велосипеда» не удалось найти, особенно, по части модульности в C++ для GUI. Судя по обсуждению под статьей, все эту модульность понимают как пакеты в Питоне, а я как плагины.
Может потому что он неудобный и не особо нужный?
У меня тоже, всё тривиально. Скопировал, например, папку «Main024» в папку «Main025» и работаешь, дальше, с ней, какие проблемы?
Непонятно как понять, что изменилось между версиям, файлы дублицируются, непонятные названия, в целом бардак - git решает все эти проблемы.
Да, могут быть структурные изменения либо рефакторинг, но, тогда откатываюсь на подходящую итерацию, вплоть до первоначальной, при необходимости, и создаю новую «итерационную ветвь»
Звучит как страшный сон. Вообще писать без системы контроля версий на C++ это кажется еще более страшным, чем на другом более простом языке. Там же можно случайно отстрелить себе ногу и долго разбираться, в чем же была ошибка. Откатываться на какую-то прошлую версию похоже на потерю огромного количества времени.
Эта система хороша для командной работы, а я всю жизнь программировал один.
Эта система отлично подходит и для случая единственного разработчика, поскольку позволяет легко просматривать изменения, создавать бекапы, ориентироваться по истории и делать многие другие полезные вещи. И для этого даже не обязательно знать консольные команды - все можно сделать с помощью какого-нибудь современного GUI.
Однако проблема контроля версий существуют и в этом случае. Для ее решения пришлось разрабатывать собственную систему «итерационно-модульного» программирования.
Похоже на изобретение велосипеда.
Для итераций я просто копирую старый проект в новый. Условие перехода – более-менее реализованная «фича», в текущей итерации. Она описывается в doc-файле, сопровождающий данный проект.
Кажется, что это слишком трудоемко и ненадежно. Тем более если использовать doc файлы, а не обычные текстовые. Как в этом случае оценивать изменения?
Если в новой итерации код заглючил – откатываюсь на предыдущую, что меня не раз выручало.
В гите это делается элементарно. Можно легко откатиться на любой другой коммит
Даже перезапись истории не гарантирует полного удаления, поскольку коммиты останутся доступными через reflog. Сборщик мусора их удалит, однако не уверен, что он вообще когда-либо вызывается на удаленных репозиториях, например на GitHub.
"Напишу рекурсию, которая проверит все пути и выберет лучший".
Почему-то новичкам в качестве примера рекурсии показывают факториал, что является неудачным примером на мой взгляд. Факториал лучше реализовывать с помощью цикла, причем это так же просто.
Кстати, последние модели вроде могут использовать Python скрипты в процессе ответа на вопрос. Возможно сначала определяется тип задачи, если выясняется, что задача счетная, то используется соответствующий инструмент.
Ну что же - вполне себе вариант, и заодно попросить его тогда смотаться в прошлое и сгенерировать нашу Вселенную...
Сомневаюсь, что интеллект, какой бы он ни был, осилит такое (пока в физике не открыто ничего фундаментального, что позволяло бы такое осуществлять практически).
Это только в теории? А на практике у вас получаются одинаковые ответы для константного сида и нулевой температуры, для каких моделей? В вашей же статье есть ответ (и в комментарии выше):
Be aware that even if you set a temperature of 0 and a seed, outputs are not guaranteed to be identical. Providers might change model configurations that might impact the output. For OpenAI models, you can monitor such changes by keeping track of the system_fingerprint provided in the responses.
Помимо сида и температуры есть еще как минимум многопоточность, которая тоже может влиять на детерминистичность (здесь уже влияет состояние ОС, на которой запущен инференс). Если запускать LLM на одном потоке, то это очень медленно и непрактично (особенно применительно к GPU).
Это неверно уже просто по определению - шахматы элементарно можно "посчитать" комбинаторикой. Да, количество вариантов огромно, но зато отсутствует принципиальная невозможность - надо просто подождать когда вычислительные мощности подрастут.
Элементарно комбинации не посчитать и вообще не посчитать до конца даже с существующими технологиями. Дело не в количестве вариантов, а в том, что критерий выигрыша формализован, в отличие от реальных задач типа научных открытий, в котором не понятно, что является критерием выигрыша, от которого можно строить все остальное.
Познавать окружающий мир они могут сейчас только через человека: сталкивать элементарные частицы, смотреть на далекие галактики, исследовать свойства материалов, наблюдать за животными и т.д. А нужно, чтобы нейросети могли это делать самостоятельно и в нужном количестве (как сами решат), причем еще и обучались методикам измерений, чтобы с каждым разом делали это более качественно и тратили меньше ресурсов.
А чем сам гитхаб не устраивает? Lean - это тоже текстовый язык, и он отлично интегрируется в Git и GitHub.
А я в 2025 на Stack Overflow даже ответил на какой-то старый вопрос, чего не делал с 2021 года.
В качестве разминки для ума - интересно. Но я не представляю в каких задачах конвертация дат может стать бутылочным горлышком.
То же самое можно сказать про сортировку - ее можно делать за линейное время. Только это не практично для больших коллекций.
Может для каких-то астрофизических расчетов и нужны такие экстремальные диапазоны, но там явно не нужна система времени, привязанная к земле, луне и даже к солнцу (то есть дни, месяцы, года).
В смысле среднего? Альфачесс обыгрывает любого человека.
Для этих проектов можно использовать единый Git репозиторий. А если нужно иметь именно физически несколько папочек, то существует git worktree - он позволяет работать над разными ветками в разных папках, причем все это работает в рамках единого репозитория (в отличие от обычных копий). Кстати, это фича недооцененная и далеко не все про нее знают/пользуются.
Это проприетарный формат, для открытия таких файлов еще нужна дополнительная программа. К тому же не текстовый - не удобно дифать. Markdown - разумный компромисс между читабельностью, и он подходит для системы контроля версий.
Тогда и посредник в виде doc файлов не нужен.
Не обязательно куда-то публиковаться, если использовать гит.
Может потому что он неудобный и не особо нужный?
Непонятно как понять, что изменилось между версиям, файлы дублицируются, непонятные названия, в целом бардак - git решает все эти проблемы.
Звучит как страшный сон. Вообще писать без системы контроля версий на C++ это кажется еще более страшным, чем на другом более простом языке. Там же можно случайно отстрелить себе ногу и долго разбираться, в чем же была ошибка. Откатываться на какую-то прошлую версию похоже на потерю огромного количества времени.
Эта система отлично подходит и для случая единственного разработчика, поскольку позволяет легко просматривать изменения, создавать бекапы, ориентироваться по истории и делать многие другие полезные вещи. И для этого даже не обязательно знать консольные команды - все можно сделать с помощью какого-нибудь современного GUI.
Похоже на изобретение велосипеда.
Кажется, что это слишком трудоемко и ненадежно. Тем более если использовать doc файлы, а не обычные текстовые. Как в этом случае оценивать изменения?
В гите это делается элементарно. Можно легко откатиться на любой другой коммит
Даже перезапись истории не гарантирует полного удаления, поскольку коммиты останутся доступными через reflog. Сборщик мусора их удалит, однако не уверен, что он вообще когда-либо вызывается на удаленных репозиториях, например на GitHub.
У автора примерно 18 голосов в день - думаю этого более, чем достаточно.
Вполне возможно что в процессе математического обоснования вы пришли бы к тому, что математически эта задача как раз решается за n^2.
Почему-то новичкам в качестве примера рекурсии показывают факториал, что является неудачным примером на мой взгляд. Факториал лучше реализовывать с помощью цикла, причем это так же просто.
Кстати, последние модели вроде могут использовать Python скрипты в процессе ответа на вопрос. Возможно сначала определяется тип задачи, если выясняется, что задача счетная, то используется соответствующий инструмент.
Ну я бога не верю, так что нет)
Сомневаюсь, что интеллект, какой бы он ни был, осилит такое (пока в физике не открыто ничего фундаментального, что позволяло бы такое осуществлять практически).
Такие, о которых вы писали ранее:
Это только в теории? А на практике у вас получаются одинаковые ответы для константного сида и нулевой температуры, для каких моделей? В вашей же статье есть ответ (и в комментарии выше):
Помимо сида и температуры есть еще как минимум многопоточность, которая тоже может влиять на детерминистичность (здесь уже влияет состояние ОС, на которой запущен инференс). Если запускать LLM на одном потоке, то это очень медленно и непрактично (особенно применительно к GPU).
Или помешало бы - не факт, что любимые ходы - хорошие ходы с точки зрения сверхчеловеческого уровня.
Элементарно комбинации не посчитать и вообще не посчитать до конца даже с существующими технологиями. Дело не в количестве вариантов, а в том, что критерий выигрыша формализован, в отличие от реальных задач типа научных открытий, в котором не понятно, что является критерием выигрыша, от которого можно строить все остальное.
Познавать окружающий мир они могут сейчас только через человека: сталкивать элементарные частицы, смотреть на далекие галактики, исследовать свойства материалов, наблюдать за животными и т.д. А нужно, чтобы нейросети могли это делать самостоятельно и в нужном количестве (как сами решат), причем еще и обучались методикам измерений, чтобы с каждым разом делали это более качественно и тратили меньше ресурсов.
Это потому что они пока не очень хорошо интегрированы в окружающий физический мир.