Форум сайта python.su
Тут немного другая ситуация. Все приборы находятся радом (длина провода соединяющая приборы не более 15 см), а длина кабеля от приборов до преобразователя не более 30 метров. Да и как я писал выше, этот кабель уменьшал до 20 см.
Офлайн
staxbelэто тоже “ответвление” , и оно может давать отражение. попробуйте всеже последовательно их включить, тогда будет понятно.
а длина кабеля от приборов до преобразователя не более 30 метров
[code python][/code]
Офлайн
PEHDOMПо правде говоря такое соединение мне и в голову не приходило. Сегодня поеду к весам - попробую. Посмотрел в интернете, вроде как имеет право на жизнь такое соединение. Спасибо, как проверю - отпишусь.
Офлайн
staxbelтолько не забудте что концы шины должны быть терминированы, иначе “кина не будет”.
Сегодня поеду к весам - попробую.
[code python][/code]
Офлайн
PEHDOMcorrect_set = [32, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57 ]
xam1816Множество делается через фигурные скобкиcorrect_set = [32, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57 ]
correct_set = {32, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57}
Офлайн
py.user.nextтак это не множество , это список
Множество делается через фигурные скобки
[code python][/code]
Офлайн
PEHDOMНу, так оно называется correct_set, а не correct_list. Ладно название, название не важно, его можно поменять в любой момент на корректное. Тут по сути это всё равно множество в контексте того алгоритма, где оно используется, - проверка на принадлежность. Так что название правильное, использование правильное, только тип неправильный. Так вот операция in для списка имеет временную сложность O(n), в то время как операция in для множества имеет временную сложность O(1). То есть на тысячах, десятках тысяч таких проверок в секунду это будет становиться заметно. Да, и словарь dict() - это тоже множество, только не простое, а нагруженное (к каждому элементу множества прицеплено значение), поэтому и в словаре на тот же миллион элементов поиск будет происходить очень быстро, так как временная сложность та же - O(1). Поэтому там, где идёт поиск элемента, нужно стремиться списки/кортежи сводить к множествам.
так это не множество , это список
Отредактировано py.user.next (Апрель 7, 2021 22:31:21)
Офлайн
py.user.next я в курсе про сложность .Но там опрос раз в 30 секунд, Будем считать что применение множеств это преждевременная оптимизация которая корень всех зол, по мнению товарища Кнута.
[code python][/code]
Офлайн
Это не преждевременная оптимизация. Это ты просто типы все базовые в питоне не знаешь. Множество в питоне ничем не отличается от списка по своей используемости. И для множества даже comprehension есть, настолько оно плотно в питоне сидит. Про преждевременную оптимизацию можно говорить тогда, когда ты, например, вместо кортежей используешь списки там, где мутабельность списков не используется. То есть списки нужно переделывать в кортежи в таких местах, но ты этого не делаешь, потому что это делается потом, перед фиксацией кода.
Так что прочитай книжку какую-нибудь до конца, чтобы потом не рассказывать про Кнута, когда реально просто базовых вещей в питоне не знаешь. Какой Кнут?! Даже не думай о Кнуте! Это всё равно что не зная азбуки лезть бороздить просторы космоса или пятилетние романы писать.
Вот это всё прочитай
https://docs.python.org/3/library/stdtypes.html
https://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset
Отредактировано py.user.next (Апрель 8, 2021 21:15:00)
Офлайн
PEHDOMВ последовательном подключение приборы не заработали :-(
Отредактировано staxbel (Апрель 13, 2021 18:06:45)
Офлайн