OberonCore

Вопрос в том, почему нет функции которая бы преобразовывала конкретно LONGINT<->SET и которая была бы доступна сразу, без SYSTEM.

Либо зачем вообще введен тип SET, если можно было просто его операции определить для LONGINT.

Наверно не уделили этому внимание. В КП об это подумали - BITS

Ну, разделите на два INTEGER (ASH или DIV-MOD).

Суммируя написанное, гораздо сложней - это так:

Конечно до такого надо додуматься, но ведь до того, что XOR битов решает нужную задачу - тоже надо додуматься. Важно лишь, кто какими категориями мыслит.

Вообще трудно представить себе прикладную задачу, в которой естественным образом вылезла бы такая манипуляция.
А раз неестественно, то и нефик жаловаться.

Вообще то это вроде как решение именно что сугубо прикладной задачи.

Задачи, пропущенной через чьи-то мозги.

Вот же она: viewtopic.php?f=12&t=2767&start=0
По моему нормальная самая что ни на есть практическая инженерная задача.

А. Август я пропустил.

Но задач, не пропущенных через чьи-то мозги, не бывает. Особенно практических.
Мой опыт таков, что подобные задачи уже искажены интерпретациями. Исключений я не встречал. Хотя исключить исключения нельзя.

Ну хорошо. А как по Вашему должно выглядеть это понимание. Предложите - ЧТО ДОЛЖЕН ПОНЯТЬ РАЗРАБОТЧИК, касаемо этой конкретной задачи.
И после этого можно будет делать выводы, что более понятно, а что менее.
Давайте разберемся по- честному. Сказать "а почти также плохо" можно практически всегда. Да не "практически", а вообще - всегда. Только смысла у такой предположительной беседы - нет никакого.

Вот как я себе этот процесс представляю (у меня есть уже разные этой задачи, но я буду говорить конкретно про то, чего сегодня уже имеет серьезную наработку в эксплуатации):

• У меня есть некий датчик - два вышеописанных сигнала
• Собрана некая апаратная поддержка (4 корпуса рассыпухи), добавляющая еще 4 бита к подсчету
• И вот внутри программы у меня есть возможность принять вышеозначенные 6 битов, и моей локальной задачей является: по результатам регулярного (16КГц) анализа этих 6 битов получить, скажем, INTEGER (мне правда достаточно Int24) со смыслом реальной физической координаты чего-там, к чему датчик физически и закреплен.

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

Далее, я просто записываю эти "еще более простые шаги" как я их понимаю. Возможно, они могут быть другими - так скажите какими.
Тогда в обсуждении появится логика. Чего и хотелось бы.
А не соревнование - "чья религия более продвинута". Чего НЕ хотелось бы.

Вот они, эти "атомы":

1. "Нормализуем" эти 6 битов. Просто функциональное преобразование - ничего более. Эту функцию (XOR) для младшего бита я и записал. Остальные биты не меняются.
2. Выделяем 6 младших битов из предыдущего значения счетчика (который INTEGER)
3. Вычисляем 6-битную разность нормализованных 6 битов (по п.1), и младших 6 битов счетчика (по п.2)
4. Делаем знаковое расширение этой 6-битной разности (по п.3). Т.е., бит_5 распространяем влево "до упора". Получится INTEGER.
5. Прибавляем к предыдущему значению счетчика нашу разность (по п.4)
6. ВСЕ

Было бы интересно послушать - в чем я (возможно) неправ, сделавши именно такое разбиение задачи. Ну или - описавши это разбиение именно такими словами.
И заодно можно протестировать "на понимаемось" соответствующий код на Обероне

А то как говорить, что нет ничего понятнее Оберона - вот они мы все
Как бы я сильно и не спорю.
Но проверять на деле - тоже иногда полезно.
Настаиваю на полезности такового мероприятия. Много нового узнать можно

Написано здесь: viewtopic.php?p=55286#p55286

Должен признаться, что я и раньше не понимал и теперь не понимаю в чем тут "задача". То есть, я не понимаю, где в изложении viewtopic.php?p=50291#p50291 задача, а где решение. Ну и фиг с ним, это не важно.
Просто хотел заметить, что 2^6=64. Т.е., 64-элементного массива хватит, что бы получить "нормализацию" простым индексированием массива, без XOR'ов.

Там не написано, ЧТО ДОЛЖЕН ПОНЯТЬ РАЗРАБОТЧИК на самом деле по Вашему личному мнению. Свое мнение я изложил - ЧТО он должен понять то, что это очень простое функциональное (безо всяких предысторий) преобразование. А Вы своего - не изложили.

Ну да, хватит наверное.
Хотя реальная задача по-проще будет (см три асм-команды), чем использование константного массива.

Peter, а не хотите случайно заметить, что внедрение в код константного массива - еще тот геморрой

