Вместо двумерных массивов прямо-таки напрашиваются таблицы, так что смело можно использовать pandas и орудовать датафреймами. Ну и если уж заниматься анализом данных, то, помимо pandas, также пригодятся библиотеки numpy, scikit-learn, matplotlib, seaborn и т.д. А лучше сразу поставить Anaconda, там уже всё это есть, и графики прямо там (в Jupyter Notebook) можно строить.
Далее идите на биржи ... и пробуйте применить полученные знания на практике. Там есть заказчики, которые готовы ждать и у которых нет завышенных ожиданий. Много они вам не заплатят, но зато вы сможете восстановить подзабытые навыки и улучшить новые.
Неплохой вроде бы совет, но только в теории, а на практике на подобных ресурсах страшный демпинг, да и сама постановка задач заказчиками далека от профессиональной IT-практики.
Спасибо за статью, очень познавательно. В формуле числа итераций, мне кажется, ошибка. Под корнем вместо n (число кубитов) должно быть N/K, где N - число всех возможных состояний и K - число искомых состояний (в примере из статьи это 4), причем эта формула оценочная и только для больших N, а в этом примере можно число итераций посчитать напрямую через угол между гиперплоскостью всех состояний кроме искомых и гиперплоскостью искомых состояний. Если этот угол поставить в формулу (2i + 1)*угол (где i - число итераций), то должно получиться около 90 градусов, для того, чтобы при измерении получались в основном только искомые состояния.
Разработка в целом так устроена, что когда ты недостаточно компетентен — да ничего не произойдет. Ты будешь незамечать кучу проблем, но от них никто не умрет.
Автор в целом прав, но все-таки в истории разработки есть примеры сильных последствий наподобие Therac-25. В наше время такие громкие провалы, конечно, редкость, но и гораздо более безобидные баги все равно могут приводить к неприятным последствиям. Хорошо, если такой разработчик не плодит баги в медицине, но вообще, если перебрать все отрасли, тяжело представить такую сферу, где описанный в статье персонаж не будет изредка приносить мелкий материальный или какой-то ещё ущерб. Разве что в индустрии игр (хотя многие и с этим не согласятся). Статья полезная в том плане, что вдохновляет новичка не быть самозванцем, несмотря на синдром оного.
Небольшая неточность в статье: «Qiskit – это визуальный язык программирования». На самом деле Qiskit — это библиотека Python для квантовых вычислений, в ней используются обычные команды в виде текста (не визуальные). То есть это примерно то же, что и Q#, но с более лаконичным кодом. Видимо, имелся в виду Circuit Composer с quantum-computing.ibm.com — визуальный редактор для квантовых вычислений.
Да, будет цикл статей, но начну, наверное, с квантовых вычислений, а потом, если получится уложиться в формат статей, продолжу про квантовый ML. Спасибо за ссылку!
Квантовую связь не получится в полной мере симулировать, так как это нелокальное взаимодействие, используется квантовая запутанность (в алгоритме квантовой телепортации). Не получится также полноценно симулировать один из методов оптимизации — квантовый отжиг, так как он работает за счет квантового туннелирования. В этих случаях можно только имитировать квантовые вычисления.
По поводу кодирования информации есть разные подходы: Сет Ллойд говорит о кодировании посредством амплитуд или вероятностей, Скотт Ааронсон пишет про использование квантового оракула. Я думаю, это будет постепенно развиваться. А что вы имеете в виду под квантовыми устройствами аналогового характера?
Всё-таки отличие большое: в квантовых вычислениях нет циклов. Помимо того, в квантовых вычислениях возможны алгоритмы, аналогов которым нет в классических компьютерах.
Если интересуют квантовые вычисления для машинного обучения, то могу порекомендовать лекцию Сета Ллойда.
Более подробно эта тема разбирается в курсе Университета Торонто Quantum Machine Learning.
Для квантовых вычислений в Python есть библиотеки qiskit и cirq, в качестве бэкенда можно использовать как симулятор, так и реальный квантовый компьютер (в облаке).
В библиотеке pandas для создания таблиц есть класс DataFrame, он бы для задачи из этой статьи идеально подошел.
Вместо двумерных массивов прямо-таки напрашиваются таблицы, так что смело можно использовать pandas и орудовать датафреймами. Ну и если уж заниматься анализом данных, то, помимо pandas, также пригодятся библиотеки numpy, scikit-learn, matplotlib, seaborn и т.д. А лучше сразу поставить Anaconda, там уже всё это есть, и графики прямо там (в Jupyter Notebook) можно строить.
Это ощутимый минус. Сомневаюсь, что рекрутеры смогли вашу вакансию закрыть, даже несмотря на высокую зарплату.
Неплохой вроде бы совет, но только в теории, а на практике на подобных ресурсах страшный демпинг, да и сама постановка задач заказчиками далека от профессиональной IT-практики.
Спасибо за статью, очень познавательно.
В формуле числа итераций, мне кажется, ошибка. Под корнем вместо n (число кубитов) должно быть N/K, где N - число всех возможных состояний и K - число искомых состояний (в примере из статьи это 4), причем эта формула оценочная и только для больших N, а в этом примере можно число итераций посчитать напрямую через угол между гиперплоскостью всех состояний кроме искомых и гиперплоскостью искомых состояний. Если этот угол поставить в формулу (2i + 1)*угол (где i - число итераций), то должно получиться около 90 градусов, для того, чтобы при измерении получались в основном только искомые состояния.
И еще по поводу слова "кубит" - оно склоняется по падежам (https://ru.wiktionary.org/wiki/кубит):
Автор в целом прав, но все-таки в истории разработки есть примеры сильных последствий наподобие Therac-25. В наше время такие громкие провалы, конечно, редкость, но и гораздо более безобидные баги все равно могут приводить к неприятным последствиям. Хорошо, если такой разработчик не плодит баги в медицине, но вообще, если перебрать все отрасли, тяжело представить такую сферу, где описанный в статье персонаж не будет изредка приносить мелкий материальный или какой-то ещё ущерб. Разве что в индустрии игр (хотя многие и с этим не согласятся). Статья полезная в том плане, что вдохновляет новичка не быть самозванцем, несмотря на синдром оного.
Да, будет цикл статей, но начну, наверное, с квантовых вычислений, а потом, если получится уложиться в формат статей, продолжу про квантовый ML. Спасибо за ссылку!
Я ещё забыл упомянуть генерацию случайных чисел. На классическом компьютере это псевдослучайные числа, на квантовом — настоящие случайные числа.
По поводу кодирования информации есть разные подходы: Сет Ллойд говорит о кодировании посредством амплитуд или вероятностей, Скотт Ааронсон пишет про использование квантового оракула. Я думаю, это будет постепенно развиваться. А что вы имеете в виду под квантовыми устройствами аналогового характера?
Мне кажется, CS в итоге разделится на две ветки: будет классический CS и квантовый.
Всё-таки отличие большое: в квантовых вычислениях нет циклов. Помимо того, в квантовых вычислениях возможны алгоритмы, аналогов которым нет в классических компьютерах.
Да, скорее речь идёт о квантовом параллелизме.
Более подробно эта тема разбирается в курсе Университета Торонто Quantum Machine Learning.
Для квантовых вычислений в Python есть библиотеки qiskit и cirq, в качестве бэкенда можно использовать как симулятор, так и реальный квантовый компьютер (в облаке).