OberonCore
https://forum.oberoncore.ru/

Oberon & bitfields & unions
https://forum.oberoncore.ru/viewtopic.php?f=30&t=3051
Страница 2 из 4

Автор:  Info21 [ Среда, 08 Декабрь, 2010 07:51 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Galkov писал(а):
те кто это придумывал - вовсе не дураки
Опыт показывает, что подобное утверждение каждый раз нуждается в отдельном доказательстве. Увы.

Экстраполируя, опять же, опыт, следует ожидать, что эта внешняя задачка -- результат типичного рукосуйства. С большой вероятностью.

Если задача изначально заточена на рукосуйство, то и инструмент она требует соответствующий, рукосуйский.
Вот и всё.

Автор:  Александр Ильин [ Среда, 08 Декабрь, 2010 08:10 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
Но в плане оберона у меня конечно руки-крюки. Наверняка как-то элегантней можно.
Немного доработал ваш код.
Код:
PROCEDURE JustDoIt (VAR i: LONGINT);
BEGIN
   IF ODD(i) = ODD(i DIV 2) THEN (* bit0 = bit1? *)
      IF ODD(i) THEN (* bit0 = 1? *)
         DEC(i) (* bit0 := 0 *)
      ELSE
         INC(i) (* bit0 := 1 *)
      END
   END
END JustDoIt;
UPD: Исправил опечатку в комментарии.

Автор:  Евгений Темиргалеев [ Среда, 08 Декабрь, 2010 09:29 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
Я кстати, не понял причины почему нет XOR'а в операциях над множеством ну и для логических выражений.
XOR --- это симметрическая разность множеств /. Она есть везде, начиная с Оберона. В общем, без комментариев.

Автор:  Александр Ильин [ Среда, 08 Декабрь, 2010 09:34 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
Я кстати, не понял причины почему нет XOR'а в операциях над множеством ну и для логических выражений.
XOR для логических выражений есть: #.

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 09:42 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Александр Ильин писал(а):
Alexey Veselovsky писал(а):
Я кстати, не понял причины почему нет XOR'а в операциях над множеством ну и для логических выражений.
XOR для логических выражений есть: #.

Спасибо. Я страшный тормоз.
Следовательно мой код превращается в такое:
Код:
PROCEDURE JustDoIt (i:LONGINT) : LONGINT;
VAR
    b0, b1 : BOOLEAN;
    j : SET;
BEGIN
    j := SYSTEM.VAL(SET, i);
    b0 := 0 IN j;
    b1 := 1 IN j;
    IF b0 # b1 THEN
        j:=j+{0}
    ELSE
        j:=j-{0};
    END;
    RETURN SYSTEM.VAL(LONGINT, j);
END JustDoIt;

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 09:45 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Евгений Темиргалеев писал(а):
Alexey Veselovsky писал(а):
Я кстати, не понял причины почему нет XOR'а в операциях над множеством ну и для логических выражений.
XOR --- это симметрическая разность множеств /. Она есть везде, начиная с Оберона. В общем, без комментариев.

XOR это не симметрическая разность множеств.
Код:
{0}/{0} = {}
{0} XOR {0} = {1 .. 31}

Автор:  Илья Ермаков [ Среда, 08 Декабрь, 2010 09:58 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

{0} XOR {0} тоже = {}

XOR любых двух одинаковых значений даёт {}, сиречь 0000...

Автор:  Евгений Темиргалеев [ Среда, 08 Декабрь, 2010 09:59 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
XOR это не симметрическая разность множеств.
Код:
{0}/{0} = {}
{0} XOR {0} = {1 .. 31}
1 XOR 1 = 0
1 XOR 1 = 0FFFFFFFEH
Где правильно?

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 10:08 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Да, похоже я не прав.

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 11:13 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Но при всём при том, сишный вариант понятней всего, т.е. по коду без коментариев понятно что собственно хотел сказать автор.

Если представить себе LONGINT как массив булевых значений. Т.е. мы имеем операцию индексации (пусть она будет {} ), а над значениями допустимы все логические операции, тогда весь код свелся бы к такому:
Код:
i{0} := i{0} # i{1}

Что, IMHO, ясно и понятно.

Какие вы видите минусы у подобного подхода?

Автор:  Евгений Темиргалеев [ Среда, 08 Декабрь, 2010 11:52 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
Но при всём при том, сишный вариант понятней всего, т.е. по коду без коментариев понятно что собственно хотел сказать автор
...
Какие вы видите минусы у подобного подхода?
Вы считаете, что код
Код:
  Counter.bit0 ^= Counter.bit1; // и всего делов
или
Код:
i{0} := i{0} # i{1}
однозначно говорит, что решена задача viewtopic.php?p=55228#p55228
Galkov писал(а):
Последовательность битов от датчика (00 -> 01 -> 11 -> 10) надо сделать нормальной: (00 -> 01 -> 10 -> 11).
Хехе... А, по-моему, он просто короткий. И без комментариев (постановки задачи) хрен поймешь, что-либо сверх того, что автор решил заксорить первый бит с нулевым.

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 12:07 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Евгений Темиргалеев писал(а):
Хехе... А, по-моему, он просто короткий. И без комментариев (постановки задачи) хрен поймешь, что-либо сверх того, что автор решил заксорить первый бит с нулевым.

Там хотя бы это понятно сразу. Т.е. что именно что ксорят первый с нулевым. Т.е. ясно КАК, но не ясно ПОЧЕМУ. Это уже много лучше нежели не ясно как и не ясно почему.

Автор:  Galkov [ Среда, 08 Декабрь, 2010 12:27 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Алексей, сказать честно, мне думается, что нужен иной базовый тип BIT, отличающийся от BOOLEAN своей НЕ ленивостью в логических операциях. Хотя, надо еще подумать, конечно же...
Причем, введенный на уровне АСТ (еще до аппаратно-зависимой части). Вот я же не просто смотрю, на написанную Евгением формулу под эпиграфом "я бы предположил, что в такие". Пытаюсь понять почему. Все правильно - именно в такие, если минимальный_размер_данных=много_битов, а тип BOOLEAN - только заготовка для условных переходов... Посмотрите - мой код на АСМе значительно больше походит на исходную формулу с битами, чем на то, во что ее превратит компилятор в АСТ

Илья Евгеньевич, специально к Вам вопрос: Вам же нравилась синтаксическая конструкция slice из Go (кажется...) :D

Мне представляется, что предложенный Алексеем SUBSET имеет slice в качестве наименьшего общего кратного. Не только для битовых массивов, но и для остальных - тоже.
Мне даже больше кажется - ссылочные переменные тоже этим slice-ом могли бы обобщиться
Ну посмотрите на какой-нибудь (сейчас под рукой нет) search из AD - в качестве VAR-переменной подставляется node.right - типичный "кусочек" записи node. И это эффективно срабатывает - алгоритму пофиг какой "кусочек" подставляли... хучь правый, хучь левый.
А дальше, внутри процедуры - от этой эффективности уже и след простыл, несколько раз один и тот же код переписывается. Только потому, что ссылочных переменных явно нет (но они на самом-то деле есть, но только как аргументы процедуры)

Илья, расскажите свои мысли про slice, ну и отношение к возможности его обобщения.

Автор:  Евгений Темиргалеев [ Среда, 08 Декабрь, 2010 12:29 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Alexey Veselovsky писал(а):
Т.е. ясно КАК, но не ясно ПОЧЕМУ. Это уже много лучше нежели не ясно как и не ясно почему.
КАК без ПОЧЕМУ не "много лучше", а почти также плохо.

Автор:  Galkov [ Среда, 08 Декабрь, 2010 12:40 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

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

Не ну порог вхождения в тему всегда есть... Ну как же без этого.
Посмотрите на вставку в какое-нибудь RB-дерево - нифига ведь непонятно. Без букварей-то.
И это не есть плохо. Потому-что буквари читать надо.

Автор:  Илья Ермаков [ Среда, 08 Декабрь, 2010 12:51 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Galkov писал(а):
Илья Евгеньевич, специально к Вам вопрос: Вам же нравилась синтаксическая конструкция slice из Go (кажется...) :D
...
Илья, расскажите свои мысли про slice, ну и отношение к возможности его обобщения.


Ну, моя мысль и практика простая - использовать интерфейс, подобный блэкбоксовому Files.File, для работы с любой двоичной памятью, независимо от её типа. В сочетании с процедурами, примеры которых я приводил здесь: viewtopic.php?f=2&t=2006

Это исключительно библиотечное решение. Это безопасное решение (невозможно испортить память помимо самого двоичного региона, с которым работаем). Это решение позволяет не импортировать SYSTEM практически нигде. Немного подумав, можно решить всё, что требуется по работе с двоичной памятью.

Это не для случая микроконтроллерной встроенки. Это для обычного системного и серверного ПО. Когда библиотечность решения даёт мизер накладных расходов по сравнению с латентностью ввода-вывода и проч.

К slice я не выказывал никаких эмоций, я просто выразил "узнавание": ага, ребята решают ту же проблему (безопасная работа с двоичной памятью), для той же ниши (серверное ПО), похожим путём, впаивая в язык похожие штуки.
Но у меня рулят КП+библиотеки :)

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 12:56 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

А кстати, почему чтобы работать с LONGINT как с SET я обязан импортировать SYSTEM? Где тут опасность?

Автор:  Илья Ермаков [ Среда, 08 Декабрь, 2010 13:06 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Да нет, не обязаны!
Но чтобы разные структуры сериализовать в/из байт, обычно приходится.

Автор:  Alexey Veselovsky [ Среда, 08 Декабрь, 2010 14:01 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Илья Ермаков писал(а):
Да нет, не обязаны!
Но чтобы разные структуры сериализовать в/из байт, обычно приходится.

Как так не обязан? А как мне из LONGINT сделать SET? Ведь к LONGINT не применымы SET-операции.

Автор:  Александр Ильин [ Среда, 08 Декабрь, 2010 15:01 ]
Заголовок сообщения:  Re: Oberon & bitfields & unions

Цитата:
А кстати, почему чтобы работать с LONGINT как с SET я обязан импортировать SYSTEM? Где тут опасность?
Alexey Veselovsky писал(а):
Ведь к LONGINT не применымы SET-операции.
Я так понимаю, вы сами себе ответили? Или нужно ещё подробнее про строгую типизацию?

Страница 2 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/