Ну так индексация массива, насколько я понимаю, - это две команды на ассемблере. Но не поручусь, да и ассемблеры разные бывают.
А про гемморой в условиях ничего не было сказано

P.S. А мы про сколько бит речь-то ведем? Я - про 6.

я вроде бы не пишу в таких объёмах, чтобы было невозможно прочитать и попытаться понять. viewtopic.php?p=55286#p55286 Говоря "другими" словами, по моему личному мнению:
1) разработчик ДОЛЖЕН ПОНЯТЬ УСЛОВИЕ ЗАДАЧИ.
2) Если никаких других документов кроме кода у него нет, то для приведённого решения ему поможет только комментарий.

Где-то выше тов. Galkov сетовал, что ни один компилятор не сделает этих трёх асм-команд из приведённого им сишного кода. Т.что, с условиями явно что-то не чисто. Хотя бы в плане того, на чём писать решение.

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

Я легко могу сказать ровно Вашу фразу в адрес любого кода на любом языке. Например, ОС Оберон - хоть ты засмотрись на эти коды, непонятно будет совершенно. И, чтобы было понятно, Вирт четыре сотни страниц написал. Прочитай эти четыре сотни страниц - и закодируй это на ассемблере. Вполне подъемная задача за пару человеко-лет. Снова убери текст Вирта, и получится Ваша фраза: "Непонятно в обоих случаях"
И что нам теперь - делать вывод об одинаковой [не]понимаемости Оберона и ассемблера Нет же конечно....
И так - для любой задачи, сложнее сложения двух чисел. И для любого языка, хоть на брэйнфаке пиши - будет непонятно в обоих случаях

Но нас-то интересует сравнение языков в плане восприятия человеком. А ЧТО тогда можно использовать для сравнения ???
Вот я и выдвинул гипотезу, что те самые мелкие детали алгоритма, которые еще независимы от языка реализации.
Смотрим реализацию на разных языках, и сравниваем время, необходимое нам для въезжания.
Посмотрим в мануал Вирта - он же не расписывает назначение каждого оператора. Но расписывает до таких "фрагментов", которые опознаваемы в коде без пояснений. Видимо считая, что если бы это был ассемблер, то расписывать пришлось бы гораздо более детально...

Если Вы считаете, что сравнивать как-то по-другому надо - ну изложите...
Если Вы считаете, что я сделал "разбиение" как-то заточено под асм или C - ну изложите Ваше разбиение
Фраза "И без комментариев (постановки задачи) хрен поймешь, что-либо..." совершенно правильная, и никаких возражений не вызвает.
Но двигаться (в смысле - сравнивать) куда-то надо же

А то получается как в анекдоте: "Вы находитесь на воздушном шаре!!!!......."

У компилятора (любого) есть показатель назначения - эффективность создаваемого им кода.
А еще у компилятора (любого) есть front-end, понимаемость текстов которого человеком также является показателем назначения.
Это два практически независимых показателя компилятора: ни откуда, например, не следует, что лучшая эффективность обязательно потащит за собой меньшую понимаемость. И наоборот.
Да, не сдержался, сетовал - больной зуб это у меня.
Потому-что за многие десятилетия развития IT можно было бы подняться и до кодирования выше среднешкольного. В шахматы компьютер меня обыгрывает на раз. А на килобайте кода я обхожу Бормана (за FPC я уж и не говорю, в силу бессмысленности) в 1.5 раза, не сильно напрягаясь. При всем том, что являюсь тут не более чем любителем. Ну кошмарно большой код в 1К для современных машин...

И ровно никакого отношения это не имеет к понимаемости исходника человеком.
Скажем так, если бы некий компилятор превратил такой код:
даже в две (чем черт не шутит) машинные команды - это еще не повод прыгать от счастья.
Ибо счастие - это когда И в две команды, И человеку сразу все понятно (при определенных условиях: чтобы в других местах не стало менее понятно)

Поэтому желательны разъяснения Вашего "Т.что, с условиями явно что-то не чисто". Синтаксически, фраза означает, что Вы сделали некий вывод из моих "сетований".
Совершенно мне непонятно: какой, и почему.
А выше - это не более чем разъяснения, почему мне непонятно...

Если есть такой компилятор, то он столь сложен внутри, что нужно бы забояться, сколько там может быть ошибок.
(Вон был пример от человека, который работал над унутрями одного из коммерческих оптимизирующих компиляторов - http://oberoncore.ru/wiki/структурирование_промышленного_цикла - а шут его знает, что он там ещё понаворочал в таком духе..)

Есть Хаскель и его компилятор, который в ряде случаев оптимизирует до более эффективного кода, чем С/С++. Однако посмотришь на какую-нибудь новую версию и Change-Log, так какие-нибудь баги правят. Или утечки памяти, или что ещё.

Баги есть и в этих ваших оберонах и блекбоксах, несмотря на их якобы простоту.
И что теперь, вешаться?