Надим Закиров, надо заметить, что вызов func(...arr) может привести к переполнению стека, если массив достаточно длинный, порядка 150 тыс элементов. Потому однострочник годится только для небольших блоков. Для больших, наверно, строку придется собирать по частям, кодируя, например, чанки по 3*N элементов... Не знаю, какой вариант наиболее быстрый. К сожалению, в браузере до сих пор нет нормального коробочного решения для base64 из байтового массива.
Нужно объединить так, чтобы списков было как можно меньше?
При объединении списков [1, 2] и [2, 3] будет [1, 2, 3] или [1, 2, 2, 3]?
И каков смысл ключей в словаре?
dron_andron, если angle = 0, то должно быть hhh = h, www = w.
А у тебя наоборот. Поменяй местами синусы и косинусы, и не забудь взять абсолютное значение от результата, а то hhh и www могут быть отрицательные.
dron_andron, можно так:
1) Построй прямоугольник с помощью своей функции, только взяв x, y не рандомные, а равные нулю.
2) Определи W и H. Они не зависят от центра прямоугольника, а только от размеров и угла поворота.
3) получи координаты центра: cx, cy = (np.random.randint(W/2, 640-W/2), np.random.randint(H/2, 480-H/2))
4) к координатам всех точек, полученных в п.1, добавь cx и cy.
у тебя в подсчете суммы делителей числа какая-то мутная логика. Нихрена не понятно, что там за число n и почему иногда происходит arr.append(i / n). На самом деле там надо arr.append(i / j), если i / j > j
для проверки: всего должно быть 6965 чисел в массиве arr_of_redundant
Исправить ее можно просто игнорируя неожиданное состояние автомата парсинга. Например двойка была неожиданной
двойка вообще не при чем. Здесь у нас в конечном автомате состояние "содержимое строки", в этом состоянии скобочки и запятые не обрабатываются, а обрабатывается только двойная кавычка и символ экранирования (экранировать, напомню, можно не только кавычку, но и сам символ \)
Богдан, чанк - это N байт?
Есть ли в твоем json какие-нибудь символы за пределами 0-127, например, кириллица? если да, то в utf8 чанк может прерваться даже не на полуслове, а на "полубукве" (а при наличии каких-нибудь эмодзей - и того хуже, но обрабатывается одинаково).
Выглядит так, что это задача даже не на регулярки, а на посимвольный (побайтовый) конечный автомат. То есть пытаться выхватывать регулярками готовые токены бесполезно, и надо сделать суровую и честную таблицу переходов. В том числе с учетом utf8 (если, повторюсь, это имеет место). Хранить на стеке текущий собираемый токен - то есть массив, объект, значение и т.д., с учетом вложенности. Как только наткнулись на "закрывашку" (запятая или закрывающая скобка), то добавляем собираемое значение в предыдущий элемент на стеке, а если при этом собирали какое-то простое значение, например число или true/false, то делаем предварительно ему JSON.parse. И т.д., тут много нюансов..
Задача по-своему прикольная, но возможно всё-таки было бы лучше предварительно зачитать весь файл и пропарсить за один присест.
насколько знаю, в sql (у автора здесь дамп базы) экранирование кавычек не такое как в js. То есть если строка содержит двойную кавычку, этот вариант может споткнуться..
то есть O(V^2), где V - количество вершин
поскольку у нас тут двудольный граф, у которого E < 2V (E - количество ребер), то, возможно, быстрее будет Алгоритм Хопкрофта — Карпа, там уже асимптотика получается O(V^1.5)
