Да, интересная конструкция, а ОЛ позволяет входа оставлять пустыми? В прочих ФБД это очень запрещено однако. Я тоже думал про кольцевой буфер на задержках, задержки вообще очень сильный инструмент, интересно как реализованы только, хотелось бы посмотреть.Сообщение от Серёга Букашкин
Предлагаю делать мультиплексоры так
https://drive.google.com/file/d/17aV...ew?usp=sharing
Не знаю будет ли быстрее или компактнее - надо знать реализацию, но обычно так "правильнее"
Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?Предлагаю делать мультиплексоры так
https://drive.google.com/file/d/17aV...ew?usp=sharing
Не знаю будет ли быстрее или компактнее - надо знать реализацию, но обычно так "правильнее"
И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!
Последний раз редактировалось Сергей0308; 24.01.2020 в 18:37.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Да не, в "правильном" варианте в муксе на 4 входа 5 блоков, на 8 входов 10 блоков, на 16 входов 1+2+4+8+4 = 19 блоков, на 32 входа 1+2+4+8+16+5 = 36 блоков итд, а сколько блоков в "неправильном" муксе на 32 входа? не 64 часом? Вероятность того что "правильный" мукс еще и будет жрать меньше тиков крайне высока, особенно если каждый блок в любом случае выполняется. И еще "битовый" мус позволяет использовать цикличность то есть если на него подавать выход счетчика он будет перебирать значения по циклу, в ФБД это очень полезное свойство, например потактовые циклы так делают.
Вообще в программировании очень не хорошо изобретать велосипеды, обычно все задачи уже решены до нас и гораздо лучше чем мы сами это сможем, поэтому везде где можно надо изучать источники - экономит много времени и человеческого и машинного. Я этот мукс естественно не сам придумал - он стандартный, я еще не родился когда такая схема работала, просто надо все время учится у предшественников - это окупается.
Последний раз редактировалось nickbeljaev; 24.01.2020 в 19:31.
Желаю Вам успехов в изучении достижений предков и их повторении, надеюсь, когда это окупится и начнёт приносить прибыль, поделитесь с окружающими?!
Вот у меня ещё имеются булевы мультиплексор и демультиплексор, можете пользоваться, пока Вы у предшественников ничему не научились(имею ввиду, как правильно делать):
Мультиплексор и демультиплексор.owl
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.
смотря что считать простотой, выкладываю "монстра", ни каких ретайнов, ни какого построение логических схем, для таблички рецептов сгенерированной случайным образомпоследняя колонка это номер рецептаКод:[21. 24. 30. 36. 41. 44. 1.] [21. 26. 29. 35. 40. 46. 2.] [20. 25. 31. 35. 40. 45. 3.] [21. 26. 29. 33. 40. 44. 4.] [19. 25. 32. 35. 43. 44. 5.] [22. 26. 29. 35. 39. 44. 6.] [21. 26. 30. 35. 41. 44. 7.] [20. 23. 31. 36. 40. 46. 8.] [19. 25. 29. 35. 40. 45. 9.] [21. 25. 32. 36. 40. 44. 10.] [19. 26. 30. 35. 40. 46. 11.] [19. 25. 31. 34. 40. 46. 12.] [20. 25. 31. 35. 40. 45. 13.] [22. 24. 30. 37. 40. 46. 14.] [20. 23. 30. 35. 42. 46. 15.] [21. 24. 29. 34. 41. 45. 16.]
займет некоторое время получение коэффициентов и в проект просто ввод этих значений
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Ваши права
