Страница 2 из 2 ПерваяПервая 12
Показано с 11 по 19 из 19

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

  1. #11
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,168

    По умолчанию

    Цитата Сообщение от nickbeljaev Посмотреть сообщение
    Предлагаю делать мультиплексоры так
    https://drive.google.com/file/d/17aV...ew?usp=sharing
    Не знаю будет ли быстрее или компактнее - надо знать реализацию, но обычно так "правильнее"
    Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?
    И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!
    Последний раз редактировалось Сергей0308; 24.01.2020 в 18:37.
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  2. #12

    По умолчанию

    Цитата Сообщение от Сергей0308 Посмотреть сообщение
    Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?
    И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!
    Да не, в "правильном" варианте в муксе на 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.

  3. #13

    По умолчанию

    Правильно то что экономичнее для конкретной функции. Есть много вариантов решения мультиплексирования. Чаще полезнее использовать в качестве задатчика канала не целочисленное значение, а сразу бегущие битовые стробы. Потом по ним селами выбираются входные данные, и сел-защёлками фиксируются результаты пока обрабатываются другие.
    Изображения Изображения
    Последний раз редактировалось Серёга Букашкин; 24.01.2020 в 20:12.

  4. #14

    По умолчанию

    Цитата Сообщение от Серёга Букашкин Посмотреть сообщение
    Правильно то что экономичнее для конкретной функции. Есть много вариантов решения мультиплексирования. Чаще полезнее использовать в качестве задатчика канала не целочисленное значение, а сразу бегущие битовые стробы. Потом по ним селами выбираются входные данные, и сел-защёлками фиксируются результаты пока обрабатываются другие.
    Да, интересная конструкция, а ОЛ позволяет входа оставлять пустыми? В прочих ФБД это очень запрещено однако. Я тоже думал про кольцевой буфер на задержках, задержки вообще очень сильный инструмент, интересно как реализованы только, хотелось бы посмотреть.

  5. #15
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,168

    По умолчанию

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

    Мультиплексор и демультиплексор.owl
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  6. #16

    По умолчанию

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

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

  7. #17
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,225

    По умолчанию

    Цитата Сообщение от ShveikOff Посмотреть сообщение
    Можно ли сделать это проще?
    смотря что считать простотой, выкладываю "монстра", ни каких ретайнов, ни какого построение логических схем, для таблички рецептов сгенерированной случайным образом
    Код:
    [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

    среди успешных людей я не встречала нытиков
    Барбара Коркоран

  8. #18
    Пользователь Аватар для Сергей0308
    Регистрация
    25.06.2011
    Адрес
    Галактика Андромеды (M31)
    Сообщений
    8,168

    По умолчанию

    Цитата Сообщение от nickbeljaev Посмотреть сообщение
    Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.
    По "вашему" принципу оптимальным получится только для количества входов 2 в степени 1 и более, то есть для большинства случаев будет неоптимальным, если рассматривать все возможные варианты, "наш" вариант можно легко обрезать до необходимого количества входов, например до 18, и Вы наверно невнимательно прочитали мой 11 пост.
    Вы слышали такое: "Гладко было на бумаге, да забыли про овраги", я тоже когда вижу недостатки в вашем решении могу не промолчать!
    Так что придумывайте сразу нормальные элементы(макросы), которые будут иметь преимущества не в теории, а на практике, то есть на 4, 8, 16, 32 входа и все(можно за исключением последнего) с расширением(без применения дополнительных элементов), пока на практике не вижу преимущества, даже наоборот, надеюсь понятно объяснил?!
    Последний раз редактировалось Сергей0308; 26.01.2020 в 10:47.
    Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
    справиться с проблемами, либо это не твои проблемы.

  9. #19

    По умолчанию

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

Страница 2 из 2 ПерваяПервая 12

Похожие темы

  1. можно ли сделать вывод списков переменных на печать или в файл?
    от Серёга Букашкин в разделе Среда программирования OWEN Logic
    Ответов: 14
    Последнее сообщение: 05.06.2021, 15:07
  2. Ответов: 3
    Последнее сообщение: 06.05.2019, 18:30
  3. Можно ли сделать автоматическое приведение типов?
    от Владимир Ситников в разделе Среда программирования OWEN Logic
    Ответов: 7
    Последнее сообщение: 01.02.2016, 10:29
  4. Ответов: 20
    Последнее сообщение: 18.04.2012, 17:01
  5. какая скада проще
    от Александр Игоревич в разделе Master SCADA 3
    Ответов: 2
    Последнее сообщение: 29.07.2009, 08:11

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •