Можно ли сделать проще?

[nickbeljaev]

Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?
И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!

Да не, в "правильном" варианте в муксе на 4 входа 5 блоков, на 8 входов 10 блоков, на 16 входов 1+2+4+8+4 = 19 блоков, на 32 входа 1+2+4+8+16+5 = 36 блоков итд, а сколько блоков в "неправильном" муксе на 32 входа? не 64 часом? Вероятность того что "правильный" мукс еще и будет жрать меньше тиков крайне высока, особенно если каждый блок в любом случае выполняется. И еще "битовый" мус позволяет использовать цикличность то есть если на него подавать выход счетчика он будет перебирать значения по циклу, в ФБД это очень полезное свойство, например потактовые циклы так делают.
Вообще в программировании очень не хорошо изобретать велосипеды, обычно все задачи уже решены до нас и гораздо лучше чем мы сами это сможем, поэтому везде где можно надо изучать источники - экономит много времени и человеческого и машинного. Я этот мукс естественно не сам придумал - он стандартный, я еще не родился когда такая схема работала, просто надо все время учится у предшественников - это окупается.

[Сергей0308]

Да не, в "правильном" варианте в муксе на 4 входа 5 блоков, на 8 входов 10 блоков, на 16 входов 1+2+4+8+4 = 19 блоков, на 32 входа 1+2+4+8+16+5 = 36 блоков итд, а сколько блоков в "неправильном" муксе на 32 входа? не 64 часом? Вероятность того что "правильный" мукс еще и будет жрать меньше тиков крайне высока, особенно если каждый блок в любом случае выполняется. И еще "битовый" мус позволяет использовать цикличность то есть если на него подавать выход счетчика он будет перебирать значения по циклу, в ФБД это очень полезное свойство, например потактовые циклы так делают.
Вообще в программировании очень не хорошо изобретать велосипеды, обычно все задачи уже решены до нас и гораздо лучше чем мы сами это сможем, поэтому везде где можно надо изучать источники - экономит много времени и человеческого и машинного. Я этот мукс естественно не сам придумал - он стандартный, я еще не родился когда такая схема работала, просто надо все время учится у предшественников - это окупается.

Желаю Вам успехов в изучении достижений предков и их повторении, надеюсь, когда это окупится и начнёт приносить прибыль, поделитесь с окружающими?!
Вот у меня ещё имеются булевы мультиплексор и демультиплексор, можете пользоваться, пока Вы у предшественников ничему не научились(имею ввиду, как правильно делать):

Мультиплексор и демультиплексор.owl

[nickbeljaev]

Желаю Вам успехов в изучении достижений предков и их повторении, надеюсь, когда это окупится и начнёт приносить прибыль, поделитесь с окружающими?!
Вот у меня ещё имеются булевы мультиплексор и демультиплексор, можете пользоваться, пока Вы у предшественников ничему не научились(имею ввиду, как правильно делать):

Мультиплексор и демультиплексор.owl

Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.

[Сергей0308]

Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.

По "вашему" принципу оптимальным получится только для количества входов 2 в степени 1 и более, то есть для большинства случаев будет неоптимальным, если рассматривать все возможные варианты, "наш" вариант можно легко обрезать до необходимого количества входов, например до 18, и Вы наверно невнимательно прочитали мой 11 пост.
Вы слышали такое: "Гладко было на бумаге, да забыли про овраги", я тоже когда вижу недостатки в вашем решении могу не промолчать!
Так что придумывайте сразу нормальные элементы(макросы), которые будут иметь преимущества не в теории, а на практике, то есть на 4, 8, 16, 32 входа и все(можно за исключением последнего) с расширением(без применения дополнительных элементов), пока на практике не вижу преимущества, даже наоборот, надеюсь понятно объяснил?!

[nickbeljaev]

По "вашему" принципу оптимальным получится только для количества входов 2 в степени 1 и более, то есть для большинства случаев будет неоптимальным, если рассматривать все возможные варианты, "наш" вариант можно легко обрезать до необходимого количества входов, например до 18, и Вы наверно невнимательно прочитали мой 11 пост.
Вы слышали такое: "Гладко было на бумаге, да забыли про овраги", я тоже когда вижу недостатки в вашем решении могу не промолчать!
Так что придумывайте сразу нормальные элементы(макросы), которые будут иметь преимущества не в теории, а на практике, то есть на 4, 8, 16, 32 входа и все(можно за исключением последнего) с расширением(без применения дополнительных элементов), пока на практике не вижу преимущества, даже наоборот, надеюсь понятно объяснил?!

Если все блоки выполняются то 17 и 18 будет быстрее, тут я не спорю.