Викилоги

Продолжим тему Blog:Advanced Algorithms/Python-оптимизация алгоритма динамического программирования из codechef.

Итак, снова решение, которое вроде как работает, но не проходит по времени и жалобы, что питон плохой «Получаю TimeLimit в системе. Мне кажется, это связано с тем, что использую питон и в решении очень много численных операций а так как в питоне используются BigInteger BigFloats, то решение замедляется».

Первая версия

Видимо легкий перебор, три вложенных цикла (три цикла, что-то дофига, причем явно с зависимостью от длины входа — не к добру), что-то считается, что-то отбирается по максимуму…, суммируется, отбирается по минимуму — типичный жадный алгоритм.

Cмотрим описание задачи Codechef/CHEFSTR2, даже сразу переходим по ссылке на разбор и разъяснение.

Разьяснение немного мутное, и мутность там даже зачем-то подмешивается во входные данные (вторая строчка входа не нужна).

Но суть простая, есть строка, хотим из нее сделать какую-то повторяющуюся подстроку меньшего размера, можем менять символы и добавлять к концу произвольные, но нужно минимизировать число таких операций.

Вот, нарисовал картинку в терминах исходной версии программы:

Мы можем попробовать делать циклы из подстрок разной длины («ind»), повторяющиеся разное число раз «ks», чтобы получилась строка, нужной длины или чуть длиннее (не больше чем на «ind»).

Рассмотрим строку «ABCABCAB».

Если делать цикл из одного символа («ind=1, ks=8»), то на «пути» (красным) надо посчитать частоты символов, выбрать самый частый (пусть он остается), остальные поменять на него — оптимальное жадное решение. Тут можно выбрать «А» или «B» и получить или . Сколько операций переименования-добавления? Это будет «len» символов новой строки с повторами, минус те символы, которых мы не переименуем («ok», три символа «A» или «B»). Будет 5 операций. (Если оставлять «C», то их будет 6, не подоходит).

Если делать цикл из двух символов («ind=2, ks=4»), то у нас уже возникают «красный» и «синий» путь — пути для первого и второго символа, на этих путях должны быть одинаковые символы, они совсем независимы, надо на каждом пути посчитать какой символ наиболее часто встречается, и переименовать все остальные в него.

На красном пути — самый частый → «A», на синем → «B». Значит, на «красном» пути оставим «A», остальных переименуем в него, на «синем» → «B». На обоих путях одинаково число оставляемых символов «ok1=2», «ok2=2» → число операций

ops = len - ok1 - ok2 = 8 - 2 - 2 = 4

Если делать цикл из трех символов («ind=3, ks=3»), то у нас уже возникают «красный», «синий» и зеленый пути — пути от первого, второго и третьего символа … … обратите внимание, что зеленый путь выходит за пределы исходной строки, т.е. один символ по любому придется добавить, ведь длина зацикленной строки «len = ks*ind = 9» больше длины исходной строки («8»).

На красном пути — самый частый → «A», на синем → «B», на зеленом → «С» Значит, на «красном» пути оставим «A», остальных переименуем в него, на «синем» → «B», на зеленом → «С».

ops = len - ok1 - ok2 - ok3 = 9 - 3 - 3 - 2 = 1

…

можно продолжать дальше, в разъяснении написано, почему «ind» не обязательно перебирать до исходной длины строки, идея понятна, у меня кончились красивые цвета для путей.

Разумеется, из всех вариантов циклов с разной длинной надо будет выбрать тот, где «ops» — минимально.

Итак, поехали. Пишем генератор тестовой строки

import random
import string
 
print(''.join((random.choice(string.ascii_letters).lower() for i in range(16000))))
print(1)

генерим «big-sample-04.txt» на 16K символов, берем референсный CPP-код из разъяснения, компилируем.

  gcc -o good good.cpp -lstdc++ -g

$ time good < big-sample-04.txt
7671 2

real    0m47.380s
user    0m46.872s
sys     0m0.053s

Работать будем сразу с PyPy3, не будем тащить numpy, какие-нибудь хитрые модули подсчета, и даже не будем использовать Counter из collections, хотя он сюда и напрашивается.

$ time pypy3 chefstr2.py  < big-sample-04.txt
7671 2

real    0m26.806s
user    0m26.286s
sys     0m0.104s

26.2 секунды.

Вау, забавно. Это решение вроде как копия референсного на CPP, а на PyPy работает быстрее. Но по TL не проходит!

Нет, пока чудес не бывает. Компилим CPP код с оптимизацией

gcc -o good good.cpp -lstdc++ -O3

и после этого наконец-то сишное решение показывает скорость:

$ time good < big-sample-04.txt
7671 2

