Большое количество вопросов поставлено некорректно. Либо мало данных, либо поставлен слишком широко. Например:
Напишите функцию, которая определяет количество шагов для преобразования одного слова в другое
И в ответе сразу "наша функция должна принимать на вход 3 аргумента". Откуда я об этом знать должен? Задание сформулировано так, что как будто даётся только слово "до" и слово "после" (и при этом ещё не сказано, что подразумевается под "преобразованием" ) Ну и зачем нужны такие вопросы в рамках подготовки?
Вы баллотируетесь на пост, в выборке из 100 избирателей 60 будут голосовать за вас. Можете ли вы быть уверены в победе?
Нет (см. gerrymandering). На вопрос ответил? Ответил. Но это совсем не то, что в предполагаемом правильном ответе. Надо чётче формулировать .
Ну и отдельно отмечу вопросы из серии
Как построить простую модель логистической регрессии на Python?
Где в коде ответа фигурирует
from sklearn.linear_model import LogisticRegression
Браво! Прямо-таки чистый Python!
Хотя чего это я, судя по корявой терминологии, это просто плохой перевод какой-то другой статьи:
Понял, спасибо за ответ. Не знал про политику W^X, спасибо что просветили. В последний раз когда я делал что-то под Android, там ещё был Dalvik, который JiT, а не AoT.
Получается, что на мобилках мы вообще никогда не увидим гомоиконичных языков, если так всё будет продолжаться?
Обилие скобочек? Это же не лисп, их тут немного. Вы точно видели код на Julia? Если приведёте пример кода с обилием скобочек, будет очень интересно посмотреть)
Уговоры о близости синтаксиса не срабатывают
Это к Mojo, Julia не пытается быть Python
Так что, объективно, с этой стороны поддержки не будет
Очень сомнительно, учитывая отличную поддержку в Julia автоматического дифференцирования за счёт метапрограммирования. Фреймворки автоматического дифференцирования на Python в принципе могут справиться далеко не со всем
И я с ним согласен. Ноутбуки Pluto очень классные. У юпитера всё хуже с повторяемостью, и нет такой интерактивности (ну или я не знаю о таких фишках там)
Развлекаться с Джулией - это скорее делать из неё stand alone application
Ну это уж точно то ещё развлечение. А вообще, покажите хоть один интерпретируемый язык, где с этим не будет проблем.
Насколько бы мне ни нравилась Julia, для скриптинга она подходит очень так себе. С точки зрения производительности надо избегать глобальных переменных, лучше всё оборачивать в функции. А это немного не кейс скриптов, как мне кажется. Ну и первый запуск кода обычно не слишком быстрый, т.к. сперва происходит компиляция кода в IR. Поэтому будет чувствоваться медленным
Вот то, что надо постоянно гонять - на джулии самое то писать. Всякие расчёты и т.д. За счёт выразительности языка проще будет писаться. Это язык для научных вычислений и он таким сделан неспроста)
Возник тот же самый вопрос. Особенно учитывая что автор - к.т.н., значит знаком с тем, что такое научный журнал и как надо публиковаться. А так публикация очередного "прорыва" на хабре, а не в предназначенном для этого месте, скорее вызывает скепсис.
Прочитав "символьное программирование", почему-то подумалось что будет что-то про математическую оптимизацию, которая так же называется "математическое программирование". Уж больно там формулировки похожие: линейное, нелинейное, квадратичное, дискретное, целочисленное и т.д., и всё программирования. Тем более, что символьные вычисления там очень даже используются.
Касательно самой статьи: спасибо, интересно, но ничего кардинально нового не увидел (впрочем, чего ещё ожидать от языка 30+ летней давности). Сейчас есть языки и поинтересней. В той же Julia можно и традиционными символьными вычислениями заниматься (на базе символов), так и то же самое проделывать с кодом (привет лисп). Плюс метчинг на базе системы типов через multiple dispatch. Можно сделать всё то же самое, что здесь, и даже больше, да ещё и быстрее.
Может я не понимаю вашего гения, но оптимизатор то у вас Adam. Оптимизатор стохастический.
Какой смысл тогда в построении поверхности при различных значениях параметров, и её дальнейшем анализе? Ведь если вы ещё раз попробуете построить эту поверхность, у вас будут совершенно другие результаты
Согласен. Rust уж очень сильно от питона отличается и требует другой квалификации.
Если и переходить, то на Julia переходить. Писать можно в питоновском стиле (и даже лучше), а производительность будет такая же, как на rust. Это если number-crunching'ом заниматься
Не хватает вам кругозора относительно классических алгоритмов машинного обучения)
Вы взяли проблему, которая уже решена методом опорных векторов (SVM), и придумали использовать метрический метод классификации, распространив наиболее банальное решение (даже проще kNN) на сетку в пространстве параметров.
Если бы вы докрутили свою мысль до конца, то пришли бы к тому же SVM, или чему-то похожему. Ход мысли примерно такой: есть много вариантов разделяющей гиперплоскости - надо сравнить их - придумать метрику, характеризующую качество разделения (чтобы она не была одинаковой для разных вариантов решения, зависела не только от ошибки) - максимизировать эту метрику.
Напоследок, картинка про SVM с тем самым margin, который следовало бы придумать автору (w).
Такие "скрытые" и "малоизвестные" библиотеки, что у каждой не меньше 8 тысяч звёзд на гитхабе, ага
Большое количество вопросов поставлено некорректно. Либо мало данных, либо поставлен слишком широко.
Например:
И в ответе сразу "наша функция должна принимать на вход 3 аргумента".
Откуда я об этом знать должен? Задание сформулировано так, что как будто даётся только слово "до" и слово "после" (и при этом ещё не сказано, что подразумевается под "преобразованием" )
Ну и зачем нужны такие вопросы в рамках подготовки?
Нет (см. gerrymandering).
На вопрос ответил? Ответил. Но это совсем не то, что в предполагаемом правильном ответе.
Надо чётче формулировать .
Ну и отдельно отмечу вопросы из серии
Где в коде ответа фигурирует
Браво! Прямо-таки чистый Python!
Хотя чего это я, судя по корявой терминологии, это просто плохой перевод какой-то другой статьи:
правдоподобия
многопроцессное
Это как вообще?
Ну, то есть изначально было ясно, что мнение не изменится)
Спасибо за честность
Понял, спасибо за ответ.
Не знал про политику W^X, спасибо что просветили. В последний раз когда я делал что-то под Android, там ещё был Dalvik, который JiT, а не AoT.
Получается, что на мобилках мы вообще никогда не увидим гомоиконичных языков, если так всё будет продолжаться?
Обилие скобочек? Это же не лисп, их тут немного. Вы точно видели код на Julia?
Если приведёте пример кода с обилием скобочек, будет очень интересно посмотреть)
Это к Mojo, Julia не пытается быть Python
Очень сомнительно, учитывая отличную поддержку в Julia автоматического дифференцирования за счёт метапрограммирования. Фреймворки автоматического дифференцирования на Python в принципе могут справиться далеко не со всем
Не согласен. Интерпретируемый по умолчанию, с возможностью сборки в бинарник. Или что тут имелось в виду?
И поэтому не очень понимаю вот эту часть.
Тот же Kivy тащит за собой рантайм (хоть и в сокращённом виде), без этого никак. На Джулии тоже такое возможно, есть даже StaticCompiler.jl
Я скорей поверю, что Джулия на мобилках пока просто не требуется, поэтому её и нет)
И я с ним согласен. Ноутбуки Pluto очень классные. У юпитера всё хуже с повторяемостью, и нет такой интерактивности (ну или я не знаю о таких фишках там)
Ну это уж точно то ещё развлечение. А вообще, покажите хоть один интерпретируемый язык, где с этим не будет проблем.
Насколько бы мне ни нравилась Julia, для скриптинга она подходит очень так себе.
С точки зрения производительности надо избегать глобальных переменных, лучше всё оборачивать в функции. А это немного не кейс скриптов, как мне кажется.
Ну и первый запуск кода обычно не слишком быстрый, т.к. сперва происходит компиляция кода в IR. Поэтому будет чувствоваться медленным
Вот то, что надо постоянно гонять - на джулии самое то писать. Всякие расчёты и т.д.
За счёт выразительности языка проще будет писаться. Это язык для научных вычислений и он таким сделан неспроста)
Возник тот же самый вопрос. Особенно учитывая что автор - к.т.н., значит знаком с тем, что такое научный журнал и как надо публиковаться.
А так публикация очередного "прорыва" на хабре, а не в предназначенном для этого месте, скорее вызывает скепсис.
Прочитав "символьное программирование", почему-то подумалось что будет что-то про математическую оптимизацию, которая так же называется "математическое программирование". Уж больно там формулировки похожие: линейное, нелинейное, квадратичное, дискретное, целочисленное и т.д., и всё программирования. Тем более, что символьные вычисления там очень даже используются.
Касательно самой статьи: спасибо, интересно, но ничего кардинально нового не увидел (впрочем, чего ещё ожидать от языка 30+ летней давности). Сейчас есть языки и поинтересней. В той же Julia можно и традиционными символьными вычислениями заниматься (на базе символов), так и то же самое проделывать с кодом (привет лисп). Плюс метчинг на базе системы типов через multiple dispatch. Можно сделать всё то же самое, что здесь, и даже больше, да ещё и быстрее.
Понятно.
Пора уже что-то такое вводить хабру. Далеко не первая статья по тематике
Я так и не понял, почему статья попала в хаб "машинное обучение". Нет тут его
Может я не понимаю вашего гения, но оптимизатор то у вас Adam. Оптимизатор стохастический.
Какой смысл тогда в построении поверхности при различных значениях параметров, и её дальнейшем анализе? Ведь если вы ещё раз попробуете построить эту поверхность, у вас будут совершенно другие результаты
Согласен. Rust уж очень сильно от питона отличается и требует другой квалификации.
Если и переходить, то на Julia переходить. Писать можно в питоновском стиле (и даже лучше), а производительность будет такая же, как на rust. Это если number-crunching'ом заниматься
Нет в статье ничего ни про Машинное обучение, ни про ИИ. Это уже вторая такая статья от вас. Не засоряйте людям ленту
Не хватает вам кругозора относительно классических алгоритмов машинного обучения)
Вы взяли проблему, которая уже решена методом опорных векторов (SVM), и придумали использовать метрический метод классификации, распространив наиболее банальное решение (даже проще kNN) на сетку в пространстве параметров.
Если бы вы докрутили свою мысль до конца, то пришли бы к тому же SVM, или чему-то похожему. Ход мысли примерно такой: есть много вариантов разделяющей гиперплоскости - надо сравнить их - придумать метрику, характеризующую качество разделения (чтобы она не была одинаковой для разных вариантов решения, зависела не только от ошибки) - максимизировать эту метрику.
Напоследок, картинка про SVM с тем самым margin, который следовало бы придумать автору (w).
Во-во, та же самая мысль возникла. Там ровно то, что нужно автору. Если смотреть линейный вариант, то там как раз поиск максимального margin'а.
Приведённая книжка просто ужасна. Сборник неразрешённых комплексов и проблем.
Специально для этого в ChatGPT сделают watermark, чтобы можно было не обучаться на собственном аутпуте
Про то, что с новым M2 Pro и Max написали, а что это за звери - не написали.
Ну ничего же не понятно(