Еще раз спасибо, что напомнили. Только что установил текущую версию. Действительно с тех пор, как я последний раз запускал Максиму - там довольно много изменений произошло. Посмотрел документацию и приятно удивился сколько всего там есть. Интерфейс тоже порадовал своей аутентичностью. А еще я вспомнил, что мне там действительно очень понравилось - это то, что графики строятся в gnuplot
Wolfram Language - это уже не система компьютерной алгебры. В плане набора функций Maxima находится слишком далеко от Wolfram Language. Пользовательский интерфейс Максимы тоже не обладает той функциональностью Mathematica, о которой я писал в статье и концепцию которой мы сумели воспроизвести. Я пользовался максимой примерно 8 лет назад и может быть с тех пор многое изменилось, но в не кажется нельзя было редактировать output и пользоваться хотя бы отдалено похожим «синтаксическим сахаром» как в WL. Но я могу ошибаться. Я обязательно поставлю текущую версию и посмотрю что там изменилось. Спасибо вам за комментарий и напоминание
Насколько я знаю уже миллионы лет человек и его предки являются социальными организмами и следовательно эволюционировали все это время в обществе. В результате наш мозг лучше всего адаптирован к взаимодействию с другими членами общества и намного хуже работает если ему нужно разбираться в чем-то точном и техническом. Мы очень хорошо видим эмоции других, понимаем по выражению лица, глаз где опасность а где нет и так далее. Еще одним следствием является то, что любое необъяснимое являете человек стал наделять личностью, так как тогда можно сказать что явление тоже как член общества обладает своим характером и поведением, которое свойственно другим членам общества. А тогда явление становится более понятным и его можно объяснить. В итоге все это превратилось в религию. Так как вместо попыток найти рациональное объяснение тому что например ветер дует - человек просто сказал что у ветра такой характер и он дует потому что хочет. А дальше по индукции. Стало можно объяснить все необъяснимое. Так и появилась религия. Кстати у животных тоже есть религия. Точнее признаки религии и того что у них есть вера в высшие силы. Так вот… Из-за невероятного количества технологий, языков, методик и фреймворков уже стало невозможно запомнить как все они работают и тут подключаются те самые механизмы когда мы начинаем наделять личностью уже технологии а затем превращать их в духов и божества
Я понял в чем дело. Почему-то в определенный момент текст, который в блоке с кодом перестал считаться редактором как те 1500 символом разрешенные для постов. В итоге я отредактировал и сократил текст поста
Я не специалист и может быть не правильно понял терминологию, но в статье слишком уж сильно обобщены выводы. В заголовке написано про торговлю с плечом, по первой ссылке проведено исследование только на фьючерсном рынке, а далее в статье приводится сравнение с инвесторами, которые купили не торгуют или торгую с низкой активностью. В итоге общий вывод - спекуляции всегда убыточны. На мой взгляд этой статье не хватает точности.
Я думаю, что среди всех, кто прочитал эта статью до конца не наберется 204 человека (на данный момент), которые прошли бы какой-то курс от GeekBrains. Скорее всего многие голосовали основываясь на общем впечатлении, а не только анализируя хороший ли конкретно тот курс, который они проходили или нет. Поэтому, думаю ответ на ваш вопрос будет скорее да, чем нет. Вы, скажем так, "познакомились" с Яндекс Практикум. То, что вы не нашли курс, рекламу которого встретили, можно отметить как минус курсов в целом, а не только самих материалов. Я добавлю еще про Яндекс Практикум, чтобы пояснить мое отношение ко многим курсам. Меня в Яндекс Практикум приглашали в качестве ментора на один из курсов. В итоге работу ментором мне не предложили, так как была довольно большая конкуренция и я ее не прошел, но я прошел короткое обучение "как быть ментором в Яндекс Практикуме". Тренеры, которые проводят все эти подготовки менторов открыто говорят или акцентируют свое внимание на том, что главная задача ментора в том, чтобы удержать студента на этих курсах. Зачем? Затем чтобы он продолжал платить. Даже если он не хочет больше учиться - то нужно с ним попытаться обсудить проблемы и уговорить его, чтобы он взял "академический отпуск". т.е. чтобы не просто бросил курс, а подумал и потом вернулся. Да, это очевиднейшая мысль, но она говорит об общем корпоративном духе среди менторов, составителей и преподавателей этих курсов. Они могли бы говорить менторам, что самое главное, чтобы студент получил знания и с их помощью смог закончить курс, но увы нет. Менторам прямым текстом говорят, что главное чтобы студент платил. Ведь много тех, кто начав и заплатив начинают сомневаться или разочаровываются или понимают, что вообще-то практически все, что дают на курсах можно довольно легко найти в открытом доступе.
В комментариях пишут, что голосование неправильно или вообще бессмысленно приводя множество аргументов, в числе которых как и разница в трафике и в числе студентов. Я тоже хотел бы высказать свое мнение.
Во-первых, здесь некого защищать. Тему голосования можно было бы переименовать в "топ самых надоедливых курсов". Так было бы даже правильнее. Голосующие выбирают Skillfactory или Skillbox в том числе потому что их уровень маркетинга этого заслуживает.
Во-вторых, на мой взгляд, для справедливости можно было бы устроить голосование в два этапа, если бы первый этап прошел успешно. Сначала устроить голосование по теме "выберите курсы с которыми знакомы/проходили/считаете хорошими", а во второй статье уже голосование за худшие курсы. И тогда для одного и того же курса соотношение тех кто считает курс хорошим или знает о нем показало бы какой процент в среди остальных он занимает, а разделив этот процент на процент тех, кто считает курс худшим можно было бы получить условный безразмерный рейтинг.
На счет того, как генерируются руки и конечности. Меня тут заставили нарисовать сначала кошечку - я нарисовал только голову и получилось ровно и узнаваемо. Потом нужно было нарисовать собачку. Я решил ее сделать в профиль в полный рост и голова получилось нормально, а вот ноги очень криво. Очень естественно, что для человека конечности рисовать сложнее. Для нейросети видимо так же
Есть бесплатный Wolfram Engine - это полная реализация языка Wolfram и единственное отличие это отсутствуют UI из Mathematica. При этом можно легко добавить Wolfram Engine в качестве ядра для Jupyter Notebooks. Либо пользоваться из консоли. Код при этом можно писать в Wolfram Workbench или пользуясь расширениями для VS Code и других редакторов кода, но для VS Code есть официальное расширение. Ну и самое главное - есть бесплатный Wolfram Cloud в браузере.
Я пользовался Mathics и первое на что я обратил внимание - к сожалению она не поддерживает полностью синтаксис языка Wolfram. Хотя на тот момент говорилось что это именно его открытая реализация. В тот момент даже UpSetDelayed к сожалению не поддерживался. Ну и плюс быстродействие было примерно в 10-30 раз ниже.
А вообще отличная статья и напоминание про язык Wolfram (ведь Mathics реализует именно его), спасибо вам!
Добрый день! Очень интересная библиотека, спасибо за статью. Хочу предложить решение этой же задачи, которое основано на предложении в первом абзаце "Метаться в поисках другого инструмента? Тоже вариант". Решение в Wolfram Cloud:
Очень часто вместо ввода пути к файлу в элемент .//input[@type='file'] загрузка происходит при помощи JS. На элемент другого типа вешается событие при срабатывании которого открывается системное окно, а затем скрипт загружает файл на сервер. Какой в этом случае верный способ загрузить файл без изменения кода страницы или поиска нужного скрипта? На каждой странице может быть свой скрипт.
OsipovRoman, большое спасибо за статью! Она действительно очень полезная и практичная!
К пункту 1.2
В этом совете основной посыл состоит в том, что надо использовать функциональную парадигму при необходимости применить функцию к списку. Однако, показанный эффект ускорения достигается совершенно не этим. Дело в том, что в случае с Map[#^2&, data] ускорения достигается благодаря комбинации чистая функция + встроенный цикл + упакованный массив, когда Математика встречает такую конструкцию, то применяет автокомпиляцию, которая и дает ускорение. Соответственно если использовать "шаблонную" функцию + цикл + упакованный массив — автокомпиляция не используется. И в конкретно этом случае применение Map/Table не даст разницы во времени выполнения.
Также на скриншоте видно, что нет разницы между использование чистой функции в полной записи Function[x, x^2] и в короткой #^2&. Действительно разница во времени вычисления есть при применении любой функции к неупакованному массиву при помощи Map и Table. Table проигрывает в этом случае и это не зависит от того, чистая была функция или шаблонная.
К пункту 1.4
На мой взгляд сравнение проведено некорректно. Опять же в заголовке сказано про процедурный стиль, но эффект, который дает такую разницу во времени заключается в другом. Первая операция выполнялась медленно не из-за While, а из-за медленной операции вставки. Так как списки в Математике неизменяемы, то вставка нового элемента всегда происходит с пересозданием списка целиком. Зная это тот же самый код можно переписать вот так:
Т.е. здесь заранее создается массив на 20000 целых чисел, а затем заполняется. И как теперь видно проблема была не в цикле While. Хотя без сомнения код на скриншоте не самый идеологически хороший. А что касается ускорения во втором случае — здесь была использована рекурсия с мемоизацией. Для человеческого глаза это понятнее, также не создается никаких дополнительных списков, куда надо вставлять значения и ничего не перепутать. Однако этот способ сохраняет все 20000 значений в определении. Поэтому, например, повторный вызов f /@ Range[20000] вообще должен выполнится за нулевое время, но в итоге выполнится за константное время, которое требуется на получение списка значений из памяти:
Тогда как результат в виде списка чисел Фибоначчи при повторном использовании будет взят из памяти мгновенно, так как это одна переменная, которая ссылается на один большой массив.
К пункту 3.2
Здесь мне хочется добавить, что использовать Parallelization -> True и Listable отдельно не имеет никакого смысла. Эти две опции (как показывают эксперименты) дают эффект ускорения только при совместном использовании. Я думаю популярное слово "параллелизация" введет читателей в заблуждение. Она есть, но применяется исключительно при применении к списку аргументов. Соответственно список делится на равные части по числу процессорных ядер и функция вызывается на каждом ядре попеременно для всех элементов. Если передавать один аргумент — этого эффекта не будет. Т.е. вот так cfunc[{1, 2, 3, 4}] — функция вычислит значение на каждом ядре отдельно, а вот так: {cfunc[1], cfunc[2], cfunc[3], cfunc[4]} уже нет. И еще одно замечание: fJITCompiledListable — определение этой функции не соответствует заявленному, потому что в нем по умолчанию будет также Parallelization -> True. Чтобы функция принимала на вход список и к каждому элементу применялась на одном ядре необходимо принудительно указывать False. На скриншоте ниже показано, что использование двух опций отдельно эквивалентно их отсутствию, если оценивать по скорости. И только комбинация опций дает ускорение в число раз равное количеству ядер:
Еще одним способом ускорить скомпилированную функцию является возможность оптимизации выражений, когда повторяющиеся части выражения вычисляются только один раз. Например в коде ниже это x^2:
Чтобы убедиться в том, что повторяющиеся части выражения действительно были заменены посмотрим на "псевдобайткод" скомпилированных функций:
И последнее про компиляцию при помощи Compile. Не всякое выражение будет скомпилировано. Существует определенный список валидных функций, которые можно использовать в выражениях внутри Compile. Посмотреть на него можно вот так:
Needs["Compile`"]
Compile`CompilerFunctions[]
Еще одной тема, которой не хватает для полноты картины и раскрытия компиляции в Wolfram Language — это экспериментальные функции в версии Wolfram Language 12.0: FunctionCompile, KernelFunction и связанные с ними. На мой взгляд одним из преимуществ данных функций является возможность более строгого указания типов входных аргументов и типа результата, а также добавлена возможность безболезненно использовать вызов встроенной функции ядра Математики внутри скомпилированной.
Спасибо всем, кто дочитал этот комментарий и очень надеюсь, что кому-то поможет это небольшое дополнение по теме компиляции выражений в Wolfram Language.
нам хотелось бы держаться как можно дальше от множества вариантов рекламных уловок
Очень иронично, что в статье про это сказано, а OsipovRoman добавляет свою рекламу в переводе статьи сделанном нанятыми переводчиками в корпоративном блоге компании, в которой он не работает.
Статья немного похоже на воззвание «Почему же, черт возьми, меня, такого замечательного, никто не любит?»
Абсолютно согласен с этим, хотя может быть сам Стивен Хьюгович и не пытался вкладывать такой посыл, но получилось похоже. Данная статья вышла относительно давно и на самом деле эта новость уже освещалась на хабре, хоть и юридически это был перевод другой статьи-конспекта.
С базами данных тоже не все очевидно – в реальном проекте почти наверняка понадобятся данные которых в языке нет. Какому проценту разработчиков может пригодиться база населения городов мира? В научном проекте – безусловно, подобные базы очень полезны. Но в разработке обычного ПО их польза сомнительна.
Думаю все же наличие любых встроенных баз данных, которые загружаются с серверов Wolfram Research — это лучше чем их полное отсутствие. Допустим их даже не применить в специфическом проекте, но в конце концов где-то на сайте компании есть описание возможности использовать свои собственные базы данных точно таким же способом как и встроенные. Но этот способ конечно же стоит отдельных денег, что сразу закономерно снижает интерес. Ибо эта схема реализуется при покупке приватного облака и загрузки данных в него.
Второе (и главное) – даже для собственного некоммерческого использования я должен получить на сайте временную лицензию и зарегистрировать продукт через интернет. А судя по фразе «В отличие от Mathematica, он не лицензирован для генерации результатов для коммерческого или организационного использования.» — я даже прав на результаты полученные дома не имею.
Не гарантирую точность, так как и сам не до конца понял лицензионное соглашение, но для личного использования можно получить бесплатно один раз для одного аккаунта постоянную лицензию, но уже невозможно использовать где-либо еще, что опять же очень плохо. И если я правильно интерпретировал фразу про использование результатов, то имеетя ввиду именно продажа, но, наверное, в научной работе их вполне можно использовать.
Используя эту технологию, я должен убедить руководство закупить лицензии для всех потенциальных пользователей (соответственно уменьшив маржу нашего продукта, возможно в разы), причем даже неизвестно на каких условиях (вначале сделайте продукт, а мы потом подумаем сколько с вас за него взять). Плюс еще получить проблемы с лицензированием каждого клиента.
Это на мой взгляд проблема даже больше чем сама по себе стоимость для разработчика. Полное отсутствие возможности пользоваться готовыми решениями для массового пользователя. Есть конечно Wolfram Player (Ранее CDF Player), который совсем бесплатен, но его функционал сильно урезан, да и все что он может делать по сути — просматривать красивые подготовленные презентации. Установка Wolfram Player — это отдельная история. Когда браузеры еще поддерживали такие расширения — думаю пользователи уже тогда не хотели устанавливать Adobe Flash Player, на который требуется 2 минуты и чуть-чуть свободного места, после чего он находится где-то в тени браузера, тогда как Wolfram Player весит больше гигабайта и его необходимо специально запускать, так как в качестве расширения браузера он тоже больше не поддерживается.
Первый – выход на массовый рынок пойдя по пути игровых движков: предлагать бесплатную базовую версию, в том числе для коммерческого использования, но только при обороте менее заданной суммы (как Unity, 100 тыс. $ в год), при превышении оборота – ставить серьезный ценник для разработчиков. С конечных пользователей не брать денег совсем, даже упоминания не требовать. Иначе о массовости можно забыть.
Второй – оставаться в собственной нише «умного» вычислительного инструмента, для хобби проектов и научных исследований. Честно признать, что это не «язык программирования», а продвинутая система запросов к базе, обычное ПО с соответствующей системой лицензирования. По сути, все та же «Mathematica» только с базой побольше.
Также абсолютно согласен с обоими предложениями. В данный момент Wolfram Research делает не очень быстрые шаги в сторону бесплатного использования и разработки, как будто пробует почву — об этом говорит и бесплатный (в том числе для коммерческого использования но с сильными ограничениями по ресурсам) Development Platform и Wolfram Player и совсем свежий Wolfram Engine, который кстати можно прикрутить к jupyter notebook. На мой взгляд можно также использовать и еще один путь, похожий на первый, предложенный вами. Это сделать полностью бесплатной для любого типа использования минимальную версию ядра, которая бы весила значительно меньше чем Wolfram Engine. Пусть эта версия содержала бы основной язык, работу с сетью, файловой системой, примитивную графику и что-то еще подобное, а за отдельную плату предоставлять доступ к встроенным базам, тренировочным данным для машинного обучения, серверам, запланированным задачам и прочему. Тогда можно было бы добиться легкого распространения как среди разработчиков, так и среди пользователей. К сожалению такой вариант малореалистичен из-за того, что с самого начала Wolfram Mathematica проектировалась с тесной интеграцией всех модулей, библиотек и пакетов друг с другом, а по итогу безболезненно разделить их уже не получится.
Сам я конечно же фанат языка Wolfram и всегда буду за то, чтобы он получал все большее распространиние в среде разработки ПО, политика компании-разработчика вселяет оптимизм, но в действительности пока что это происходит очень медленно и с постоянными ограничениями.
Не является программистом и не будет ничего писать на компилируемых языках, ему изначально удобнее работать в Математике чтобы анализировать данные.
На счет того, что закомментированно — для этого надо просто иметь подходящий Си-компилятор подходящей версии, я сделал так, чтобы те, кто хочет код просто скопировать/вставить не встретили ошибку без него. По подключению есть подробный гайд, где перечислены поддерживаемые компиляторы. В среднем эта опция давала ускорение еще в 1.5-2 раза:
Превратить этого бота в интерпретатор Mathematica еще проще. Просто заменить: answer[text_String]["answer"] := ToString[ToExpression[text]]
И все команды, которые должны возвращать текстовый результат будут работать. Отдельно нужно реализовать команды, которые возвращают график через sendPhoto. Тоже самое для аудио-файла или видео/анимации. Я хотел обратить особое внимание на возможность развертывания в облаке — тогда не требуется запускать отдельный процесс или докер-контейнер на компьютере или сервере.
Еще раз спасибо, что напомнили. Только что установил текущую версию. Действительно с тех пор, как я последний раз запускал Максиму - там довольно много изменений произошло. Посмотрел документацию и приятно удивился сколько всего там есть. Интерфейс тоже порадовал своей аутентичностью. А еще я вспомнил, что мне там действительно очень понравилось - это то, что графики строятся в gnuplot
Wolfram Language - это уже не система компьютерной алгебры. В плане набора функций Maxima находится слишком далеко от Wolfram Language. Пользовательский интерфейс Максимы тоже не обладает той функциональностью Mathematica, о которой я писал в статье и концепцию которой мы сумели воспроизвести. Я пользовался максимой примерно 8 лет назад и может быть с тех пор многое изменилось, но в не кажется нельзя было редактировать output и пользоваться хотя бы отдалено похожим «синтаксическим сахаром» как в WL. Но я могу ошибаться. Я обязательно поставлю текущую версию и посмотрю что там изменилось. Спасибо вам за комментарий и напоминание
Насколько я знаю уже миллионы лет человек и его предки являются социальными организмами и следовательно эволюционировали все это время в обществе. В результате наш мозг лучше всего адаптирован к взаимодействию с другими членами общества и намного хуже работает если ему нужно разбираться в чем-то точном и техническом. Мы очень хорошо видим эмоции других, понимаем по выражению лица, глаз где опасность а где нет и так далее. Еще одним следствием является то, что любое необъяснимое являете человек стал наделять личностью, так как тогда можно сказать что явление тоже как член общества обладает своим характером и поведением, которое свойственно другим членам общества. А тогда явление становится более понятным и его можно объяснить. В итоге все это превратилось в религию. Так как вместо попыток найти рациональное объяснение тому что например ветер дует - человек просто сказал что у ветра такой характер и он дует потому что хочет. А дальше по индукции. Стало можно объяснить все необъяснимое. Так и появилась религия. Кстати у животных тоже есть религия. Точнее признаки религии и того что у них есть вера в высшие силы. Так вот… Из-за невероятного количества технологий, языков, методик и фреймворков уже стало невозможно запомнить как все они работают и тут подключаются те самые механизмы когда мы начинаем наделять личностью уже технологии а затем превращать их в духов и божества
Я сначала подумал, что пост Король Разработки написал
Я понял в чем дело. Почему-то в определенный момент текст, который в блоке с кодом перестал считаться редактором как те 1500 символом разрешенные для постов. В итоге я отредактировал и сократил текст поста
Я не знаю почему, но после публикации пропадает код из одного блока с кодом. В пустом блоке должно быть вот это:
Я не специалист и может быть не правильно понял терминологию, но в статье слишком уж сильно обобщены выводы. В заголовке написано про торговлю с плечом, по первой ссылке проведено исследование только на фьючерсном рынке, а далее в статье приводится сравнение с инвесторами, которые купили не торгуют или торгую с низкой активностью. В итоге общий вывод - спекуляции всегда убыточны. На мой взгляд этой статье не хватает точности.
Я думаю, что среди всех, кто прочитал эта статью до конца не наберется 204 человека (на данный момент), которые прошли бы какой-то курс от GeekBrains. Скорее всего многие голосовали основываясь на общем впечатлении, а не только анализируя хороший ли конкретно тот курс, который они проходили или нет. Поэтому, думаю ответ на ваш вопрос будет скорее да, чем нет. Вы, скажем так, "познакомились" с Яндекс Практикум. То, что вы не нашли курс, рекламу которого встретили, можно отметить как минус курсов в целом, а не только самих материалов.
Я добавлю еще про Яндекс Практикум, чтобы пояснить мое отношение ко многим курсам. Меня в Яндекс Практикум приглашали в качестве ментора на один из курсов. В итоге работу ментором мне не предложили, так как была довольно большая конкуренция и я ее не прошел, но я прошел короткое обучение "как быть ментором в Яндекс Практикуме". Тренеры, которые проводят все эти подготовки менторов открыто говорят или акцентируют свое внимание на том, что главная задача ментора в том, чтобы удержать студента на этих курсах. Зачем? Затем чтобы он продолжал платить. Даже если он не хочет больше учиться - то нужно с ним попытаться обсудить проблемы и уговорить его, чтобы он взял "академический отпуск". т.е. чтобы не просто бросил курс, а подумал и потом вернулся. Да, это очевиднейшая мысль, но она говорит об общем корпоративном духе среди менторов, составителей и преподавателей этих курсов. Они могли бы говорить менторам, что самое главное, чтобы студент получил знания и с их помощью смог закончить курс, но увы нет. Менторам прямым текстом говорят, что главное чтобы студент платил. Ведь много тех, кто начав и заплатив начинают сомневаться или разочаровываются или понимают, что вообще-то практически все, что дают на курсах можно довольно легко найти в открытом доступе.
В комментариях пишут, что голосование неправильно или вообще бессмысленно приводя множество аргументов, в числе которых как и разница в трафике и в числе студентов. Я тоже хотел бы высказать свое мнение.
Во-первых, здесь некого защищать. Тему голосования можно было бы переименовать в "топ самых надоедливых курсов". Так было бы даже правильнее. Голосующие выбирают Skillfactory или Skillbox в том числе потому что их уровень маркетинга этого заслуживает.
Во-вторых, на мой взгляд, для справедливости можно было бы устроить голосование в два этапа, если бы первый этап прошел успешно. Сначала устроить голосование по теме "выберите курсы с которыми знакомы/проходили/считаете хорошими", а во второй статье уже голосование за худшие курсы. И тогда для одного и того же курса соотношение тех кто считает курс хорошим или знает о нем показало бы какой процент в среди остальных он занимает, а разделив этот процент на процент тех, кто считает курс худшим можно было бы получить условный безразмерный рейтинг.
На счет того, как генерируются руки и конечности. Меня тут заставили нарисовать сначала кошечку - я нарисовал только голову и получилось ровно и узнаваемо. Потом нужно было нарисовать собачку. Я решил ее сделать в профиль в полный рост и голова получилось нормально, а вот ноги очень криво. Очень естественно, что для человека конечности рисовать сложнее. Для нейросети видимо так же
Есть бесплатный Wolfram Engine - это полная реализация языка Wolfram и единственное отличие это отсутствуют UI из Mathematica. При этом можно легко добавить Wolfram Engine в качестве ядра для Jupyter Notebooks. Либо пользоваться из консоли. Код при этом можно писать в Wolfram Workbench или пользуясь расширениями для VS Code и других редакторов кода, но для VS Code есть официальное расширение. Ну и самое главное - есть бесплатный Wolfram Cloud в браузере.
Я пользовался Mathics и первое на что я обратил внимание - к сожалению она не поддерживает полностью синтаксис языка Wolfram. Хотя на тот момент говорилось что это именно его открытая реализация. В тот момент даже UpSetDelayed к сожалению не поддерживался. Ну и плюс быстродействие было примерно в 10-30 раз ниже.
А вообще отличная статья и напоминание про язык Wolfram (ведь Mathics реализует именно его), спасибо вам!
Добрый день! Не до конца понятны условия задачи. Все найденные числа должны быть в одних и тех же множествах? Что если множество такое:
{{1, 2}, {2, 3}, {3, 4}}Здесь выходит, что 2 есть в первом и втором векторе, а 3 во втором и третьем. Ну и мое решение на Wolfram
Всегда мечтал дожить до дня когда к нам прилетит ufo
Добрый день! Очень интересная библиотека, спасибо за статью. Хочу предложить решение этой же задачи, которое основано на предложении в первом абзаце "Метаться в поисках другого инструмента? Тоже вариант". Решение в Wolfram Cloud:
Очень часто вместо ввода пути к файлу в элемент
.//input[@type='file']загрузка происходит при помощи JS. На элемент другого типа вешается событие при срабатывании которого открывается системное окно, а затем скрипт загружает файл на сервер. Какой в этом случае верный способ загрузить файл без изменения кода страницы или поиска нужного скрипта? На каждой странице может быть свой скрипт.OsipovRoman, большое спасибо за статью! Она действительно очень полезная и практичная!
К пункту 1.2
В этом совете основной посыл состоит в том, что надо использовать функциональную парадигму при необходимости применить функцию к списку. Однако, показанный эффект ускорения достигается совершенно не этим. Дело в том, что в случае с
Map[#^2&, data]ускорения достигается благодаря комбинации чистая функция + встроенный цикл + упакованный массив, когда Математика встречает такую конструкцию, то применяет автокомпиляцию, которая и дает ускорение. Соответственно если использовать "шаблонную" функцию + цикл + упакованный массив — автокомпиляция не используется. И в конкретно этом случае применение Map/Table не даст разницы во времени выполнения.Также на скриншоте видно, что нет разницы между использование чистой функции в полной записи
Function[x, x^2]и в короткой#^2&. Действительно разница во времени вычисления есть при применении любой функции к неупакованному массиву при помощи Map и Table. Table проигрывает в этом случае и это не зависит от того, чистая была функция или шаблонная.К пункту 1.4
На мой взгляд сравнение проведено некорректно. Опять же в заголовке сказано про процедурный стиль, но эффект, который дает такую разницу во времени заключается в другом. Первая операция выполнялась медленно не из-за While, а из-за медленной операции вставки. Так как списки в Математике неизменяемы, то вставка нового элемента всегда происходит с пересозданием списка целиком. Зная это тот же самый код можно переписать вот так:
Т.е. здесь заранее создается массив на 20000 целых чисел, а затем заполняется. И как теперь видно проблема была не в цикле While. Хотя без сомнения код на скриншоте не самый идеологически хороший. А что касается ускорения во втором случае — здесь была использована рекурсия с мемоизацией. Для человеческого глаза это понятнее, также не создается никаких дополнительных списков, куда надо вставлять значения и ничего не перепутать. Однако этот способ сохраняет все 20000 значений в определении. Поэтому, например, повторный вызов
f /@ Range[20000]вообще должен выполнится за нулевое время, но в итоге выполнится за константное время, которое требуется на получение списка значений из памяти:Тогда как результат в виде списка чисел Фибоначчи при повторном использовании будет взят из памяти мгновенно, так как это одна переменная, которая ссылается на один большой массив.
К пункту 3.2
Здесь мне хочется добавить, что использовать Parallelization -> True и Listable отдельно не имеет никакого смысла. Эти две опции (как показывают эксперименты) дают эффект ускорения только при совместном использовании. Я думаю популярное слово "параллелизация" введет читателей в заблуждение. Она есть, но применяется исключительно при применении к списку аргументов. Соответственно список делится на равные части по числу процессорных ядер и функция вызывается на каждом ядре попеременно для всех элементов. Если передавать один аргумент — этого эффекта не будет. Т.е. вот так
cfunc[{1, 2, 3, 4}]— функция вычислит значение на каждом ядре отдельно, а вот так:{cfunc[1], cfunc[2], cfunc[3], cfunc[4]}уже нет. И еще одно замечание: fJITCompiledListable — определение этой функции не соответствует заявленному, потому что в нем по умолчанию будет также Parallelization -> True. Чтобы функция принимала на вход список и к каждому элементу применялась на одном ядре необходимо принудительно указывать False. На скриншоте ниже показано, что использование двух опций отдельно эквивалентно их отсутствию, если оценивать по скорости. И только комбинация опций дает ускорение в число раз равное количеству ядер:Еще одним способом ускорить скомпилированную функцию является возможность оптимизации выражений, когда повторяющиеся части выражения вычисляются только один раз. Например в коде ниже это x^2:
Чтобы убедиться в том, что повторяющиеся части выражения действительно были заменены посмотрим на "псевдобайткод" скомпилированных функций:
И последнее про компиляцию при помощи Compile. Не всякое выражение будет скомпилировано. Существует определенный список валидных функций, которые можно использовать в выражениях внутри Compile. Посмотреть на него можно вот так:
Еще одной тема, которой не хватает для полноты картины и раскрытия компиляции в Wolfram Language — это экспериментальные функции в версии Wolfram Language 12.0: FunctionCompile, KernelFunction и связанные с ними. На мой взгляд одним из преимуществ данных функций является возможность более строгого указания типов входных аргументов и типа результата, а также добавлена возможность безболезненно использовать вызов встроенной функции ядра Математики внутри скомпилированной.
Спасибо всем, кто дочитал этот комментарий и очень надеюсь, что кому-то поможет это небольшое дополнение по теме компиляции выражений в Wolfram Language.
Очень иронично, что в статье про это сказано, а OsipovRoman добавляет свою рекламу в переводе статьи сделанном нанятыми переводчиками в корпоративном блоге компании, в которой он не работает.
Оставлю дополнение к вашему комментарию.
Абсолютно согласен с этим, хотя может быть сам Стивен Хьюгович и не пытался вкладывать такой посыл, но получилось похоже. Данная статья вышла относительно давно и на самом деле эта новость уже освещалась на хабре, хоть и юридически это был перевод другой статьи-конспекта.
Думаю все же наличие любых встроенных баз данных, которые загружаются с серверов Wolfram Research — это лучше чем их полное отсутствие. Допустим их даже не применить в специфическом проекте, но в конце концов где-то на сайте компании есть описание возможности использовать свои собственные базы данных точно таким же способом как и встроенные. Но этот способ конечно же стоит отдельных денег, что сразу закономерно снижает интерес. Ибо эта схема реализуется при покупке приватного облака и загрузки данных в него.
Не гарантирую точность, так как и сам не до конца понял лицензионное соглашение, но для личного использования можно получить бесплатно один раз для одного аккаунта постоянную лицензию, но уже невозможно использовать где-либо еще, что опять же очень плохо. И если я правильно интерпретировал фразу про использование результатов, то имеетя ввиду именно продажа, но, наверное, в научной работе их вполне можно использовать.
Это на мой взгляд проблема даже больше чем сама по себе стоимость для разработчика. Полное отсутствие возможности пользоваться готовыми решениями для массового пользователя. Есть конечно Wolfram Player (Ранее CDF Player), который совсем бесплатен, но его функционал сильно урезан, да и все что он может делать по сути — просматривать красивые подготовленные презентации. Установка Wolfram Player — это отдельная история. Когда браузеры еще поддерживали такие расширения — думаю пользователи уже тогда не хотели устанавливать Adobe Flash Player, на который требуется 2 минуты и чуть-чуть свободного места, после чего он находится где-то в тени браузера, тогда как Wolfram Player весит больше гигабайта и его необходимо специально запускать, так как в качестве расширения браузера он тоже больше не поддерживается.
Также абсолютно согласен с обоими предложениями. В данный момент Wolfram Research делает не очень быстрые шаги в сторону бесплатного использования и разработки, как будто пробует почву — об этом говорит и бесплатный (в том числе для коммерческого использования но с сильными ограничениями по ресурсам) Development Platform и Wolfram Player и совсем свежий Wolfram Engine, который кстати можно прикрутить к jupyter notebook. На мой взгляд можно также использовать и еще один путь, похожий на первый, предложенный вами. Это сделать полностью бесплатной для любого типа использования минимальную версию ядра, которая бы весила значительно меньше чем Wolfram Engine. Пусть эта версия содержала бы основной язык, работу с сетью, файловой системой, примитивную графику и что-то еще подобное, а за отдельную плату предоставлять доступ к встроенным базам, тренировочным данным для машинного обучения, серверам, запланированным задачам и прочему. Тогда можно было бы добиться легкого распространения как среди разработчиков, так и среди пользователей. К сожалению такой вариант малореалистичен из-за того, что с самого начала Wolfram Mathematica проектировалась с тесной интеграцией всех модулей, библиотек и пакетов друг с другом, а по итогу безболезненно разделить их уже не получится.
Сам я конечно же фанат языка Wolfram и всегда буду за то, чтобы он получал все большее распространиние в среде разработки ПО, политика компании-разработчика вселяет оптимизм, но в действительности пока что это происходит очень медленно и с постоянными ограничениями.
Вы имеете ввиду, что она никому не нужна? Я встречал множество задач и примеров, где требовались различные оптимизации. Вот где это использовал я сам:
github.com/KirillBelovTest/CustomImportExport
В коде пакета есть функции для работы с данными SEG-Y и они как раз таки являются скомпилированными. А пользователь, задавший вопрос здесь:
community.wolfram.com/groups/-/m/t/1272436
Не является программистом и не будет ничего писать на компилируемых языках, ему изначально удобнее работать в Математике чтобы анализировать данные.
На счет того, что закомментированно — для этого надо просто иметь подходящий Си-компилятор подходящей версии, я сделал так, чтобы те, кто хочет код просто скопировать/вставить не встретили ошибку без него. По подключению есть подробный гайд, где перечислены поддерживаемые компиляторы. В среднем эта опция давала ускорение еще в 1.5-2 раза:
reference.wolfram.com/language/CCompilerDriver/tutorial/SpecificCompilers.html
answer[text_String]["answer"] := ToString[ToExpression[text]]И все команды, которые должны возвращать текстовый результат будут работать. Отдельно нужно реализовать команды, которые возвращают график через sendPhoto. Тоже самое для аудио-файла или видео/анимации. Я хотел обратить особое внимание на возможность развертывания в облаке — тогда не требуется запускать отдельный процесс или докер-контейнер на компьютере или сервере.