real    0m1.968s
user    0m1.947s
sys     0m0.006s

Итак, правильное решение знаем, можем проверить, есть куда стремится по скорости. Первое, что напрягает — зачем нам тут модуль «math», вещественные числа (ересь! у нас тут честная комбинаторика). Только для того, чтобы округлять вверх? Это можно делать не выходя из целых чисел.

Делаем такие правки и получаем версию работающую за 24.5 — чуть лучше.

Для очистки совести уберем хардкод на 26 символов и прочтем входную строку через sys.readline — 26.6 стало даже чуть хуже, но вроде это более надежный ввод, если запускать на серверах кодечифа.

Что еще напрягает? Ну вот зачем такие глубокие косвенности:

 frequency[symbols[(input_str[j])]]

• Давайте сразу переведем строку в байт-массив индексов символов, и будем работать с ним → 13.7 — почти в два раза!

• Давайте не уныло обнулять вектор частот, а сразу выделять новый забитый нулями → 13.1.

• Попытка поставить более вероятную ветку в первый «if» не помогла → 13.1.

• А вот континтуитивное — заменяем стандартный поиск максимального элемента на корявое поддержание «максимальной текущей частоты» → 9.3. Тут выигрыш скорее всего за счет того, что на «длинных путях» у нас массив частот становится разряженным, и максимальную частоту дешевле считать так, чем бегать по всему массиву.
• А может, если у нас чувствуется разряженность, перейти с списка частот на хеш? → 13.4. Не помогает, стало хуже.

Пора подумать внимательно, зачем нам так много нужно вложенных циклов.

• Внешний цикл по длинам подстрок — ладно, пусть остается.
• А два внутренних — по сути, подсчет «частот символов на разноцветных путях», и расчет из этого количества операций. Давайте заменим это на один цикл, по самой строке (вернее по массиву индексов символов), и для каждого индекса, будем решать, частоту какого символа (из «lenalf» символов) и на каком «пути» (из «ind» возможных путей) он увеличивает. Заводим списки векторы frequency — по сути, двухмерный массив, который моделируем одномерным списком, и массив max_frequency → 9.1 удивительно! Выигрыш есть, но совсем небольшой. А ведь еще мы память тратим, но вроде тут она бесплатна^[1].
• От огорчения убрал sys и вернул input — не повлияло.

Пробуем загрузить решение в СС → увы, TL

Ночь, хочеться спать.... и тут оживают Дьявольские Советы Черного Программиста → стоит подумать — а в чем практическая задача нашего кода?

Пройти приемочные испытания! Показать себя хорошо на реальных входных данных. Будут ли среди них такие плохие данные, ради которых стоит перестраховываться и увеличивать перебор? (по сути, можно считать, мы исследуем переход к вероятностным алгоритмам или «эффективности для почти всех исходных данных»).

• Подкручиваем-уменьшаем перебор! — и наше решение подходит, даже с хорошим запасом!

Возможно конечно когда-нибудь в этой задаче дополнят тест-сет, и это решение не пройдет… так что оставим как челлендж на «отл» (при условии, что есть «одна теоретическая задача») →

• сделать питон решение (без машинных кодов), которое проходит тесты, но перебирет все циклы до 0.75*n
  • ну либо обосновать, что действительно, можно опустить верхнюю оценку максимальной длины цикла в переборе.

Челледж на «хор» → подобрать входные данные, на которых вот это решение даст неправильный результат.

1. ↑ Не надо так весело разбрасываясь памятью оптимизировать в продакшне реальных проектов, если действительно этот размен не будет оправдан!

При разборе ваших решений, столкнулся с одной из попыток, с результатом «вроде все сделано правильно, но система не пропускает, наверно что-то не так с системой или вообще питон не потянет, вот на плюсах все решают и все хорошо».

Попробую кратко показать, как можно системно поработать с улучшением решения, даже не особо вьезжая в алгоритм (ну при условии, что идея будет правильна).

Первая версия digprime.py

Видим вроде типичный алгоритм ДП, смотрим описание задачи Codechef/DIGPRIME, переходим по ссылке Editorial на разбор и разъяснение задачи, но даже если этой ссылки не будет, смотрим список принятых решений:

Берем из них любое принятое CPP-решение, сохраняем его в файл digprime-good.cpp компилируем его

 gcc -g -o digprime-good digprime-good.cpp -lstdc++

Итак, у нас есть референсное решение.

Смотрим на описание задачи, особенно на секцию «ограничения»…

и пишем примитивных генератор «digprime-generate.py», такой, чтобы задействовать все ограничения (вдруг все проходит на минимальных данных, но где-то что-то переполняется на самых крайних случаях), плюс большой тестсет даст возможность разумно измерять время работы.

