Так вы дайте ссылку на эту статью, или ещё лучше, напишите про это статью на хабр. А то выглядит так, что вы ругаетесь с автором по какой-то одной вам ведомой причине.
Так как в 1с сложно быть чистым разработчиком, нужно вникать в предметную область.
Мне казалось, надо везде вникать в предметную область. Нужно же понимать, что делает код.
А из за отсутствия ООП и как следствие примитивной ide для работы в 1с требуется повышенное внимание, отличная память, развитое воображение, умение читать модули по 10-20 000 строк, держать в голове прочитанное так как логика начинается а форме, потом уходит в модуль с вызовом сервера, потом в модуль сервера, затем вызывает процедуры из модуля повт.исп которые в свою очередь вызывают функции ещё из нескольких модулей и все это для одной функции одной сущности.
Это в java/c# ide подскажет тебе какие методы можно применять к данному типу, где он используется. Плюс сам подход ООП снизит сложность ограничив видимость кода и его количество.
Выглядит так, что для работы с 1с надо уметь держать в голове множество абстракий и зависимостей, уметь отслеживать процесс передачи данных и ход выполнения алогритма. То есть быть опытным разработчиком :)
Это перевод, так что я не могу ответить на этот вопрос. Автор пишет, что цель поста заполнить промежуток между запуском на одной машине и документацией PyTorch где вопрос распределённого обучения обсуждается в широком смысле, так что эксперименты они проводили только на двух машинах.
И у вас такой же вывод. Может быть я не правильно выразился.
Просто вы пишете, что это -- лучшая идея. А потом сразу же пишете, что это сложно и настройка билда в одном файле [как в Rust] было бы упрощением. На мой взгляд это немного противоречит друг другу.
Rust имеет возможность использовать скрипт для сборки, но часть функционала всё же вне самого компилятора, и для более простой работы с C надо подгружать внешнюю библиотеку.
Как-то вы неожиданным образом перешли от использования скрипта для сборки к подгрузке внешней библиотеки (это какой? crate это не библиотека, он будет вкомпилен в ваш бинарник как составная часть, после компиляции внешним он не будет) через функциональность компилятора. Или чтобы использовать скрипт для сборки надо какую-то внешнюю библиотеку использовать? Нет, не нужно, компилятор это из коробки умеет.
По умолчанию при создании проекта из cargo создается файл Cargo.toml, который отвечает за настройку сборки.
Да, потому что чаще всего декларативного описания хватает. Но если не хватает, то можно и к императивному подходу обратиться. А в Zig сразу императивный, причём вы сначала говорите, что это лучший подход, а потом пишете, что, возможно, Zig перейдет на более простой метод. То есть подход лучший, но не простой? Чем же он тогда лучший?
Методы type1_add и type2_add отличаются только тем, в какой класс добавляется точка. Лучше выделить общее в отдельный метод и передавать номер класса через аргументы.
Метод restudy вызывается при добавлении очередной точки. То есть если мы добавим 10 точек, то мы 10 раз переобучим модель. Лучше обучить модель один раз, когда все точки уже добавлены. Не говоря уже о том, что чем больше добавляем точек, тем сложнее обучение и гонять долгий и тяжелый процесс на каждую точку -- очень плохо.
Обычно процесс обучения модели называют fit или train, а не study.
Ну и наконец, зачем вы используете линейную регрессию для задачи бинарной классификации? Чем не устроила логистическая регрессия, которая как раз для бинарной классификации и предназначена?
Странно выглядит сам процесс обучения. Почему бы не использовать градиентный спуск? Зачем корректировать веса для каждой точки отдельно?
Хеш-функции разные бывают. Те, которые еще называют чексуммами или контрольными суммами, возвращают число 32 или 64 бита и предназначены не для паролей, а для контроля того что данные не испорчены. Некоторые еще позволяют какие-то оишбки исправить. Сюда относятся CRC, Adler-32, MurmurHash и более современный xxhash. Пример применения -- записать в файл архива хеш исходных данных и после распаковки проверить, что распаковали правильно или записать в заголовок пакета, передаваемого по сети, чтобы получатель мог проверить, что данные доехали. Для защиты паролей не имеют смысла. Этими функциями занимаются математика и теория информации.
А есть криптографичесике хеш-функции. Сюда относятся md5 (устарела), sha-1 (устарела), sha-2 (пока не устарела, но осталось недолго), sha-3 (замена sha-2 и пока почти нигде не поддерживается). Их задача обнаружить изменение исходных данных, даже самое минимальное, и при этом минимизировать вероятность коллизии, особенно, умышленной. Их можно (но не нужно) использовать для защиты паролей. Можно использовать для электронной подписи. Считаем такой хеш и подписываем его ассиммитричной криптой. Если хеш не сошелся, значит документ был изменён. Еще их может использовать файловое хранилище для дедупликации. Посчитав такой хеш для файла и проверив по базе, можно понять, есть файл в хранилище или нет, и если есть, то не загружать. Благодаря тому что эти функции специально нацелены на минимизацию коллизий, в целом, вероятностью коллизии можно пренебречь при определенных условиях. Но поскольку мы сжимаем много данных (в случае файлового хранилища файлы могут был размером в гигабайты) в маленькое количество данных (256 бит для sha-256) коллизии все равно возможны. Но благодаря этому мы получаем еще одно свойство -- по хешу невозможно даже примерно получить представление об исходных данных, поэтому, например, практически невозможно понять, как поменять данные, чтобы получить заданных хеш. Еще одно требование к ним -- лавинный эффект, то есть при минимальном изменении исходных данных, хеш должен меняться до неузнаваемости (нельзя, чтобы менялась только часть хеша). Этими функциями занимается криптограция.
Теперь о паролях. Проблема в том, что хеш-функция для одних и тех же данных дает один и тот же хеш. Поэтому если у двух пользователей одинаковый пароль, в базе для них будут записаны одинаковые хеши, что плохо, так как упрощает атаку (можно атаковать одного пользователя и получить пароли от нескольких). Здесь сейчас приняты разные хитрые схемы, например, можно посчитать для кажого пользователя случайный массив байт и объединить его с паролем и хешировать уже результат такого объединения. Здесь можно посмотреть bcrypt.
Есть еще хеш-функции в хеш-таблицах (они же мапы, они же словари, они же ассоциативные массивы, много названий для одного и того же). У них чуть иные требования. Контроль целостности как таковой не нужен. Нужно для одних и тех же данных гарантированного давать один и тот же результат, время расчета должно быть минимальным и при этом разборс значений должен быть довольно велик. Используются для поиска того, в какой бакет (сегмент) ассоциативного массива положить данные или где их искать. Считаться быстро нужно чтобы этот поиск работал моментально, разброс значений нужен чтобы все данные не попали в один сегмент.
Я прямо в тексте написал, как это все (и еще вагон дополнительных требований) элементарно реализовывается на ФС.
Вот это, что ли?
Мы могли бы легко хранить количество обращений по сокращенной ссылке, а также любые другие прикрепленные данные, ведь конечный файл может быть какого-угодно формата (в том числе, он сам может быть директорией).
Ну такое себе описание того, как реализовать, больше похоже на утверждение о том что это возможно. И как же реализовать счетчик посещений на файлах? Если что, посещения могут быть одновременными.
Помню, когда учился в Петербургском государственном морском техническом университете к нам приходил представитель верфей с Большого Камня и звал. Я, правда, не судостроитель, а программист, так что нас не звал. Его только проектанты интересовали.
Не заложили. Любая ссылка на вас ничего не стоит и ценности не представляет. Потому что внезапно ссылка на блоги (и даже Хабр) в научных публикациях весом не обладают. Так что ссылаться на вас можно максимум в постах такого же уровня, что и этот. То есть опять-таки, ничего научного не представляющих.
Когда вы пишете научную статью эти правила не работают. Не держите читателя за дурака, он достаточно квалифицирован. Работа должна отражать ваше послание максимально полно. Но не забывайте, что статья должна быть посвящена одному вопросу или в крайнем случае — нескольким, но очень близким.
И сколько отказов вы собрали? И, конечно, было бы интересно увидеть конкретные формулировки. Мой опыт отказов говорит что там пишут конкретно, что не так.
Ну, собственно, тут у нас классический случай. Берем некоторую гипотезу, высказанную много-много лет назад (в масштабах науки 30 лет это очень много) и пытаемся ее проверить. Предположим, сошлось.
Тут есть развилка. Либо мы пишем некий текст и пытаемся его опубликовать, либо пытаемся искать другие работы на эту же тему и почему-то не находим. Во втором случае мы просто пропускаем один этап и сразу переходим на этап поиска заговора. Если мы идем первым путем и пишем текст, нам скорее всего откажут в публикации, во многом потому что мы не ученые и просто не знаем, как пишутся научные статьи. Например, было бы здорово ссылаться не на одну гипотезу 30 летней давности, а все же дать ссылки на другие работы по теме, привести источники данных и так далее. Также было бы неплохо отказаться от обиходных оборотов вроде "заставляет задуматься", "Как вам размеры циклонов?" и прочее.
Ну так вот, нам отказали. Здесь опять-таки есть развилка. Мы можем попытаться исправить работу, чтобы пройти дальше по пути рецензирования. Есть, правда, опасность, прийти к выводу о том что гипотеза не верна или найти ее опровержения. Или, скажем, по просьбе рецензента привести свои расчеты, из которых будет видно, что описанного эффекта не наблюдается. Но это наука, случается и ошибиться. Но есть и второй путь. Можно прийти к выводу о том что журнал "контролируется сторонниками СО2-версии глобального потепления", то есть что нашу статью не приняли не потому что мы просто не смогли написаать научную работу, а потому что есть некий заговор по замалчиванию истинной причины вещей. Здесь трудно оказать себе в удовольствии сразиться с мировой закулисой, ведь знание Истины окрыляет.
Итак, мы решили выйти на бой мировой закулисой. Для этого нужно завести сайт, где опубликовать свои выкладки (какая-нибудь соцсеть тоже подойдет) и прийти на Хабр. Автор оба пункта уже выполнил.
P.S. Самое любопытное, что это почти стандартный путь. Вспомните товарища, который пращой пытался космические аппараты запускать или другого товарища, который упругий вакуум исследовал.
Репозиторий якобы должен заменить недружественный GitHub, который начал блокировать российские учётки.
Понятно, что ключевое слово "якобы", но когда речь идет именно в формулировке "российский GitHub" или "замена GitHub" все же представляется именно общедоступная репа, а не только для гос. кода.
Так же из статьи автора:
А на днях утвердили список будущих создателей репозитория.
В такой формулировке выглядит так, что они не код будут коммитить, а саму платформу создавать.Но по ссылке в указе другая формулировка, да.
Может я конечно чего-то не понимаю, но выглядит как нечто аналогичное этому code.europa.eu
Все боятся того что создав "российский GitHub" доступ к оригинальному закроют. Вряд ли у этого европейского хостинга есть такой мрачный шлейф опасений. Ну и вряд ли он стоил 1.3 млрд (14 млн евро, если что).
Для граждан и их пет-проектов-то есть полно всяких gitflic.ru
Так вы дайте ссылку на эту статью, или ещё лучше, напишите про это статью на хабр. А то выглядит так, что вы ругаетесь с автором по какой-то одной вам ведомой причине.
Мне казалось, надо везде вникать в предметную область. Нужно же понимать, что делает код.
Выглядит так, что для работы с 1с надо уметь держать в голове множество абстракий и зависимостей, уметь отслеживать процесс передачи данных и ход выполнения алогритма. То есть быть опытным разработчиком :)
Это перевод, так что я не могу ответить на этот вопрос. Автор пишет, что цель поста заполнить промежуток между запуском на одной машине и документацией PyTorch где вопрос распределённого обучения обсуждается в широком смысле, так что эксперименты они проводили только на двух машинах.
А вот Rust как раз можно :)
Просто вы пишете, что это -- лучшая идея. А потом сразу же пишете, что это сложно и настройка билда в одном файле [как в Rust] было бы упрощением. На мой взгляд это немного противоречит друг другу.
Как-то вы неожиданным образом перешли от использования скрипта для сборки к подгрузке внешней библиотеки (это какой? crate это не библиотека, он будет вкомпилен в ваш бинарник как составная часть, после компиляции внешним он не будет) через функциональность компилятора. Или чтобы использовать скрипт для сборки надо какую-то внешнюю библиотеку использовать? Нет, не нужно, компилятор это из коробки умеет.
Да, потому что чаще всего декларативного описания хватает. Но если не хватает, то можно и к императивному подходу обратиться. А в Zig сразу императивный, причём вы сначала говорите, что это лучший подход, а потом пишете, что, возможно, Zig перейдет на более простой метод. То есть подход лучший, но не простой? Чем же он тогда лучший?
Методы
type1_addиtype2_addотличаются только тем, в какой класс добавляется точка. Лучше выделить общее в отдельный метод и передавать номер класса через аргументы.Метод
restudyвызывается при добавлении очередной точки. То есть если мы добавим 10 точек, то мы 10 раз переобучим модель. Лучше обучить модель один раз, когда все точки уже добавлены. Не говоря уже о том, что чем больше добавляем точек, тем сложнее обучение и гонять долгий и тяжелый процесс на каждую точку -- очень плохо.Обычно процесс обучения модели называют
fitилиtrain, а неstudy.Ну и наконец, зачем вы используете линейную регрессию для задачи бинарной классификации? Чем не устроила логистическая регрессия, которая как раз для бинарной классификации и предназначена?
Странно выглядит сам процесс обучения. Почему бы не использовать градиентный спуск? Зачем корректировать веса для каждой точки отдельно?
Хеш-функции разные бывают. Те, которые еще называют чексуммами или контрольными суммами, возвращают число 32 или 64 бита и предназначены не для паролей, а для контроля того что данные не испорчены. Некоторые еще позволяют какие-то оишбки исправить. Сюда относятся CRC, Adler-32, MurmurHash и более современный xxhash. Пример применения -- записать в файл архива хеш исходных данных и после распаковки проверить, что распаковали правильно или записать в заголовок пакета, передаваемого по сети, чтобы получатель мог проверить, что данные доехали. Для защиты паролей не имеют смысла. Этими функциями занимаются математика и теория информации.
А есть криптографичесике хеш-функции. Сюда относятся md5 (устарела), sha-1 (устарела), sha-2 (пока не устарела, но осталось недолго), sha-3 (замена sha-2 и пока почти нигде не поддерживается). Их задача обнаружить изменение исходных данных, даже самое минимальное, и при этом минимизировать вероятность коллизии, особенно, умышленной. Их можно (но не нужно) использовать для защиты паролей. Можно использовать для электронной подписи. Считаем такой хеш и подписываем его ассиммитричной криптой. Если хеш не сошелся, значит документ был изменён. Еще их может использовать файловое хранилище для дедупликации. Посчитав такой хеш для файла и проверив по базе, можно понять, есть файл в хранилище или нет, и если есть, то не загружать. Благодаря тому что эти функции специально нацелены на минимизацию коллизий, в целом, вероятностью коллизии можно пренебречь при определенных условиях. Но поскольку мы сжимаем много данных (в случае файлового хранилища файлы могут был размером в гигабайты) в маленькое количество данных (256 бит для sha-256) коллизии все равно возможны. Но благодаря этому мы получаем еще одно свойство -- по хешу невозможно даже примерно получить представление об исходных данных, поэтому, например, практически невозможно понять, как поменять данные, чтобы получить заданных хеш. Еще одно требование к ним -- лавинный эффект, то есть при минимальном изменении исходных данных, хеш должен меняться до неузнаваемости (нельзя, чтобы менялась только часть хеша). Этими функциями занимается криптограция.
Теперь о паролях. Проблема в том, что хеш-функция для одних и тех же данных дает один и тот же хеш. Поэтому если у двух пользователей одинаковый пароль, в базе для них будут записаны одинаковые хеши, что плохо, так как упрощает атаку (можно атаковать одного пользователя и получить пароли от нескольких). Здесь сейчас приняты разные хитрые схемы, например, можно посчитать для кажого пользователя случайный массив байт и объединить его с паролем и хешировать уже результат такого объединения. Здесь можно посмотреть bcrypt.
Есть еще хеш-функции в хеш-таблицах (они же мапы, они же словари, они же ассоциативные массивы, много названий для одного и того же). У них чуть иные требования. Контроль целостности как таковой не нужен. Нужно для одних и тех же данных гарантированного давать один и тот же результат, время расчета должно быть минимальным и при этом разборс значений должен быть довольно велик. Используются для поиска того, в какой бакет (сегмент) ассоциативного массива положить данные или где их искать. Считаться быстро нужно чтобы этот поиск работал моментально, разброс значений нужен чтобы все данные не попали в один сегмент.
Вот это, что ли?
Ну такое себе описание того, как реализовать, больше похоже на утверждение о том что это возможно. И как же реализовать счетчик посещений на файлах? Если что, посещения могут быть одновременными.
Помню, когда учился в Петербургском государственном морском техническом университете к нам приходил представитель верфей с Большого Камня и звал. Я, правда, не судостроитель, а программист, так что нас не звал. Его только проектанты интересовали.
Не заложили. Любая ссылка на вас ничего не стоит и ценности не представляет. Потому что внезапно ссылка на блоги (и даже Хабр) в научных публикациях весом не обладают. Так что ссылаться на вас можно максимум в постах такого же уровня, что и этот. То есть опять-таки, ничего научного не представляющих.
Когда вы пишете научную статью эти правила не работают. Не держите читателя за дурака, он достаточно квалифицирован. Работа должна отражать ваше послание максимально полно. Но не забывайте, что статья должна быть посвящена одному вопросу или в крайнем случае — нескольким, но очень близким.
Это ваша обязанность доказать корректность работы. Собственно, вам в ответе из журнала указали на ваш недочет. Вы его исправили?
Так отразите в своей работе, почему несравнимо меньшая энергия запуска не является проблемой. Рассмотрите этот случай, проработайте его.
И сколько отказов вы собрали? И, конечно, было бы интересно увидеть конкретные формулировки. Мой опыт отказов говорит что там пишут конкретно, что не так.
А в какие вы пытались отправить? И что вам ответили?
Ну, собственно, тут у нас классический случай. Берем некоторую гипотезу, высказанную много-много лет назад (в масштабах науки 30 лет это очень много) и пытаемся ее проверить. Предположим, сошлось.
Тут есть развилка. Либо мы пишем некий текст и пытаемся его опубликовать, либо пытаемся искать другие работы на эту же тему и почему-то не находим. Во втором случае мы просто пропускаем один этап и сразу переходим на этап поиска заговора. Если мы идем первым путем и пишем текст, нам скорее всего откажут в публикации, во многом потому что мы не ученые и просто не знаем, как пишутся научные статьи. Например, было бы здорово ссылаться не на одну гипотезу 30 летней давности, а все же дать ссылки на другие работы по теме, привести источники данных и так далее. Также было бы неплохо отказаться от обиходных оборотов вроде "заставляет задуматься", "Как вам размеры циклонов?" и прочее.
Ну так вот, нам отказали. Здесь опять-таки есть развилка. Мы можем попытаться исправить работу, чтобы пройти дальше по пути рецензирования. Есть, правда, опасность, прийти к выводу о том что гипотеза не верна или найти ее опровержения. Или, скажем, по просьбе рецензента привести свои расчеты, из которых будет видно, что описанного эффекта не наблюдается. Но это наука, случается и ошибиться. Но есть и второй путь. Можно прийти к выводу о том что журнал "контролируется сторонниками СО2-версии глобального потепления", то есть что нашу статью не приняли не потому что мы просто не смогли написаать научную работу, а потому что есть некий заговор по замалчиванию истинной причины вещей. Здесь трудно оказать себе в удовольствии сразиться с мировой закулисой, ведь знание Истины окрыляет.
Итак, мы решили выйти на бой мировой закулисой. Для этого нужно завести сайт, где опубликовать свои выкладки (какая-нибудь соцсеть тоже подойдет) и прийти на Хабр. Автор оба пункта уже выполнил.
P.S. Самое любопытное, что это почти стандартный путь. Вспомните товарища, который пращой пытался космические аппараты запускать или другого товарища, который упругий вакуум исследовал.
Да, я уже заметил. после комента автора про "журнал, который НЕ контролируется сторонниками СО2-версии глобального потепления" стало все понятно.
А почему это опубликовано здесь, а не в рецензируемом профильном журнале?
Не знаю. В посте автора написано
Понятно, что ключевое слово "якобы", но когда речь идет именно в формулировке "российский GitHub" или "замена GitHub" все же представляется именно общедоступная репа, а не только для гос. кода.
Так же из статьи автора:
В такой формулировке выглядит так, что они не код будут коммитить, а саму платформу создавать.Но по ссылке в указе другая формулировка, да.
Все боятся того что создав "российский GitHub" доступ к оригинальному закроют. Вряд ли у этого европейского хостинга есть такой мрачный шлейф опасений. Ну и вряд ли он стоил 1.3 млрд (14 млн евро, если что).
А не-гражданам нельзя? :)