На вопрос нельзя дать однозначный ответ, мы не знаем твоих субъективных ощущений от разных мониторов, особенности твоего зрения, твои привычки работы, наконец твои финансовые возможности.
Поскольку я также не знал, какой монитор выбрать, решил начать с относительно недорогого китайского монитора IPS 28 дюймов 2К за 15 000 руб.; с учётом того что использую довольно старый компьютер; ну и подумал, что если не подойдёт, отдам детям. Но пока что прекрасно подошло.
spoiler
Пришлось ножку монитора буквально допиливать напильником :))) в остальном проблем нет, год полет нормальный
eji001, у вас есть два пути:
Делать самостоятельно или нанять специалиста.
В первом случае делаете до тех пор, пока не возникает конкретная проблема, с которой самостоятельно не удается справиться; с этим конкретным вопросом приходите сюда. Например, «я выбрал вот такое решение. Попробовал его вот так, ожидал вот это, а получается вот такая фигня. Вот код, вот так запускаю, вот traceback с ошибкой. Что я делаю не так?»
Вы экономите деньги, тратите свое время, силы, приобретаете опыт разработки и возможно приобретаете продукт.
Во втором случае вы экономите свои время и силы, платите деньгами и риском их потери. Приобретаете опыт менеджмента и возможно приобретаете продукт.
eji001, в идеале хорошо приводить минимальную модель, демонстрирующую вашу проблему. Весь проект не надо, если это не понадобится по ходу обсуждения в комментариях.
Для верстки и прочего фронтэнда (html/css/js) удобно использовать <codepen src="Ссылка на codepen"/>
Кроме того, конкатенация строк тут, мне кажется, может сыграть злую шутку.
Я бы советовал отдельной функцией формировать список с нужными объектами и затем другой функцией при помощи метода join собирать итоговую строку.
А логика пусть просто берет результат действий функции и печатает.
А вот эти последовательные конкатенации трудно отследить; мало ли что там внутри исходной строки было? Вы думаете, что пустая была, а там хвосты от предыдущих конкатенаций.
В вашем коде, вероятно, некорректно приведены отступы. От этого логическая структура кода сбивается и не понятно на глаз, где и кто и что и за чем.
Я бы советовал отдельно формировать нужные строки в функциях, и отдельно писать логику, внутри которой функции только вызываются.
Тогда визуальная структура строк не будет сбивать структуру логики.
def print_hi(name):
print(f'Hi, {name}')
if __name__ == '__main__':
while input('Продолжать? Y или N').lower() == 'y':
print_hi('PyCharm')
print('Конец программы')
s4q, в действительности во втором мы получим только точки, подтянутые к оси АБ. Но там много нюансов: например, их порядок. Но это можно их отсортировать по сумме координат, а если ось ляжет неудачно, то там еще придется пошаманить.
И например могут попасться точки вне АБ, это тоже надо убирать.
Кстати, по-моему для обоих случаев вначале можно повыкидывать все, у которых координата х вне АхВх, а координата y вне AyBy.
s4q, зачем?
Ну, в том смысле, какую цель в итоге хотим достичь?
Потому что можно оптимизировать три разных параметра:
стоимость
время
качество (вероятность утраты/повреждения/ошибки)
И чем-то придется пожертвовать. И для каждого варианта свои способы решения.
Самый тупой способ - получаем функцию оси - прямой, проходящей через А и Б, потом можно сделать поворот, затем для каждой из промежуточных точек опускаем перпендикуляр на ось и измеряем его.
Фильтруем точки, у которых координата x вне АБ. Сортируем оставшиеся точки по длинам перпендикуляров по asc и отбираем нужное количество.
Другой вариант - для каждой точки меряем расстояния до А и до Б, затем сортируем их по сумме этих расстояний. Те, у которых сумма ближе всего к отрезку АБ, и есть самые подходящие.
+