import numpy as np
num = 100000
print(num)
for t in range(num):
    print(np.random.randint(1,1000000000000000000))

Генерим наш тестовый набор:

python digprime-generate.py > big-samples.txt

Генерим результаты нашего алгоритма и референсной реализации на тех же входных данных:

digprime-good < big-samples.txt > reference-good.txt
python digprime.py < big-samples.txt > big-our-results.txt

Сравниваем («meld», «winmerge», «fc», ) — используйте то, что ставится на вашу ось и есть под рукой, но в данном случае, совпадение добайтовое даже по ответу «md5sum»:

md5sum big-our-results.txt
  e602cd2d36e9c6749764cace13774bdc  big-our-results.txt

md5sum reference-good.txt
  e602cd2d36e9c6749764cace13774bdc  reference-good.txt

Вроде же все в абсолютном порядке, но что выдает codechef?

Ошибка «NZEC» — «какая-то ошибка», увы, без малейших подсказок на чем, и что за ошибка. Но по времени работы — доли секунды, предположим, что что-то сразу с вводом.

Тут на самом деле наблюдались разные проблемы в этих (codechef, spoj) тестовых системах. То что-то не так с буферизацией, и какой-то перевод строки становился пробелом, или длинная строка, и input() не вычитывал ее до конца, то большое количество операций input, а там перенаправление на чтение из файла, много IO операций, срабатывают какие-то контейнерные ограничения или просто будет тормозить.

Поэтому, лучше сразу сделать чтение типа

    lines = sys.stdin.readlines()
    content = " ".join(lines).strip()

А потом парсить и отдавать результаты генератором.

Делаем такие правки и получаем

версию, которая работает абсолютно также по результату, возможно чуть медленней перекопированием ввода в память (если померять у себя), но возможно быстрее, чем у них на сервере, с задушенным IO.

В любом случае, сначала надо избавиться от NZEC, потом уже заниматься оптимизацией.

Ага, от NZEC уже избавились, но теперь здравствуй TL.

Может если перейти на PYPY, скомпилируется и пройдет?

Увы, нет.

Обращаю внимание — 10.01 и 4.01 секунды это не время работы программы! Это только таймлимиты (плюс сколько мгновений, пока программу не убили), которые выделены питону (Python 3.6) и скомпилированному питону (PYPY).

Хотя обычному питону дается фора, в 2.5 раза времени, выигрыш PYPY обычно бывает больше. Есть конечно минусы PYPY — в нем нет numpy, удобных многомерных массивов и эффективных матричных операций, есть модуль «array», который иногда полезен… но в нашем случае, попробуем обойтись без всего этого, используя обычные питоновые списки-вектора, структуры, которые были изначально.

А вот что необходимо — начать замерять время выполнения (экзаменационная система вам не поможет — там только да или нет), и профилировать выполнение.

У меня древний десктоп нулевых годов, цифры могут отличатся от ваших, если вы повторяете эксперименты, плюс у вас будут другие входные данные, но буду приводить свои данные. Обычная linux утилита time, где нужно смотреть только «user time» нам вполне подойдет.

time python digprime.py < big-samples.txt > big-our-results.txt

real    1m8.108s
user    1m6.412s
sys     0m0.351s

time pypy3 digprime.py < big-samples.txt > big-our-results.txt

real    0m4.519s
user    0m4.143s
sys     0m0.143s

Впечатляющая разница? Но нам увы, недостаточно.

Давайте посмотрим, что «жрет». Всегда можно сделать стандартное профилирование (разумная сортировка по общезатраченному времени «-s cumulative»)

python -m cProfile -s cumulative digprime.py < big-samples.txt >profile-results.txt

Что видно — огромное количество (43.5M) рекурсивных вызовов функции «calculate», ну и еще там где-то зря дергаются лишний раз «len()».

Начинаем оптимизировать, учитываем пропущенную эвристику^[1], делаем правку, получаем версию, для которой

CPython time → 41.203s
Pypy time → 2.722s
Вызовов calculate → 26874678

Уберем кстати, хардкодинг, число цифр в константу.

делаем правку, получаем версию, для которой

CPython time → 40.610s
Pypy time → 2.749s
Вызовов calculate → 26874678

(ничего интересного не достигли)

Введем глобальную переменную N c длиной текущего числа, уберем перерасчитывание высчитывание длины внутри функции.

… делаем правку, получаем версию, для которой …

CPython time → 37.117s
Pypy time → 2.907s
Вызовов calculate → 26874678

… чуть ускорили обычный питон, где байткода такие вещи не оптимизирует, но скомпилированный PyPy лучше не стал.

