Ну, я искал, как на Питоне сделать реальное распараллеливание. Или я плохо искал, или его просто так не сделаешь. В общем, один из моих курсачей, которому нужно считать интеграл, работает не так шустро, как хотелось бы. В 12 раз не так шустро.
раскрыть ветку (19)
раскрыть ветку (2)
На тот момент, кстати, с Python я сталкивался впервые. Стал гуглить, как распараллелить вычисления и узнал, что даже если я и буду создавать потоки, всё равно аппаратного разделения не будет. Ну и я решил не городить огород, от которого всё равно не будет толка. А выбирать интерпретатор я тогда не умел... Да и сейчас, наверное, тоже не умею.
Просто нашёл свой старый курсач, решил ради прикола на малинке запустить. Оно и на нормальных машинах работало с болью и страданиями. На малинке стало работать ещё медленнее. Но завелось.
раскрыть ветку (1)
раскрыть ветку (2)
Вот мне ещё докера не хватало. Хотя, если в будущем возникнет такая необходимость, я, конечно, воспользуюсь Вашим советом.
Но всё равно, то, что я не могу просто создать поток и отдать его на исполнение системе, меня удручает.
раскрыть ветку (1)
используйте scipy или аналогичные библиотеки с сишными реализациями тяжелых математических функций
раскрыть ветку (12)
А оно умеет искать центр тяжести фигуры, ограниченной произвольным набором функций? А то в том курсаче надо было всенепременно руками написать небольшой кусочек нечёткой логики. Мне, например, надо было написать нечёткие когнитивные карты, кажется, обобщённые. А там был такой момент, что нечёткое решение, состоящее из объединения (в данном случае, брался максимум) нескольких обрезанных термов, надо было дефаззифицировать. Т.е. найти центр тяжести по оси x того, что у меня на картинке находится под зелёной линией. При этом, пересечения термов не должны были давать дополнительного веса, т.е. вариант с нахождением центра тяжести каждого терма и последующим усреднением был бы либо не применим, либо над ним бы надо было подумать. Ещё можно было использовать метод "правого или левого максимума", он был бы очень быстрым, но не достаточно точным. В общем, я искал точку x, для которой бы интегралы этой функции от начала до x и от x до начала были бы равны. Делал я это максимально долго и тупо. Но сделал.
раскрыть ветку (11)
Блжад, круто наверное быть таким умным, я своим раненым пхп мозгом не придумал ничего лучше чем разделить нужный отрезок на N точек, потом циклом с двумя счётчиками идти справа и слева чередуясь, и прибавлять к правой и левой сумме соответственно максимальное значение функций в данной точке, сдвигая счётчик с той стороны, где сумма меньше, как встретятся, там и центр масс.
Это и есть метод правого или левого максимума?
раскрыть ветку (2)
Метод правого и левого максимума в нечёткой логике - это когда ты не считаешь интеграл, а тупо берёшь первую точку с максимальным значением по оси y. Соответственно, справа или слева. Её x и будет дефаззифицированным значением. Это быстро, но слишком тупо. Я не стал брать этот метод, ибо тогда система выдавала бы уж слишком много одинаковых значений.
Твой метод, в принципе, будет получше моего, т.к. я сначала считал тупо весь интеграл, а потом ещё раз, но до половины найденного ранее значения. Чем больше точность, тем дольше это всё работало. С учетом того, что мне лень было из имеющихся термов строить одну кривую, это было очень долго.
раскрыть ветку (1)
Мой в принципе похож на твой получается, только я параллельно считаю более примитивным методом прямоугольников, это позволяет позволяет считать интеграл всей функции за один проход и остановиться посередине так что справа и слева будут суммы равны.
Но при этом нет возможности приблизиться итерационно к определённой погрешности при подсчёте интеграла.
Лол, у меня фиксированная скорость, а у тебя погрешность и точность, прикольно.
Я так понимаю в вашем примере справа всё-таки есть ограничение, тогда технически основная задача сводится к формализации итоговой кусочно-заданной функции.
Имея её или получая в результате тривиальных расчетов функцию, Формализуете расчет интеграла с применением scipy'шных методов и бинарным поиском ищете центр масс.
Для совсем жесткого варианта с символьными функциями есть интеграция с scilab и matlab (для уж совсем жестких пацанов)
Подытожив. scipy не сможет принять запрос в стиле "вот тебе три символьно заданные функции, найди мне центр масс быстро и без проблем" - нужно будет все-таки немного пораскинуть мозгами.
с другой стороны scilab вполне сможет это сделать
А так, даже в матлабе насколько я знаю нет straitforward решений этой задачи без танцев с бубном.
в любом случае, если вы перебирали все x от xmin до xmax то это ваши проблемы, а не проблемы языка
раскрыть ветку (7)
То, что я использовал под это дело метод трапеций, это действительно мои проблемы. А вот то, что без танцев с бубнами это нельзя было распараллелить, уже проблема Python'а.
Нас просто изначально один из руководителей практики заставлял писать это именно на Python. Хотя потом оказалось, что у самых затянувших принимали проги и на c#. А уж там-то это было бы гораздо быстрее, во всяком случае, в моём исполнении.
раскрыть ветку (6)
А вам бюджет озвучивали или сложность алгоритма? Если решение в лоб считается за приемлимое время, то зачем все это разводить?
И кто вам запрешает классически запустить N интерпретаторов в разных процессах и потом объеденить результаты их работы в родительском? Если в алгоритме, есть простои на ожидание результата, то можно таки использовать родные потоки питоновские или корутины. Правда судя по задаче вы тут упретесь в процессорное время.
раскрыть ветку (3)
В данном случае, мне во-первых, было это просто интересно, а во-вторых, более быстрая работа алгоритма была бы гораздо более комфортной во время защиты.
А то беру я, значит, простую когнитивную карту с 4 концептами, задаюсь начальными условиями и хочу посмотреть 25 итераций её жизни. Хотя там цикличность или смерть сети за 3-5 итераций можно увидеть, но это отдельный разговор. И вот, всё это хуедрыгало считается примерно минуту.
На малине, соответственно, считалось ещё дольше, а мониторинг говорил, что одно ядро загружено на максимум, а остальные простаивают.
раскрыть ветку (2)
Везде есть свои подводные камни - не без этого. Но адекватное решение на распалеливание гуглится почти сразу (а общую концепцию еще в 80х придумали) Да и питонских библиотек для вычислений написано уже на все случаи жизни в нескл вариантах (в том числе те которые распределенно на GPU считают); так что вполне нормальный язык для выбраной задачи.
P.S. У нас правда разрешали на любом языке сдавать, лишь бы оно запускалось и ты мог объяснить алгоритм работы + нарисовав на это блок схему. Это более правильный подход
раскрыть ветку (1)
Про pycuda я знаю. Сейчас бы, возможно, попробовал сделать с помощью этой библиотеки. Ну или чего-то более универсального, если гуглить более 10 секунд.
А так, большинство преподов у нас были лояльными и разрешали писать на том, что нравится. Но тут же нашёлся молодой, амбициозный, фапающий на pycharm ЧСВ-шник, решивший, что так будет правильно, а остальное его не ебёт.
раскрыть ветку (1)
И то, и другое. Просто на тот момент, на c# я уже довольно много чего делал по учёбе. Хоть какой-то опыт был. Было бы меньше геморроя с освоением языка в процессе написания кода. И даже если бы я использовал тот же подход, я бы просто его распараллелил.
Я ничего плохого не хочу сказать про Питон, но на тот момент, прога на нём получилась крайне медленной. С другой стороны, это дало небольшой опыт работы с этим языком.
И сейчас, например, когда мне надо было использовать протокол Modbus rtu на малинке, там я это на питоне завёл с полтычка.
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору