Тут ищутся все картинки в каталоге ~/pictures, каждая картинка отдаётся на разбиение нашей (ненаписанной еще правильно) утилитке split.py, которая на выход даёт, скажем, те же base64-строки с битмапами входных и выходных примеров, а teech.py принимает на вход поток таких примеров, десериализует их из base64 и загоняет в персистентную нейронку.
Если приучить себя все скрипты делать в таком unix-way стиле, то может отрасти борода и свитер, что не всегда плохо.
Вот и печатайте шкивы, а не шестеренки. А ремень можно взять какой есть, настраивать же расстояние между шкивами с помощью салазок и регулировочного винта.
Кстати, где-то видел как делают шкивы склеивая три вырезанных из листового пластика круга.
Или вы меня не поняли или я вас.
Всего 4 секунды на фокусном 135 — это из-за вращения Земли? То есть звёзды уезжают на условный пиксель за 4 секунды на таком фокусном расстоянии. Так?
Так вот, я это к тому, что и хрен с ними, пусть уезжают. На 30 секундной выдержке статичной камеры у нас будут приличных размеров дуги вместо точек. Однако, камера же фиксированная, Земля вертится достаточно предсказуемо, звёзды — это довольно статичные (мягко говоря) в наших масштабах объекты.
Если мы знаем очень точно по какой траектории проехала каждая звезда, то можем чисто алгоритмически провести обратную свёртку и «собрать» свет из дуги в точку. Причем задача, вроде бы, хотя я не очень уверен, но жопой чую, достаточно однозначно решается. Зная длительность экспозиции (а затвор же отрабатывает очень точно) и центр вращения (а его по большому количеству дуг тоже можно найти достаточно точно простым усреднением), можно понять какой точке статичной картинки принадлежит какое количество света каждой точки кадра. Блин… так себе объяснил, да?
Сейчас камеры с цифровой стабилизацией умеют по данным акселерометра нивелировать алгоритмически дрожание рук. А здесь никаких акселерометров не надо, земля движется очень стабильно и предсказуемо.
Это если передаточное число не велико и шаговик работает в недискретном режиме. Я бы делал большое соотношение зубьев и постоянно импульсами крутил бы шаговик. И экономично и плавно.
Похоже mmMike имеет в виду, что ступенчатое дискретное перемещение на фиксированный шаг гораздо более энергоэффективно, чем удержание вала между шагами или (что практически идентично удержанию) медленный плавный поворот (векторное управление).
Напрашивается для оптимизации использование двигателя в шаговом режиме, если речь не идёт о съёмке видео и можно подгадать дискретный поворот монтировки «между кадрами».
Тут хочется отметить, что на фоне прочего оборудования для астро-съёмки мощный китайский, возможно самосборный павербанк не будет играть решающей роли ни по массе ни по стоимости, по этой причине мощный шаговик с удержанием — вполне рабочая схема.
PID регулятор, энкодер, пропорциональное управление, необходимость калибровки, мне кажется, сильно усложняют схему по сравнению с использованием шаговика.
Почему нельзя решать проблему за счет увеличения передаточного числа шестеренок? Ведь при большом передаточном числе становится неважной дискретность шага (тупо деленный на передаточный коэффициент угол шага поглощается погрешностью и низкой добротностью трансмиссии). Можно быстро и достаточно энергоэффективно крутить шаговик и за счет большого передаточного числа получить мощное и плавное движение монтировки. Ну да, придётся делать большую шестерёнку, или ещё одну дополнительную, но простота и предсказуемость…
Я так понимаю автор хочет автономности в поле и рассчитывает на 5V повербанки. Я уже писал, что современные павербанки с QC дают 12 вольт без проблем, но цена подходящих преобразователей получается примерно как ваши упомянутые БП. Ну и плюс сам павербанк.
Объясните дилетанту, почему вопрос стабилизации не принято решать программно? Звёзды точечные объекты, удалённые «на бесконечность», почему не делать много кадров с 30 секундной выдержкой, а потом сводить кадры каким-нибудь автоматическим «цифровым» трекером звёзд? Мы же отказались от плёнки, не пора ли отказаться от точных механических монтировок?
Может быть проблемы люфтов дешевых самодельных монтировок можно решать автоматической пост-обработкой? Всё-таки звёздное небо — это не длинный плавный гиперлапс, его трекать и стабилизировать алгоритмически, как мне кажется, куда проще.
А в чем проблема с напряжением?
Сейчас полно китайских повышающих модулей вроде такого:
Или даже вот вариант совсем уж люксовый:
А современные павербанки отдают приличный ток и, мне кажется, его на шаговик с избытком хватит. Я бы, кстати, попробовал заюзать шаговик от старого принтера. Их там много и они довольно мощные, причем уже с шестерёнкой на валу. 12 вольт для них не проблема, как я уже сказал, поскольку повышайки 5->12 достаточно эффективны, а недорогого павербанка хватит, мне кажется, на всю ночь работы такого трекера, еще и останется.
Ещё я бы использовал прямую шпильку. Тот конец, который сейчас закреплен жестко — закрепить на шарнире (навернуть гайку и просверлить шпильку вместе с гайкой надев затем на ось, которая, в свою очередь, закреплена на поворотной плоскости).
Мне кажется прямую шпильку пропускать через гайку будет проще и стабильнее по усилию, от этого будет меньше люфта, а за счет большого плеча посадку концевого шарнира можно сделать очень плотной, что тоже позволит избежать лишнего люфта шпильки.
UPD.
Осторожно, кому важно, ссылки на али, похоже, получились с кэшбеком. У меня какое-то расширение для этого в браузере стоит. Но там таких модулей полно и можно выбрать похожие. Эту плату я покупал — работает отлично, крутит не шибко мощный 12V насос от павербанка. Со шнурочком повышайку только заказал, не знаю какой ток отдаст, не пришла еще.
UPD2.
Чуть не забыл. Сейчас павербанки умеют отдавать через USB больше 5 вольт. На али стали появляться специальные переходники, которые сигнализируют источнику о том, что примут 12 или 20 вольт и сами не повышают напряжение, что позитивно сказывается на КПД и надёжности. Для применения в такой самоделке, ИМХО, КПД не сильно важен, поскольку условия не походные и трекер сам по себе довольно громоздкий. Экономить на массе павербанков не приходится.
О, на счет видео с регистраторов.
Что если сделать сервис и приложение на десктоп для публикации треков и обмена видео с регистраторов.
Суть какая: автолюбители ставят на софтину, которая так или иначе регулярно или с помощью человека заглядывает на флешку регистратора, стягивает оттуда трек и видео (опционально без звука), а затем анонимно постит на веб-сервис инфу, что видео по такому вот треку (с таймштампами) будет доступно по запросу до такого-то числа (потом затрётся).
Посетители сервиса могут запросить у владельца куски его записей с регистратора для своих нужд (может кто кражу, ДТП или угон хочет рассмотреть или просто посмотреть как выглядит то или иное место когда нет гуглстритвью).
Владелец регистратора в настройках своего клиента может указать зоны, треками в которых он делиться не хотел бы.
Сам обмен видео с региков можно осуществлять через торрент протокол по генерируемым на лету с разрешения автора магнет-ссылкам.
А давайте помозгоштурмим требования к ИДЕАЛЬНОЙ CLI утилите для работы с фотоколлекциями.
Я вот набросал свои хотелки тут.
Постепенно разгребу всё это, выделю MVP и по 5 минут в неделю буду выкраивать=)
Вот тоже много думал об этих датах. Хорошо бы при разгребании такие аномалии автоматически находить и предлагать упорядочивать.
Что характерно, тут есть несколько типичных кейсов:
Дата на фотоаппарате слетела при смене батареек.
В этом случае фотографии относительно друг-друга выстраиваются по времени пропорционально и правильно. Достаточно привязать один кадр такой серии к реальной дате/времени, а остальные можно рассчитать и привязать автоматом.
Важно обнаружить момент, когда дата слетает посередине серии так, что часть фоток улетают на несколько лет в прошлое. Как на косвенный признак такой ситуации можно опираться на порядковый номер фото и её положение в исходных каталогах в файлопомойке.
Дата/время сдвинуты из-за приблизительной установки. Серия в целом отображается в таймлайне где надо, и (при наличии опорного кадра, где были засняты часы) можно восстановить точное время всей серии.
Дата/время установлены по некорректному часовому поясу во всей серии или её частях. Можно, к примеру, предусмотреть возможность ручной установки в таймлайне с фотографиями маркеров смены часового пояса.
Сочетание всех вышеперечисленных случаев из-за слияния в куче каталогов фоток из разных источников. Самый неприятный случай, когда большая шумная компания сливает все свои фотки в кучу, потом самый инициативный еще и разгруппирует по людям или по каким-то еще не очевидным признакам. Тут надо, наверно, какое-то автотегирование по модели и серийному номеру фотика, группировку источников… Ну и адаптацию решений вышеперечисленных проблем к такому вот сложному случаю.
О, какую больную тему затронули. Давно у меня зреет в загашниках такой пет-проект. Только вот долбаный перфекционизм не даёт начать с малого, как это сделали вы.
У меня к такой утилитке, похоже, гораздо больше требований, чем у вас.
Вот в ридмишке к проекту их можно глянуть.
Жалко времени на все эти завалы из пет-проектов не хватает.
Бесит каждый раз вручную раскладывать фотки из нескольких источников, а еще нужно думать об облачных бэкапах в гугле и яндексе, о том, что у меня хранятся и raw и jpeg, о том. что EXIF у них немного разные, о том, что куча сопутствующего хлама рядом валяется из брекетинговых и панорамных серий. Жалко же выбрасывать, "вдруг руки дойдут" (обычно не доходят). Иногда нащёлкаешь как из пулемёта десятки кадров одного сюжета с намерением потом выбрать ОДИН хороший, где никто не моргает, но потом просто забиваешь за неимением времени. Вот такие бы серии как-то группировать и прятать до хороших времен.
Ну я в детстве тоже писал программы в тетрадочке потому, что не было компьютера дома, а в школе урок информатики и кусочек времени после уроков, когда удавалось дорваться до компов слишком коротки.
Я бы сказал, что интерес — это скорее вопреки всему, хотя, наверно, хороший учитель порой способен пробудить его к своей теме.
Да ладно! Было бы желание. Я в том смысле, что преподы обычно с удовольствием разрешают взять в качестве задания свою собственную тему студента. Да и не важно на каких примерах осваивать профессию, просто если это интересная тема, то она и выполняется с бОльшим желанием.
А вот такие синтетические формальные задания, как мне кажется, получают те, кому не очень-то и интересно то, чему они учатся и у них нет идей поинтереснее.
Пожалуй я тоже был слегка излишне язвителен по отношению к автору. Посыпаю голову пеплом. Но если автор еще разродится подобной статьёй с таким же кодом не потратив даже пару вечеров на чтение Лутца или просто постижение азов питона, то яду будет куда больше.
А так-то парень хоть взял и написал, да оформил, а у меня до сих пор все мои статьи в черновиках шлифуются. Скорее всего истина где-то посередине и лишний перфекционизм — тоже плохо.
В том-то и дело. Я боюсь, что кто-то придёт учиться по этой статье, по этому коду! Ума не приложу зачем я влез в эти каменты. Автор выбрал слишком дорогих репетиторов вместо того, чтобы почитать азы там, где это следовало бы.
На месте препода я бы влепил трояк, честно сказать, особенно если бы узнал про статью. Вообще не понятно о чем тут задание? Автора программировать пытались научить, или с матрицами работать?
Вот действительно, давайте придумаем такого сферического новичка в вакууме, которому эта статья могла бы оказаться полезной и при этом ко всему еще и не вредной. ХЗ.
Ну вообще-то не всё так однозначно.
В данном случае автор как будто постарался написать на питоне как на C. Это всегда плохая идея — использовать язык не по назначению и не так, как было задумано разработчиками.
В коде рассматриваемой библиотеки всё написано совсем не по-питоновски.
А еще в некоторых случаях производительности питона достаточно, а вот в других языках недостаёт выразительности и простоты. "С" безусловно быстрее, но в нём нет сахара для ООП и прочего, бизнес-логика на нём будет нечитабельной.
Во многих случаях достаточно аккуратно написанного прототипа, чтобы отработать весь (порой не маленький) жизненный цикл приложения. Питон в этом смысле достаточно хорош, если не пытаться на нём делать вещи в которых он не эффективен.
Кстати, есть же еще архитектурные приёмы, которые позволяют разменять производительность на железо за счет масштабирования. Если хорошо написанный питоновский код окажется легче разделить и модифицировать для улучшения масштабируемости, чем хорошо написанный более нативный код на С/С++, то выбор питона уже оправдан, несмотря на в целом меньшую производительность.
Железо дёшево и дешевеет, а программисты, особенно хорошие низкоуровневые очень дороги и не дешевеют.
def copy(self, matrix = None):
"""
Возвращает копию матрицы
"""
if matrix == None:
matrix = self.matrix
result = []
if self.checkvector(matrix = matrix):
for i in matrix:
result.append(i)
else:
i = len(matrix)
j = len(matrix[0])
for i_ in range(i):
temp = []
for j_ in range(j):
temp.append(matrix[i_][j_])
result.append(temp)
return result
Вы нарочно постарались сделать помедленнее?
О, докину сюда же.
Вместо if(n == None): нужно делать if n is None:.
Зачем вы пишете return(matrix)? Это дезориентирует. return — это не функция, а скобки в питоне используются для создания кортежей, хотя здесь запятой нет и это можно нечаянно не заметить. Не делайте так.
Еще в питоне можно сделать так: [0] * 10 и получить список из десяти нулей.
Вот этот ваш кусок сломается, если высота матрицы больше ширины:
matrix = []
for i in range(self.I):
temp = []
for j in range(self.J):
temp.append(0)
temp[i] = 1
matrix.append(temp)
return(matrix)
А что это у вас метод сложения матриц 0 возвращает, если матрицы несовместимы? ой всё… даже читать дальше не хочется. Ну хотя бы Лутца почитайте. Нельзя же с этим сразу кидаться статью писать. Вдруг какие-то еще более новички в питоне у вас чему-нибудь плохому "научатся".
ох…
Не имейте привычки вставлять свои принты в код. Надо учиться правильно работать с исключениями.
Что вы вообще хотели сказать этой статьёй? Что первая наивная лабораторная на до сих пор незнакомом языке программирования — это хорошая тема для статьи?
Само собой не взлетит. Он и поплыл-то не с первого раза, хотя определить проблемы с балансировкой можно было "наощупь" еще при сборке, взявшись вдвоём за "лыжи" посередине.
А еще есть такая штука, как элементарная школьная физика, которая позволяет легко посчитать плавучесть вот этого всего. Объём ваших труб вычисляется элементарно, плотность байкальской воды — не секрет. А вот почему вы решили сделать бессмысленный кусок мусора, прежде чем посчитать его целесообразность — для меня секрет.
Может быть это звучит довольно жестоко, но знаете, это, всё же, конструктивная критика. И выше по тексту тоже комментарии довольно конструктивны. Ваш дрон действительно больше вреден чем полезен.
Жаль, что эта штука займёт своё место на свалке. Трубы могли бы послужить и по назначению.
Напрашивается какой-то дружественный к пайпам CLI.
Например такой:
Тут ищутся все картинки в каталоге
~/pictures, каждая картинка отдаётся на разбиение нашей (ненаписанной еще правильно) утилиткеsplit.py, которая на выход даёт, скажем, те же base64-строки с битмапами входных и выходных примеров, аteech.pyпринимает на вход поток таких примеров, десериализует их из base64 и загоняет в персистентную нейронку.Если приучить себя все скрипты делать в таком unix-way стиле, то может отрасти борода и свитер, что не всегда плохо.
Кстати, где-то видел как делают шкивы склеивая три вырезанных из листового пластика круга.
Всего 4 секунды на фокусном 135 — это из-за вращения Земли? То есть звёзды уезжают на условный пиксель за 4 секунды на таком фокусном расстоянии. Так?
Так вот, я это к тому, что и хрен с ними, пусть уезжают. На 30 секундной выдержке статичной камеры у нас будут приличных размеров дуги вместо точек. Однако, камера же фиксированная, Земля вертится достаточно предсказуемо, звёзды — это довольно статичные (мягко говоря) в наших масштабах объекты.
Если мы знаем очень точно по какой траектории проехала каждая звезда, то можем чисто алгоритмически провести обратную свёртку и «собрать» свет из дуги в точку. Причем задача, вроде бы, хотя я не очень уверен, но жопой чую, достаточно однозначно решается. Зная длительность экспозиции (а затвор же отрабатывает очень точно) и центр вращения (а его по большому количеству дуг тоже можно найти достаточно точно простым усреднением), можно понять какой точке статичной картинки принадлежит какое количество света каждой точки кадра. Блин… так себе объяснил, да?
Сейчас камеры с цифровой стабилизацией умеют по данным акселерометра нивелировать алгоритмически дрожание рук. А здесь никаких акселерометров не надо, земля движется очень стабильно и предсказуемо.
Напрашивается для оптимизации использование двигателя в шаговом режиме, если речь не идёт о съёмке видео и можно подгадать дискретный поворот монтировки «между кадрами».
Тут хочется отметить, что на фоне прочего оборудования для астро-съёмки мощный китайский, возможно самосборный павербанк не будет играть решающей роли ни по массе ни по стоимости, по этой причине мощный шаговик с удержанием — вполне рабочая схема.
PID регулятор, энкодер, пропорциональное управление, необходимость калибровки, мне кажется, сильно усложняют схему по сравнению с использованием шаговика.
Почему нельзя решать проблему за счет увеличения передаточного числа шестеренок? Ведь при большом передаточном числе становится неважной дискретность шага (тупо деленный на передаточный коэффициент угол шага поглощается погрешностью и низкой добротностью трансмиссии). Можно быстро и достаточно энергоэффективно крутить шаговик и за счет большого передаточного числа получить мощное и плавное движение монтировки. Ну да, придётся делать большую шестерёнку, или ещё одну дополнительную, но простота и предсказуемость…
Может быть проблемы люфтов дешевых самодельных монтировок можно решать автоматической пост-обработкой? Всё-таки звёздное небо — это не длинный плавный гиперлапс, его трекать и стабилизировать алгоритмически, как мне кажется, куда проще.
Сейчас полно китайских повышающих модулей вроде такого:
Или даже вот вариант совсем уж люксовый:
А современные павербанки отдают приличный ток и, мне кажется, его на шаговик с избытком хватит. Я бы, кстати, попробовал заюзать шаговик от старого принтера. Их там много и они довольно мощные, причем уже с шестерёнкой на валу. 12 вольт для них не проблема, как я уже сказал, поскольку повышайки 5->12 достаточно эффективны, а недорогого павербанка хватит, мне кажется, на всю ночь работы такого трекера, еще и останется.
Ещё я бы использовал прямую шпильку. Тот конец, который сейчас закреплен жестко — закрепить на шарнире (навернуть гайку и просверлить шпильку вместе с гайкой надев затем на ось, которая, в свою очередь, закреплена на поворотной плоскости).
Мне кажется прямую шпильку пропускать через гайку будет проще и стабильнее по усилию, от этого будет меньше люфта, а за счет большого плеча посадку концевого шарнира можно сделать очень плотной, что тоже позволит избежать лишнего люфта шпильки.
UPD.
Осторожно, кому важно, ссылки на али, похоже, получились с кэшбеком. У меня какое-то расширение для этого в браузере стоит. Но там таких модулей полно и можно выбрать похожие. Эту плату я покупал — работает отлично, крутит не шибко мощный 12V насос от павербанка. Со шнурочком повышайку только заказал, не знаю какой ток отдаст, не пришла еще.
UPD2.
Чуть не забыл. Сейчас павербанки умеют отдавать через USB больше 5 вольт. На али стали появляться специальные переходники, которые сигнализируют источнику о том, что примут 12 или 20 вольт и сами не повышают напряжение, что позитивно сказывается на КПД и надёжности. Для применения в такой самоделке, ИМХО, КПД не сильно важен, поскольку условия не походные и трекер сам по себе довольно громоздкий. Экономить на массе павербанков не приходится.
О, на счет видео с регистраторов.
Что если сделать сервис и приложение на десктоп для публикации треков и обмена видео с регистраторов.
Суть какая: автолюбители ставят на софтину, которая так или иначе регулярно или с помощью человека заглядывает на флешку регистратора, стягивает оттуда трек и видео (опционально без звука), а затем анонимно постит на веб-сервис инфу, что видео по такому вот треку (с таймштампами) будет доступно по запросу до такого-то числа (потом затрётся).
Посетители сервиса могут запросить у владельца куски его записей с регистратора для своих нужд (может кто кражу, ДТП или угон хочет рассмотреть или просто посмотреть как выглядит то или иное место когда нет гуглстритвью).
Владелец регистратора в настройках своего клиента может указать зоны, треками в которых он делиться не хотел бы.
Сам обмен видео с региков можно осуществлять через торрент протокол по генерируемым на лету с разрешения автора магнет-ссылкам.
Может такое есть уже?
А давайте помозгоштурмим требования к ИДЕАЛЬНОЙ CLI утилите для работы с фотоколлекциями.
Я вот набросал свои хотелки тут.
Постепенно разгребу всё это, выделю MVP и по 5 минут в неделю буду выкраивать=)
Вот тоже много думал об этих датах. Хорошо бы при разгребании такие аномалии автоматически находить и предлагать упорядочивать.
Что характерно, тут есть несколько типичных кейсов:
В этом случае фотографии относительно друг-друга выстраиваются по времени пропорционально и правильно. Достаточно привязать один кадр такой серии к реальной дате/времени, а остальные можно рассчитать и привязать автоматом.
Важно обнаружить момент, когда дата слетает посередине серии так, что часть фоток улетают на несколько лет в прошлое. Как на косвенный признак такой ситуации можно опираться на порядковый номер фото и её положение в исходных каталогах в файлопомойке.
О, какую больную тему затронули. Давно у меня зреет в загашниках такой пет-проект. Только вот долбаный перфекционизм не даёт начать с малого, как это сделали вы.
У меня к такой утилитке, похоже, гораздо больше требований, чем у вас.
Вот в ридмишке к проекту их можно глянуть.
Жалко времени на все эти завалы из пет-проектов не хватает.
Бесит каждый раз вручную раскладывать фотки из нескольких источников, а еще нужно думать об облачных бэкапах в гугле и яндексе, о том, что у меня хранятся и raw и jpeg, о том. что EXIF у них немного разные, о том, что куча сопутствующего хлама рядом валяется из брекетинговых и панорамных серий. Жалко же выбрасывать, "вдруг руки дойдут" (обычно не доходят). Иногда нащёлкаешь как из пулемёта десятки кадров одного сюжета с намерением потом выбрать ОДИН хороший, где никто не моргает, но потом просто забиваешь за неимением времени. Вот такие бы серии как-то группировать и прятать до хороших времен.
Да уж. А на воде бы такое трудно было устроить. Всех бы адски укачивало. Хотя на реке на плоту… почему бы и нет.
Ну я в детстве тоже писал программы в тетрадочке потому, что не было компьютера дома, а в школе урок информатики и кусочек времени после уроков, когда удавалось дорваться до компов слишком коротки.
Я бы сказал, что интерес — это скорее вопреки всему, хотя, наверно, хороший учитель порой способен пробудить его к своей теме.
Да ладно! Было бы желание. Я в том смысле, что преподы обычно с удовольствием разрешают взять в качестве задания свою собственную тему студента. Да и не важно на каких примерах осваивать профессию, просто если это интересная тема, то она и выполняется с бОльшим желанием.
А вот такие синтетические формальные задания, как мне кажется, получают те, кому не очень-то и интересно то, чему они учатся и у них нет идей поинтереснее.
Пожалуй я тоже был слегка излишне язвителен по отношению к автору. Посыпаю голову пеплом. Но если автор еще разродится подобной статьёй с таким же кодом не потратив даже пару вечеров на чтение Лутца или просто постижение азов питона, то яду будет куда больше.
А так-то парень хоть взял и написал, да оформил, а у меня до сих пор все мои статьи в черновиках шлифуются. Скорее всего истина где-то посередине и лишний перфекционизм — тоже плохо.
В том-то и дело. Я боюсь, что кто-то придёт учиться по этой статье, по этому коду! Ума не приложу зачем я влез в эти каменты. Автор выбрал слишком дорогих репетиторов вместо того, чтобы почитать азы там, где это следовало бы.
На месте препода я бы влепил трояк, честно сказать, особенно если бы узнал про статью. Вообще не понятно о чем тут задание? Автора программировать пытались научить, или с матрицами работать?
Вот действительно, давайте придумаем такого сферического новичка в вакууме, которому эта статья могла бы оказаться полезной и при этом ко всему еще и не вредной. ХЗ.
Ну вообще-то не всё так однозначно.
В данном случае автор как будто постарался написать на питоне как на C. Это всегда плохая идея — использовать язык не по назначению и не так, как было задумано разработчиками.
В коде рассматриваемой библиотеки всё написано совсем не по-питоновски.
А еще в некоторых случаях производительности питона достаточно, а вот в других языках недостаёт выразительности и простоты. "С" безусловно быстрее, но в нём нет сахара для ООП и прочего, бизнес-логика на нём будет нечитабельной.
Во многих случаях достаточно аккуратно написанного прототипа, чтобы отработать весь (порой не маленький) жизненный цикл приложения. Питон в этом смысле достаточно хорош, если не пытаться на нём делать вещи в которых он не эффективен.
Кстати, есть же еще архитектурные приёмы, которые позволяют разменять производительность на железо за счет масштабирования. Если хорошо написанный питоновский код окажется легче разделить и модифицировать для улучшения масштабируемости, чем хорошо написанный более нативный код на С/С++, то выбор питона уже оправдан, несмотря на в целом меньшую производительность.
Железо дёшево и дешевеет, а программисты, особенно хорошие низкоуровневые очень дороги и не дешевеют.
А почему вы даже копируете матрицу и то "вручную"? Есть же встроенные методы для этого.
Вы нарочно постарались сделать помедленнее?
О, докину сюда же.
Вместо
if(n == None):нужно делатьif n is None:.Зачем вы пишете
return(matrix)? Это дезориентирует.return— это не функция, а скобки в питоне используются для создания кортежей, хотя здесь запятой нет и это можно нечаянно не заметить. Не делайте так.Еще в питоне можно сделать так:
[0] * 10и получить список из десяти нулей.Вот этот ваш кусок сломается, если высота матрицы больше ширины:
А что это у вас метод сложения матриц 0 возвращает, если матрицы несовместимы? ой всё… даже читать дальше не хочется. Ну хотя бы Лутца почитайте. Нельзя же с этим сразу кидаться статью писать. Вдруг какие-то еще более новички в питоне у вас чему-нибудь плохому "научатся".
ох…
Не имейте привычки вставлять свои принты в код. Надо учиться правильно работать с исключениями.
Что вы вообще хотели сказать этой статьёй? Что первая наивная лабораторная на до сих пор незнакомом языке программирования — это хорошая тема для статьи?
Само собой не взлетит. Он и поплыл-то не с первого раза, хотя определить проблемы с балансировкой можно было "наощупь" еще при сборке, взявшись вдвоём за "лыжи" посередине.
А еще есть такая штука, как элементарная школьная физика, которая позволяет легко посчитать плавучесть вот этого всего. Объём ваших труб вычисляется элементарно, плотность байкальской воды — не секрет. А вот почему вы решили сделать бессмысленный кусок мусора, прежде чем посчитать его целесообразность — для меня секрет.
Может быть это звучит довольно жестоко, но знаете, это, всё же, конструктивная критика. И выше по тексту тоже комментарии довольно конструктивны. Ваш дрон действительно больше вреден чем полезен.
Жаль, что эта штука займёт своё место на свалке. Трубы могли бы послужить и по назначению.