Потом в коде видим странные штуки типа «taken | (x == 2) | (x == 3) | (x == 5) | (x == 7)» — ох тыж, считается «бинарное или» вместо логического, а ведь в везде «логическое или» оптимизируется слева направо, т.е. если левый операнд уже «истина», то дальше ничего считать не надо.

… делаем правку, получаем версию, для которой …

CPython time → 24.413s
Pypy time → 2.907s
Вызовов calculate → 26874678

Большой прорыв по обычному питону, но PyPy3 об этом похоже, догадался сам, тут не помогло.

Небольшие правки, вроде убираем ненужные требования о преобразованиях типов

… делаем правку, получаем версию, для которой …

… если и есть экономия, то копеечная.

Пора заняться важным, оптимизацией хвостовой рекурсии.

Мы видим, что в рекурсивной функции, в самом начале у нас куча эвристик по выходу из этой функции… так может ее сразу не вызывать в рекурсивных вызовах? А в первом вызове они не сработают.

Начинаем, переносить каждое условие по одному

… делаем правку, получаем версию, для которой …

… экономия начинает появлятся, хотя во времени на уровне колебаний измерения, но вот количество рекурсивных вызовов уменьшилось:

CPython time → 24.718s
Pypy time → 2.413s
Вызовов calculate → 25324715

Переносим «эвристику с десятками»

… делаем правку, получаем версию, для которой …

радикально уменьшились рекурсивные вызовы (хотя внутри функции теперь больше работы), но время тоже падает

CPython time → 21.763s
Pypy time → 2.270s
Вызовов calculate → 11972222

Переносим «кеширование DP»

… делаем правку, получаем версию, для которой …

радикально уменьшились рекурсивные вызовы (хотя внутри функции теперь больше работы), но время тоже падает

CPython time → 17.762s
Pypy time → 2.099s
Вызовов calculate → 3477870

Явно улучшилось!

Да, тут многое чешеться еще улучшить, но пора попробовать, вдруг уже пройдет → ура, проходит!

Да, тут многое можно было написать красивей^[2], очень желательны комментарии для будущих читателей кода… но для целей иллюстрации, как оптимизировать питоновский код, думаю, достаточно, чтобы не перегружать статью!

Удивительно, что один из наших студентов решил эту задачу на на CPython, хотя это конечно хак, запускать питоном чистый ассемблер! Не надо так делать в наших задачах, лучше подумать над алгоритмом, но всеже тема интересная и попробуем написать про такой подход статью-заметку.

1. ↑ что когда у нас «230» → то на второй цифре можно сразу вернуть число десятков, не перебирая глубже
2. ↑ жалко, что пришлось вставлять лишний парсинг входа, с точки зрения чистых алгоритмов это конечно хак, хотя в любом случае это читаемый код, а не С++шный «лишбыработало» [1], [2])

Так делать не надо:

• Leetcode/minimum-cost-to-cut-a-stick — испорчена задача, не питон, сколько уже можно объяснять.

• Литкодовские должны решаться.
  • Участник:Hakob/chef and strings
  • Участник:Hakob/longest-polindromic-substring

• Codechefские скорее да, но надо смотреть. Spoj-могут быть проблемны.
  • Участник:Hakob/prime-digits

• Профилирование

python -m cProfile -s cumulative mycode.py < bigcase.txt  >profile.log

• Отладка в VSCode

       {
           "name": "mycode",
           "type": "python",
           "request": "launch",
           "program": "mycode.py",
           "console": "integratedTerminal",
           "justMyCode": true,
           "args": ["<", "mycode.txt"]
       },

• Категория:На_проверку

• Розыгрыш «хор»-зачета за баллы.
• Двойной выигрыш → «отл»

• Логинимся сюда
• Потом кликаем на https://discopal-lab.0x1.tv/auth/oauth1?target=%2Fauth%2Fsign-in
  • Соглашаемся со всем там.
  • Вы должны оказаться залогинены в https://discopal-lab.0x1.tv

• • Потом пройдите по ссылке- приглашению в проект «coding-tasks»
  • Потом откроем совместную сессию и покодим.

• • Потом пройдите по ссылке- приглашению в проект «lectures-notebooks»

Если что не получилось — посмотрите, там дальше ссылка с видео

• Lab

• Категория:На_проверку

Поразбираем:

• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота

Так делать не надо:

• Codechef/NPLELE
• Codechef/SPECTAC

Поразбираем:

• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота

• Категория:На_проверку

Розыгрыш «хор»-зачета за баллы.

• Логинимся сюда
• Потом кликаем на https://discopal-lab.0x1.tv/auth/oauth1?target=%2Fauth%2Fsign-in
  • Соглашаемся со всем там.
  • Вы должны оказаться залогинены в https://discopal-lab.0x1.tv
  • Потом пройдите по ссылке приглашению в проект «coding-tasks»
  • Потом откроем совместную сессию и покодим.

Если что не получилось — посмотрите, там дальше ссылка с видео

• Lab

• Категория:На_проверку
• «Отл» за 5 задач из Spoj/Codechef (не LeetCode) + одна теоретическая
• «Хор» за 3 задачи из Spoj/Codechef (не LeetCode).

• Логинимся сюда
• Потом кликаем на https://discopal-lab.0x1.tv/auth/oauth1?target=%2Fauth%2Fsign-in
  • Соглашаемся со всем там.
  • Вы должны оказаться залогинены в https://discopal-lab.0x1.tv
  • Потом пройдите по ссылке приглашению в проект «coding-tasks»
  • Потом откроем совместную сессию и покодим.

Если что не получилось — посмотрите, там дальше ссылка с видео

• Lab

• Категория:На_проверку
• «Отл» за 5 задач из Spoj/Codechef (не LeetCode) + одна теоретическая
• «Хор» за 3 задачи из Spoj/Codechef (не LeetCode).

Кому скучно:

• Blog:Advanced Algorithms/2021-11-15 Research Block

Поразбираем:

• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота

• Логинимся сюда
• Потом кликаем на https://discopal-lab.0x1.tv/auth/oauth1?target=%2Fauth%2Fsign-in
  • Соглашаемся со всем там.
  • Вы должны оказаться залогинены в https://discopal-lab.0x1.tv
  • Потом пройдите по ссылке приглашению в проект «coding-tasks»
  • Потом откроем совместную сессию и покодим.

Если что не получилось — посмотрите, там дальше ссылка с видео

• Lab

• Категория:На_проверку
• «Отл» за 4 задачи из Spoj/Codechef (не LeetCode).
• «Хор» за 3 задачи из Spoj/Codechef (не LeetCode).

Кому скучно:

• Blog:Advanced Algorithms/2021-11-15 Research Block

Поразбираем:

• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота

• Категория:На_проверку

