Зачем нужны отдельные fGT/fADD, когда есть GT и ADD?
Точно так же и остальные.
Можно сделать, чтобы был просто блок ADD, а фактическая реализация выбиралась исходя из типов данных, поступающих на вход?
Вид для печати
Зачем нужны отдельные fGT/fADD, когда есть GT и ADD?
Точно так же и остальные.
Можно сделать, чтобы был просто блок ADD, а фактическая реализация выбиралась исходя из типов данных, поступающих на вход?
Да особенно когда на один вход прицепил буля и на другой флат ,случайно ..Не там автоматизируете ....однако .С имеющими возможностями написание средней сложности проекта(несколько десятков элементов и фб) на ПР занимает несколько часов ,а вы думаете что с автоматизацией нарисования разработка сократится до минут ,но при этом потратите дни при отладки на обьекте ,вылавливая баги не от алгоритмических ошибок ,а от описок ....
Я уже не говорю о международных стандартах (МЭК) ,которые все это регламинтируют ,и которые все одинаково понимают глядя на те или иные элементы ,как они работают ...
Возможности отладки/тестирования в OL действительно хромают. Но это совсем другой вопрос. А в остальном, среда не должна мешать создавать программу.Цитата:
Сообщение от rovki
Алгоритмические же ошибки на раз появляются, когда слишком много держишь в голове. Именно по-этому я и хочу упразнить блоки fGT, fADD, научить SEL работать с BOOL/FLOAT, и тем самым получить более-менее удобный конструктор, когда не нужно задумываться "а какой у нас там тип входа/выхода/результата". Надо GT -- поставили.
А вот вы скажите что-нибудь о МЭК. Там-то как раз и пропагандируется подход: "блок ADD работает с числовыми типами данных". Да, в стандарте есть "ADD_INT" и "ADD_FLOAT", но никто же их не использует. Все ставят ADD и всего делов.Цитата:
Сообщение от rovki
Я к чему: бросаться словами "МЭК" все горазды.
А текущие "возможности OL по добавлению GT -> TO_FLOAT -> MUL(0, ...)" это просто прорыв. И это в 2016 году.
Честное слово, не вижу сложностей с реализацией, а вот пользу для пользователей -- вижу.
Использовать POW(-1, N) для того, чтобы генерировать -1 или 1? Это явно нецелевое использование ресурсов. SEL намного понятнее, и без всяких ошибок округления.
Неужели на уровне железа там вообще нет возможности сделать fSEL?
пожалуй поддержу Анатолия. всем удобно, Вам не удобно... вторая тема от Вас с нано-новшествами...
так упраздните. напишите свой овенлоджик, делов-то, с таким энтузиазмом.Цитата:
Сообщение от vladimirisitnikov
Уважаемые друзья!
Призываю вас к терпимости.
У каждого из нас есть своё мнение о данном продукте, и мы, компания ОВЕН, хотели бы слышать все ваши идеи, какими бы фантастическими они не являлись.
Поддержу vladimirisitnikov. Зачем изобретать велосипед.
ВЫ О каком велосипеде ?С ПР и ОЛ работаем 6 лет...Схема(элементы и связи составляющие ее) должна быть читабельна даже с листа ,а не когда нажимаешь кнопочки ,комментарии,свойства ...Сразу видно ,что ТС не был никогда электронщиком ,сразу в программисты и привык писать схемы (проекты) ,а не рисовать , ну тогда лучще начать с модернизации кодесис и ПЛК....:rolleyes:Цитата:
Сообщение от Andrew_Stranger
не надо этого. Ни в коем случае не надо. FLOAT должен быть FLOATом, INT должен быть INTом. И их надо четко разделять.Цитата:
Сообщение от vladimirisitnikov
А то что FSEL нужен как ФБ согласен.
Ну в голове надо держать всю программу. Такова увы, нелегкая программерская доля. А ошибок в случае универсальных блоков будет на порядок больше.Цитата:
Алгоритмические же ошибки на раз появляются, когда слишком много держишь в голове. Именно по-этому я и хочу упразнить блоки fGT, fADD, научить SEL работать с BOOL/FLOAT, и тем самым получить более-менее удобный конструктор, когда не нужно задумываться "а какой у нас там тип входа/выхода/результата". Надо GT -- поставили.
Вот вы сейчас говорите про "надпись на квадратике" или про его сущность?Цитата:
Сообщение от Мордорец
Приведу пример: в выражении 2+2*2 знаки + и * не содержат явных упоминаний что они умножают и складывают.
Нет специальных знаков для "сложения целых" и "сложения дробных".
И ничего, математики живут как-то, не путаются.
А по-вашему, почему-то нужно разделять float_add и int_add. Зачем?
С чего бы это?Цитата:
Сообщение от Мордорец
Можете привести пример ошибки, которая будет возникать при универсальном add/sel, и не будет возникать (или реже) на типизированных add/fadd?
именно про сущность. Потому как 2(FLOAT) и 2 (INT) это совершенно разные числа, которые не в коем случае нельзя между собой смешивать. Это сродни тому что выполнить 10(HEX) + 10 (DEC) =???. Математики не путаются, а вот для программиста (особенно ассемблер) это стандартная ошибка, которая кстати порой довольно сложно отлавливается. Сейчас OL надежно защищен от данных ошибок.Цитата:
Сообщение от vladimirisitnikov
Кто-то запретил складывать разные числа? Как бы ни было, это одно и то же число в разных бинарных представлениях. Для выполнения арифметики предварительно делается type promotion меньшего типа.Цитата:
Потому как 2(FLOAT) и 2 (INT) это совершенно разные числа, которые не в коем случае нельзя между собой смешивать.
26 (DEC) / 1A (HEX). Причём без вариантов.Цитата:
Это сродни тому что выполнить 10(HEX) + 10 (DEC) =???.
Как видите, я без проблем сложил десятичное и шестнадцатеричное. Но если бы вы попросили меня сделать это столбиком игнорируя шестнадцатеричность, то я бы сделал, и это оказалось бы на вашей совести, ибо ассемблер. А в высокоуровневом ЯП между нами был бы ещё человек, который каждый раз переспрашивал у вас, в какой системе счисления вы передаёте мне операнды, и если система не десятичная, то переводил бы их для меня.Цитата:
а вот для программиста (особенно ассемблер) это стандартная ошибка
Ни в одном типичном ЯП сегодня вы не сможете допустить ошибку, о которой вы говорие, без явного поразрядного приведения типов. Эта проблема решена очень давно, и сегодня я спокойно пишу 2.0f + 2, получая 4.0f.Цитата:
Сейчас OL надежно защищен от данных ошибок.