Size: a a a

2020 March 31

А

Алексей in pro.algorithms
Thorn
1. см. закон Амдала.
2. на HDL удобно реализуется достаточно узкий класс алгоритмов, в основном ЦОС (конвейеры из map/reduce, преобразований типа Фурье и т. п.). чем сильнее алгортим отличается от этого, тем труднее его будет реализовать (особенно эффективно), тем более что на HDL пишут не программисты, а EE, которым лучше всего знакома именно предметная область ЦОС и смежные с ней
👍
источник

T

Thorn in pro.algorithms
конечно, на плис активно делают ассоциативную память для маршрутизаторов, коды коррекции ошибок, аудио-видео кодеки и всякие микшеры, разные tcp/ip вещи типа SDN, DPI, VoIP шлюзы и мн. др., но паттерн прослеживается. делать на плис сверхбыструю субд или веб-сервер скорее всего глупо. разве-что какую-то небольшую часть задачи ускорить
источник

BV

Boris Vinogradov in pro.algorithms
Thorn
конечно, на плис активно делают ассоциативную память для маршрутизаторов, коды коррекции ошибок, аудио-видео кодеки и всякие микшеры, разные tcp/ip вещи типа SDN, DPI, VoIP шлюзы и мн. др., но паттерн прослеживается. делать на плис сверхбыструю субд или веб-сервер скорее всего глупо. разве-что какую-то небольшую часть задачи ускорить
ну там в любом случае в этих всяких штуках софт кора есть какая никакая - т.е. чистой логикой без программного автомата эти задачи не решаются
источник

BV

Boris Vinogradov in pro.algorithms
кстати в аппаратных кодеках и микшерах тоже есть процессорное ядро, пусть и не доступное конечному пользователю, так что в чистом случае переход на программируемую логику может быть вовсе не оправдан с экономической точки зрения
источник

T

Thorn in pro.algorithms
Boris Vinogradov
ну там в любом случае в этих всяких штуках софт кора есть какая никакая - т.е. чистой логикой без программного автомата эти задачи не решаются
в реальной задаче обязательно будет процессор с программой. обычно плис/асик обрабатывает большой поток входных данных, уменьшает его до того, что способен съесть процессор, и отдает ему для дальнейшей (менее математичной, более алгоритмичной) обработки
источник

BV

Boris Vinogradov in pro.algorithms
Thorn
в реальной задаче обязательно будет процессор с программой. обычно плис/асик обрабатывает большой поток входных данных, уменьшает его до того, что способен съесть процессор, и отдает ему для дальнейшей (менее математичной, более алгоритмичной) обработки
внутри самих плис/асик тоже будет процессор, пусть и специализированный
источник

BV

Boris Vinogradov in pro.algorithms
так проще и быстрей выходит
источник

BV

Boris Vinogradov in pro.algorithms
Алексей если прям достаточно просто вам ответить: ваша задача должна быть очень хорошо преобразуемой в ранг поточный операций с очень малым потреблением памяти, а лучше вообще без неё (т.к. в плис и асиках память внутренняя это прям дорого и её очень мало)
источник

f

fashdrag (VladKov) in pro.algorithms
Можете объяснить решение задачи о нахождении треугольников за m√m? Не понимаю
источник

f

fashdrag (VladKov) in pro.algorithms
источник

MB

Mikail Bagishov in pro.algorithms
Доказательство через разделение вершин на легкие и тяжелые
источник

f

fashdrag (VladKov) in pro.algorithms
Сортировка и почему треугольников не больше m√m понятно. Почему удаляют ребра ведущие в тяжёлые вершины, если мы наоборот сортируем по степени и идём из меньшей в большую?
Последняя часть кода тоже понятна
источник

MB

Mikail Bagishov in pro.algorithms
Типа вот мы перебрали ребро 1-2.
1)
Если вершина 2 легкая, то для таких ребер мы сделаем суммарно m sqrt m работы, ОК.
2)
Если вершина 2 тяжелая, то вершина 1 - тоже тяжелая, но мы сделали M работы по перебору 3.
Оценим кол-во таких комбинаций 123, что вершины 1 и 2 тяжелые.
Давай сначала переберем ребро 23, их всего m штук. Для каждой вершины 2 есть не более чем sqrt(M) вершин 1. То есть таких комбинаций тоже O(M sqrt M)
источник

MB

Mikail Bagishov in pro.algorithms
А, туплю)
источник

MB

Mikail Bagishov in pro.algorithms
fashdrag (VladKov)
Сортировка и почему треугольников не больше m√m понятно. Почему удаляют ребра ведущие в тяжёлые вершины, если мы наоборот сортируем по степени и идём из меньшей в большую?
Последняя часть кода тоже понятна
Ну мы отсортировали списки смежности. Теперь справа вершины с большой степенью. Мы их и удаляем, чтобы дальше перебер просматривал тройки вершин в порядке убывания степеней. Мне непонятно, в чем проблема?
источник

f

fashdrag (VladKov) in pro.algorithms
Mikail Bagishov
Ну мы отсортировали списки смежности. Теперь справа вершины с большой степенью. Мы их и удаляем, чтобы дальше перебер просматривал тройки вершин в порядке убывания степеней. Мне непонятно, в чем проблема?
Убывания? Как я понял из текста выше, по возрастанию.
"Отсортируем вершины по возрастанию степени, ориентируем v->u, v <= u"
источник

MB

Mikail Bagishov in pro.algorithms
По-моему, любой порядок их этих двух сойдет
источник

MB

Mikail Bagishov in pro.algorithms
Потому что реверс просто поменяет все ребра на противоположные, а это не влияет на кол-во путей длины 2
источник

f

fashdrag (VladKov) in pro.algorithms
Наверное в контексте имелось ввиду сортировать по убыванию, а я пытаюсь понять что да как...
Просто смотрел разбор задачи с ИОИП 2016-2017, там было по возрастанию, наверное это и сбило с толку
источник

f

fashdrag (VladKov) in pro.algorithms
источник