Решения задач — ищем решения именно на Python! «4 из 6» колонок чтобы были накрыты (некоторые задачи могут накрыть две колонки — две темы.

• User:Nechda — не на C++.

• «Отл» за 3 задачи из Spoj/Codechef (не LeetCode).
  • До сих пор открыто после будет за 4 задачи.

Кому скучно:

• Blog:Advanced Algorithms/2021-11-15 Research Block
• Lab

Поразбираем:

• Leetcode/split-array-largest-sum
• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота
• LiveShare не работает?

• Категория:На_проверку

Решения задач — так держать!

• User:Aleksei_Volkov

«отл» автоматом для тех, кому не лень

• Участник:Shishqa/codechef/MRS
  • Хорошая техника ускорения питона — I/O
  • Не жалко → Участник:Shishqa/Spoj/PRMFN
• Участник:Fckxorg/RANAGIC

• Участник:Aleksei Volkov/longest turbulent subarray — DP

• «Отл-автоматом» — теперь, при условии хотя бы одной теорзадачи.
• Эта неделя → «Отл» за 3 задачи из Spoj/Codechef.

• Spoj — Browsec.
• https://www.youtube.com/channel/UC81Q2wnuk5KqOFVgAbq4nUw — разбор задач.

• Полиномиальные сводимости и NP-полные задачи. Классы NP, coNP, NPC/Полнота

Просмотрел несколько видеопрезентаций по юпитер-ноутбукам.

• Часто встречается паттерн «свалка кода сбоку» в рядом лежащих питон-файлах, в ноутбуке только интерфейс к какому-нибудь простому интерфейсу. Это конечно, не то, что хотелось бы.
  • Почему это плохо?
  • Такой ноутбук «не работает» как передача знаний, он бесполезен, он не лучше, чем кусок кода, ибо все равно
    • разбирающемуся придется реинженирить код, его функциональные связи, что там и что означает…
    • такой ноутбук не «расшарить» в colab.research.google.com или cocalc.com (там всегда плохо на тему шаринга рядом лежащих файлов).
    • он не работает как презентация-пояснение-живой плейграунд («а что если тут поменять XXX»?).
• Посмотрите реально примеры и разбор из Blog:Advanced Algorithms/2021-12-01 Как делать лучше jupyter по статьям
  • Последовательно вводите понятия, каждая питон функция в отдельной ячейке, в ячейке перед ней — описание, в ячейке после нее — примеры вызова с характерными данными.
  • Не бойтесь, если будет длинно — никогда не жалейте места для лишних слайдов или ячеек в ноутбуках — в зависимости от аудитории, слайды-ячейки можно пропустить, зато гарантирует, что хоть кто-то разберется в теме (включая вас, такой рефакторинг для научного ресерча — самый эффективный способ найти проблему).
• Вот пример неплохого доклада вашего однокурсника → https://youtu.be/XeZTpQWTDUU (ноутбук)
  • При записи доклада, разумно использовать какой-нибудь экранный аннотатор (рисовалку), на худой конец, поставьте курсор побольше, это поможет.
  • В идеале — добавляйте вебкамеру и научится хромакею. Учитывая, что защита в этом году будет скорее всего дистанционная — хороший повод потренироваться записывать себя, чтобы потом вырезать неудачное, остальное ускорить, и потом прокрутить на защите идеально выведенный по таймлимиту ролик защиты (на вопросы подключится живьем).
• По срокам — я выторговал в деканате до 25го декабря, но лучше не задерживать до последнего момента.

StasFomin 13:56, 20 декабря 2021 (UTC)

• Продолжение темы Blog:Advanced Algorithms/2021-11-15_Research_Block
• [1]

→ продолжить чтение…

Концептуально:

• Это на «отл»
• Win-Win!
• Моделирование диплома-научной работы и ее защиты.
• глобальная проблема воспроизводимости + https://paperswithcode.com/ → мы помогаем решать.

• Свежие статьи на относительно знакомые темы
• Надо «воспроизвести»
• Юпитер-ноутбук или SageWorksheet или …
• Наш сервис — https://discopal-lab.0x1.tv
  • Почему наш?
  • https://colab.research.google.com — хорошая альтернатива, но
  • все теряется, сложно собрать все времесте.
  • только ядро Python (нет R/Sage/… возможно у нас будет Coq и т.п.)
  • Почему не jupyterlab или jupyterhub — нет коллаборации.

• • Почему не cocalc.com — стал хотеть денех.

• Введение будет отдельно
  • Но разобраться что есть юпитер-ноутбук можно и самостоятельно

• Доступ к https://discopal-lab.0x1.tv (логин/емейл-пароль) получите лично (почта или тг)
  • Как только пройдете более простые квесты (по задачам и тестам).

• Резервируем статью
  • Открытые статьи для разбора
  • Примерно как с было задачами
• Выбирайте из Открытые статьи для разбора, переходите к редактированию по «Беру…» →
  • • помечайте их как {{reserve-task|~~~~~}}
    • «Зарезервированные статьи» убираются в Зарезервированные практические задачи
  • Только одна статья! Но максимально качественно!
• Заводите в discopal-lab.0x1.tv проект.
  • Правильно загрузить туда PDF статьи (на всякий случай).
  • И что еще.
  • И делайте юпитер-ноутбук, sage-лист и что еще.

• Полностью «переписывать статью не надо»
  • Разобраться в введении
  • Воспроизвести максимально декомпозировав, основной алгоритм.
  • Доказательства не нужны.
  • «Модель»-«Алгоритм»

• Если что не получается — пингуйте.
  • Можно конечно
    • Работать с локальным Jupyter
    • Использовать colab
    • Но регулярно перегружайте в discopal-lab — чтобы я видел прогресс, и мог комментировать-корректировать.

• Как что получится.
  • Научитесь пользоваться OBS — (см. также [1]), попробуйте использовать экранное рисование ([2]) и сделать это живым и доступным.
  • Запишите видео-презентацию и забросьте мне (unlisted youtube, файлохранилища…)

• Срок — первая группа — давайте попробуем до 5 декабря.

• Поздравляем тех, кто не побоялся «challenge»-задач на отлично. Часто решения там были тривиальны:
  • Участник:Golovanova.oi/SRTX16E (+ Участник:MCheck/Practice/BYTESM2 + +, +, +)
  • Проблема местами в чтении списка интов со входа.

©

• Если проблемы в решении → исправляем и снова «на проверку». (1)

• Оформление:
  • Ссылки в решении → сначала на страницу, не напрямую на сайт.
  • Резервирование:

• • Не ломайте сами задачи

• Не гонитесь за количеством литкодов — это на «уд», база.
  • Выгнал из резервированных кому хватит!

• Никого левого не пускаем! — не зовите.
• Совсем плохо с решением задач — ну гуглите решения, или даже смотрите ютуб-каналы с разбором.

• Идея баланса — «задачи ←→ теория-тесты ←→ ресерч-навык»

• • Вариант без «теории»
  • Неделя «отл» за два «не LeetCode»-решения (Spoj/CodeChef). → до 22.11 включительно. (ну при этом надо чтобы было 4х-задачное покрытие тем, как обычно». А 23го подведем итоги по задачам (чтобы больше их не решать), откинем и удачливых, и тех, кто не осилил, и будет очередной созвон по теории.
    • Как отлаживать без тестов?
    • Написать генератор
    • Проверить существующими решениями на других языках

Концептуально:

• Win-Win!
• Абсолютно практические задачи с собеседований.
  • LeetCode
  • CodeChef
  • SpojCode
  • Сотни решенных и нерешенных
• Условно поделены на «Dynamic Programming», «Greedy», «Random», «Sorting», «Numbers»
• Нужно быть залогиненным
  • Скрыто из интернета
• Изучайте Решенные практические задачи (Их там 1027)
• Надо решить 4 задачи из разных разделов.
  • Или взять бонусную задачу — «отл» автоматом.

• Выбирайте задачи из Открытые практические задачи, переходите к редактированию по «Беру…» →

• • помечайте их как {{reserve-task|~~~~~}}
• Зарезервированные задачи убираются в Зарезервированные практические задачи

(Их там 55)

• • Не нужно брать десятки задач на себя сразу, и освобождайте то, что не получается.
• Решенное
  • Ну смотрите, как оформлено в прошлые годы
  • Решение на подстранице вашей личной страницы
    • Вики-ссылка на задачу
    • Python-код в «<source lang="python"></source>»
    • Метка «{{checkme}}», когда решите.

• • • Внизу вставка всего этого по клику →
• Они попадут в Категория:На проверку

(Их там 10)

• Как легче решать Python
  • Загрузка данных
  • Выбирайте более свежий CPython или PyPy.

Кратко, что будет, чего не будет и что ждать.

• Лекций — не будет. Это бред и бессмыслица, особенно при дистанционке. Созвоны будут при небходимости, в формате семинара, может индивидуальные.
• Будет путешествие-квест, с разными активностями.
• Берем только практические вещи — алгоритмы для разных задач, особенно NP-полных.
• Условно будет три блока
  • Теоретический — прочитать темы, посмотреть записи лекций, пройти тестирование, возможно решить некоторые теорзадачи.
  • Тут будет первый отсев — если не проходите тесты (отсеим, скажем, 25% нижних), то «досвидания».
    • Не рекламируйте этот курс — чем меньше народу, тем будет лучше. Я заинтересован сократить численность всеми способами. Особенно нафиг я посылаю всех, кто пытается запрыгнуть в курс в середине семестра и позже. Без шансов. Когда-то прогибался в виде исключения, сейчас не буду.
  • Легкий практический — решение нескольки задач, даваемых на собеседованиях в IT-компаниях, типа LeetCoding, SpojCoding, CodeChefing и т.п.
  • Тут будет второй отсев — но можно будет тут свалить, получив «уд» — кому нужно время, и не очень все это интересно.
  • Теор-практический — взять некоторую тему из заданных (свежая статья, я отберу), и сделать ее разбор-презентацию-реализацию в каком-нибудь jupyter или cocalc-ноутбуке (там будет видно). Тут возможно будет и индивидуальная работа и может тренировка презентейшн скиллс, что полезно для ваших дипломов (сколько я смотрел защит, все ужасно).

Ну остальные новости будут в группе, если что. Вопросы тоже там или напрямую.

Как зарегистрироваться — написано на основной странице курса, где все и будет https://discopal.ispras.ru/Advanced-algorithms

Регистраций открыта до 15 октября.

Подумайте еще раз — надо ли вам это. «Халявы», «Лекций», «Оценок за удаленную посещаемость» тут не будет. Даже «уд. нахаляву». Посмотрите, вокруг полно интересных курсов по выбору.

• Большой тест в подарок.
• Кучу тем Курс лекций «Сложность алгоритмов» (ИСПРАН, 3 курс МФТИ)#не берем в этом году
• «A»-фактор поделен на 5.
• Больше баллов за самостоятельную работу.
• Continuous Integration — оценки выставляются непрерывно до середины июня. Или нет?
  • Похоже выставляем скрочно, до конца пятницы.
  • С 15:00 до 17:00 меня можно найти в ИСПРАН, 301 комнате, и попробовать сдать лично (кому не хватает баллов и т.п.).
• Проблемы с оформлением:
  • Участник:Ivan_mipt/teor1
• Как бороться с NZEC с задачами.
  • Пишите генератор тестов.
  • Сравнивайте с имеющимися решениями на C
• Непитоновые задачи засчитывались — Участник:Srip09/USelection
• Много совсем не проходит тесты — 1, 2

• Новый блок задач (отдельная графа в суммировании)
  • CodeChefing/Графы

• Сегодня и завтра даются баллы за решения с нарушением TL за 3 балла!, разумеется, если запускать в PyPy режиме — Почти как полное решение, хотя тут даже не факт, что пройдет нетривиальные тесты. Пользуйтесь!

• Более-менее все зарегистрировались
• Пошли оценки — геймификация
• Стартует квест
  • CodeChefing — должно хватить всем, повышенные баллы (4) до 18 марта.
  • SpojCoding
  • LeetCoding

[1]

• Начинаем штрафовать за непрохождение квеста регистрации.
  • Блокирует оценку за тесты
• Как добавлять категории
• Не забываем ссылки на исходную задачу, [1], [2]
• Отслеживайте замечания про проблемы в решении → [3]
• Главный секрет метрик!

, где — очки за задачу. Т.е. выгодно решить 1-2 задачи в каждой из тем, вместо того, чтобы выгрызать только одну тему, насобачившись решать что-то одно.

• Переключаемся в алгоритмы. Новый фокус. Курс лекций «Сложность алгоритмов» (ИСПРАН, 3 курс МФТИ)#Фокус
• Новые квесты → LeetCoding и SpojCoding. Можно питонизировать решенное!
• Видеозаписи собраний будут собираться тут → Курс лекций «Сложность алгоритмов» (ИСПРАН, 3 курс МФТИ)/Видео/2021

Понижены

• Стартовые штрафы ленивым
• Границы перцентилей
• «Отлично» в два раза меньше «Лидеров»

Numb3rs

• 18/30 финишировали с оценкой
• Только в SpojCoding
  • 39 нерешенных задач
  • 147 решенных и не питонизированных
  • А еще LeetCoding
  • {{checkme}}

• Давайте отгружайте активней!
• Можно срубать «чужие блоки», если старше 5 дней.
  • Бывают столкновения правок [1]

• Quest-D — на самом деле легкий способ улучшить оценку на балл, не пренебрегайте.
  • User:Easik — c самых больших штрафов, до «отл»

• Решение каждой задачи на отдельной странице, а не как [1]
• 1, 2, 3, 4, 5, … — проверяйте перед записью!
• «Time Limit Exceeded» — если не питон, то скорее всего алгоритм сильно не оптимален (квадрат вместо nlogn, экспонента вместо полинома и т.п.).
• «1 → 2» — списывать и передавать решения неспортивно!

• Штраф для «раздолбаев» понижен — включайтесь!
• Новая возможность — написать питон решение к задачам решенным не на Python

• • Иногда это может быть сложно — понять длинное решение на C или Rust
    • Но в целом, полезный навык
    • Можно использовать для тестирования своего решения
    • по 2 балла за задачу
    • Таких много, несколько десятков.
    • Можно даже если это вы сами
    • Если не укладываетесь по времени — пробуйте PyPy
    • Местами есть проблемы Участник:Andriygav/BAT3

• Привлечь внимание {{checkme}} (новое решение, исправление старого, и т.п.)

• Для тех, кому надоели задачи и хочеться чуть лекций
  • Quest-D — три балла отдельно.

• Сроки — скажем до 29 декабря.
  • Может можно будет продолжить, не уверен.
  • «запланированные даты экзамена» — игнорируйте.

• Оптимально — баланс по темам!

• Leet/Spoj
  • Хороший питон — numpy
  • Leetcoding — мягче, показывает, где фейл
  • Несравнимо с CodeForces — издевательство, все в ведро…
• В целом — мы делаем полезное!
  • Можете рекламировать себя («подпишись на мой гитхаб»).
• Можно добавлять новонайденные задачи с этих ресурсов в соответствующие разделы.

• Насколько часто проверяю?
  • Служебная:Свежие_правки
  • Стараюсь раз в несколько дней «начать проверочный обход»
  • Убираю «Блокирующие метки» старше 5 дней!

• Начиная со следующей недели можно фиксировать отметки!

Проблемы

• Трудно определимый код (Rusal)
  • Участник:Rusal/Bird-planet
  • Участник:Rusal/BCAKE

• Зависания и «блокировки» задач
  • Это четыре тильды, не три.
  • Теперь 5 дней.
  • «Блокировку» можно стирать после решения.

• Красивее код
  • Он не только для задачи, но и для ваших коллег.
  • тег «code-python», «code-cpp»
  • Ссылку на исходную задачу
  • Лишних категорий не надо.

Оценки

• Участник:Phokov — молодец.
  • Порадуем трех первых сразу!
  • Лучше понадкусывать везде!
• Автоматического «уд» нет, обязанности «принимать» — тоже нет.
  • Курсов по выбору много.
• A_index

• Квест по машинлернингу.
  • 0x1-classification — 20 баллов за разумное, 12 — за минимально вменяемое. Наверное можно даже троих параллельно.